1 files changed, 58 insertions, 0 deletions
diff --git a/results/classifier/118/none/1014099 b/results/classifier/118/none/1014099
new file mode 100644
index 000000000..3b25ea2d0
--- /dev/null
+++ b/results/classifier/118/none/1014099
@@ -0,0 +1,58 @@
+network: 0.730
+architecture: 0.605
+ppc: 0.603
+performance: 0.581
+device: 0.479
+files: 0.478
+socket: 0.476
+mistranslation: 0.459
+graphic: 0.457
+peripherals: 0.412
+kernel: 0.408
+hypervisor: 0.404
+register: 0.396
+semantic: 0.389
+permissions: 0.368
+vnc: 0.359
+boot: 0.341
+PID: 0.332
+risc-v: 0.321
+debug: 0.307
+user-level: 0.306
+VMM: 0.221
+arm: 0.218
+i386: 0.217
+virtual: 0.215
+TCG: 0.192
+x86: 0.169
+assembly: 0.142
+KVM: 0.130
+
+hw/esp.c does not properly deal with TEST_UNIT_READY in NetBSD/sparc
+
+The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN but dma disabled sometimes (early during bus enumeration). This is fine, as the command will not produce nor consume any data, and works on real hardware.
+
+However, the qemu emulation does not allow this (for reasons I don't understand).
+
+The change below fixes the problem.
+
+
+
+Guess I understand the code now - so here is a working version - though it may be considered slightly hackish
+
+On Sat, Jun 16, 2012 at 5:50 PM, Martin Husemann <email address hidden> wrote:
+> ** Patch added: "esp.c.patch"
+>   https://bugs.launchpad.net/bugs/1014099/+attachment/3192643/+files/esp.c.patch
+
+Please see this on how to contribute patches to QEMU:
+http://wiki.qemu.org/Contribute/SubmitAPatch
+
+Stefan
+
+
+Patch removed, as it was bogus and your workflow is weird, so I'll post a better patch to the devel list
+
+Has this problem been fixed in 2012, so that we could close this ticket now? Or is there still something left to do?
+
+Yes. Just to make sure I tested qemu 2.8 against an old disk image from 2012 and it boots fine w/o any  complaints during the device probes.
+