Opened 9 years ago
Last modified 7 years ago
#15553 new defect
USB 1.1 (OHCI) controller stops working after a period of time
Reported by: | rp3k | Owned by: | |
---|---|---|---|
Component: | USB | Version: | VirtualBox 5.0.22 |
Keywords: | USB FTDI | Cc: | |
Guest type: | Linux | Host type: | Windows |
Description
I have 2 identical FTDI Quad RS232-HS USB virtual serial port chips connected to a Ubuntu 12.04.5 LTS guest running on Windows host (behaves the same on Win7x64 and Win10x64). I am using USB 1.1 (OHCI) controller, but the FTDI chips are physically connected to the host via USB2.0 ports. On VirtualBox 4.3.12 everything works just fine. On higher versions (I tried 4.3.38, 5.0.22, 5.0.23, 5.1.0 Beta 3) I am able to open the virtual serial ports and read and write data to them for a few minutes (maybe 5) after which the communication stops and no data can be sent nor received. When monitoring the USB ports on the guest with usbmon+wireshark, I can see no packets being sent or received after it stops working. This only happens when 2 are connected and open at the same time. One on its own doesn't do it. When I install the extension pack and use USB3.0 (xHCI), the problem doesn't appear.
I am attaching two logs, one running USB1.1 and one USB2.0 controllers both manifesting the issue.
Attachments (1)
Change History (3)
by , 9 years ago
Attachment: | VBoxSVC.zip added |
---|
comment:1 by , 8 years ago
Same / very similar issue here!
Host: Windows 7 Pro 64 Bit; Guest: Linux 4.8.10 Kernel 64 Bit; USB: 3.0 via Extension Pack; VirtualBox: 5.1.12 + matching extension pack; USB Chip: FTDI USB to Serial
Problem:
- Using USB 1.1 or 2.0 freezes after a few minutes (5-20), meaning: either the write command or the subsequent tcdrain command block forever in guest.
- Using USB 3.0 works more or less stable as long as you limit the guest system to just 1 CPU, otherwise it blocks either the write or tcdrain command forever in guest.
No log-events, no errors, it just stucks "forever". The stucked USB can be released by removing the particular FTDI USB from the guest and re-assigning it to the guest (by bottom status bar, USB-icon).
What could be the reason for that? Tested on different computers with different intel based USB controllers (USB 2.0 or 3.0) - same issue everywhere. The FTDI traffic is very low, approx. 20 bytes/s - running the guest directly/natively on the computer (without VM) gives a rock solid USB-connection with the FTDI.
comment:2 by , 7 years ago
If this is still an issue you might try the latest 5.2 or 5.1 testbuild from the Testbuilds page, we identified and fixed an issue in the OHCI and EHCI controller emulations which could explain your issue.
Log files from runs when USB controllers stop working.