Re: USB Gadget Filesystem HID stuck on write when using mass storage at the same time

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 [off-list ref]:

On Tue, Jun 29, 2021 at 03:45:46PM +0200, Benjamin Marty wrote:

quoted

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