Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005)
Junichi Uekawa wrote:
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.
v4l2 support could not have been broken, since it was never present.
You were going through a compat layer.... Maybe that's where the
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.
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.
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
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...)
df70b17f88a4d1d8545d3569a1f6d28c6004f9e4 2 Nov 2005 Nonfunctional bttv
d83c671fb7023f69a9582e622d01525054f23b66 1 Nov 2005 (fails to boot due to USB issues)
6e9d6b8ee4e0c37d3952256e6472c57490d6780d 27 Oct 2005 Functional bttv
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
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:
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
#4) Once again, the -git bisection regression testing is the best thing
to do here.