1 files changed, 146 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1276879 b/results/classifier/zero-shot/108/other/1276879
new file mode 100644
index 000000000..b46fa06a0
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1276879
@@ -0,0 +1,146 @@
+permissions: 0.777
+semantic: 0.771
+other: 0.770
+debug: 0.750
+device: 0.723
+graphic: 0.721
+PID: 0.717
+performance: 0.697
+KVM: 0.696
+vnc: 0.664
+network: 0.605
+boot: 0.599
+socket: 0.582
+files: 0.538
+
+lots of dma command 10, 14 not supported
+
+Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0.
+In the terminal that started QEMU, there are a lot of
+    dma: command 10 not supported
+and 
+    dma: command 14 not supported
+messages.  When the installation of NeXTSTEP gets to
+'preparing disk for nextstep installation', there are a lot
+of messages that ATA command c5 failed and other info.
+The result is a failed installation.
+
+Is this a bug in QEMU?  Is there a workaround, e.g. by
+disabling DMA altogether?
+
+thank you
+
+Getting the same result in QEMU 1.6.2.  NeXT setup is reporting
+'interrupt timeout, cmd: 0xc5', ATA command c5 failed,
+resetting drives.
+This repeats until it gives up.
+
+
+On 02/06/14 02:14, tyler knosis wrote:
+> Public bug reported:
+> 
+> Trying to install NeXTSTEP 3.3 onto a 2GB file with QEMU 1.7.0.
+> In the terminal that started QEMU, there are a lot of
+>     dma: command 10 not supported
+> and 
+>     dma: command 14 not supported
+> messages.
+
+These correspond to
+
+  CMD_CYCLIC_PRIORITY
+
+and
+
+  CMD_CYCLIC_PRIORITY | CMD_BLOCK_CONTROLLER
+
+in write_cont() [hw/dma/i8257.c]. They are not supported (see
+CMD_NOT_SUPPORTED in the same file).
+
+> When the installation of NeXTSTEP gets to
+> 'preparing disk for nextstep installation', there are a lot
+> of messages that ATA command c5 failed and other info.
+> The result is a failed installation.
+
+0xC5 is WIN_MULTWRITE ("write sectors using multiple mode"), and it
+seems to hook into DMA.
+
+> Is this a bug in QEMU?
+
+Probably not, it's more likely "incomplete" DMA emulation ("lack of
+support").
+
+> Is there a workaround, e.g. by
+> disabling DMA altogether?
+
+It's worth a try I guess, if you can figure out a way how to do that.
+FWIW, ide_identify() appears to report unconditional support for:
+- single word dma0-2
+- mdma0-2
+- udma5
+
+(I have no clue about IDE or DMA btw.)
+
+Laszlo
+
+
+p.s.  I tried Bochs 2.6.2, and it is not stuck at the same place.  Did qemu take the bochs bios
+and change anything regarding the IDE drives?
+
+
+Successfully installed NextStep in bochs, but not qemu.
+
+Having same problem with OpenStep 4.2 in qemu.
+
+
+http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg00889.html
+
+So, Zoltan pointed to two patches.  I applied the first (v8-06-10-i8259-fix.....),
+but the second patches a file that is not in version 1.7.0.
+
+With the one patch, I am now able to get past the step where it crapped out
+before.  The dma messages are still there, but it seems that they can be ignored.
+NextStep can now install its basic system onto a file.
+
+Thank you for the help so far.
+
+Now, I get to the point when NeXTStep want me to click on something to configure
+the new system, but QEMU is not grabbing the mouse.  After this step, it will install
+the remainder of the system + apps.
+
+I have a USB mouse on a x86_64 linux machine, and QEMU 1.7.0.  This is the
+command line I used:
+qemu-system-x86_64 -hda x.img -fda f.img -cdrom cd.img
+
+I have tried ctl-alt (both sides of the keyboard) to no avail.
+
+
+The other patch is for KVM. Here's a way to build a patched kvm module (I did not test it):
+http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_0_kvm_kmod_build
+
+A click in the window should be enough to grab the mouse. If it's not working it may be that NeXTSTEP is using a different driver than what QEMU emulates. Since NeXTSTEP is quite old you may have better luck with a serial mouse emulation such as msmouse or make sure a PS/2 mouse driver is selected in NeXTSTEP (it may not autodetect it).
+
+
+No luck with msmouse.  NextStep assumes a PS/2 mouse, I believe,
+which is what QEMU emulates by default.  In bochs, the mouse does
+work in NextStep.  Do you know if bochs emulates the PS/2 mouse
+by default?
+
+
+I don't know about Bochs but here's another page with resources on running OPENSTEP on a VM:
+http://www.zebpedersen.co.uk/?p=126
+The VMWare drivers (both svga and mouse) should work with QEMU too but I don't know if they are compatible with NeXTSTEP.
+Now I remember there was some problem with mouse emulation with the PS/2 or serial driver also on VMWare which made the mouse pointer jump around and then freeze. This may also happen with QEMU but it was never debugged AFAIK.
+
+thank you.  Will keep at it.
+
+
+Mouse not working in WinXP with QEMU either.
+But it is working with bochs (same disk image).
+
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+