add 18th iteration of classifier

1 files changed, 64 insertions, 0 deletions

diff --git a/results/classifier/118/files/1247478 b/results/classifier/118/files/1247478
new file mode 100644
index 000000000..d5255ebd4
--- /dev/null
+++ b/results/classifier/118/files/1247478
@@ -0,0 +1,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.]
+