linux-kernel - Re: UVCvideo: Failed to resubmit video URB (-27) with Linux 3.3.3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 May 2012 14:24:11 +0200
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Anisse Astier <anisse@...ier.eu>
Cc:	linux-uvc-devel@...ts.sourceforge.net, linux-media@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: UVCvideo:  Failed to resubmit video URB (-27) with Linux 3.3.3

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

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