On Thu, 19 Oct 2006, David Brownell wrote: > Just a quick note about problems I observed with RC2 ... I don't have > time to track it down just yet unfortunately, so what we have here is > just some bug reporting. > > 0 Connect an FT232B based device to root hub, it's handed to OHCI. > (The problem has nothing to do with that device or its driver.) > > 1 Hotplugs to ftdi_sio, ok that's as expected. (But, advance notice > of a glitch: it uses address 3, not address 2, despite being the > first device connected to this root hub ...) > > 2 Now rmmod ftdi_sio, since this needs to use libftdi to bitbang > some stuff before rs232 connections can be useful. > > 3 Run userspace tool that connects via usbfs ... and now the > device instantly gets kicked off. The device can't be used > with usbfs any more !! > > 4 Hey, this sucks ... the device now has ftdi_sio bound to it, > completely the wrong result. > > 5 Goto 2 ... or if after disabling hotplug for the ftdi_sio driver, > just repeat 3 forever. > > It seems that every time a device enumerates, it autosuspends until > a driver appears, then it's kicked off and must re-enumerate (hence > address 3 not 2). > > The can't-work-with-this regression is that this means nothing > which needs usbfs can work with OHCI any more. That seems to be > a secondary failure though -- side effect of autosuspend bugs.
I'll have to take a look at this over the weekend. I don't remember seeing anything like it in previous testing with OHCI, but I wasn't running 2.6.19-rc2 at the time. > Now, the first clue I can offer is that when I looked at the OHCI > root hub in this "autosuspend" state, it was clearly in a bogus > state, since the root hub was not correctly suspended ... it was > not in the SUSPENDED state. (A regression.) I'm speculating > that's the root cause of the other regression, with usbfs. That's not a bogus state at all. Look again; the root hub wasn't autosuspended, only one of its ports was. This isn't to say you didn't encounter any errors or unexpected behaviors. But the root hub's state wasn't part of it. > Anyway, that's it for the moment ... annotated dmesg output is > attached, and I'm reverting to an older kernel for now. > > - Dave > > > Port handed off from EHCI to OHCI, enumerates as address #2: > > ohci_hcd 0000:00:02.1: wakeup > hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0002, resume root > ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00010101 CSC PPS > CCS > hub 3-0:1.0: port 1, status 0101, change 0001, 12 Mb/s > hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 > ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS > PES CCS > usb 3-1: new full speed USB device using ohci_hcd and address 2 > ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS > PES CCS > usb 3-1: ep0 maxpacket = 8 > usb 3-1: default language 0x0409 > usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0 > usb 3-1: Product: USB <-> Serial > usb 3-1: Manufacturer: FTDI > PM: Adding info for usb:3-1 > usb 3-1: uevent > usb 3-1: usb_probe_device > PM: Adding info for No Bus:usbdev3.2_ep00 > usb 3-1: configuration #1 chosen from 1 choice > usb 3-1: adding 3-1:1.0 (config #1, interface 0) > PM: Adding info for usb:3-1:1.0 > usb 3-1:1.0: uevent > PM: Adding info for No Bus:usbdev3.2_ep81 > PM: Adding info for No Bus:usbdev3.2_ep02 > drivers/usb/core/inode.c: creating file '002' > > No driver yet, so ... > > usb 3-1: usb auto-suspend All as it should be. Notice that the autosuspend is for 3-1, not usb3: the ftdi device, not the root hub. Too bad you don't have timestamps in the log; they would show the autosuspend occurring 2 seconds after the configuration was set. I've seen the same thing happen many times. It's very puzzling; why should the hotplug system take more than two seconds to locate and install a driver for a new device? Does udev have some sort of built-in delay? > At which point -- based on later observation -- the problem > seems to be that the root hub is in a bogus state: > > - port 1 enabled and suspended > - ports 2 and 3 unconnected > - root hub OPERATIONAL not SUSPENDED > > I'm speculating that last is the root cause of the other issues > here ... it's a regression, since previously the driver would have > (properly) put the controller into its low power state. No, this isn't a bogus state. It's perfectly correct and as intended: a selective suspend of port 1. When the remaining part of the USB autosuspend code gets merged, the root hub _would_ suspend after an additional 2-second delay. Except that the usb-serial driver would be loaded by then... > usbcore: registered new interface driver usbserial > drivers/usb/serial/usb-serial.c: USB Serial Driver core > drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB > Serial Device > ftdi_sio 3-1:1.0: usb_probe_interface > ftdi_sio 3-1:1.0: usb_probe_interface - got id > > ... now there's a driver, so ... > > usb 3-1: usb auto-resume > hub 3-0:1.0: port 1 status 0000.0107 after resume, 0 > > That is, status == POWER, SUSPEND, ENABLE, CONNECTION. Here's where the funny business starts. > The port was never resumed ... I'm guessing that the root hub > resume path never got executed since the root hub didn't get > suspended, it of course couldn't be resumed, ergo confusion ... You're right that the root-hub resume path never got executed. But the ClearPortFeature(suspend) path did run -- or at least it was supposed to run -- and it didn't work. 25 ms after the hub driver tried to turn off the suspend feature, the port was still suspended. If you want to take time to look further into this, a good way to start would be by making certain that the USB_PORT_FEAT_SUSPEND case in the ClearPortFeature code really did run. > And in this case the confusion was _partially_ recovered > from by disconnecting the device: > > hub 3-0:1.0: logical disconnect on port 1 That's normal. The hub driver sees that a port resume failed (the port is still suspended) and reacts by initiating a logical disconnect. > hub 3-0:1.0: state 7 ports 3 chg 0002 evt 0000, resume root Here's another funny thing. Why is "resume root" turned on? For that matter, why did we have "resume root" at the start of the log? The OHCI_INTR_RD processing in ohci_irq() should have seen that ohci->autostop was set and therefore avoided calling usb_hcd_resume_root_hub(). If you want to do some more debugging, try to find out exactly where and why usb_hcd_resume_root_hub() was called. There aren't many possibilities. > usb 3-1: can't resume, status -19 > hub 3-0:1.0: port 1, status 0107, change 0000, 12 Mb/s > usb 3-1: USB disconnect, address 2 > usb 3-1: unregistering device > usb 3-1: usb_disable_device nuking all URBs > usb 3-1: unregistering interface 3-1:1.0 > PM: Removing info for No Bus:usbdev3.2_ep81 > usbdev3.2_ep81: ep_device_release called for usbdev3.2_ep81 > PM: Removing info for No Bus:usbdev3.2_ep02 > usbdev3.2_ep02: ep_device_release called for usbdev3.2_ep02 > PM: Removing info for usb:3-1:1.0 > usb 3-1:1.0: uevent > PM: Removing info for No Bus:usbdev3.2_ep00 > usbdev3.2_ep00: ep_device_release called for usbdev3.2_ep00 > PM: Removing info for usb:3-1 > usb 3-1: uevent > ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00040103 PSSC PPS > PES CCS Now finally the PSSC (Port Suspend Status Change) bit is set and PSS is clear, so the port has resumed. Of course it's far too late... > ohci_hcd 0000:00:02.1: GetStatus roothub.portstatus [0] = 0x00100103 PRSC PPS > PES CCS > > Dunno if this is a regression, but it's clearly wrong to have > a disconnect _not_ involve the port going back to EHCI ... it > may be because "logical" disconnect was (wrongly) invoked, and > that doesn't do the full dance. That's right. A logical disonnect isn't a physical disconnect, and the port-routing switch responds to physical events. > At any rate, next we see a normal enumeration with the device > getting a NEW ADDRESS, and bound to ftdi_sio. Binding is fine, > the enumeration (and new address) is not. And the rest is largely a repeat of what came before... Like I said, I'll try to reproduce this on my machine. The main question is why didn't the port resume work? Alan Stern ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
