USB Controller Initialization Error

Developer's Corner
1

I was testing the usb_hid_raw application from the Genode 26.05 release on an HP ProDesk 600 G1 hardware platform. The following error occurs during USB controller initialization:

[init -> usb -> usb] Error: INVALID RPC: sigh
[init -> usb -> usb] Error: attempt of IPC call to an invalid object

To investigate the issue in more detail, I reproduced the same problem in QEMU using the following command:

sudo qemu-system-x86_64 \
  -display sdl \
  -device nec-usb-xhci,id=xhci0 \
  -device usb-mouse,bus=xhci0.0 \
  -serial mon:stdio \
  -m 800 \
  -drive format=raw,file=build/x86_64/var/run/usb_hid_raw.img \
  -machine q35 \
  -cpu Skylake-Client \
  -net nic,model=e1000,netdev=net0 \
  -netdev user,id=net0 \
  -device ich9-usb-ehci1,id=ehci

However, the issue does not occur under either of the following conditions:

  1. Changing the EHCI PCI address by explicitly assigning it to addr=0x5:
-device ich9-usb-ehci1,id=ehci,addr=0x5
  1. Initializing the EHCI controller before the xHCI controller.

In both cases, usb_hid_raw starts and operates correctly.

This suggests that the issue may be related to the PCI address/BDF assignment or the initialization order of the xHCI and EHCI USB controllers.

2

Hi hamed,

I can reproduce this issue, thanks to your Qemu line and description. The problem is more related to the innovations of release 26.05 with respect to MSI and MSI-x support. Within the Linux emulation environment accidentally the GSI number 11 was tried to open for the EHCI controller as well as the XHCI controller (both controller share the same line here), although the XHCI controler was already using the device in MSI fashion. Resulting side-effect was an invalid interrupt capability returned to the Linux emulation layer that was used to register a signal handler, which resulted in the fault you have seen.
I’ve opened an issue in our issue tracker and provided a patch there.
Thank you for your report!

3

Hi Stefan,

Thanks for the patch. I applied it to my 26.05 tree and can confirm that the problem is solved. The USB controllers now initialize correctly, and the USB mouse works as expected.

Thanks for fixing the issue!

4

Thanks for the suggestion! I applied your proposed fix and tested via USB on an HP ProDesk 600 G1. The error is gone now, but usb_block (which I’m using for storage) fails to execute. I initially thought it was a misconfiguration on my end, so I checked usb_block.run, but it didn’t work either. it just silently fails without throwing any errors.

Interestingly, the exact same test runs fine on a system that doesn’t have the MSI issue. So while your fix resolved the initial USB error, read/write functionality still seems to be broken.

5

Hi Hamed,

well I assume that is some other issue not related to the previous one. Is the host controller working in general? You could try to connect some USB mouse or keyboard to it. If yes, the problem might be related to our own, simple USB block driver, which is known to work with most, but not all USB mass storage devices.

In that test, have you used the very same USB block device?

6

Actually, I have two systems:

A. Asus motherboard Works out of the box (no MSI issue)
B. hp G1 600: Initially had the MSI issue.

After applying your patch, System B boots successfully and the host controller starts working, but I still encounter read/write issues with the USB storage.

And yes, I am using the exact same USB flash drive and the exact same usb_block and part_block configuration on both systems. The flash drive reads and writes perfectly on System A.

So, since the same device and configuration work correctly on System A, it seems the remaining issue is specific to System B or something related to the MSI fix, rather than the flash drive or the usb_block configuration itself.

7

Hi Hamed,

So once again, just to ensure or contradict whether USB host controller (and its interrupts) is working or not apart from the concrete USB block device resp. driver: have you tried to drive some USB HID device like mouse or keyboard with it?

It is possible that there is still some problem with interrupts, but there are a lot of other potential reasons as well. That is why I would like to limit in a well-organized manner the potential reasons. Therefore, it would be nice to test another USB device client driver first. Moreover, you could check whether the USB host controller driver actually reports all USB devices that are connected. And you could try to plug, and unplug devices at runtime, before and after the stagnation that you observe, and report what is happening.

Best regards Stefan

8

HP ProDesk 600 G1 comes with an Intel Core i3-4130 (2x 3,4 GHz) CPU. Is that correct?

I’m uncertain about the implications on this scenario but according to [1] this CPU lacks VT-d support and, thus, does not support interrupt remapping or DMA redirection. Maybe we should investigate in this direction as 1) almost any modern hardware we use regularly is equipped with VT-d support and 2) one of our test machines is an Intel Core i7-4770 - a close relative with VT-d support - that works flawless.

[1] https://www.intel.com/content/www/us/en/products/sku/77480/intel-core-i34130-processor-3m-cache-3-40-ghz/specifications.html