a few usb issues related to edge cases
avg at FreeBSD.org
Wed Dec 21 11:29:56 UTC 2011
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.
More information about the freebsd-current