Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junichi Uekawa wrote:

mplayer  tv://1 -tv driver=v4l2
MPlayer dev-CVS--4.0.2 (C) 2000-2005 MPlayer Team
CPU: Advanced Micro Devices Athlon 64 Newcastle,Winchester,San Diego,Venice; Sempron Palermo (Family: 15, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2

bttv currently only supports v4l1. We are still in the process of porting the bttv driver from v4l1 to v4l2. Nickolay is working on it.

Thanks for the info. It's strange since this is a regression
(pre 2.6.14 used to work. New code made it fail).
Do you mean there was a change that broke v4l2 support in bttv ?
Ever since Linux Kernel 2.6.3, I used v4l2 for recording (more
than one and a half years...)

v4l2 support could not have been broken, since it was never present. You were going through a compat layer.... Maybe that's where the regression is. One question -- At exactly what point does this break for you? The git commit key above was from today, but at what point did this LAST work for you? It would be really helpful if you can do a git bisection test, so that we can isolate the trouble patch if in fact it is a regression.
df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv
d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues)
6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv
This info was quite helpful... Looking through gitweb, it looks like the trouble began for you BEFORE Mauro started to send our new patchsets over to akpm. If I am correct, this indicates that the problem patch is from elsewhere in the kernel.

I saw a thread about some i2c related bttv problem... I don't know if that's a red herring or not, but it was also around the time that you say your kernel breaks.

At this point, the best thing that you can do is run a git bisection regression test, like I had previously suggested. Linus has written a HOWTO thread about it a few months ago on LKML. Does anybody know if there is a howto online for git bisection testing? Maybe there's a copy of the thread on kerneltrap.org? just a guess...

If we can narrow this down to the exact patch that is causing the problem for you, it would be a lot easier to deal with.

You might also like to join us in #v4l on irc.freenode.net ... Sometimes it's much quicker to troubleshoot this stuff over irc instead of email.
joined, but currently rebooting sporadically to test different kernels.
Okay, well here are a few other things that I would have you try:

#1) Try using v4l-kernel cvs, and tell us if you still have the problem. Since I think that the problem is occurring for you elsewhere in the kernel, using our code in cvs should yeild no change in behavior. Even though this doesn't sound promising, it can help us to prove whether v4l is responsible for this problem or not:

http://linuxtv.org/v4lwiki/index.php/How_to_build_from_CVS

First, try out latest cvs. Yes, there is still some new code in cvs that we have not yet sent upstream, including some compat_ioctl32.c fixes from Nickolay from this morning.

#2) After testing the latest cvs, then I would ask for you to wipe out the cvs tree and try again, but using older code..... Say, from October first or so, maybe even September first. To do this, follow the same procedure in the wiki-howto above, but add the -D parameter to the cvs checkout command. ( cvs co -D 2005-09-01 -- see man cvs)

I would assume that there will be no difference in behavior between the different cvs versions, but maybe you will find otherwise.

#3) Another thing you can try is to build the current cvs modules against the last known working kernel. If the new cvs modules in the older kernel break it again, then it tells us that some new v4l code IS to blame.

#4) Once again, the -git bisection regression testing is the best thing to do here.

Regards,

Michael Krufky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux