Closed rsta2 closed 2 years ago
What happens if you add dwc_otg.nak_holdoff=0
to /boot/cmdline.txt (and reboot)?
With dwc_otg.nak_holdoff=0
no problems any more. Thanks. For interest, what does this do?
By default, the dwc_otg code will ignore any FS control or bulk endpoint transfer that completes with a NAK (no data available) for a set period of time, defaulting to 1ms (8x125us microframes). This avoids high interrupt loads for devices that sit for ages before returning data in response to a request, as is usual for usb-serial dongles or devices that take ages to initialise.
The vast majority of devices have no issue with an extended polling interval, so on Pi 0 / 1 / 2 / 3 the relaxed polling interval frees up significant CPU time for other purposes. This device probably has very small endpoint buffers (or only single-buffers packets).
Edit: if the resulting increase in interrupt loading on your Pi 3 setup causes issues, nak_holdoff can be set to 1 or 2 to provide a compromise between available CPU and keeping the keyboard happy.
Thanks for explaining this!
OK, 1 does work too, 2 does not work. Thanks.
Describe the bug
When I attach a M-AUDIO Keystation Mini 32 MK3 USB MIDI keyboard to a Raspberry Pi 3 Model B and continuously press the MOD (modulation) button, from time to time a MIDI event is not received by the USB host, and is missing in the row of modulation events. Because the USB MIDI transfer takes place via an USB bulk pipe, this is an error. Bulk pipes are normally safe by definition.
I was able to reproduce with a debug kernel, that this data loss happens, when a USB data toggle error occurs.
Steps to reproduce the behaviour
usb-midi-mod-test < /dev/midi1
(may be midi2 instead)The program checks the received MIDI MOD messages and reports, when a message with the wrong index has been received, like that:
23??
. This happens after some time.usb-midi-mod-test.zip
Device (s)
Raspberry Pi 3 Mod. B
System
Logs
Additional context
No response