summary refs log tree commit diff stats
path: root/results/classifier/118/files/1247478
blob: d5255ebd4269a6e12325112b64e81496ad9c2b56 (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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
files: 0.958
graphic: 0.851
device: 0.753
performance: 0.733
architecture: 0.683
user-level: 0.673
peripherals: 0.644
semantic: 0.598
ppc: 0.596
network: 0.576
assembly: 0.512
socket: 0.504
register: 0.481
PID: 0.476
debug: 0.469
mistranslation: 0.417
vnc: 0.344
hypervisor: 0.333
permissions: 0.325
boot: 0.280
x86: 0.278
risc-v: 0.277
virtual: 0.264
VMM: 0.258
TCG: 0.216
arm: 0.213
kernel: 0.195
i386: 0.194
KVM: 0.086

usb passthrough mass storage write data corruption

the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb
in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and
except for the last packet for odd-sized files). The pattern is:
3 times bulk out 20480
1 time bulk out 4096

and that repeats for files longer than 65536 bytes.

the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each
20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and
57344-61440.
and so on. and because the 4096 sized  bulk out is always error free, the next corrupt span is from
81920-86016.

the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same
transfer.

to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file.
(possibly check the bulk transfer sizes with usbmon).
note that attaching usb disks with hw/usb/dev-storage does work just fine.
cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are
always ok even with usb passthrough.

it is apparently not a qemu bug, but either a libusb or (more likely) linux bug.
it happens on linux 3.6 but not linux 3.4, with the difference of:
(USBFS_CAP_NO_PACKET_SIZE_LIM | USBFS_CAP_BULK_SCATTER_GATHER)
added to the hcd capabilities bitfield in 3.6

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Did you report it to the libusb folks?

[Expired for QEMU because there has been no activity for 60 days.]