1 files changed, 43 insertions, 0 deletions
diff --git a/results/classifier/108/other/1014099 b/results/classifier/108/other/1014099
new file mode 100644
index 00000000..8c9045ad
--- /dev/null
+++ b/results/classifier/108/other/1014099
@@ -0,0 +1,43 @@
+network: 0.730
+performance: 0.581
+other: 0.483
+device: 0.479
+files: 0.478
+socket: 0.476
+graphic: 0.457
+semantic: 0.389
+permissions: 0.368
+vnc: 0.359
+boot: 0.341
+PID: 0.332
+debug: 0.307
+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.
+