Bug 6374
|
Description
crazy
2006-04-10 17:17:18 UTC
Begin forwarded message: Date: Mon, 10 Apr 2006 17:17:22 -0700 From: bugme-daemon@bugzilla.kernel.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 6374] New: ehci via disconnect and usb hang http://bugzilla.kernel.org/show_bug.cgi?id=6374 Summary: ehci via disconnect and usb hang Kernel Version: 2.6.16.2 Status: NEW Severity: normal Owner: greg@kroah.com Submitter: crazy@wi.rr.com Most recent kernel where this bug did not occur: ? Distribution: Debian Hardware Environment: Via KM400 chipset Software Environment: Problem Description: Eventually any ehci device will disconnect and hang khubd in D state, in my case a ZD1211 wireless ethernet controller and a Sandisk memorystick reader, but only if ehci_hcd is loaded. With uhci_hcd only everything works fine. It looks to be the same as http://marc.theaimsgroup.com/?l=linux-ide&m=113653806322524&w=2 except it talks about an IDE throughput problem, which I don't see. The stack for khubd after hang looks like: Apr 10 16:56:30 shows kernel: khubd D 002BD2CA 0 1489 5 3529 1309 (L-TLB) Apr 10 16:56:30 shows kernel: df386eb0 c0104281 df386ec0 002bd2ca 00000000 dbbbce00 003d14e3 dfc68178 Apr 10 16:56:30 shows kernel: dfc68050 e0437900 003d14e3 00000000 00000000 00000282 df386ec0 0031def2 Apr 10 16:56:30 shows kernel: 00000010 dec874d0 c028b1ac df386ec0 0031def2 c032c3b8 c032c3b8 0031def2 Apr 10 16:56:30 shows kernel: Call Trace: Apr 10 16:56:30 shows kernel: [<c0104281>] do_IRQ+0x48/0x50 Apr 10 16:56:30 shows kernel: [<c028b1ac>] schedule_timeout+0x76/0x95 Apr 10 16:56:30 shows kernel: [<c011a87e>] process_timeout+0x0/0x9 Apr 10 16:56:30 shows kernel: [<e13dd7f1>] ehci_endpoint_disable+0x9f/0x13f [ehci_hcd] Apr 10 16:56:30 shows kernel: [<e1388008>] usb_disable_device+0x65/0x140 [usbcore] Apr 10 16:56:30 shows kernel: [<e13834da>] usb_disconnect+0x8e/0x115 [usbcore] Apr 10 16:56:30 shows kernel: [<e138494b>] hub_thread+0x535/0xcf7 [usbcore] Apr 10 16:56:30 shows kernel: [<c0122c54>] autoremove_wake_function+0x0/0x3a Apr 10 16:56:30 shows kernel: [<c0122be5>] kthread+0x80/0xc1 Apr 10 16:56:30 shows kernel: [<e1384416>] hub_thread+0x0/0xcf7 [usbcore] Apr 10 16:56:30 shows kernel: [<c0122bf9>] kthread+0x94/0xc1 Apr 10 16:56:30 shows kernel: [<c0122b65>] kthread+0x0/0xc1 Apr 10 16:56:30 shows kernel: [<c0101005>] kernel_thread_helper+0x5/0xb ehci device lspci -vvxxx: 0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI]) Subsystem: Giga-byte Technology GA-7VAX Mainboard Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin D routed to IRQ 3 Region 0: Memory at ea010000 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 04 31 13 00 10 02 82 20 03 0c 10 20 00 00 10: 00 00 01 ea 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 04 50 30: 00 00 00 00 80 00 00 00 00 00 00 00 03 04 00 00 40: 00 00 03 00 00 00 00 00 80 10 00 09 00 00 00 00 50: 00 5a 00 80 00 00 00 00 04 0b 88 88 53 88 00 00 60: 20 20 01 00 00 00 00 00 01 00 00 00 00 00 00 c0 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 01 00 c2 ff 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 87 00 00 00 00 00 00 00 00 00 kern.log just before hang: Apr 10 15:53:04 shows kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0002 Apr 10 15:53:04 shows kernel: ehci_hcd 0000:00:10.3: GetStatus port 1 status 00180b POWER sig=j PEC CSC CONNECT Apr 10 15:53:04 shows kernel: hub 4-0:1.0: port 1, status 0501, change 0003, 480 Mb/s Apr 10 15:53:04 shows kernel: usb 4-1: USB disconnect, address 2 Apr 10 15:53:04 shows kernel: usb 4-1: usb_disable_device nuking all URBs Apr 10 15:53:04 shows kernel: ehci_hcd 0000:00:10.3: shutdown urb def44ec0 pipe c0010280 ep2in-bulk Apr 10 15:53:06 shows kernel: zd1211: failed reg_urb Apr 10 15:53:06 shows kernel: zd1211:USB ST Code = -19 Steps to reproduce: Load ehci_hcd, plug in a high speed device and wait. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. Some code was added to the ehci-hcd driver to try and help with with problem. Can you try using the current 2.6.17-rc kernel to see if the same thing still happens? With 2.6.17-rc1 no change. Created attachment 8020 [details]
experimental 2.6.17-rc3 patch reworking ehci unlink
This may help. There's some goofy code that could easily hide bugs,
and the patch takes a different -- and, I hope, more obviously
correct -- approach to the "wait for unlink to complete" problem.
Applied patch to 2.6.17-rc3 and there's no change. Since this issue involves the external (although GPL'ed) zd1211 module: Is it really an ehci_hcd issue, or could there be a bug in the zd1211 driver causing this issue? This is definitely a problem with ehci-hcd and the EHCI hardware. Other people have seen the same thing, and in at least one case it was shown (by printk) that a routine in ehci-hcd was starting but never exiting. I have similar problem with EHCI on SMP. After some time of run of the system, I notice that interrupt counter of USB devices stops (in /proc/interrupts). The first visible thing is that USB moust stop run smouthly, it start jumping in about 1 second cycles, and in this time interrupt counters of USB don't increment. After stop of interrupts, system don't detect new USB devices. If I removed ehci_hcd module in this state, and loaded it again I received something like that in log: May 9 10:51:22 [kernel] ehci_hcd 0000:00:10.4: remove, state 1 May 9 10:51:22 [kernel] usb usb5: USB disconnect, address 1 May 9 10:51:22 [kernel] ehci_hcd 0000:00:10.4: USB bus 5 deregistered May 9 10:51:22 [kernel] ACPI: PCI interrupt for device 0000:00:10.4 disabled May 9 10:56:05 [kernel] ACPI: PCI Interrupt 0000:00:10.4[C] -> Link [ALKD] -> GSI 21 (level, low) -> IRQ 58 May 9 10:56:05 [kernel] ehci_hcd 0000:00:10.4: EHCI Host Controller May 9 10:56:05 [kernel] ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 5 May 9 10:56:05 [kernel] ehci_hcd 0000:00:10.4: irq 58, io mem 0xd2206c00 May 9 10:56:05 [kernel] ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 May 9 10:56:05 [kernel] usb usb5: configuration #1 chosen from 1 choice May 9 10:56:05 [kernel] hub 5-0:1.0: USB hub found May 9 10:56:05 [kernel] hub 5-0:1.0: 8 ports detected May 9 10:56:05 [kernel] usb 5-7: new high speed USB device using ehci_hcd and address 3 May 9 10:56:06 [kernel] ehci_hcd 0000:00:10.4: Unlink after no-IRQ? Controller is probably using the wrong IRQ. May 9 10:56:17 [kernel] usb 5-7: device not accepting address 3, error -110 May 9 10:56:17 [kernel] usb 5-7: new high speed USB device using ehci_hcd and address 4 May 9 10:56:28 [kernel] usb 5-7: device not accepting address 4, error -110 May 9 10:56:29 [kernel] usb 5-7: new high speed USB device using ehci_hcd and address 5 May 9 10:56:39 [kernel] usb 5-7: device not accepting address 5, error -110 May 9 10:56:39 [kernel] usb 5-7: new high speed USB device using ehci_hcd and address 6 May 9 10:56:50 [kernel] usb 5-7: device not accepting address 6, error -110 May 9 10:56:50 [kernel] usb 2-1: USB disconnect, address 3 May 9 10:56:50 [kernel] usb 2-1: new low speed USB device using uhci_hcd and address 4 May 9 10:56:53 [kernel] usb 2-1: configuration #1 chosen from 1 choice May 9 10:56:55 [kernel] input: Microsoft Microsoft Wheel Mouse Optical as /class/input/input3 May 9 10:56:55 [kernel] input: USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse Optical] on usb-0000:00:10.1-1 In that case USB mouse was in system all the time. When problem occured, I plugged USB stick, then unloaded ehci module, and loaded it again. When the problem occur, there is nothing in the log and dmesg. Created attachment 8067 [details]
dmesg of my system
Created attachment 8068 [details]
lspci
I'm also experiencing random/unexpected USB disconnects, even with different devices. I've seen this behaviour using two similar devices: a Linksys wusb54g and a Linksys wusb54gp. I've used different kernel versions, up to a suspend2-gentoo kernel (I know, it's not vanilla, but still): suspend2-sources-2.6.15-r8. I still have to try with later versions, even with a vanilla version, to make sure this still happens, but by the looks of it it seems to be the same bug. I have an Acer 1355LC laptop (VIA KM400) chipset, and I'm using ehci_hcd to handle the devices. As stated in other bug reports, everything seems to be working for a while (in my case, normally a few hours, even under heavy usage), and then, for no apparent reason... "usb disconnect". The devices work on another machine with a kernel from the same package (same sources), only compiled with some other options, because of the different hardware. But the USB options are similar. Please find the "dmesg", "lspci -v" and "cat /proc/cpuinfo" output, as well as my kernel config, as attachments. Please note that in the dmesg_01 output, the time between plugging the device and getting the "usb disconnect" is more than 3 hours. The error messages that ndiswrapper reports are usual, and I'm getting those on another machine that doesn't have this problem. Created attachment 8081 [details]
[ev] laptop - suspend2-sources-2.6.15-r8_04 - dmesg output
Created attachment 8082 [details]
[ev] laptop - suspend2-sources-2.6.15-r8_04 - 01 - lspci -v output
Created attachment 8083 [details]
[ev] laptop - suspend2-sources-2.6.15-r8_04 - 01 - cat /proc/cpuinfo output
Created attachment 8084 [details]
[ev] laptop - suspend2-sources-2.6.15-r8_04 - kernel config
Now tested against 2.6.16-suspend2-r4 (gentoo). Kernel config and dmesg output attached to this entry. Created attachment 8089 [details]
[ev] laptop - suspend2-sources-2.6.16-r4_01 - dmesg output
Created attachment 8090 [details]
[ev] laptop - suspend2-sources-2.6.16-r4_01 - kernel config
Sorry, I forgot to mention that the behaviour is still the same: it works for a few hours, then it "disconnects" itself. I disabled several things before leaving the machine pinging the router (so that "heavy usage" issues are discarded, considering the machine was doing nothing else): * cpufreqd (normally it shouldn't kick in anyway, but...) * vmware drivers * at BIOS setup: disabled "legacy USB support" (you can see that the kernel still loaded the uhci driver and successfully recognized the hardware as USB 1.1 compliant, though). Please note that the device still used ehci_hcd (usb 2.0), and it worked in the same way as before (that is, apparently successfully until the "usb disconnect"). Hi. More news on this issue. I've compiled 2.6.17-rc3 from the vanilla sources (no gentoo patches this time). I've also disabled the vmware drivers, but this time I left the cpufreqd daemon running. This time, the device stay connected close to the 12 hour mark, although this may just be circumstancial. The strangest thing is, the device seems to be working (at least the pings using the usb device still work), although not "completely". Using the network interface as such seems to be working ok, but: * any attempts to run lsusb are futile (processes are "hung"). * running programs that try to access the device directly (such as running "iwlist wlan0 scan") report error messages. This can also be seen in the kernel log I'm attaching. So in a way, it looks exactly as before, if you consider that I can't access the usb device as such, or the usb core with programs like "lsusb". *But* the network interface is still working. This never happened until now. I'll try and apply the patch attached to this bug later to test whether it changes anything. For now, I'm attaching my "dmesg" output and my kernel config. Hope this helps. Created attachment 8095 [details]
[ev] laptop - vanilla-sources-2.6.17_rc3_01 - dmesg output
Created attachment 8096 [details]
[ev] laptop - vanilla-sources-2.6.17_rc3_01 - kernel config
I've also tried with vanilla-sources-2.6.16.16 and vanilla-sources-2.6.17_rc4, but it's still not working. Note: the device *is* working on a different PC *and* it's also working as a USB 1.1 device on the very same laptop machine. I have exactly the same problem with an EPIA ME6000 (Via vt8235 southbridge) and a Cinergy T2 USB DVB-T box using kernel 2.6.17.1. The device works for some time (I have seen everything from 5 minutes to 5 hours) and then dies with usb 1-1: USB disconnect, address 2 It makes no difference if it is connected directly or using a powered hub or using an unpowered hub. Several people at vdrportal.de report this device working with similar drivers but other USB 2 hosts (and some have the same problem with EPIA boards using Via southbridges). Disabling ehci and sticking to USB 1 solves the issues but makes the device unusable as it needs USB 2 for operation (in USB 1 mode it acts only as a remote control receiver but for any period of time). It seems that (in USB 2 mode) it dies faster if the device is heavy used but it also occurs if there is only low traffic. dmesg etc. does not tell anything that was not reported in the other comments so I skip this. Well I've had one person confirm that the patch makes _their_ problem with VIA EHCI go away, so I've submitted it for merge to 2.6.19 ... However note that there are multiple problems here. One is the wedge in removing an URB from its queue ... where VIA's EHCI silicon has always needed a bug workaround, improved in that patch. Another problem is as noted in Comment #8 ... it's not just the IAA IRQ that stops arriving, it's _all_ IRQs. Of course #8 indicates an IRQ routing problem (notice the "no-irq" message), potentially resolved in more current kernels. (VIA has IRQ routing quirks that have never been handled quite right...) And a third seems to be the spontaneous "disconnect", which I don't recall being reported on non-VIA hardware. It's unclear whether that would stop once the first two vanish, but in any case it's clearly the hardware which is misbehaving. (I hate to say it but I've explicitly avoided systems with VIA hardware since in my experience it's been so flakey...) I'll ask folk to try reproducing this after 2.6.18 ships and the first batch of USB patches goes upstream, with that unlink patch. This sounds promising! As testing is not that simple (the machine is my video disk recorder and therefore can be used for testing only in a limited way) but I want to help and I want to test the patch - would you test it with the installed 2.6.17.1 or better change to the latest 2.6.18-pre-whatever (which could imply problems with the other components of the system)? If I understand you correctly the patch was developed for 2.6.17-pre so it could be even better to stay with 2.6.17.1 for the test, right? Regarding VIA... after the experience with that EPIA-board (which is not really low cost) and the non-existing help from VIA (they even did not respond to similar reports in their own forum) I stopped buying VIA-equipped hardware but I still habe to live with that little thing. Hi again, in the meantime 2.6.18 is released so I was able to test the patch against this. It was necessary to add one missing "break;" statement in order to compile ehci-hcd.c. It was pretty stable for one hour... than it died again with "USB disconnect" so this patch unfortunately does not solve that part (the third part) of the problem. I also tested with 2.6.17.1 with no USb disconnect but this was probably due to the short test time (only few hours... sometimes it takes days to occure, sometimes minutes). So I will continue solving the problem by finding another board that fits into the home made HTPC-box and does not include any VIA components... :-( Jan I believe I'm experiencing the same bug described here. To reproduce it quickly
and semi-reliably, I generate a ton of incoming traffic with my iPod Nano like so:
dd if=/dev/sda bs=4096 count=276072 | cat | wc -c
A disconnect usually results before 400M is transfered. If any of you have
memory sticks, this might also work for you.
I'd be willing to test any patches for this. Here's the last few kernel messages
I get before dd hangs in state D, along with any new lsusb processes. They seem
similar to the messages which started this thread.
Dec 28 20:45:31 eggnog kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0008
Dec 28 20:45:31 eggnog kernel: ehci_hcd 0000:00:10.3: GetStatus port 3 status
00180b POWER sig=j PEC CSC CONNECT
Dec 28 20:45:31 eggnog kernel: hub 4-0:1.0: port 3, status 0501, change 0003,
480 Mb/s
Dec 28 20:45:31 eggnog kernel: usb 4-3: USB disconnect, address 3
Dec 28 20:45:31 eggnog kernel: usb 4-3: unregistering device
Dec 28 20:45:31 eggnog kernel: usb 4-3: usb_disable_device nuking all URBs
Dec 28 20:45:31 eggnog kernel: ehci_hcd 0000:00:10.3: shutdown urb ec906360 pipe
c0008380 ep1in-bulk
Dec 28 20:46:01 eggnog kernel: usb 4-3: usb_sg_cancel, unlink --> -19
Here's my VIA USB controllers as they show up in lspci -v:
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80) (prog-if 00 [UHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer: Unknown device a232
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at d800 [size=32]
Capabilities: <available only to root>
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20
[EHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer: Unknown device a232
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at e6000000 (32-bit, non-prefetchable) [size=256]
Created attachment 9959 [details]
Complete 2.6.19.1 kern.log for my VIA EHCI disconnect
Is this still happening with 2.6.22-rc4? Thanks, --Natalie Please reopen this bug if it's still present with kernel 2.6.22. Please reopen! The problem remains unsolved up until 2.6.23-rc6. I've tried next to all major+minor releases since 2.6.18. Disabling EHCI brings a few days more uptime. But the issue shows up in any case with next to any sys configuration; in and excluding SMP/Preempt/ACPI and some other stuff. Just minor variations in uptime. Only disabling EHCI seems to make a statistic relevant difference. However, quite a few people using the EPIA ME-6000 have reported this issue and it would be great to have a fix as these boards are often used as headless servers/for HTPC application. I can provide any further data, test any configuration. Can you please attach boot log, lspci -vv, any error messages from other logs that you see, and /proc/interrupts, and your system/chipset, to make sure this is same problem. Thanks. Please look also at Bug #8692, which includes some test patches for the 2.6.22 kernel. In particular, try using the patches in comments #18 and #38 of that bug report. Just so we don't miss another data point: we just closed bug #6708 because of reporter won't reply, but that was the same error as the one reported here originally, and reporter stated that 2.6.15 was free from this bug. As described in comment #25, there actually are 3 separate (possibly related) bugs mentioned in this bug report: (1) Spontaneous disconnects (2) EHCI interrupts stop occurring (3) Khubd hangs in D state The patches in Bug #8692 are meant to help with (3). We can't help with (1) or (2) because we don't know what causes them or how to prevent them. We also don't know of any kernel in which these bugs don't occur. Can anybody please try out 2.6.15 (or even earlier versions) to see if they also have these bugs? Oha. I applied the patch from #8692, comment #38, and successfully recompiled the 2.6.23-rc6 kernel. The box has been operating stable for one and a half days... with a NEC USB Card, as you proposed in another thread. But thats not really a solution as the (only :/) PCI-Slot in the little box usually carries a DVB-S card. I will write back when system is back on my desk and wired up. I'm having the same USB troubles with my VIA chipset. The things I've figured out so far: 2.6.25-rc3 -> Spontaneous disconnects, Khubd keeps responding, device is reassigned in companion mode (see log with usb debugging enabled) 2.6.24 -> Spontaneous disconnects, Khubd hangs in D state 2.6.15 -> Spontaneous disconnects, whole system seems to slow down and becomes not responding (it's quite hard to get a remote terminal for sysrq reboot) < 2.6.15 -> I will try earlier kernel versions and report the results --- Feb 26 17:37:12 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:12 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 00100a POWER sig=se0 PEC CSC Feb 26 17:37:12 vdr kernel: hub 4-0:1.0: port 2, status 0100, change 0003, 12 Mb/s Feb 26 17:37:12 vdr kernel: usb 4-2: USB disconnect, address 2 Feb 26 17:37:12 vdr kernel: usb 4-2: unregistering device Feb 26 17:37:12 vdr kernel: usb 4-2: usb_disable_device nuking all URBs Feb 26 17:37:12 vdr kernel: ehci_hcd 0000:00:10.3: shutdown urb dde369c0 ep1in-bulk Feb 26 17:37:12 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:12 vdr kernel: usb 4-2: unregistering interface 4-2:1.0 Feb 26 17:37:12 vdr kernel: ndiswrapper: device wlan1 removed Feb 26 17:37:12 vdr kernel: usb 4-2:1.0: uevent Feb 26 17:37:12 vdr kernel: usb 4-2: uevent Feb 26 17:37:12 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT Feb 26 17:37:13 vdr kernel: hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Feb 26 17:37:13 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:13 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT Feb 26 17:37:13 vdr kernel: usb 4-2: new high speed USB device using ehci_hcd and address 3 Feb 26 17:37:18 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:18 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:23 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:23 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:28 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:28 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:28 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:28 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 00100f POWER sig=se0 PEC PE CSC CONNECT Feb 26 17:37:28 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:28 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:28 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT Feb 26 17:37:28 vdr kernel: hub 4-0:1.0: port 2, status 0501, change 0001, 480 Mb/s Feb 26 17:37:28 vdr kernel: hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Feb 26 17:37:28 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:28 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT Feb 26 17:37:28 vdr kernel: usb 4-2: new high speed USB device using ehci_hcd and address 4 Feb 26 17:37:33 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:33 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:38 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:38 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:43 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:43 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:43 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:43 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 00100f POWER sig=se0 PEC PE CSC CONNECT Feb 26 17:37:43 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:43 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:43 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT Feb 26 17:37:43 vdr kernel: hub 4-0:1.0: port 2, status 0501, change 0001, 480 Mb/s Feb 26 17:37:43 vdr kernel: hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Feb 26 17:37:43 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:43 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT Feb 26 17:37:43 vdr kernel: usb 4-2: new high speed USB device using ehci_hcd and address 5 Feb 26 17:37:48 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:48 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:53 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:53 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:58 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:37:58 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:37:58 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:58 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 00100f POWER sig=se0 PEC PE CSC CONNECT Feb 26 17:37:58 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:58 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:37:58 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT Feb 26 17:37:58 vdr kernel: hub 4-0:1.0: port 2, status 0501, change 0001, 480 Mb/s Feb 26 17:37:58 vdr kernel: hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Feb 26 17:37:59 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:37:59 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT Feb 26 17:37:59 vdr kernel: usb 4-2: new high speed USB device using ehci_hcd and address 6 Feb 26 17:38:04 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:38:04 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:38:09 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:38:09 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:38:14 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:38:14 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:38:14 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:38:14 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 00100f POWER sig=se0 PEC PE CSC CONNECT Feb 26 17:38:14 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:38:14 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:38:14 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT Feb 26 17:38:14 vdr kernel: hub 4-0:1.0: port 2, status 0501, change 0001, 480 Mb/s Feb 26 17:38:14 vdr kernel: hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 Feb 26 17:38:14 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:38:14 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT Feb 26 17:38:14 vdr kernel: usb 4-2: new high speed USB device using ehci_hcd and address 7 Feb 26 17:38:19 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:38:19 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:38:24 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:38:24 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:38:29 vdr kernel: ehci_hcd 0000:00:10.3: IAA watchdog: status a008 cmd 10069 Feb 26 17:38:29 vdr kernel: usb 4-2: khubd timed out on ep0in len=0/64 Feb 26 17:38:29 vdr kernel: ehci_hcd 0000:00:10.3: port 2 high speed Feb 26 17:38:29 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 00100f POWER sig=se0 PEC PE CSC CONNECT Feb 26 17:38:29 vdr kernel: usb usb1: wakeup_rh (auto-start) Feb 26 17:38:29 vdr kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0004 Feb 26 17:38:29 vdr kernel: ehci_hcd 0000:00:10.3: GetStatus port 2 status 003802 POWER OWNER sig=j CSC Feb 26 17:38:29 vdr kernel: hub 4-0:1.0: port 2, status 0100, change 0001, 12 Mb/s Feb 26 17:38:29 vdr kernel: hub 4-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100 Feb 26 17:38:29 vdr kernel: hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0004 Feb 26 17:38:29 vdr kernel: uhci_hcd 0000:00:10.0: port 2 portsc 0093,00 Feb 26 17:38:29 vdr kernel: hub 1-0:1.0: port 2, status 0101, change 0001, 12 Mb/s Feb 26 17:38:29 vdr kernel: hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x101 Feb 26 17:38:29 vdr kernel: usb 1-2: new full speed USB device using uhci_hcd and address 2 Feb 26 17:38:30 vdr kernel: usb 1-2: not running at top speed; connect to a high speed hub Feb 26 17:38:30 vdr kernel: usb 1-2: default language 0x0409 Feb 26 17:38:30 vdr kernel: usb 1-2: uevent Feb 26 17:38:30 vdr kernel: usb 1-2: usb_probe_device Feb 26 17:38:30 vdr kernel: usb 1-2: configuration #1 chosen from 1 choice Feb 26 17:38:30 vdr kernel: usb 1-2: adding 1-2:1.0 (config #1, interface 0) Feb 26 17:38:30 vdr kernel: usb 1-2:1.0: uevent Feb 26 17:38:30 vdr kernel: ndiswrapper 1-2:1.0: usb_probe_interface Feb 26 17:38:30 vdr kernel: ndiswrapper 1-2:1.0: usb_probe_interface - got id Feb 26 17:38:30 vdr kernel: usb 1-2: reset full speed USB device using uhci_hcd and address 2 Feb 26 17:38:30 vdr kernel: ndiswrapper: driver rt73 (Ralink,01/12/2006, 1.00.04.0000) loaded Feb 26 17:38:31 vdr kernel: wlan0: ethernet device 00:0e:2e:dc:0d:a0 using NDIS driver: rt73, version: 0x0, NDIS version: 0x500, vendor: 'IEEE 802.11g Wireles s Card.', 148F:2573.F.conf Feb 26 17:38:31 vdr kernel: wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK Feb 26 17:38:31 vdr kernel: drivers/usb/core/inode.c: creating file '002' Feb 26 17:38:31 vdr kernel: usb 1-2: New USB device found, idVendor=148f, idProduct=2573 Feb 26 17:38:31 vdr kernel: usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Feb 26 17:38:31 vdr kernel: usb 1-2: Product: 802.11 bg WLAN Feb 26 17:38:31 vdr kernel: usb 1-2: Manufacturer: Ralink |