summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/108/other/2087
blob: 579dbd8663f59461277440c502c70682462955b2 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
device: 0.812
performance: 0.629
debug: 0.595
socket: 0.563
semantic: 0.558
other: 0.534
PID: 0.506
files: 0.505
vnc: 0.499
network: 0.441
boot: 0.429
permissions: 0.351
graphic: 0.261
KVM: 0.243

usb-host / libusb: handling of clear_halt leads to slow device attach, possibly unusable VMs (edit:fix within)
Description of problem:
When passing through a common JMicron USB SATA IDE brige storage device to a windows guest, the windows VM and the attached device become unusable. It appears to take several minutes to identify the connected device, and many minutes to pull up the device properties (though they are correct). The trace log seems to indicate a retry/reset retry loop is occuring.

The device works fine passed through to a fedora guest VM. Device also work fine when used by the Windows host system.

The primary difference may be the XHCI controller device behavior in the Windows and fedora guest VMs.\
It appears there may possibly be 2 separate issues:

1. Incompatible handling of this type of storage device in usb-host / libusb.
2. Windows XHCI not properly handling malformed or possibly mis-behaved devices.

I also tried the nec-usb-xhci device instead of qemu-xhci, and also tried the ICH9 usb device; no difference in behavior in the Windows VM. (Though windows appears to use the same xhci device driver in all cases).

A simple USB 3.x storage stick (at speed 5000) works fine passed through to the Windows guest VM, configured in the same way, with both cases using WinUSB to allow passthrough/attach to work.
Additional information:
lsusb output in the working Fedora VM case:

only the debug descriptor fails to dump, running as root

[lsusb.txt](/uploads/c1a702bc628ed9bc983dba3e703e8af4/lsusb.txt)

\-trace enable=usb_host\_\* output (fragment of logfile) from the non-working Windows VM case:

[usb_noprogress.txt](/uploads/f66b2ff7d4658f9569859ac122413d9f/usb_noprogress.txt)

```plaintext
```