Ubuntu 20.04: HID write causes system to hang

[Guillaume-RF]

I'm working with an FTDI FT260 HID device and have encountered an issue whereupon a HID.write() with a specific reportID (0xC2, an I2C request to the FT260) is causing an Ubuntu system to hang indefinitely. I've mainly been using a VirtualBox guest, but I also replicated the issue on a server with the same distribution and environment. On Windows 11 there are no issues. My debugging has mostly been using the HIDAPITester, but I stumbled upon the issue while using the cython wrapper for HIDAPI python package. Using the following call always results in a system hang, 'sudo ./hidapitester --vidpid 0403 --open --length 5 --send-output 0xC2,0x48,6,2,0'. Other writes have no problem executing. I've collected Wireshark captures on both Windows 11 and Ubuntu and can see the HID messages being sent successfully, and the expected response being sent back.

The only indication of an issue in var/log is in kern.log, just showing that the system is in fact hanging: Sep 26 16:32:49 hifi-VirtualBox kernel: [ 498.172349] hrtimer: interrupt took 12206242 ns

Running strace along with the above mentioned command also did not reveal to my eye the issue at hand. write.log

I would appreciate an expert eye and advice on where to look next. Thanks for your attention.

Below are results from the Wireshark captures Request (Win left, Ubuntu right)

Response 1

Response 2

[mcuee]

So this is on a VirtualBox Ubuntu 20.04 VM. Can you reproduce the issue under a physical machine? Virtualbox USB is known to have issues.

If using VM, could you reproduce the issue on Ubuntu 22.04 or 24.04?

Edit: you also mentioned that you can reproduce the issue with a physical server. Does that server also run Ubuntu 20.04?

[Youw]

I don't see anythiong obvious in the Wireshark capture or the write.log file.

What I do see, is that the hid_write function performs w/o hang, and exits normally/successfully. Also, hid_write is extremely thin wrapper over system write call, so it is unlikely HIDAPI implementation could do any better here.

My assumption is one of the two: 1) Maybe this is a bad FTDI HID (hidraw) driver, that is causing a system hang. You could double-check by using hidapi-libusb backend on the same device.

2) Maybe you're using wrong report length. I'm not sure how the system would respond if you provide too short or too long buffer for the report (on Windows that is always handled explicitly, but the requirements of WinAPI). Did you check with your HID Report descriptor?

[Guillaume-RF]

Thank you very much for both of your responses. I greatly appreciate you taking the time.

@mcuee I reproduced the issue on a VirtualBox VM running 20.04, remotely on a physical server running 20.04, and since my original post, I tried the same steps on a USB live boot of 20.04. On the VM and remote server, I lacked some visual information in that the machine (and my connection to it) would hang prior to the terminal indicating that the device was closed, but on the live boot I can clearly see that the call to hidapitester completes, as in the device is reported to be closed successfully and the program terminates before the hang occurs. This also appears to be the case with the VM as the Wireshark traces show the expected writes and read as if the program had successfully completed.

If trying 22.04 or 24.04 would be practical for debugging purposes I can certainly give it a try, but the machine this software would be deployed to is 20.04 and that is out of my control, so ideally I'd get this running there.

@Youw Right, my assumption at the moment is very much that I am making a call that results in edge behavior, I'm just at a loss about what exactly that is, I had hoped there could be some evidence in the Ubuntu logs, wireshark captures, strace logs ,etc. I'm also slightly concerned that a bad call would cause such a catastrophic failure.

As to your first point, I had previously attempted using the libusb backend when I was debugging through the cython wrapper for hidapi. I experienced the same behavior, but I will give it another go while using only hidapi in case I erred in my prior attempt.

And to your second, I have tried changing the write to 4 and 6 but the behavior is the same, I will try more variations in the future. Below I attached an image from the devices datasheet showing the report I am writing. It seems obvious the report length should be 5, perhaps I don't know enough about how HID works, this is my first attempt!

Again, thank you.

[Youw]

Hm, maybe you have to read the date after you request it by hid_write? You will not be able to do it with hidapitester. You would need to write a something like:

hid_write(...);
// .. error handling
hid_read(...); // make sure to read immediatelly after write.

At most what I can help you here with is you share your HID Descriptor here, to double-check if it matches the documentation.

If trying 22.04 or 24.04 would be practical

Sure it would - it would tell if the problem with FTDI HID driver or not.

[Guillaume-RF]

I ended up being able to run the same command fine on 22.04. Is it safe to assume the issue lies within the kernel hid module? I see that the only possible differences since kernel V5.15 lie specifically in usbhid. I was looking into recompiling the latest of usbhid on 5.15 to make sure the issue is isolated there.

See below for the report descriptor as given by 'sudo ./hidapitester --vidpid 0403/6030 --open --get-report-descriptor c2': 20_04 report descriptor.txt

[Youw]

Is it safe to assume the issue lies within the kernel hid module?

That is the assumption I'd made.

I was looking into recompiling the latest of usbhid on 5.15 to make sure the issue is isolated there.

Sounds logical.

20_04 report descriptor.txt

NOTE: you could also check it yourself here: https://eleccelerator.com/usbdescreqparser/

Report Size (8)

All of the reports for this device are of 8 bytes + 1 byte for report ID. Try having a buffer of 9 bytes.

[Guillaume-RF]

Unfortunately I came at an impasse with trying to recompile select components of the hid modules as they were using some functions that would have required updating my Linux headers beyond 5.15.

Regardless, I've come to discover that the Kernel has an included driver for the FT260 (hid_ft260) that more or less makes the device appear as an I2C device with which you can use I2C-tools and the like. Using this tool, you can successfully send the problem command, and since hid_ft260 uses the hid and usbhid modules, it leads me to believe the problem isn't related to the hid drivers.

I would much rather use the hidapi library since I've already got much of my desired functionality working on Windows, and the ft260 kernel driver isn't fully fleshed out until somewhere in Kernel V6.

I also tried setting the buffer to 7,8,9,10 bytes but no luck.

[Guillaume-RF]

I ended up downloading an older version of the cython wrapper, which uses hidapi V0.10.1, and I can now successfully send the messages. Afterwards I tried resetting the hid and hidapitester to V0.10.1 and V0.2 respectively, but that failed.