Hi !
I've got various reports of kernel crashes (schedule in interrupt) after
seeing the message "hid.c: had to kill output urb".
Digging a bit into the source, I saw that in usb-ohci.c (this happens on
a Mac with an OHCI controller), sohci_ulink_urb() may call schedule if
the USB_ASYNC_UNLINK flag is not set. It also look like this flag is
never set by hid.c
Finally, it appears that hid.c , just after printing the above debug
message, will call usb_unlink_urb from interrupt.
Note that if my conclusions are correct, and that usb_unlink_urb() must
not be called from interrupts without having the USB_ASYNC_UNLINK flag,
it is possible that other drivers exhibit this bug since this is not
trivial from an API point of view. I didn't neither look if setting this
flag is ok since that would mean the urb must not be re-used before
actually unlinked (or did I miss something ?)
It appears that the uhci driver has some protection against this by using
mdelay instead of schedule while in interrupt.
So the question is (provided that I didn't miss anything):
- should hid.c be fixed to use USB_ASYNC_UNLINK ? (and potentially other
drivers). In this case, I beleive this should be documented with a big
warning, or eventually add a test of in_interrupt() in usb_unlink_urb()
displaying a big error when this flag is not set so at least we know
what's going on and driver writers using UHCI will fix their bugs ;)
- should usb-ohci be fixed ? This doesn't seem to be trivial. We should
probably replace the schedule_timeout/waitqueue, when in_interrupt() is
true, by a polling mecanism that would repeately poll the done list.
- Did I miss something ?
Regards,
Ben.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
