Bug 15206

Summary:	uvcvideo fails to work since 2.6.32
Product:	v4l-dvb	Reporter:	Rich Ercolani (rercola)
Component:	v4l-core	Assignee:	v4l-dvb_v4l-core (v4l-dvb_v4l-core)
Status:	CLOSED UNREPRODUCIBLE
Severity:	normal	CC:	alan, florian, hpa, laurent.pinchart+bugzilla-kernel, rjw, zajec5
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.32.7	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	14230

Description Rich Ercolani 2010-02-01 12:51:03 UTC

Since upgrading from 2.6.31 to 2.6.32 (and then 2.6.32.7), the machine's webcam, a Lifecam NX-6000, has been inaccessible.

All the old utilities for extracting video from it fail with the same sorts of errors in dmesg:
compat_ioctl32: unknown ioctl 'U', dir=1, #1 (0x40185501)
compat_ioctl32: unknown ioctl 'U', dir=1, #1 (0x40185501)
compat_ioctl32: unknown ioctl 'U', dir=1, #1 (0x40185501)
compat_ioctl32: unknown ioctl 'U', dir=1, #1 (0x40185501)
compat_ioctl32: unknown ioctl 'U', dir=3, #2 (0xc0405502)
compat_ioctl32: unknown ioctl 'U', dir=3, #2 (0xc0405502)
compat_ioctl32: unknown ioctl 'U', dir=3, #2 (0xc0405502)
compat_ioctl32: unknown ioctl 'U', dir=3, #2 (0xc0405502)
compat_ioctl32: unknown ioctl 'U', dir=3, #2 (0xc0405502)
compat_ioctl32: unknown ioctl 'U', dir=3, #2 (0xc0405502)

I've tried three or four different uvc-compatible utilities, all of which worked on 2.6.31, and all of which fail on 2.6.32.

I'll probably do a git bisect on this soon, but I was waiting to see if this was something stupid fixed in revs >2.6.32 (no).

Comment 1 Laurent Pinchart 2010-02-03 01:26:57 UTC

Hi Rich,

I'm quite puzzled by this, as V4L1 and V4L2 ioctls use 'v' and 'V' respectively, not 'U'. I'm not aware of any kernel change in the uvcvideo driver that could trigger this. Have you upgraded anything beyond the kernel ? If not, bisecting could help.

Comment 2 Rich Ercolani 2010-02-03 01:29:41 UTC

I've not upgraded anything but the kernel. If I switch back to 2.6.31, it all works nicely.

I've tried various tools for each (mjpg-streamer, uvccapture), both the latest head of their respective VCS and their latest stable releases. They both work on 2.6.31 and fail silently-ish on 2.6.32 and above, and dmesg floods with the above.

Comment 3 Laurent Pinchart 2010-02-03 01:33:54 UTC

Could you try to backport the uvcvideo driver from 2.6.32 to 2.6.31 ? Copying the drivers/media/video/uvc repository should do the trick. If the newer driver works on 2.6.31, the bug probably comes from somewhere else.

Comment 4 Laurent Pinchart 2010-02-03 01:34:12 UTC

s/repository/directory

Comment 5 Rich Ercolani 2010-02-03 01:34:47 UTC

Sure, I'll do that and get back to you shortly - I need to go grab the camera and plug it into a machine that I can bisect and manipulate the kernel on.

Comment 6 Rich Ercolani 2010-02-03 15:36:31 UTC

After doing five of the required fourteen builds for a bisect on a machine I could easily reboot, it occurred to me that I hadn't tested whether the kernel from the machine I was having trouble with would fail on this other machine.

So I tested it...and it succeeds.

So it appears to be less a UVC bug and more a bug with how UVC is interacting with...something.

Since it's definitely the case that it works perfectly on 2.6.31 on the affected machine, I guess I get to go do git bisect on the affected machine...rather inconvenient, but c'est la vie.

(Working machine: ThinkPad T61p, ICH8-based. USB controller is 82801H)
(Faulty machine: homebuilt machine, ICH7-based. USB controller is 82801G)

Comment 7 Rich Ercolani 2010-02-03 16:35:15 UTC

I hate everything.

The machine is a 64b 2.6.32.7 with a 32b userland.

The program succeeds trivially in 32b land on 2.6.31.
The program fails with the above dmesg dumps in 32b land on 2.6.32.7.
The program succeeds with no dmesg output built in a 64b chroot from the same 32b userland on 2.6.32.7.

It still works on 2.6.31 if I reboot into 2.6.31 on the machine and build the program and run it in the 32b userland.

Comment 8 Rich Ercolani 2010-02-03 20:18:27 UTC

Oh god, it's strictly worse than that.

Apparently the compiler on the machine I've been building this on miscompiles the kernel.

Building clean 2.6.32.7 from kernel.org on gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1, this works wonderfully.
Building clean 2.6.32.7 from kernel.org on gcc (Debian 4.3.2-1.1) 4.3.2 is failing miserably.

I wonder if ccache is doing the wrong thing. It shouldn't have for 2.6.32, as it had never seen 2.6.32 before, and I also think it shouldn't have for 2.6.32.7 compared to 2.6.32, esp. failing in the same way.

I'll go investigate if building it sans ccache gets this to stop.

Comment 9 Rafał Miłecki 2010-03-12 21:24:43 UTC

Rich: any news on this?

Comment 10 Rich Ercolani 2010-05-02 07:37:29 UTC

Sorry, hadn't needed a new kernel in awhile and forgot to update.

Just was reminded of this when I rolled to 2.6.33.3.

Comment 11 Rich Ercolani 2010-05-02 07:39:18 UTC

That is to say, 2.6.33.3 did the Wrong Thing as well on the above compiler, and resulted in the uvcvideo driver being unusable.

I'm building with gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 to make sure the problem still goes away there.

Comment 12 Rich Ercolani 2010-05-02 10:32:13 UTC

Occurs on 2.6.33.3 compiled on the Ubuntu-provided Gcc version. This is fascinating.

Comment 13 Florian Mickler 2010-10-07 19:56:51 UTC

Is this issue still present in current mainline kernels?

Also, can you post the output of scripts/ver_linux for the failing case?

And then could you please clarify comment #12: Since 2.6.33.3 uvcvideo fails in all cases?

Comment 14 Florian Mickler 2011-02-01 15:41:52 UTC

Ping?