Kernel page fault with QEMU Accelerator Module enabled

Forum thread started by qwilk on Thu, 2006-06-22 19:53

Hello all,

I was wondering if anyone else have tried running Haiku under QEMU with the Accelerator Module (a.k.a. kqemu, see http://fabrice.bellard.free.fr/qemu/qemu-accel.html)? For me, Haiku boots fine when the Accelerator Module is disabled, but if enabled I get a kernel page fault during boot. And needless to say, virtualization is much nicer than emulation... :) I am using the raw images from http://www.schmidp.com/index.php?option=com_files&path=/haiku/images/ btw, and to verify that nothing was wrong with my QEMU setup I also tried AROS and ReactOS, and they both seem to work fine with kqemu enabled.

I guess most of you developers are likely using VMWare, but that's proprietary (though free-of-charge) software, and QEMU is free for all to download and is available for most operating systems ("Q" for Mac OS X being particularly nice).

Anyway, if any of you kernel devs could tell me what KDL info to dump I'd be glad to help out - let me know if you want me to.

BR//Karl -> qwilk
http://xoblite.net/

Comments

Kernel page fault with QEMU Accelerator Module enabled

Hi! Here's what you need to do:

  1. When in Kernel Debugging Land, type in "sc" to do a stack crawl.
  2. Go to http://www.haiku-os.org/bugzilla and either create an account or log into your existing one
  3. File a new bug report (after searching the existing reports to make sure the problem you're having hasn't already been reported) and attach the output from the stack crawl command you issued earlier along with other useful information like what you were doing, etc.

I don't use Qemu for testing, but I'm sure it supports logging serial output. This would be the easiest way to capture the output from the stack crawl.

Kernel page fault with QEMU Accelerator Module enabled

Thanks for the quick reply! :)

Unfortunately, for some reason I couldn't get the serial logging to file in QEMU to work (at least not on my Windows box). How much more info than what's being displayed in the KDL CLI is sent over serial? Just FYI, here's a screenshot of the stack crawl dump:

BR//Karl -> qwilk

Re: Kernel page fault with QEMU Accelerator Module enabled

qwilk wrote:
I guess most of you developers are likely using VMWare, but that's proprietary (though free-of-charge) software, and QEMU is free for all to download and is available for most operating systems ("Q" for Mac OS X being particularly nice).

Actually, I think that QEMU was the first officially supported emulation environment that Haiku was tested under.

I've never personally tried the kqemu option - but j_freeman is correct - you're best bet is to log it as a kernel issue in bugzilla.

For various emulator setups, btw, you can consult here:

http://www.haiku-os.org/wiki/index.php?title=Getting_Haiku

The "Using Haiku Images" link is probably where you want to look, but you'll also find some other potentially useful information here.

Most of the time, I test Haiku on a separate partition using real hardware :)

Kernel page fault with QEMU Accelerator Module enabled

j_freeman wrote:
[*]When in Kernel Debugging Land, type in "sc" to do a stack crawl.

In the Haiku debugger, I think it is not "sc" (stack crawl), but "bt" (back trace) instead.

Kernel page fault with QEMU Accelerator Module enabled

koki wrote:
j_freeman wrote:
[*]When in Kernel Debugging Land, type in "sc" to do a stack crawl.

In the Haiku debugger, I think it is not "sc" (stack crawl), but "bt" (back trace) instead.

I believe (unless something has changed) that they are both synonyms, with the resulting output stating "stack trace" to top it off :D - this should be true in the kernel debugger at least - not sure about gdb.

Kernel page fault with QEMU Accelerator Module enabled

umccullough wrote:
koki wrote:
j_freeman wrote:
[*]When in Kernel Debugging Land, type in "sc" to do a stack crawl.

In the Haiku debugger, I think it is not "sc" (stack crawl), but "bt" (back trace) instead.

I believe (unless something has changed) that they are both synonyms, with the resulting output stating "stack trace" to top it off :D - this should be true in the kernel debugger at least - not sure about gdb.

I do know that in gdb the bt command is used (instead of sc), so you may be right.

Kernel page fault with QEMU Accelerator Module enabled

umccullough wrote:
koki wrote:
j_freeman wrote:
[*]When in Kernel Debugging Land, type in "sc" to do a stack crawl.

In the Haiku debugger, I think it is not "sc" (stack crawl), but "bt" (back trace) instead.

I believe (unless something has changed) that they are both synonyms, with the resulting output stating "stack trace" to top it off :D - this should be true in the kernel debugger at least - not sure about gdb.

I believe so 8).

Gdb: bt, back trace, where and backtrace.
Kernel Debugger: bt, where, sc.

Not sure about the 'stack trace' command though in the kernel debugger.

Kernel page fault with QEMU Accelerator Module enabled

