Hi Alan, On Thu, 2004-01-22 at 22:42, Alan Stern wrote: > On Thu, 22 Jan 2004, Axel Waggershauser wrote: > > I observed the transitions 1->0, 2->0, 3->0, 36->32 and 32->32. > > I made the same test on my computer and got the same result. Apparently > this is one respect in which the standard differs from the reality.
I took a look at the spec (uhci11d.pdf from usb.org) myself and agree with you that the spec says nothing about a different behavior for the USBSTS_HCH bit. > 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. > > This lets me suspect that your information about the specification in > > this regard is either wrong or a lot of hardware (at least 3 different > > types) just violate the USB spec. > > Again, I got the same result you did. This is another respect in which > the standard differs from the reality. Probably (if anyone cares) this > will be fixed by changing the specification! 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. > 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. 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 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. I'd like to thank you very much for your effort. Axel. ------------------------------------------------------- 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
