1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
mistranslation: 0.821
semantic: 0.771
other: 0.770
instruction: 0.751
assembly: 0.738
device: 0.723
graphic: 0.721
KVM: 0.696
vnc: 0.664
network: 0.605
boot: 0.599
socket: 0.582
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.]
|