On Monday 27 September 2004 11:25 am, Alan Stern wrote: > David: > > I've been seeing a lot of complaints recently about problems assigning > device addresses. Like in this case, where apparently a full speed device > only works when the EHCI driver isn't loaded. Any idea what's going on?
Well, it didn't necessarily work right with just UHCI either, but the disk corruption sounds orthogonal to usbcore. 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? > 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? What I'd expect right here is UHCI resetting again ... debounce is not needed (but maybe it's been there before). 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. > 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. 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. - Dave ------------------------------------------------------- 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
