a few usb issues related to edge cases

[Andriy Gapon]

on 20/12/2011 14:25 Andriy Gapon said the following:
> I just wanted to draw your attention to the fact that obtaining any locks in the
> kdb context (or USB polling code in general, even) is not a good idea.
> Chances of getting into trouble on those locks are probably quite moderate or
> even low, but they do exist.  I am not sure if you are getting any bug reports
> about such troubles :-)  Regular users probably do not use kdb too often and a
> panic for them is just a "crash", so they likely do not expect anything
> usable/debuggable after that :-)

Looking some more at the code I just got myself confused as to how the dumping
to a umass device could work when the scheduler is stopped.
It seems that the umass_command_start -> usbd_transfer_start ->
usbd_callback_ss_done_defer functions would always put a transfer request onto a
queue and try to wake up a thread to process that queue and the request.  But
that's obviously not going to work when the other thread is not going to be run.
Have I missed a code path that leads directly to the controller in this context?
Thank you for your help.
-- 
Andriy Gapon