On Thu, 2004-01-15 at 17:20, Alan Stern wrote: > > So I guess that is bad (meaning the hardware is buggy?). > > I would hesitate to make that conclusion, but it's certainly a > possibility. The best test would be to try running your driver on a > different computer.
I don't know why I didn't have this idea earlier but I still have my old driver written for 2.4.18 and voila: the "buggy" machine works well with 2.4.18. I think that clearly shows that the hardware is not per see buggy. I guess it could still mean the controller doesn't behave according the spec but if I can get it to work, violating the spec, that would be the way to go, right? The problem is now that the two different kernels/drivers are _so_ different that I don't know where to start... I briefly tried to find corresponding calls for uhci_urb_dequeue, uhci_irq, etc in the 2.4 driver (usb-uhci by the way). I found that the two implementations vary quite a lot. So far I was able to determine the following differences in behavior of the 2.4 kernel. - I never see a uhci_interrupt with a state other than 1 or 2 (especially no 32, didn't check for 0 this time) - after the "usb.c: USB disconnect on device 3" line my disconnect() function gets called and blocks as with 2.6. The I get the lines: kernel: usb-uhci.c: Root-Hub INT complete: port1: 488 port2: 480 data: 2 last message repeated 288 times # then my interruptible_sleep_on_wait times out... kernel: lpcusb.c: wait_for_transfer_completion: timeout(0) kernel: lpcusb.c: wait_for_transfer_completion: UNLINK URB ced67990, dev cd9ee000 kernel: usb-uhci.c: uhci_unlink_urb called for ced67990 kernel: usb-uhci.c: unlink_urb_async called ced67990 kernel: usb-uhci.c: dequeued urb: ced67990 kernel: usb-uhci.c: uhci_clean_transfer: No more bulks for urb ced67990, qh cc94cc00, bqh 00000000, nqh 00000000 kernel: usb-uhci.c: uhci_clean_transfer: No more bulks for urb ced67990, qh cc94cc00, bqh 00000000, nqh 00000000 kernel: usb-uhci.c: Root-Hub INT complete: port1: 488 port2: 480 data: 2 kernel: usb-uhci.c: unlink_urb: calling completion kernel: lpcusb.c: completion of ced67990 >>> (-2) So the URB does not get unlinked automatically but I can unlink it after the timeout and my completion handler returns with -2. It could be of interest, that with 2.4 I don't see any uhci_interrupt() calls after the disconnect either. In case you have any suggestions what else I should try with the 2.4 code, please tell me (now that I see some hope again :-)). It is unfortunately not a strait forward option to try the newest 2.4 kernel since I had no luck to get my driver working with neither 2.4.20 nor 2.4.22 (I can't remember why, I think was because of some api changes.) Thanks, 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
