I was able to re-factor the usb emulation to prevent re-entrant scheduling. However, now I encounter some timer-related issues that I struggle with for not understanding the lx_emul/lx_kit's handling of linux ticks and timing (nor am I an expert in how native Linux does this, it seems to be quite involved). The basic problem is that the driver wants to call "msleep" in Linux to wait between various register writes and reads to the USB hardware. This function is not emulated, so the native Linux implementation is called, which sets a timer.

Now, if I understand it right, the timer setting operation does not update the "hardware" timer until the next schedule (I can trace Genode's clocksource emulation and the msleep call doesn't reset it). In a Linux schedule, I guess this would be handled somehow, but in the emulated schedule, the timer code (tick_nohz_enter/exit) only gets called if (task_flags & PF_WQ_WORKER) is true, which apparently it isn't when msleep is called. If I disable that check, meaning force a tick_nohz_enter/exit on every schedule, then the clocksource will reset after scheduling and the driver can at least initialize the hardware. But as is, it leaves the clocksource scheduled with some default timeout that takes essentially forever (2000 seconds or something), meaning *every* msleep call waits 20+ minutes unless there was a timer event already scheduled.

So, it would be nice to know what's the way msleep emulation in lx_emul/lx_kit is "supposed" to work? Do I have to make sure the calling function always has PF_WQ_WORKER context? Have I disabled some critical code path that makes it run? Do I need to change kernel CONFIG_NO_HZ settings?

To Josef's points about the USP API: