1 files changed, 91 insertions, 0 deletions
diff --git a/results/classifier/108/other/1608802 b/results/classifier/108/other/1608802
new file mode 100644
index 000000000..e5430e8f8
--- /dev/null
+++ b/results/classifier/108/other/1608802
@@ -0,0 +1,91 @@
+semantic: 0.682
+network: 0.624
+permissions: 0.621
+other: 0.559
+device: 0.546
+performance: 0.502
+debug: 0.492
+boot: 0.492
+graphic: 0.480
+socket: 0.447
+files: 0.446
+PID: 0.436
+vnc: 0.436
+KVM: 0.296
+
+READ_DMA (0xC8) command does not work correctly
+
+The QEMU PC emulation of DMA does not behave like real hardware or other virtualization software.
+
+From the original bug report (Benjamin David Lunt):
+
+    Back to the READ_DMA command, it is my conclusion that the
+    READ_DMA command, more precisely, the BUS Master part of QEMU is
+    in error.  The tests that people have done to see if it works, is
+    probably the guest finding out that DMA doesn't work and defaulting
+    to PIO, but since the read was successful visually to the user, the
+    user assumed the READ_DMA command works, where the guest actually
+    defaulted back to PIO transfers without notice.
+
+    My code works on real hardware (numerous machines), Bochs, and Oracle's
+    Virtual Box.
+
+    ...
+
+    I have a small test suite, zipped and included at:
+    www.fysnet.net/temp/c8bug.zip
+
+    Within this zip file is a.img. This is a freeDOS bootable
+    floppy.  Emulate it with QEMU and then at the DOS prompt, run
+    c8bug.exe.
+
+    It will say that the drive is not ready.
+     "Drive never became ready"
+    (along with a few other lines of text)
+
+    The source for this test suite is also included.
+     c8bug.c is the c source code
+     c8bug.h is the header file
+     ctype.h is a quick way to get 'bit8u' type defines
+     timer.h is a delay routine from another project I have
+    (The base IO addresses are assumed and set at the top of c8bug.c)
+    (compiled with DJGPP for DPMI)
+
+    q.bat is my command line for QEMU
+
+    On all other machines and VirtualBox, the controller is ready
+    for me to receive the sector data.
+     "Drive is ready to transmit data..."
+
+    However, in QEMU, the controller never becomes ready.
+     "Drive never became ready" 
+
+The bug was reported for QEMU for Windows, but I can confirm that QEMU for Linux also shows that
+behaviour, while VirtualBox works.
+
+Okay, I think there are two parts to this, and both the test case and qemu are
+buggy, though perhaps the test case more seriously than qemu.
+
+The ATA spec describes DMA commands as having two phases, preparation and
+transfer. During the first phase, BSY=1,DRQ=0 is required. In the second phase,
+the device can use the same status (BSY=1,DRQ=0) or switch to BSY=0,DRQ=1.
+I couldn't find clear information on which state the device should be in between
+receiving the ATA command and enabling the bus master operation, which is what
+the test case checks, but it must be one of the two.
+
+So the reason that the test case is buggy is that it waits for DRQ to be set,
+while the spec only guarantees that either DRQ or BSY is set during the
+transfer. It doesn't work on hardware that sets BSY rather than DRQ. (It also
+means that the test expects the device to be in the transfer state before the
+bus master is enabled.)
+
+The problem with qemu is that it sets _both_ bits, whereas the spec requires
+that only one of them is set. Apparently most drivers don't care about this as
+long as any of the bits is set, but technically it's wrong.
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+