On Fri, 23 Jan 2004, Axel Waggershauser wrote: > > That's progress. I think that 9 vs. 1 may be connected with the relative > > timing of the retry mechanism and the hub status polling. However, it > > would be nice if the driver worked correctly even when you perform an > > illegal disconnect. > > I definitely agree with you. First I was afraid that the only "correct" > way a disconnect is detected is through the controller as you stated and > that the problems I have are indeed solely "electrical". I tried to find > something in the spec about that and got the impression that there are > other "valid" disconnect detection ways. A Loss Of Activity condition > could be what I establish with my power disconnect. But I got the > impression I would have to study the spec a _lot_ before I really > understand what is supposed to happen.
The more low-level electrical parts of the standard are hard to figure out (for me, at least). But regardless of the details of the signalling, the host controller should realize there's a problem when it fails to get a response from the device. That should happen even if the device _doesn't_ disconnect but only stops responding. > I tend to disagree with you on that count. I found explicit mentioning > of an interrupt to be expected when the controller resumes (4.2.1 in > uhci11d.pdf) but nothing equivalent about the suspension. Looking back at the spec, I see you are right. I assumed that all the bits in the status register would trigger an interrupt, but it does not say that they will. > > On the whole, it look like you're running up across one of the entries on > > my list of UHCI driver problems, although in a very severe form. The > > basic problem is that the driver doesn't handle unlinking correctly when > > the controller is suspended or reset. The unlink procedure is > > interrupt-driven, but there aren't any interrupts when the controller > > isn't running. And for you it's even worse, since there isn't an > > interrupt to mark when the controller is suspended. > > > > Below is a quick patch that may help solve this problem. It's not a > > proper fix -- I wasn't too careful about some things, it's rather > > inelegant, and it totally ignores proper locking. Actually, the driver > > needs so many other changes that it's not worth spending much time on > > this one issue until some of the others have been addressed. > > > > Anyway, try the patch and tell how it works out. > > The patch works ... sort of (:-)). It seems to effectively prevent the > urb-gets-not-unlinked problem. But on the other hand, it has the same > problem than my mentioned panic workaround. In my case the urb gets > dequeued when the resume interrupt occurs after the replugging. I don't understand. Your URB doesn't get unlinked until after you replug? The patch was specifically supposed to fix that. The URB should be unlinked within a fraction of a second after you unplug. It should happen either when the controller detects a communication problem or when hcd_endpoint_disable is called. > And the > problem is, the enumeration fails with a timeout: > > Jan 22 23:48:24 koffer kernel: drivers/usb/host/uhci-hcd.c: e400: > wakeup_hc > Jan 22 23:48:24 koffer kernel: hub 1-0:1.0: new USB device on port 1, > assigned address 4 > Jan 22 23:48:29 koffer kernel: usb 1-1: control timeout on ep0out > Jan 22 23:48:29 koffer kernel: uhci_urb_dequeue cf02e620 If everything worked correctly at unplug time, there shouldn't be any problems when you replug. A timeout like this is more likely to be the result of a bad cable connection or a device error. > I did not further investigate this until now and I don't intend to at > the moment. I am sort of satisfied with the result of this debugging > marathon. I still have no solution to my problem but I have good faith > that a solution is possible. This is not a problem that really bugs us > but I had to make sure that it is not a hardware thing. (We are going to > buy a lot of these machines for a semi-embedded application.) Since my > desktop machine had _no_ problems as long as there were enough shared > interrupts from my sound card, I think there might me a workaround using > some timer interrupt that unlinks the urb earlier (before the > suspension). > > If you think it is time to readdress this issue I'd be happy to go on > with tests and help further investigating any remaining problems. In > that case, please contact me personally, I don't know how alert I am > going to follow the list. Okay. When a real fix for this part of the UHCI driver gets written, I'll ask you to test it. That probably won't be for a few months. > I'd like to thank you very much for your effort. You're welcome. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
