On Tue, 13 Jan 2004, Axel Waggershauser wrote:
> > Are you sure your wait_event() logic is working correctly? One
> > explanation for these questions is that it missed the event.
>
> Lets say, I am pretty sure. If it would merely miss the event and the
> URB would have successfully been unlinked the following unlink call
> would not return -EBUSY and there would not really be a problem
> (especially no kernel panic when I replug the device), wouldn't it?
If you want to be certain, add a printk to your completion handler. But
if you're monitoring giveback_urb then you already know whether or not the
handler is getting called.
> I still have these printks in giveback() and found to my surprise that
> this function gets called repeatedly for an other urb with a frequency
> of about 4/sec. This starts about the same time the unplugging is
> detected, that means shortly after I see the "uhci_hcd 0000:00:07.2:
> shutdown urb" and keeps on endlessly. At that time there is no usb
> device attached to the machine. Maybe this behavior is part of the
> problem or a hint where to search next?
Maybe. It indicates the the hub driver is stuck waiting for something;
most likely it's waiting for your driver to return from a call to its
disconnect routine.
> > Once the controller driver returned from its dequeue()
> > method, that meant the URB was going to be returned "soon". Isn't
> > there a uhci timer that's supposed to make that happen?
No there isn't. The UHCI driver relies on interrupts for that.
> I guess what I should do is to keep on trying to find the point where
> the URB "gets stuck" by distributing more printks to the right places. I
> know hcd_endpoint_disable()/unlink1() gets called and seems to do what
> it's supposed to but giveback_urb() is never called for this urb. Any
> suggestions where to go on?
On Tue, 13 Jan 2004, Axel Waggershauser wrote:
> It is not quite obvious to me where to go. If you could tell me the
> missing function calls "between" endpoint_disable()/unlink1() and
> giveback_urb(), that would be helpful.
To both questions, the answer lies in the UHCI driver,
drivers/usb/host/uhci-hcd.c. Here are some good spots to try putting
printk's:
uhci_urb_dequeue() is the routine that gets called via unlink1()
to dequeue your URB (your URB is put on the urb_remove_list);
The grossly misnamed routine uhci_remove_pending_qhs() is the
one that notes when your URB can safely be sent to giveback_urb
(your URB is taken off the urb_remove_list and put on the
complete_list);
uhci_finish_urb() is the routine that actually calls giveback_urb
(your URB is taken off the complete_list). Be careful about
this one because it gets called for every single URB, so it has
a lot of activity.
If you can find out where in that sequence your URB is going and where it
is getting stuck, that will be a good step forward.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
