Lost USB packets

[bloguetronica]

Hi all,

I've reported this on another topic/forum, but I can't upload pictures or documents there, so I've decide to create a new thread here.

Anyways, I'm having issues with the latest VirtualBox version under Kubuntu 18.04 LTS. I'm having constant errors when testing a software I've made in a VM, virtually having any Linux distribution (even the same as my host machine). However, my software doesn't have issues when it is running directly on my host machine. I even tested this on a different hardware, and saw no issues whatsoever.

The history here is that this software controls a USB switcher, monitoring it continuously, ever 200ms (but that can be changed in the options). The USB switcher itself is based on the CP2130 from Silicon Labs. The software has all the kinks ironed, but it fails on a VirtualBox VM, which should not happen. This also happens, seemingly, irregardless of the version of VBox I have installed. I've recently updated to the latest version from the VirtualBox repository, but saw no differences. In fact, I've seen it fail catastrophically and even causing the device to reset (the software forces a reset if more than 10 errors occur) quite rapidly.

To sort this out, I've decided to run traces with Wireshark, simultaneoulsy inside and outside the VM, monitoring the same connections essentially. I can conclude that there were some lost packets because I've seen errors reporting inside the VM pertaining to packets that simply were not matched to any packets caught outside the VM, which might mean that the request packet never went outside the VM to the USB host, and due to timeout, it generated a ENOENT response inside the VM, but not outside. I must add that responses that exceed 100ms are ruled out the the application.

I've attached some of the images. I'll attach more further down. However, though I have the traces taken, the files are too big.

Kind regards, Samuel Lourenço

[bloguetronica]

Here is the VirtualBox log, attached to this message.

[bloguetronica]

Now, here are some images of the traces I took. It is very telling that there are two missing error report packets (-ENOENT) on the trace that was taken outside that VM.

[bloguetronica]

More images of the traces follow.

[fth0]

In the VBox.log file, the corresponding log messages start at 00:16:44. You can add the absolute time displayed in the 2nd line of the VBox.log file, to get absolute times with an accuracy of about 1 second. Then you can correlate the log messages with your Wireshark traces.

If interrupt accuracy plays a role in your problems, you could try enabling the HPET with VBoxManage modifyvm "Kubuntu Wireshark" --hpet on.

[bloguetronica]

In the VBox.log file, the corresponding log messages start at 00:16:44. You can add the absolute time displayed in the 2nd line of the VBox.log file, to get absolute times with an accuracy of about 1 second. Then you can correlate the log messages with your Wireshark traces.

If interrupt accuracy plays a role in your problems, you could try enabling the HPET with VBoxManage modifyvm "Kubuntu Wireshark" --hpet on.

Thanks! Many of the messages in the log had to do with the machine going to and from suspension, and enumerations. However, the message below called my attention:

Code: Select all

...
00:23:20.200906 usb-linux: Reset failed, rc=Not supported. errno=19.
..

Could it have to do with the forced reset after the "disaster"?

Another question. What would VBoxManage modifyvm "Kubuntu Wireshark" --hpet on do?

Kind regards, Samuel Lourenço

[bloguetronica]

Ok, I executed VBoxManage modifyvm "Kubuntu Wireshark" --hpet on and then started the VM again. The situation did not improve. Log is attached.

However, I found out that repeatedly detaching and re-attaching the device via the application would facilitate the occurrence of errors, to the point to cause the application to reset the device (this is so to ensure that the device is not affected by some internal race condition). Even though, there is no "Reset failed" message, so the previous message is not related to the forced reset implemented by the application.

Kind regards, Samuel Lourenço

[fth0]

What would VBoxManage modifyvm "Kubuntu Wireshark" --hpet on do?

Search for HPET in the VirtualBox User Manual ...

[bloguetronica]

Thanks, fth0.

Anyway, as per my latest reply, activating HPET doesn't solve the issue. I'll need to do more testing.

Kind regards, Samuel Lourenço

[bloguetronica]

I've retested with several devices, either with HPET on or off. HPET makes no difference on the error rate. However, having the pen under test enumerated on the VM may lead to catastrophic errors immediately after the attach operation. This indicates there is a problem with VirtualBox regarding multiple and simultaneous USB operations.

In order to exclude issues with the device or the software (I'm confident that there are none), I'll perform tests using another software (that also uses libusb) and device. Essentially, with Gqrx and my RTL-SDR pen.

Kind regards, Samuel Lourenço

[bloguetronica]

Hi all,

Found a solution for my problem. My machine has USB 3.0 controllers, even for its USB 2.0 ports. Seemingly, I have my VM configured to use OHC + EHCI, instead of xHCI. So, I've changed the USB settings to use xHCI, and now the application runs without hitches. It is weird, because EHCI is compatible with xHCI, and xHCI provides backward compatibility.

Anyway, I think my issue is solved, for now.

Kind regards, Samuel Lourenço

[Martin]

Some time ago one of the developers mentioned that the xHCI protocol works much better with the virtualization in Vbox.
The general recommendation seems to be to use xHCI wenn possible.

[bloguetronica]

Hi Martin,

I think this may be a problem, though. I have been auditing my software for weeks, thinking it was an issue related to it, or the hardware. After all, it is a VirtualBox issue.

I must add that, even changing the controller to xHCI might not be the solution because, again, some packets are lost. However, the frequency of such occurrences is much lower. I should say that I get an error every hour or every two hours, on average, which is far better and makes a demo possible.

Kind regards, Samuel Lourenço