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.]