On Sun, 31 Dec 2006, Vermont wrote:
> 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.
Hard to say whether this is meaningful or not.
> 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.
Very interesting... If Windows can't handle the hardware either then
Linux's problems seem more understandable.
> Unplugging the device without ejection results in the disconnect
> message but not a hung khubd process.
The two situations aren't exactly parallel. With unplugging you have a
disconnect, but when the problem occurs the computer sees a disconnect
immediately followed by a re-connect.
You know, it is possible that those spurious disconnects actually result
from a bug in the VIA controller and not from anything done by the iPod.
Again, there's no way to tell for sure until you can try it out with a
non-VIA controller.
> 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
The number of those messages isn't particularly important. It merely
indicates that 3 scatter-gather I/O requests were still pending when the
disconnect occurred.
> > > 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
The important things here are the CSC ("Connect Status Change"; it's the
controller's indication of a disconnection) and CONNECT (the current
status; it implies the iPod re-connected after the disconnect).
> > > 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
Presumably you mean the disconnects show in the original bug submission
and in Comment #28. Yes, they are "genuine" because they both show CSC.
I put "genuine" in quotes here because I mean that the controller _thinks_
there was a disconnect. It's just as bad as having a real, physical
disconnect, but it could be caused by a bug in the controller rather than
an actual electrical disconnect.
> If not, is the difference between evt 0002 and evt 0008?
Those numbers refer to the port on which the event occurred. 0002 means
port 1 and 0008 means port 3.
> 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
This is typical of what happens with those buggy VIA controllers. The
khubd process enters ehci_endpoint_disable() and never leaves, because the
necessary interrupt request gets lost.
Alan Stern
-------------------------------------------------------------------------
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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
