Hi,
bgg wrote:
https://imgur.com/a/GEm7jjXHere is the bios booting up before the vm crashes.
Hrm - that's confusing.
From the debug log; at the time it crashes the CPU is in real mode, CS is set to 0xF000 with CS.base as 0xFFFF0000. That isn't normally possible in real mode (if CS is loaded with 0xF000 then CS.base would be set to 0x000F0000), but internally when 80x86 CPUs are first started or reset internally the CPU cheats and forces the abnormal "CS is 0xF000, CS.base as 0xFFFF0000" condition for historical reasons. In other words; this indicates that CS has not changed since the computer was turned on; including "CS not changed when starting an operating system's boot loader (e.g. by something like "jmp 0x0000:0x7C00").
Another thing is that SS:SP is 0x0000:0x0002 (the highest 16 bits of ESP are ignored in real mode). This would indicate that Qemu's firmware corrupted its own stack and then crashed, possibly because a function returned to a strange address because the stack was corrupted.
However; there's something else that doesn't make sense. In real mode the highest 16 bits of EIP are also ignored; so the CPU should be executing code at "CS.base+IP = 0xFFFF0000+0x07FD = 0xFFFF07FD", but it's crashing and saying that it tried to execute code at "0x1A6607FD". It's as if the CPU is executing 32 bit code (using the whole of EIP) with CS.base = 0 in real mode, which isn't possible (especially when the code segment descriptor's "default operand size" flag is clear and CS.base is not zero). From this I'd have to assume that the error message is wrong (misreports the address) and that it actually tried to execute code at 0xFFFF07FD, and that the ROM is 32 KiB or smaller.
In other words; the most likely scenario is:
- Qemu's firmware starts trying to boot from DVD/CD
- Qemu's firmware corrupts its own stack
- Qemu's firmware tries to execute code 0xFFFF07FD that doesn't exist
- Qemu stops emulating and reports the error, but displays the wrong address in the error message
Note that there is also the possibility that there's something strange about the DVD/CD that triggers a rare corner-case that Qemu's firmware fails to handle properly, and for a different DVD/CDs (ISOs) Qemu might work properly.
With that in mind; I'd suggest trying a different ISO (e.g. downloaded from somewhere you trust - e.g. maybe a Ubuntu installation CD) to see if the problem still occurs. I'd also try uninstalling and re-installing Qemu, just in case you've got a bad copy of Qemu's firmware.
That way you'd know if it's a problem you can work around (something strange about your ISO triggering bugs in Qemu's firmware) or if it's a problem that can only be fixed by Qemu's developers (everything triggers bugs in Qemu's firmware and the firmware isn't corrupted).
Cheers,
Brendan