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.
As mentioned in one of my first mails regarding this issue I tested it on my development machine (other cpu, chipset, etc.) and it works without problems. The following trace is taken from a working unplugging event from that machine: Preceding the lines below are more uhci_irq calls than on the buggy machine. They start with the same 32 -> 1 -> 32 -> ... pattern (repeats 3-4 times as well) then there are like 15 additional 0 -> 32 -> ... loops. Then I see the "USB disconnect" and the uhci_urb_dequeue() exactly the same way as on the other machine. Then some more 0,32,0,32,... lines and then suddenly: Jan 15 22:08:52 strand kernel: drivers/usb/host/uhci-hcd.c: c400: suspend_hc Jan 15 22:08:52 strand kernel: uhci_irq status 32 Jan 15 22:08:52 strand kernel: uhci_remove_pending_qhs process c40b33c0 Jan 15 22:08:52 strand kernel: >>> uhci_clear_next_interrupt Jan 15 22:08:52 strand kernel: << uhci_clear_next_interrupt Jan 15 22:08:52 strand kernel: >>> uhci_finish_urb c40b33c0 Jan 15 22:08:52 strand kernel: >>> uhci_set_next_interrupt Jan 15 22:08:52 strand kernel: << uhci_set_next_interrupt Jan 15 22:08:52 strand kernel: >>> giveback c40b33c0 Jan 15 22:08:52 strand kernel: spheroncam.c: spheroncam_complete urb: c40b33c0 status: -104 > Another possibility is that, for some reason, the controller isn't running > when uhci_urb_dequeue() is called. In your printk at the end of the > routine, try displaying the value of uhci->state. On both machines I get uhci->state == 3 at the end of uhci_urb_dequeue(). > However, if the > controller had stopped there ought to be a message in your system log > saying so. Something like: > > kernel: d400: suspend_hc > > And the controller shouldn't stop as long as your device is plugged in. As seen above, on the working machine I get such a line after the disconnect and before the uhci_remove_pending_qhs() call actually removes the URB. On the buggy machine I see one after the disconnect as well: Jan 15 23:06:57 koffer kernel: drivers/usb/host/uhci-hcd.c: e400: suspend_hc The crucial difference is, that the buggy machine doesn't get any uhci_irq() calls after the disconnect. > No, that's not true. There's no counter or anything like that involved. > All that matters is which one runs last. So even if set_next is called 10 > times, if clear_next is called it will cancel the effect. I understand. That means the uhci_irq gets called in other cases as well but what ever caused the interrupt, clear_next is called, which would not be always be necessary? (not that I really cared...) > > Jan 14 23:33:26 koffer kernel: uhci_irq status 32 > > Status 32? That means the controller _is_ stopped! But then _nothing_ > should be working... Since the develop machine works but I get even more uhci_status = 32 reads, I guess they are not as bad as you thought. 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
