On Fri, 2004-01-16 at 22:51, Alan Stern wrote: > 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.
I found that I have two onboard UHCI controllers. I was not aware of that fact until now... This perfectly explains to me those 32's. Now that I disabled the second controller in the BIOS of my "working" machine they are gone. Since my "buggy" machines BIOS does not offer this option I have no solution for that so far (please see the thread "Howto "disable" one of two uhci-controllers?"). > 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. OK, I'll trust this value and ignore it in the future. > 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. This is explained with the second controller as well, right? I ran the test on the "working" hardware again with the this result: Jan 18 21:08:44 strand kernel: usb 1-1: USB disconnect, address 2 Jan 18 21:08:44 strand kernel: >>> uhci_urb_dequeue d68921c0 Jan 18 21:08:44 strand kernel: >>> uhci_set_next_interrupt Jan 18 21:08:44 strand kernel: << uhci_set_next_interrupt Jan 18 21:08:44 strand kernel: uhci_urb_dequeue d68921c0 list_empty == true Jan 18 21:08:44 strand kernel: >>> uhci_set_next_interrupt Jan 18 21:08:44 strand kernel: << uhci_set_next_interrupt Jan 18 21:08:44 strand kernel: << uhci_urb_dequeue d68921c0 uhci->state: 3 So far it looks like I think it should and as it did before. But there still seems to be a problem. You told me the controller should send an interrupt with the next frame, so within the next ms after the uhci_urb_dequeue call. But there seems to be a delay of about a second. I don't only see it in the syslog message's time stamp (see below) but also my test program exits with this delay. I am not completely sure about that fact, though. Jan 18 21:08:45 strand kernel: drivers/usb/host/uhci-hcd.c: c400: suspend_hc Jan 18 21:08:45 strand kernel: uhci_irq status = 32, uhci->state = -10 Jan 18 21:08:45 strand kernel: uhci_remove_pending_qhs process d68921c0 Jan 18 21:08:45 strand kernel: >>> uhci_finish_urb d68921c0 Jan 18 21:08:45 strand kernel: >>> uhci_set_next_interrupt Jan 18 21:08:45 strand kernel: << uhci_set_next_interrupt Jan 18 21:08:45 strand kernel: spheroncam.c: spheroncam_complete urb: d68921c0 status: -104 Jan 18 21:08:45 strand kernel: << uhci_finish_urb d68921c0 My interpretation is, that the "working" hardware seems to interrupt the moment it gets shut down by the suspend and this removes the pending URB. I thought it should be removed independently from the suspend, especially because my device might be not the only one on the bus. I took another look at the syslog of "buggy" machine. With my new insight (the second controller thing), I'd say the crucial difference in the behavior is that the "working" machine's controller keeps on generating interrupts when it is suspended state where as the "buggy" controller does not. It looks like I see a uhci_irq() call with status = 32 and uhci->state = -10 if and only if there preceded a uhci_irq() call from the other, enabled, controller. Another thing I saw and might give a hint is, if I load the uhci-hcd module and unload it again with or without my device attached, I see this line: "usb usb1: hcd_unlink_urb cf03c320 fail -22". If you think it might be worth it and could have something to do with all that, I can further investigate that. > 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. I sort of figured that myself but wasn't sure. 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
