Hi Anisse,
On Thursday 26 April 2012 20:07:21 Anisse Astier wrote:
> Hi,
>
> I'm experiencing a problem with uvcvideo with kernel 3.3.3 and today's
> Linus' tree.
>
> Problem not reproduced in 3.2.15, so this could be labelled as a regression.
>
> See webcam lsusb and (verbose!) dmesg log in attachment, which exhibits
> the problem.
>
> We see lots of error (-18 = -EXDEV), that indicate that URB was too late
> and then dropped, and they add up until we reach the "Failed to resubmit
> video URB" scheduling issue.
Those are USB controller issues. The uvcvideo driver submits URBs with the
URB_ISO_ASAP transfer flag, so the controller should not fail to schedule
them.
> Installed libv4l version is 0.8.6.
> I'm reproducing this with: gst-launch-0.10 --verbose v4l2src ! xvimagesink
> (Skype exhibits the problem too, while it isn't using gstreamer, so it
> really seems to come from kernel. Also, doesn't happen with 3.2)
>
> This is the first part of the problem. The second part is that if I
> restart the webcam with gst-launch after the first failure, I have a
> total freeze, just after these messages in the log (fetched with
> netconsole, I wasn't able to get a panic trace):
>
> [ 191.796217] uvcvideo: Marking buffer as bad (error bit set).
> [ 191.796233] uvcvideo: Marking buffer as bad (error bit set).
> [ 191.796244] uvcvideo: Marking buffer as bad (error bit set).
> [ 191.796252] uvcvideo: Marking buffer as bad (error bit set).
> [ 191.796259] uvcvideo: Frame complete (EOF found).
> [ 191.796265] uvcvideo: EOF in empty payload.
> [ 192.972803] uvcvideo: Marking buffer as bad (error bit set).
> [ 192.972818] uvcvideo: Dropping payload (out of sync).
> [ 194.289463] uvcvideo: Marking buffer as bad (error bit set).
> [ 194.289478] uvcvideo: Frame complete (FID bit toggled).
> [ 194.289486] uvcvideo: Marking buffer as bad (error bit set).
> [ 194.289493] uvcvideo: Frame complete (FID bit toggled).
> [ 194.289499] uvcvideo: Marking buffer as bad (error bit set).
> [ 194.289505] uvcvideo: Frame complete (FID bit toggled).
> [ 194.289511] uvcvideo: Marking buffer as bad (error bit set).
> [ 194.289518] uvcvideo: Frame complete (FID bit toggled).
> [ 194.289524] uvcvideo: Marking buffer as bad (error bit set).
> [ 194.289531] uvcvideo: Frame complete (FID bit toggled).
>
> Last but not least, uvcvideo is un-bisectable because there were a few
> crash-fixes during the 3.3 development cycle. I started bisecting and got
> kernel panics.
Are the kernel panics related to uvcvideo ? There's one known bug introduced
between v3.2 and v3.3 and fixed (before v3.3) in commit
8e57dec0454d8a3ba987d18b3ab19922c766d4bc.
--
Regards,
Laurent Pinchart
On Wed, 02 May 2012 14:24:11 +0200, Laurent Pinchart <[email protected]> wrote :
> Hi Anisse,
>
> On Thursday 26 April 2012 20:07:21 Anisse Astier wrote:
> > Hi,
> >
> > I'm experiencing a problem with uvcvideo with kernel 3.3.3 and today's
> > Linus' tree.
> >
> > Problem not reproduced in 3.2.15, so this could be labelled as a regression.
> >
> > See webcam lsusb and (verbose!) dmesg log in attachment, which exhibits
> > the problem.
> >
> > We see lots of error (-18 = -EXDEV), that indicate that URB was too late
> > and then dropped, and they add up until we reach the "Failed to resubmit
> > video URB" scheduling issue.
>
> Those are USB controller issues. The uvcvideo driver submits URBs with the
> URB_ISO_ASAP transfer flag, so the controller should not fail to schedule
> them.
Yes, it's weird.
So I followed Oleksij's adviced and reverted the following commit groups:
- 66847ef [media] uvcvideo: Add UVC timestamps support, 3afedb9 [media]
uvcvideo: Don't skip erroneous payloads and ed0ee0c [media] uvcvideo:
Fix race-related crash in uvc_video_clock_update()
- ab86e9e [media] uvcvideo: Allow userptr IO mode and 6998b6f [media]
uvcvideo: Use videobuf2-vmalloc
- 3d95e93 [media] uvcvideo: Move fields from uvc_buffer::buf to
uvc_buffer
- c4d99f8 [media] uvcvideo: Ignore GET_RES error for XU controls
- 806e23e [media] uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()
- d0d9748 [media] uvcvideo: Use kcalloc instead of kzalloc to allocate
array
None of this fixed the issue.
So I just decided to revert the whole uvc driver: git checkout v3.2 --
drivers/media/video/uvc.
But, the problem was still here.
I reverted the usb host code in drivers/usb/host/. Again the problem was
reproduced (both with and without 3.2's uvcvideo driver)
Then I tested the whole kernel v3.2, and indeed it still works very well.
So this problem could have it's root in USB core changes, or even a
combilation of USB and UVC changes.
>
> > Installed libv4l version is 0.8.6.
> > I'm reproducing this with: gst-launch-0.10 --verbose v4l2src ! xvimagesink
> > (Skype exhibits the problem too, while it isn't using gstreamer, so it
> > really seems to come from kernel. Also, doesn't happen with 3.2)
> >
> > This is the first part of the problem. The second part is that if I
> > restart the webcam with gst-launch after the first failure, I have a
> > total freeze, just after these messages in the log (fetched with
> > netconsole, I wasn't able to get a panic trace):
> >
> > [ 191.796217] uvcvideo: Marking buffer as bad (error bit set).
> > [ 191.796233] uvcvideo: Marking buffer as bad (error bit set).
> > [ 191.796244] uvcvideo: Marking buffer as bad (error bit set).
> > [ 191.796252] uvcvideo: Marking buffer as bad (error bit set).
> > [ 191.796259] uvcvideo: Frame complete (EOF found).
> > [ 191.796265] uvcvideo: EOF in empty payload.
> > [ 192.972803] uvcvideo: Marking buffer as bad (error bit set).
> > [ 192.972818] uvcvideo: Dropping payload (out of sync).
> > [ 194.289463] uvcvideo: Marking buffer as bad (error bit set).
> > [ 194.289478] uvcvideo: Frame complete (FID bit toggled).
> > [ 194.289486] uvcvideo: Marking buffer as bad (error bit set).
> > [ 194.289493] uvcvideo: Frame complete (FID bit toggled).
> > [ 194.289499] uvcvideo: Marking buffer as bad (error bit set).
> > [ 194.289505] uvcvideo: Frame complete (FID bit toggled).
> > [ 194.289511] uvcvideo: Marking buffer as bad (error bit set).
> > [ 194.289518] uvcvideo: Frame complete (FID bit toggled).
> > [ 194.289524] uvcvideo: Marking buffer as bad (error bit set).
> > [ 194.289531] uvcvideo: Frame complete (FID bit toggled).
> >
> > Last but not least, uvcvideo is un-bisectable because there were a few
> > crash-fixes during the 3.3 development cycle. I started bisecting and got
> > kernel panics.
>
> Are the kernel panics related to uvcvideo ? There's one known bug introduced
> between v3.2 and v3.3 and fixed (before v3.3) in commit
> 8e57dec0454d8a3ba987d18b3ab19922c766d4bc.
I don't think that's it. As I've said, problem exists with both 3.3.3 and
Linus' 3.4-rc5.
--
Anisse