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

Reply via email to