OSDev.org

I have recently set up a bare bones C# setup on Ubuntu 18.04.
When I start up the ISO in qemu, it crashes out and sends out an error (in the title).
Any help?

Hi,



For people to be able to help you'd need to provide more information. For example, I'm not sure whether you installed Ubuntu (and a C# development environment) in the ISO and Ubuntu crashed, or whether it's your code on the ISO that crashed (or something else - GRUB, Mono, Qemu's firmware, ...).

Of course knowing what crashed is just the beginning (what was it doing when it crashed, was it compiled to use something like SSE that Qemu wasn't configured to support, ...).


Cheers,

Brendan

To clarify the qemu virtual machine crashed.
And here is the qemu debug information.
https://imgur.com/a/iQMd6f3

Hi,



That's Qemu emulating the guest machine crashing.



Most of the registers look like what you'd expect immediately after the (emulated) CPU starts (the values for CS especially); so I'd say it's safe to assume that Qemu's error message is correct and the problem is the second one - Qemu didn't find valid firmware so it kept executing "nothing" until EIP ran out of RAM.

There's a few command line arguments you can give Qemu to tell it where to find the BIOS - the "-L <path>" option to tell it the path of a directory containing the BIOS or the "-bios <file>" option to tell it the exact name of the file you want to use for the BIOS. You'd probably need to figure out where the BIOS was installed (or why it's missing) and try one of those.


Cheers,

Brendan

https://imgur.com/a/GEm7jjX
Here is the bios booting up before the vm crashes.

Hi,



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

I have reinstalled qemu and have gotten a different result.
https://imgur.com/a/Pdpl3uH
And I successfully booted a ubuntu 18.04 install iso.

I have fixed the issue with giving the qemu machine 300 MB of ram and adding a while(true) loop to the end of (wanted) execution. That could have been the problem before. And why 300MB? Any less would give the old memory error, and any more has the qemu system hang on the bios screen. Thank you for your help.