other: 0.183
semantic: 0.106
PID: 0.099
device: 0.087
files: 0.075
graphic: 0.073
debug: 0.067
network: 0.056
socket: 0.052
vnc: 0.050
permissions: 0.050
performance: 0.048
boot: 0.036
KVM: 0.017
PID: 0.170
debug: 0.170
files: 0.153
boot: 0.069
network: 0.067
device: 0.065
performance: 0.054
other: 0.051
semantic: 0.042
socket: 0.042
graphic: 0.039
vnc: 0.030
permissions: 0.028
KVM: 0.020

installing NT4 on MIPS Magnum/Jazz asserts

While installing NT4 on MIPS Magnum (Jazz), when the NT Installer tries to format the harddisk, QEmu 1.6.1 crashes with an assertion:

qemu-system-mips64el: g364: invalid read at [0000000000102000]
qemu-system-mips64el: hw/scsi/scsi-bus.c:1577: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed.
./nt4mips.sh: line 3: 20336 Aborted                 (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384

This assertion also occurred with the stock Ubuntu version of QEmu (1.5.0 (Debian 1.5.0+dfsg-3ubuntu5)) which I tried before.

Note that to even get this far, you need the patch mentioned in BUG1245924, otherwise QEmu 1.6.1 won't even start/boot at all

NT4 installation guide I'm following:
http://gunkies.org/wiki/Installing_Windows_NT_4.0_on_Qemu(MIPS)
http://virtuallyfun.superglobalmegacorp.com/?p=2255

As a side note, that "invalid read at..." warning is unrelated, as it happens right on startup

This bug is still present in qemu 1.7.0:

qemu-system-mips64el: g364: invalid read at [0000000000102000]
qemu-system-mips64el: hw/scsi/scsi-bus.c:1578: scsi_req_data: Assertion `req->cmd.mode != SCSI_XFER_NONE' failed.
./nt4mips.sh: line 3: 26409 Aborted                 (core dumped) ./qemu-system-mips64el --machine magnum -m 64 -net nic -net user -hda nt4.dsk -cdrom NTWKS40D.ISO -global ds1225y.filename=nvram.bin -global ds1225y.size=16384


We're about to release 2.0, so it would be more interesting to know whether it still happens in latest qemu.git.

And since this seems to depend on .iso and nvram.bin files that we don't have available for reproducing, some tracing on your part might help narrow down whether this is caused by a bug in MIPS-specific or generic SCSI code and what exactly it's been trying to do at the point of assertion. Running it in gdb to get a backtrace on SIGABRT would be a start. --enable-trace-backend= and -trace would be further options to investigate.

Indeed the crash doesn't happen in current git anymore. Setup still doesn't copy anything off the CD (hangs on the first file) but at least the crash is fixed and formatting the harddisk works now.

I'll investigate the other issue and maybe open up a new bug for that.

This bug here can be closed. Thank you!