On the iMX8 device `Linux imx8mm-var-dart 5.4.3-g050b21f4b394 #1 SMP PREEMPT Fri Oct 9 11:36:53 PDT 2020 aarch64 GNU/Linux` and on the Raspberry Pi device `Linux raspberry 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux`. File write to `/dev/hidg0` starts to hang when there was high mass storage traffic. It also doesn't recover itself. There is no `complete kernel lockup`. I haven't used usbmon yet but if I don't have high traffic scenarios on the mass storage then the mass storage and HID device works as expected. So I'm confident that I send the correct data. Also saw that I'm getting this error in dmesg on both devices: [ 1895.677053] configfs-gadget gadget: End Point Request ERROR: -108 Thanks Benjamin Am Di., 29. Juni 2021 um 19:20 Uhr schrieb Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>: > > On Tue, Jun 29, 2021 at 03:45:46PM +0200, Benjamin Marty wrote: > > Hello > > > > In my application, I boot a Linux System through USB Gadget mass > > storage and at the same time pass in USB Touch commands via USB HID > > Device. Both over the same USB OTG Gadget Link. > > > > If I execute USB HID commands during high traffic over the USB Mass > > Storage, the HID device gets stuck. Writes to it are then blocking > > forever. I'm not sure if I use something wrong or if this is a Kernel > > issue. Do I maybe need to check something before I'm allowed to write > > to the HID device? > > > > Hardware issue are unlikely, I tried it on the Raspberry Pi Platform > > and also on the NXP iMX8MM platform. Both have this HID device stuck > > issue. I have also tried multiple Intel Computers as USB Host. > > > > I tried to document my issue here with test scripts to replicate what > > I do in my C Application with the same result: > > https://github.com/raspberrypi/linux/issues/4373 > > What kernel version are you using for your device? > > What is locking up, the kernel on the device, or the kernel on the USB > host side? > > And have you used usbmon to look at the USB traffic to ensure that you > really are sending the data you think you are sending? > > thanks, > > greg k-h