a few usb issues related to edge cases

[Hans Petter Selasky]

On Wednesday 21 December 2011 12:29:49 Andriy Gapon wrote:
> 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.

Hi,

Those threads should be polled when calling usbd_transfer_poll(). I.E. the 
wakeup should be stubbed in the !scheduler_running case.

--HPS