On Fri, Dec 29, at 10:31AM(-0500), Alan Stern wrote: > On Thu, 28 Dec 2006, Vermont wrote: > > To trigger the disconnect, I run > > > > dd if=/dev/sda bs=4096 count=276072 | cat | wc -c > > Just out of curiosity, why do you include the "cat" in this pipeline? Not > that it's wrong, but it doesn't seem to add anything either.
Since dd hangs in state D and becomes unkillable, sandwiching cat in the pipeline allows killing cat and causing wc to print its count. Rather than cat | wc -c, something like dd which will print its transfer count upon signal would also work. For what it's worth, here's a few vague observations: Running dd if=/dev/sda of=/dev/null bs=4096 without X or much else running appears to take much longer to trigger a disconnect. I've been able to make Windows hard lock on the same computer by running dd for a while in Cygwin. I don't have non-VIA USB 2.0 ports to test with the iPod yet. Unplugging the device without ejection results in the disconnect message but not a hung khubd process. Also, the last time the spurious disconnect occurred there were three "shutdown urb" messages. Dec 31 00:11:42 eggnog kernel: ehci_hcd 0000:00:10.3: shutdown urb ece6c9e0 pipe c0008380 ep1in-bulk Dec 31 00:11:42 eggnog kernel: ehci_hcd 0000:00:10.3: shutdown urb eda12540 pipe c0008380 ep1in-bulk Dec 31 00:11:42 eggnog kernel: ehci_hcd 0000:00:10.3: shutdown urb ece6c960 pipe c0008380 ep1in-bulk > > 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 > > As Pete said, the disconnect was genuine -- caused by the iPod for no > apparent reason. Without knowing the cause, I don't see how we can > prevent it. The recovery should be smoother, though... That VIA bug has > caused difficulties for many people. Are the disconnects here also genuine? http://bugzilla.kernel.org/show_bug.cgi?id=6374 If not, is the difference between evt 0002 and evt 0008? Here's a dump from my hung 2.6.19.1 khubd process: khubd D EFF2D070 0 1660 5 2903 1659 (L-TLB) efeece18 00000046 00005d63 eff2d070 efed1560 efde4ba0 efec0b64 0000000a efed1560 8cead800 000002e4 00000000 efed166c efeece2c c0316880 003d0900 00000000 efeece2c 000afd21 e913f0d8 ef26d180 c0254418 0000029c 003d0900 Call Trace: [schedule_timeout+131/160] schedule_timeout+0x83/0xa0 [process_timeout+0/5] process_timeout+0x0/0x5 [<f08b6a84>] ehci_endpoint_disable+0xa9/0x166 [ehci_hcd] [<f0898414>] unlink1+0x89/0xc1 [usbcore] [<f0899197>] usb_hcd_endpoint_disable+0x1bd/0x223 [usbcore] [<f089a0d5>] usb_disable_device+0x71/0x144 [usbcore] [<f08960d5>] usb_disconnect+0xbe/0x11b [usbcore] [<f08970ef>] hub_thread+0x53d/0xdb4 [usbcore] [autoremove_wake_function+0/53] autoremove_wake_function+0x0/0x35 [<f0896bb2>] hub_thread+0x0/0xdb4 [usbcore] [kthread+173/216] kthread+0xad/0xd8 [kthread+0/216] kthread+0x0/0xd8 [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
