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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
