On Fri, 20 Oct 2006, David Brownell wrote: > > > 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. > > It's a regression, and "bogus" in the sense that state never would > have existed before. That's exactly the sort of thing that's very > likely to trigger never-existed-before (== untested, == unreliable) > code paths ...
Yes, it is a new state (i.e., one we haven't implemented until now). It's a little unfortunate that the set of patches got pushed up to Linus so quickly -- just bad timing. Anyway, I trust we can fix things before 2.6.19 is finalized. To me, "bogus" means invalid, illegal, forbidden by the spec. In that respect the state is not "bogus". > > 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. > > In the sense that it's a new and never-used-before state, I don't > see how you could realistically make that claim ... I meant that the state wasn't an error and should not in itself have caused any unexpected behavior. Untested pathways in the driver, on the other hand, could easily account for such things. > > 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... > > Still doesn't change the point I was making: that your patches have > added a new state to the OHCI driver, one that never existed before > and which accordingly should not be expected to work. (A state, BTW, > which is pointless...) Well, it worked in my tests. Limited though they were. As for the new state being pointless, that's a topic for a separate discussion... > > 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. > > Hmm. After I wrap up this other stuff, maybe. I'm just building 2.6.19-rc2, so we'll see what happens with the OHCI controllers on my machine. > ISTR some changes you did that may have gotten khubd out of certain > loops, and maybe that's part of the problem. I don't know what you're thinking of. Anyway, time will tell. > > > 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 > > ... which was not invoked! And should not have been, since > the root hub wasn't suspended, and since the event in question > wasn't externally triggered. Terminology problem here. We've run across this difficulty before. When I say the root is suspended, I mean that usbcore has called hcd_bus_suspend() and hence hcd->driver->bus_suspend(). That didn't happen here. Instead the root hub was auto-stopped -- which is exactly the same as being suspended as far as the hardware is concerned but differs in how the software views it. (This wasn't obvious in the log, by the way. But the very first line does at least indicate some sort of root-hub wakeup.) When you first plugged in the ftdi device, that triggered the wakeup (i.e., auto-start) at the beginning of the log. But there should not have been any resume_root_hub request. > > Like I said, I'll try to reproduce this on my machine. The main question > > is why didn't the port resume work? > > Very likely that's related to the first thing that went wrong: the root > hub state was not as expected. Not just sitting annoyingly in OPERATIONAL > state, but also that "resume root" thing you noted. Those are software differences, not hardware differences. If the ClearPortFeature(suspend) pathway was invoked correctly they shouldn't cause this misbehavior. 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