I always get bt and sc mixed up. Occasionally I get it right on the first try, but usually I end up typing in the wrong one.

In KDL, I use sc. In GDB, I use bt. Are there others I'm unaware of?

And when I said "stack crawl" I meant stack trace. :oops:

qwilk wrote:
How much more info than what's being displayed in the KDL CLI is sent over serial?

Depending on how far into the system you get, it could be a whole lot. Here's some example output of Haiku crashing just after Tracker loads. (Of course, I rebooted... so there's 2 outputs in that.)

All sorts of events are logged, from when Haiku first starts until the system shuts down (or crashes). This allows devs to see what was happening up to the crash and give insight on what the problem is and how to fix it.

But if you can't get serial output to work, the stack trace should be sufficient. Just make sure you specify what you were doing when it happened. And if you can reproduce it, tell them how. (It's even better if they can reproduce the bug, as they won't need your stack trace or serial output--they can make their own!)

Kernel page fault with QEMU Accelerator Module enabled

To whom it may concern:

FYI I've just tried revision 18522 under the recently released QEMU 0.8.2 + the latest QEMU Accelerator Module version 1.3.0pre9, and it boots and works just fine now! :D

Thanks,

BR//Karl -> qwilk
http://xoblite.net/

Kernel page fault with QEMU Accelerator Module enabled

qwilk wrote:
To whom it may concern:

FYI I've just tried revision 18522 under the recently released QEMU 0.8.2 + the latest QEMU Accelerator Module version 1.3.0pre9, and it boots and works just fine now! :D

Thanks,

BR//Karl -> qwilk
http://xoblite.net/

Good to know :)

I'll probably be putting together some new info on setting up Haiku in virtual machines soon - were there any special tricks to make the accelerator work? I assume no (in the end).

Kernel page fault with QEMU Accelerator Module enabled

Definitely not working here under Gentoo Linux with the same versions of all modules/software quoted above. Getting an error regarding pagefaults with interrupts turned off ...

Kernel page fault with QEMU Accelerator Module enabled

eNGIMa wrote:
Definitely not working here under Gentoo Linux with the same versions of all modules/software quoted above. Getting an error regarding pagefaults with interrupts turned off ...

That's a bummer - I suppose maybe the windows version could work differently (since it has to provide "native" access to the hardware through a different method I'm sure).

I guess this means I'll need to try it myself on windows. I will report back.

Kernel page fault with QEMU Accelerator Module enabled

eNGIMa wrote:
Definitely not working here under Gentoo Linux with the same versions of all modules/software quoted above. Getting an error regarding pagefaults with interrupts turned off ...

Please, so that the devs become aware of these issues and potentially fix them, file bugs at www.haiku-os.org/bugzilla (if you have not already, that is :-).

Thanks!

Kernel page fault with QEMU Accelerator Module enabled

koki wrote:
Please, so that the devs become aware of these issues and potentially fix them, file bugs at www.haiku-os.org/bugzilla (if you have not already, that is :-).

Already done so :) http://www.haiku-os.org/bugzilla/show_bug.cgi?id=748

Kernel page fault with QEMU Accelerator Module enabled

On my Windows XP machine, qemu-0.8.2-windows and kqemu-1.3.0pre9 run just fine with Haiku. Whether I start it with or without kqemu support, it still runs without KDL.

There is definitely a noticeable difference with kqemu on my Intel P4 3ghz box - so I would have to say this definitely good news.

Hopefully the linux issue is minor and can be fixed :)

Kernel page fault with QEMU Accelerator Module enabled

My guess currently is that my installation had some GCC level inconsistencies. Qemu isn't able to be compiled with GCC 4.x so I had to temporarily switch to GCC3.4; Now that version has an identical ABI so in _theory_ it shouldn't be a problem. I've tried removing every trace of kqemu and qemu from my system and rebuilding _all_ depencencies with GCC3.4 but it still appears borked on my end.

Unfortunately a day or two ago portage did an update which appears to conflict with kqemu, so I can't test again for a little bit. On that note, I had a glance at getting it running under Ubutu, but haven't had the time to manually install it (Unless anyone can point me to a prebuilt repository). I'll let you all know how it goes whatever the case as soon as portage updates.

PS: Would be a great idea to mention kqemu for Windows with the rest of the emu/virtualisation stuff, the speed difference as you've noticed is pretty damn good.

Kernel page fault with QEMU Accelerator Module enabled

eNGIMa wrote:
PS: Would be a great idea to mention kqemu for Windows with the rest of the emu/virtualisation stuff, the speed difference as you've noticed is pretty darn good.

Noted.

I did start making some verbiage/layout changes to the "Using Haiku Images" article - but I didn't have a lot of time so I just applied them to the "article in progress" on the new site.