On Tue, 20 Jan 2004, Axel Waggershauser wrote: > > Then run your test again and post what you get in your log. If, as you > > say, set_next_interrupt is working then the interrupt should show up in > > the log after urb_dequeue. As I recall that wasn't happening before and > > it was the cause of your problem. > > Your are right. > > Here is the update: > - set_next_interrupt works right after startup, I can plug/unplug my > device, I can send URBs both ways, no problem, set_next_interrupt still > works.
If you unplug (without running the test) and wait for the controller to be suspended, does uhci_irq get called right after the suspend_hc message? > - when I run my test, unplugging the device during transmission, I see > uhci_urb_dequeue as before, uhci->state = 2 at the end of urb_dequeue. > There is _no_ uhci_irq call after the "usb 1-1: USB disconnect". Not > even after the "uhci-hcd.c: e400: suspend_hc" Doesn't urb_dequeue call set_next_interrupt? If it does, shouldn't you see uhci_irq being called? Are you saying that the problem comes up only when you disconnect during your test transmission? Does your test involve trying to send a bulk-out message or a bulk-in? Can you post your debugging log information, from when you start your test up until shortly after the suspend_hc message? > - after I ran my test set_next_interrupt does not work anymore > (triggered by "cat /proc/drivers/uhci..."). It shouldn't work because the controller is suspended. > If I replug the device, I > get the kernel panic. Caused by the original failure to get an interrupt after the call to urb_dequeue. > - both machines behave exactly the same way, except that the "working" > one returned a uhci->state = 3 at the end of urb_dequeue. I have seen a > uhci->state = 3 on the "buggy" machine on an earlier test runs, too. state = 2 is the normal running state. state = 3 means the driver has detected that nothing is plugged in and it will suspend the controller soon. > Hope that clears a few clouds. > > Did you change your mind about the one interrupt to expect right after > the suspension of the controller, or do you think the absence of it on > my machines has nothing to do with my original problem? I thought that > would be something to jump on, because it has nothing to do with my > device... There should be an interrupt with status = 32 right after the controller is suspended. It's an additional odd thing. If you have another USB device, you could try plugging it in and unplugging it, to see what interrupts you get. I'm thinking that maybe part of the trouble is caused by your test device, although I can't imagine how. 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