yamt@mwd.biglobe.ne.jp said:
> it usually means context switch in illegal context. i guess
> usbd_do_request can't be used from interrupt context. 

Yes - thanks, it seems that usbd_do_request attempts to sleep
under some circumstances which happen randomly.

lennart@augustsson.net said:
> usbd_do_request() has to be used very carefully from a non-process
> context.  Perhaps you should consider a kernel thread? 

As I understand it, the kernel thread would be on an lower
priority than the softclock handler, increasing the jitter
even more.
The original Linux driver used asynchronous USB calls --
initiated from a timer handler, with the result delivered to
a callback. I could perhaps model this with more low-level
usbdi functions like usbd_setup_default_xfer(). Would that
work? Can I reuse an xfer initialized that way, or do I have
to call the usbd_setup_default_xfer() always before submitting?
Is that interface for public consumption at all?

best regards
Matthias