On Sun, 18 Jan 2004, Axel Waggershauser wrote: > 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?").
That makes sense -- the unused controller is in state 32 since it isn't running. You can selectively ignore that controller in your debugging messages simply by checking the value of io_addr (or uhci->io_addr). > 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. It sure looks like you're not getting that extra interrupt, the one that set_next_interrupt is supposed to provoke. Nothing happens until the controller is suspended, one second after the last device is unplugged. > 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. You're right on both counts. > 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. I don't know about the relation between your two controllers. They _should_ be completely independent. Anyway, the controller generates a single interrupt at the time it is suspended. That's the status = 32 and state = -10 you see. But then while it is suspended it won't generate any interrupts at all until you plug in a device. Even if you call set_next_interrupt. > 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. No, that's normal and unrelated. It looks like set_next_interrupt isn't working on your systems. You can test that by patching uhci_proc_open() in uhci_debug.c. Add a call to set_next_interrupt, say right before the "ret = 0" line. Then each time you open the /proc/devices/uhci... file you should cause an interrupt. Just make sure a device is plugged in (so the controller isn't suspended) and is idle (so you aren't confused by unrelated interrupts). 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
