BareMetal
BareMetal copied to clipboard
ReturnInfinity
Random lockups when running in qemu
First off, sorry this bug report isn't too specific about a number of things, mostly involving steps to reproduce the problem... Anyway, the problem is that BM hangs a lot. I have been playing with modifying the c source for the hello world demo app, by doing simple things like adding another line of output using b_output(), and it will often hang up and not go back to the command prompt. Other times it will print both lines correctly, but adding any more code after that and it starts hanging again.
I've tried recompilation without any code changes, and it has acted differently both times! Sometimes there is a message about an interrupt being handled, other times it just silently crashes. I've tried building my own qemu binary from current git sources, but the problem persists. The BM tree is from current git, too....
Go ahead and close this bug if you are unable to reproduce it, and I'll chalk it up to not wearing my tinfoil hat or something :-). I just wanted to vent. And please let me know if there is a good way to track down the problem, too - maybe I could get someone some debug logs or something.
Go ahead and close this bug if you are unable to reproduce it, and I'll chalk it up to not wearing my tinfoil hat or something :-).
First, try taking the tinfoil hat off and putting it back on again.
Secondly, do you have a system monitor that you can check to see what's causing the hang up? That might indicate if it's a disk program or a CPU program.
On the host, I can run 'top', which shows that the "qemu-system-x86" process is consuming around 100% of the CPU once the hangup condition shows itself:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3774 jon 20 0 1322064 162296 59716 S 102.3 4.2 1:07.79 qemu-system-x86
If you do some Google searching, you will find some scattered references over the years to a problem with QEMU where it locks up and the CPU used by the qemu-x-y process spikes to around 100%. I'm not sure if this is a factor in this particular case, but it's all I could find in the way of a case for blaming the problem on QEMU instead of the BM guest code....