lkml.org 
[lkml]   [2005]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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:

>>>>> 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-11 14:15    [W:0.075 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site