On Thu, 15 Jan 2004, Axel Waggershauser wrote: > 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.
I'm beginning to think that bad or strange hardware really may be your problem... > 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. I still don't understand those 32's. They don't occur on my computer. If you look at uhci_irq() you'll see that unless uhci->state is <= 0, status = 32 (= USBSTS_HCH) should trigger a rather ominous "host controller halted. very bad" message. That's why I asked what usb->state was. Status = 0 is supposed to mean that the interrupt wasn't generated by the host controller at all, but by some other device sharing the same interrupt line. > 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 It sounds like this machine isn't working as expected either. Do you have any idea why remove_pending_qhs wasn't called, or didn't do any work, during one of those earlier passes through uhci_irq? It should have appeared on the very next pass through uhci_irq after the call to urb_dequeue. > On both machines I get uhci->state == 3 at the end of > uhci_urb_dequeue(). But what was it before that? In fact, what was it each time uhci_irq ran? > > 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 suspend_hc is normal. It's supposed to happen about 1 second after the last device is unplugged from your host controller. > The crucial difference is, that the buggy machine doesn't get any > uhci_irq() calls after the disconnect. At this stage neither machine is working right. > 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...) Here's the idea. Sometimes we want to know when the next frame starts. set_next makes the controller issue an interrupt when that happens. But usually we don't want to know, so the default processing in the interrupt handler calls clear_next. Yes, that means a lot of the time clear_next is called when it's not needed. It's such a short function that the extra overhead doesn't matter. > > 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. No, status = 32 really is significant. (That number is in decimal, not hex, right? Although even 0x32 has that particular bit set.) About the only thing I can think of to explain what you're seeing is that your host controllers aren't standard UHCI devices! And even that wouldn't explain why you don't get any "host controller halted" log messages. (If you did mean 0x32 that would account for the missing messages.) 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
