On Tue, 28 Sep 2004, David Brownell wrote: > Well, it didn't necessarily work right with just UHCI either, but the disk > corruption sounds orthogonal to usbcore.
I agree. Although the underlying causes may be related. > The most interesting issue > in the debug log here is when khubd asked UHCI to do something with > the iPod's port, but the actual result was to hand the port back to EHCI > in some broken state. > > Multiple things are goofy here. Do non-iPod full-speed devices work > OK, or is it just an iPoddity? Does it work with other USB 2.0 hosts, > like some non-laptop Intel box? Is that "infinite reset loop" new in > rc2, or did it happen in earlier kernels too? > > > > Sep 26 07:17:52 doolittle kernel: ehci_hcd 0000:00:1d.7: GetStatus port > > 4 status 001803 POWER sig=j CSC CONNECT > > Sep 26 07:17:52 doolittle kernel: hub 4-0:1.0: port 4, status 0501, > > change 0001, 480 Mb/s > > Sep 26 07:17:52 doolittle kernel: hub 4-0:1.0: debounce: port 4: total > > 100ms stable 100ms status 0x501 > > Sep 26 07:17:52 doolittle kernel: hub 4-0:1.0: port 4 not reset yet, > > waiting 50ms > > Sep 26 07:17:52 doolittle kernel: ehci_hcd 0000:00:1d.7: port 4 full > > speed --> companion > > Sep 26 07:17:52 doolittle kernel: ehci_hcd 0000:00:1d.7: GetStatus port > > 4 status 003801 POWER OWNER sig=j CONNECT > > At this point, there's nothing else EHCI does with the port. It's > all up to UHCI to enumerate, retry, etc. > > > > Sep 26 07:17:52 doolittle kernel: uhci_hcd 0000:00:1d.1: port 2 portsc 0083 > > Sep 26 07:17:52 doolittle kernel: hub 2-0:1.0: port 2, status 0101, > > change 0001, 12 Mb/s > > Sep 26 07:17:52 doolittle kernel: uhci_hcd 0000:00:1d.1: wakeup_hc > > Sep 26 07:17:52 doolittle kernel: hub 2-0:1.0: debounce: port 2: total > > 100ms stable 100ms status 0x101 > > Presumably it didn't forget 50msec of reset signaling here, right? The 50ms delay is built into the UHCI hub driver. There's no debugging output associated with it. > > Sep 26 07:17:52 doolittle kernel: uhci_hcd 0000:00:1d.1: > > uhci_result_control: failed with status 440000 > > Sep 26 07:17:52 doolittle kernel: [f7f54240] link (37f541e2) element > > (37f55040) > > Sep 26 07:17:52 doolittle kernel: 0: [f7f55040] link (37f55080) e0 > > Stalled CRC/Timeo Length=7 MaxLen=7 DT0 EndPt=0 Dev=0, PID=2d(SETUP) > > (buf=37039b00) > > Sep 26 07:17:52 doolittle kernel: 1: [f7f55080] link (00000001) e3 IOC > > Active Length=0 MaxLen=7ff DT1 EndPt=0 Dev=0, PID=69(IN) (buf=00000000) > > Sep 26 07:17:52 doolittle kernel: > > Sep 26 07:17:52 doolittle kernel: uhci_hcd 0000:00:1d.1: > > uhci_result_control: failed with status 440000 > > ... retries ... > > Sep 26 07:17:55 doolittle kernel: uhci_hcd 0000:00:1d.1: port 2 portsc 0082 > > Sep 26 07:17:55 doolittle kernel: hub 2-0:1.0: port 2, status 0100, > > change 0001, 12 Mb/s > > Sep 26 07:17:55 doolittle kernel: hub 2-0:1.0: debounce: port 2: total > > 100ms stable 100ms status 0x100 > > OK, this is odd. Right here EHCI gets Connect Status Change; UHCI > let loose of this port. Did the logical disconnect or reset changes > make trouble here? It's not clear how that could work. The "status 0100, change 0001" indicates that UHCI really did see an electrical disconnect. Disabling the port (which is all a logical disconnect does) wouldn't cause that to happen. > What I'd expect right here is UHCI resetting again ... debounce is not > needed (but maybe it's been there before). I made khubd do a debounce for disconnects as well as for connects. That's why it shows up here; khubd thinks the iPod disconnected since UHCI told it so. > Then try to enumerate > again. Instead, UHCI just gave the port back to EHCI. Presumably > it's actually a goof by khubd or the UHCI root hub, not the iPod actually > triggering a soft disconnect. Hard to tell, isn't it? From the log, it sure does look like the iPod actually did a soft disconnect. That's what the kernel thinks happened, anyway. I don't know anything about how the dual EHCI-UHCI setup works. How does the UHCI controller give the port back to the EHCI controller? There's nothing in the UHCI driver to account for it. I've been assuming this was all handled by hardware associated with the controllers and it could only be triggered by an actual disconnect. > > Sep 26 07:17:55 doolittle kernel: ehci_hcd 0000:00:1d.7: GetStatus port > > 4 status 001002 POWER sig=se0 CSC > > Sep 26 07:17:55 doolittle kernel: hub 4-0:1.0: port 4, status 0100, > > change 0001, 12 Mb/s > > Sep 26 07:17:55 doolittle kernel: hub 4-0:1.0: debounce: port 4: total > > 100ms stable 100ms status 0x100 > > Sep 26 07:17:56 doolittle kernel: uhci_hcd 0000:00:1d.1: suspend_hc > > Sep 26 07:17:56 doolittle kernel: ehci_hcd 0000:00:1d.7: GetStatus port > > 4 status 001803 POWER sig=j CSC CONNECT > > Sep 26 07:17:56 doolittle kernel: hub 4-0:1.0: port 4, status 0501, > > change 0001, 480 Mb/s > > Sep 26 07:17:56 doolittle kernel: hub 4-0:1.0: debounce: port 4: total > > 100ms stable 100ms status 0x501 > > Sep 26 07:17:56 doolittle kernel: hub 4-0:1.0: port 4 not reset yet, > > waiting 50ms > > Sep 26 07:17:56 doolittle kernel: ehci_hcd 0000:00:1d.7: GetStatus port > > 4 status 001002 POWER sig=se0 CSC > > Sep 26 07:17:56 doolittle kernel: ehci_hcd 0000:00:1d.7: GetStatus port > > 4 status 001803 POWER sig=j CSC CONNECT > > .... > > > > (and these messages go on and on...) > > Well, it looks like not only did UHCI give the port back to EHCI, but > it first put it into a really wierd mode where it can't reset again. How could UHCI do that? All that happened was UHCI disabled the port. Should that have affected the EHCI controller at all? > That "goes on and on" behavior is trouble, likely from one of > the recent khubd changes. I've seen similar trouble from > an RC2 kernel when an OHCI root hub port misbehaved ... > seems like disabling a port doesn't "stick" the way it used to. Or resetting the port causes EHCI to think a disconnect occurred... Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
