Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote: Okay, that proves this really is a timing bug in the hardware. But we can't go around putting 2-millisecond delays in the kernel! Maybe you can test to see if smaller delays will fix the problem. If 50 microseconds or less doesn't work then it will be necessary to add a new timer to ehci-hcd. Okay I'll check with smaller values there but I couldn't get the meaning of if 50 us or less doesn't work then it will be necessary to add a new timer to ehci-hcd. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Sat, 24 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote: Alan Stern wrote: Okay, that proves this really is a timing bug in the hardware. But we can't go around putting 2-millisecond delays in the kernel! Maybe you can test to see if smaller delays will fix the problem. If 50 microseconds or less doesn't work then it will be necessary to add a new timer to ehci-hcd. Okay I'll check with smaller values there but I couldn't get the meaning of if 50 us or less doesn't work then it will be necessary to add a new timer to ehci-hcd. If everything works with a delay of 50 us or less then we probably can just put the udelay() statement into the kernel. If it doesn't (for example, if the delay has to be longer than 100 us) then we can't -- the delay would be too long. Instead we will have to add a new timer. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote On 22-10-2009 17:05: On Thu, 22 Oct 2009, [UTF-8] Ozan Çağlayan wrote: Here's the outputs from /sys/kernel/debug/usb/ehci: periodic: size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) There's something odd about this. I'd like to see this file again, after the patch below has been applied. periodic size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) t registers bus pci, device :00:1d.7 EHCI Host Controller EHCI 1.00, hcd state 0 ownership 0001 SMI sts/enable 0x8008 structural params 0x00104208 capability params 0x00016871 status 6008 Periodic Recl FLR command 01 (park)=0 ithresh=1 period=1024 HALT intrenable 00 uframe 0677 port 1 status 001000 POWER sig=se0 port 2 status 001000 POWER sig=se0 port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 port 5 status 001005 POWER sig=se0 PE CONNECT port 6 status 001005 POWER sig=se0 PE CONNECT port 7 status 001000 POWER sig=se0 port 8 status 001000 POWER sig=se0 irq normal 60 err 0 reclaim 14 (lost 0) complete 60 unlink 1 After putting a udelay() the problem seems to be resolved. I did a rmmod-modprobe-sleep in 50 iterations, and the host controller was still functional along with the web-cam: periodic size = 1024 registers bus pci, device :00:1d.7 EHCI Host Controller EHCI 1.00, hcd state 1 ownership 0001 SMI sts/enable 0x8008 structural params 0x00104208 capability params 0x00016871 status 2008 Recl FLR command 010001 (park)=0 ithresh=1 period=1024 RUN intrenable 37 IAA FATAL PCD ERR INT uframe 0908 port 1 status 001000 POWER sig=se0 port 2 status 001000 POWER sig=se0 port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 port 5 status 001005 POWER sig=se0 PE CONNECT port 6 status 001005 POWER sig=se0 PE CONNECT port 7 status 001000 POWER sig=se0 port 8 status 001000 POWER sig=se0 irq normal 2115 err 0 reclaim 300 (lost 0) complete 2110 unlink 8 -- Thanks a lot for all your efforts! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Fri, 23 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote: There's something odd about this. I'd like to see this file again, after the patch below has been applied. periodic size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) t On closer study and more careful thought, there's nothing odd here at all. This is what would be expected given the bug that you saw. After putting a udelay() the problem seems to be resolved. I did a rmmod-modprobe-sleep in 50 iterations, and the host controller was still functional along with the web-cam: Okay, that proves this really is a timing bug in the hardware. But we can't go around putting 2-millisecond delays in the kernel! Maybe you can test to see if smaller delays will fix the problem. If 50 microseconds or less doesn't work then it will be necessary to add a new timer to ehci-hcd. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote On 22-10-2009 04:36: On Thu, 22 Oct 2009, Laurent Pinchart wrote: Here's the outputs from /sys/kernel/debug/usb/ehci: periodic: size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) registers: bus pci, device :00:1d.7 EHCI Host Controller EHCI 1.00, hcd state 0 ownership 0001 SMI sts/enable 0x8008 structural params 0x00104208 capability params 0x00016871 status 6008 Periodic Recl FLR command 01 (park)=0 ithresh=1 period=1024 HALT intrenable 00 uframe 2fa0 port 1 status 001000 POWER sig=se0 port 2 status 001000 POWER sig=se0 port 3 status 001000 POWER sig=se0 port 4 status 001000 POWER sig=se0 port 5 status 001005 POWER sig=se0 PE CONNECT port 6 status 001005 POWER sig=se0 PE CONNECT port 7 status 001000 POWER sig=se0 port 8 status 001000 POWER sig=se0 irq normal 60 err 0 reclaim 16 (lost 0) complete 60 unlink 1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Thu, 22 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote:
Here's the outputs from /sys/kernel/debug/usb/ehci:
periodic:
size = 1024
1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8)
There's something odd about this. I'd like to see this file again,
after the patch below has been applied.
registers:
bus pci, device :00:1d.7
EHCI Host Controller
EHCI 1.00, hcd state 0
ownership 0001
SMI sts/enable 0x8008
structural params 0x00104208
capability params 0x00016871
status 6008 Periodic Recl FLR
command 01 (park)=0 ithresh=1 period=1024 HALT
intrenable 00
uframe 2fa0
port 1 status 001000 POWER sig=se0
port 2 status 001000 POWER sig=se0
port 3 status 001000 POWER sig=se0
port 4 status 001000 POWER sig=se0
port 5 status 001005 POWER sig=se0 PE CONNECT
port 6 status 001005 POWER sig=se0 PE CONNECT
port 7 status 001000 POWER sig=se0
port 8 status 001000 POWER sig=se0
irq normal 60 err 0 reclaim 16 (lost 0)
complete 60 unlink 1
This confirms that the periodic schedule was never disabled.
So first get another copy of the periodic file with the patch below.
Then try changing the enable_periodic() routine in ehci-sched.c: Add
udelay(2000);
just before the final return 0; line. Let's see if that prevents the
problem from occurring.
Alan Stern
--- usb-2.6.orig/drivers/usb/host/ehci-dbg.c
+++ usb-2.6/drivers/usb/host/ehci-dbg.c
@@ -591,18 +591,21 @@ static ssize_t fill_periodic_buffer(stru
qtd-hw_token) 8)) {
case 0: type = out; continue;
case 1: type = in; continue;
+ case 2: type = ?2; continue;
+ case 3: type = ?3; continue;
}
}
temp = scnprintf (next, size,
(%c%d ep%d%s
- [%d/%d] q%d p%d),
+ [%d/%d] q%d p%d) %08x,
speed_char (scratch),
scratch 0x007f,
(scratch 8) 0x000f, type,
p.qh-usecs, p.qh-c_usecs,
temp,
- 0x7ff (scratch 16));
+ 0x7ff (scratch 16),
+ hc32_to_cpu(ehci,
qtd-hw_token));
if (seen_count DBG_SCHED_LIMIT)
seen [seen_count++].qh = p.qh;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote: On Thu, 22 Oct 2009, [UTF-8] Ozan Çağlayan wrote: Here's the outputs from /sys/kernel/debug/usb/ehci: periodic: size = 1024 1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8) There's something odd about this. I'd like to see this file again, after the patch below has been applied. Do you want me to apply this patch altogether with the first one that you sent a while ago in this thread or directly onto the vanilla kernel? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Thu, 22 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote:
Alan Stern wrote:
On Thu, 22 Oct 2009, [UTF-8] Ozan Ãâ¡aßlayan wrote:
Here's the outputs from /sys/kernel/debug/usb/ehci:
periodic:
size = 1024
1: qh1024-0001/f6ffe280 (h2 ep2 [1/0] q0 p8)
There's something odd about this. I'd like to see this file again,
after the patch below has been applied.
Do you want me to apply this patch altogether with the first one that
you sent a while ago in this thread or directly onto the vanilla kernel?
It doesn't matter. The size = 1024 line in your debugging output
means that the first patch won't have any effect; my hunch was wrong.
However it turns out that the most recent patch wasn't quite what I
wanted. Here's an updated version to be used instead.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci-dbg.c
===
--- usb-2.6.orig/drivers/usb/host/ehci-dbg.c
+++ usb-2.6/drivers/usb/host/ehci-dbg.c
@@ -596,18 +596,22 @@ static ssize_t fill_periodic_buffer(stru
qtd-hw_token) 8)) {
case 0: type = out; continue;
case 1: type = in; continue;
+ case 2: type = ?2; continue;
+ case 3: type = ?3; continue;
}
}
temp = scnprintf (next, size,
(%c%d ep%d%s
- [%d/%d] q%d p%d),
+ [%d/%d] q%d p%d) t%08x,
speed_char (scratch),
scratch 0x007f,
(scratch 8) 0x000f, type,
p.qh-usecs, p.qh-c_usecs,
temp,
- 0x7ff (scratch 16));
+ 0x7ff (scratch 16),
+ hc32_to_cpu(ehci,
+ p.qh-hw-hw_token));
if (seen_count DBG_SCHED_LIMIT)
seen [seen_count++].qh = p.qh;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Wed, 21 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote: Nope it didn't help. Here's the DEBUG enabled dmesg output: ... [ 420.737748] usb 1-5: link qh1024-0001/f6ffe280 start 1 [1/0 us] The periodic schedule was enabled here. [ 420.737891] usb 1-5: unlink qh1024-0001/f6ffe280 start 1 [1/0 us] And it was disabled here. Do you have any idea why the uvcvideo driver submits an interrupt URB and then cancels it 150 us later? The same thing shows up in the usbmon traces. [ 420.741605] usb 1-5:1.0: uevent [ 420.741957] usb 1-5: uevent [ 420.745592] usb 1-5:1.0: uevent [ 420.807880] ehci_hcd :00:1d.7: reused qh f6ffe280 schedule [ 420.807894] usb 1-5: link qh1024-0001/f6ffe280 start 1 [1/0 us] Now ehci-hcd tried to re-enable the periodic schedule. Note that this is 70 ms after it was supposed to be disabled. [ 420.808780] ehci_hcd :00:1d.7: force halt; handhake f7c6a024 4000 - -110 This error message means that the disable request from 70 ms earlier hasn't taken effect. It looks like a nasty hardware bug -- the controller is supposed to disable the schedule no more than 2 ms after being told to do so. Has this device ever worked with any earlier kernels? A little more debugging information could confirm this. After the error occurs, go into /sys/kernel/debug/usb/ehci/:00:1d.7 and post a copy of the registers file. If there's anything of interest in the other files, post them too. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote: (Add uvcvideo maintainer to CC) [ 420.737748] usb 1-5: link qh1024-0001/f6ffe280 start 1 [1/0 us] The periodic schedule was enabled here. [ 420.737891] usb 1-5: unlink qh1024-0001/f6ffe280 start 1 [1/0 us] And it was disabled here. Do you have any idea why the uvcvideo driver submits an interrupt URB and then cancels it 150 us later? The same thing shows up in the usbmon traces. [ 420.741605] usb 1-5:1.0: uevent [ 420.741957] usb 1-5: uevent [ 420.745592] usb 1-5:1.0: uevent [ 420.807880] ehci_hcd :00:1d.7: reused qh f6ffe280 schedule [ 420.807894] usb 1-5: link qh1024-0001/f6ffe280 start 1 [1/0 us] Now ehci-hcd tried to re-enable the periodic schedule. Note that this is 70 ms after it was supposed to be disabled. [ 420.808780] ehci_hcd :00:1d.7: force halt; handhake f7c6a024 4000 - -110 This error message means that the disable request from 70 ms earlier hasn't taken effect. It looks like a nasty hardware bug -- the controller is supposed to disable the schedule no more than 2 ms after being told to do so. Has this device ever worked with any earlier kernels? I only tried 2.6.30.9 and 2.6.31.4, both of them is affected by the same problem but sometimes it works without a problem so I think that this can be interpreted as *at-least-working* on those kernels from time to time. A little more debugging information could confirm this. After the error occurs, go into /sys/kernel/debug/usb/ehci/:00:1d.7 and post a copy of the registers file. If there's anything of interest in the other files, post them too. OK I'll look at them tomorrow, Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Wednesday 21 October 2009 17:07:51 Alan Stern wrote: On Wed, 21 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote: Nope it didn't help. Here's the DEBUG enabled dmesg output: ... [ 420.737748] usb 1-5: link qh1024-0001/f6ffe280 start 1 [1/0 us] The periodic schedule was enabled here. [ 420.737891] usb 1-5: unlink qh1024-0001/f6ffe280 start 1 [1/0 us] And it was disabled here. Do you have any idea why the uvcvideo driver submits an interrupt URB and then cancels it 150 us later? The same thing shows up in the usbmon traces. Probably because hal opens the device to query its capabilities and closes it right after. The driver submits the interrupt URB when the first user opens the device and cancels it when the last user closes the device. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Laurent Pinchart wrote: Probably because hal opens the device to query its capabilities and closes it right after. The driver submits the interrupt URB when the first user opens the device and cancels it when the last user closes the device. So who's guilty now? :) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Thu, 22 Oct 2009, Laurent Pinchart wrote: On Wednesday 21 October 2009 22:09:46 Ozan ÃaÄlayan wrote: Laurent Pinchart wrote: Probably because hal opens the device to query its capabilities and closes it right after. The driver submits the interrupt URB when the first user opens the device and cancels it when the last user closes the device. So who's guilty now? :) Not me :-) I don't think there's anything wrong with submitting an interrupt URB and canceling it soon after. Nothing wrong at all. Even if hal didn't do this, the same thing might very well occur the second time somebody ran a program accessing the video device. The real problem will be to figure out why the hardware isn't turning off the periodic schedule. It might be a timing issue (the schedule was running too briefly before the driver tried to disable it). That could explain why it shows up only occasionally. But if it isn't, I have no idea what the underlying cause is or how to fix it. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Ozan Çağlayan wrote On 14-10-2009 11:16: Alan Stern wrote On 13-10-2009 17:53: Can you add a dump_stack() call just after the ehci_err() line in drivers/usb/host/ehci-hcd.c:handshake_on_error_set_halt()? It should provide some clues. At the same time (i.e., during the same test) you should collect a usbmon trace. Alan Stern Hi. First the backtrace: [ 149.510272] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) [ 149.515017] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 [ 149.515588] usbcore: registered new interface driver uvcvideo [ 149.516247] USB Video Class driver (v0.1.0) [ 149.658012] Pid: 1137, comm: hald-probe-vide Tainted: G C 2.6.31.4-128 #2 [ 149.658012] Call Trace: [ 149.658012] [c0373f62] handshake_on_error_set_halt+0x36/0x65 [ 149.658012] [c0374073] enable_periodic+0x32/0x72 [ 149.658012] [c03741c9] qh_link_periodic+0x116/0x11e [ 149.658012] [c0374665] qh_schedule+0x120/0x12c [ 149.658012] [c03775d0] intr_submit+0x8c/0x124 [ 149.658012] [c0377d2a] ehci_urb_enqueue+0x7a/0xa5 [ 149.658012] [c036965f] usb_hcd_submit_urb+0xbb/0x13c [ 149.658012] [c0369b1e] usb_submit_urb+0x1f1/0x20d [ 149.658012] [f854aaff] uvc_status_start+0x18/0x1a [uvcvideo] [ 149.658012] [f8546e23] uvc_v4l2_open+0x8a/0xcf [uvcvideo] [ 149.658012] [f7c3d74a] v4l2_open+0x68/0x7c [videodev] [ 149.658012] [c01c648e] chrdev_open+0x125/0x13c [ 149.658012] [c01c28a9] __dentry_open+0x119/0x207 [ 149.658012] [c01c2a31] nameidata_to_filp+0x2c/0x43 [ 149.658012] [c01c6369] ? chrdev_open+0x0/0x13c [ 149.658012] [c01ccc28] do_filp_open+0x3e5/0x741 [ 149.658012] [c01ccfe9] ? getname+0x20/0xb7 [ 149.658012] [c01d4be8] ? alloc_fd+0x55/0xbe [ 149.658012] [c01c2699] do_sys_open+0x4a/0xe2 [ 149.658012] [c0435527] ? do_page_fault+0x2d6/0x304 [ 149.658012] [c01c2773] sys_open+0x1e/0x26 [ 149.658012] [c0103214] sysenter_do_call+0x12/0x28 [ 149.658012] ehci_hcd :00:1d.7: force halt; handhake f7c66024 4000 - -110 And the usbmon trace during modprobe uvcvideo can be found at: http://cekirdek.pardus.org.tr/~ozan/ivir/logs/usbmon.trace.bad I also manage to not reproduce the problem so it's kinda racy. You can find good/bad dmesg/usbmon traces at: http://cekirdek.pardus.org.tr/~ozan/ivir/logs ping! in case it's got lost between high traffic :) Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
On Tue, 20 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote:
Hi. First the backtrace:
[ 149.510272] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203)
[ 149.515017] input: BisonCam, NB Pro as
/devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10
[ 149.515588] usbcore: registered new interface driver uvcvideo
[ 149.516247] USB Video Class driver (v0.1.0)
[ 149.658012] Pid: 1137, comm: hald-probe-vide Tainted: G C
2.6.31.4-128 #2
[ 149.658012] Call Trace:
[ 149.658012] [c0373f62] handshake_on_error_set_halt+0x36/0x65
[ 149.658012] [c0374073] enable_periodic+0x32/0x72
[ 149.658012] [c03741c9] qh_link_periodic+0x116/0x11e
[ 149.658012] [c0374665] qh_schedule+0x120/0x12c
[ 149.658012] [c03775d0] intr_submit+0x8c/0x124
[ 149.658012] [c0377d2a] ehci_urb_enqueue+0x7a/0xa5
...
[ 149.658012] ehci_hcd :00:1d.7: force halt; handhake f7c66024
4000 - -110
And the usbmon trace during modprobe uvcvideo can be found at:
http://cekirdek.pardus.org.tr/~ozan/ivir/logs/usbmon.trace.bad
I also manage to not reproduce the problem so it's kinda racy. You can
find good/bad dmesg/usbmon traces at:
http://cekirdek.pardus.org.tr/~ozan/ivir/logs
ping! in case it's got lost between high traffic :)
Yes, sorry, my email client tends to hide messages with non-ASCII
characters in the From: address. It's unforunate. :-(
I can't tell exactly what's wrong, but I've got a hunch that the patch
below might help. If it doesn't, send another dmesg log but this time
with CONFIG_USB_DEBUG enabled in the kernel.
Alan Stern
Index: usb-2.6/drivers/usb/host/ehci-q.c
===
--- usb-2.6.orig/drivers/usb/host/ehci-q.c
+++ usb-2.6/drivers/usb/host/ehci-q.c
@@ -818,6 +818,9 @@ qh_make (
dbg (intr period %d uframes, NYET!,
urb-interval);
goto done;
+ } else if (qh-period ehci-periodic_size) {
+ qh-period = ehci-periodic_size;
+ urb-interval = qh-period 3;
}
} else {
int think_time;
@@ -840,6 +843,10 @@ qh_make (
usb_calc_bus_time (urb-dev-speed,
is_input, 0, max_packet (maxp)));
qh-period = urb-interval;
+ if (qh-period ehci-periodic_size) {
+ qh-period = ehci-periodic_size;
+ urb-interval = qh-period;
+ }
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo causes ehci_hcd to halt
Alan Stern wrote On 13-10-2009 17:53: Can you add a dump_stack() call just after the ehci_err() line in drivers/usb/host/ehci-hcd.c:handshake_on_error_set_halt()? It should provide some clues. At the same time (i.e., during the same test) you should collect a usbmon trace. Alan Stern Hi. First the backtrace: [ 149.510272] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) [ 149.515017] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 [ 149.515588] usbcore: registered new interface driver uvcvideo [ 149.516247] USB Video Class driver (v0.1.0) [ 149.658012] Pid: 1137, comm: hald-probe-vide Tainted: G C 2.6.31.4-128 #2 [ 149.658012] Call Trace: [ 149.658012] [c0373f62] handshake_on_error_set_halt+0x36/0x65 [ 149.658012] [c0374073] enable_periodic+0x32/0x72 [ 149.658012] [c03741c9] qh_link_periodic+0x116/0x11e [ 149.658012] [c0374665] qh_schedule+0x120/0x12c [ 149.658012] [c03775d0] intr_submit+0x8c/0x124 [ 149.658012] [c0377d2a] ehci_urb_enqueue+0x7a/0xa5 [ 149.658012] [c036965f] usb_hcd_submit_urb+0xbb/0x13c [ 149.658012] [c0369b1e] usb_submit_urb+0x1f1/0x20d [ 149.658012] [f854aaff] uvc_status_start+0x18/0x1a [uvcvideo] [ 149.658012] [f8546e23] uvc_v4l2_open+0x8a/0xcf [uvcvideo] [ 149.658012] [f7c3d74a] v4l2_open+0x68/0x7c [videodev] [ 149.658012] [c01c648e] chrdev_open+0x125/0x13c [ 149.658012] [c01c28a9] __dentry_open+0x119/0x207 [ 149.658012] [c01c2a31] nameidata_to_filp+0x2c/0x43 [ 149.658012] [c01c6369] ? chrdev_open+0x0/0x13c [ 149.658012] [c01ccc28] do_filp_open+0x3e5/0x741 [ 149.658012] [c01ccfe9] ? getname+0x20/0xb7 [ 149.658012] [c01d4be8] ? alloc_fd+0x55/0xbe [ 149.658012] [c01c2699] do_sys_open+0x4a/0xe2 [ 149.658012] [c0435527] ? do_page_fault+0x2d6/0x304 [ 149.658012] [c01c2773] sys_open+0x1e/0x26 [ 149.658012] [c0103214] sysenter_do_call+0x12/0x28 [ 149.658012] ehci_hcd :00:1d.7: force halt; handhake f7c66024 4000 - -110 And the usbmon trace during modprobe uvcvideo can be found at: http://cekirdek.pardus.org.tr/~ozan/ivir/logs/usbmon.trace.bad I also manage to not reproduce the problem so it's kinda racy. You can find good/bad dmesg/usbmon traces at: http://cekirdek.pardus.org.tr/~ozan/ivir/logs Thanks, Ozan Caglayan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
uvcvideo causes ehci_hcd to halt
Hi, Some recent netbooks (Some MSI winds and LG X110's) equipped with an integrated webcam have non-working USB ports unless the uvcvideo module is blacklisted. I've found some bug reports in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/435352 I have an LG X110 on which I can reproduce the problem with 2.6.30.8. Here's the interesting part in dmesg: Oct 13 08:46:32 x110 kernel: [ 261.048312] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) Oct 13 08:46:32 x110 kernel: [ 261.053592] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 Oct 13 08:46:32 x110 kernel: [ 261.053891] usbcore: registered new interface driver uvcvideo Oct 13 08:46:32 x110 kernel: [ 261.054755] USB Video Class driver (v0.1.0) Oct 13 08:46:32 x110 kernel: [ 261.091014] ehci_hcd :00:1d.7: force halt; handhake f807c024 4000 - -110 Oct 13 08:46:33 x110 kernel: [ 261.742335] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742360] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742381] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742400] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742419] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742433] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742454] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742478] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742496] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742514] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742532] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742550] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742564] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742582] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742597] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742609] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742622] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742634] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742647] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742657] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742670] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742684] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742697] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742709] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742722] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742734] hub 1-0:1.0: cannot reset port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742744] hub 1-0:1.0: Cannot enable port 6. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.742758] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742771] hub 1-0:1.0: cannot disable port 6 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742839] hub 1-0:1.0: hub_port_status failed (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742902] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742923] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742943] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742963] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742983] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.742997] hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.743018] hub 1-0:1.0: cannot disable port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743041] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743059] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743076] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743092] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743108] hub 1-0:1.0: cannot reset port 2 (err = -108) Oct 13 08:46:33 x110 kernel: [ 261.743121] hub 1-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? Oct 13 08:46:33 x110 kernel: [ 261.743139] hub 1-0:1.0: cannot disable port 2 (err = -108) Oct 13
Re: uvcvideo causes ehci_hcd to halt
On Tue, 13 Oct 2009, [UTF-8] Ozan ÃaÄlayan wrote: Hi, Some recent netbooks (Some MSI winds and LG X110's) equipped with an integrated webcam have non-working USB ports unless the uvcvideo module is blacklisted. I've found some bug reports in launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/435352 I have an LG X110 on which I can reproduce the problem with 2.6.30.8. Here's the interesting part in dmesg: Oct 13 08:46:32 x110 kernel: [ 261.048312] uvcvideo: Found UVC 1.00 device BisonCam, NB Pro (5986:0203) Oct 13 08:46:32 x110 kernel: [ 261.053592] input: BisonCam, NB Pro as /devices/pci:00/:00:1d.7/usb1/1-5/1-5:1.0/input/input10 Oct 13 08:46:32 x110 kernel: [ 261.053891] usbcore: registered new interface driver uvcvideo Oct 13 08:46:32 x110 kernel: [ 261.054755] USB Video Class driver (v0.1.0) Oct 13 08:46:32 x110 kernel: [ 261.091014] ehci_hcd :00:1d.7: force halt; handhake f807c024 4000 - -110 Can you add a dump_stack() call just after the ehci_err() line in drivers/usb/host/ehci-hcd.c:handshake_on_error_set_halt()? It should provide some clues. At the same time (i.e., during the same test) you should collect a usbmon trace. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
