On Friday 20 October 2006 8:21 am, Alan Stern wrote: > On Thu, 19 Oct 2006, David Brownell wrote: > > > 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.
You might not have tested with usbfs either ... or have noticed that glitch with the strange address assignments. > > 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 ... > 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 ... > 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...) > > 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. Hmm. After I wrap up this other stuff, maybe. ISTR some changes you did that may have gotten khubd out of certain loops, and maybe that's part of the problem. > > 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. > 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. Well, the root hub _would_ normally have been suspended at that point, but wasn't. Again this points to changes in the root hub handling. > 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. - Dave ------------------------------------------------------------------------- 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
