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.
When in Kernel Debugging Land, type in "sc" to do a stack crawl.
Go to http://www.haiku-os.org/bugzilla and either create an account or log into your existing one
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.
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:
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:
[*]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 - this should be true in the kernel debugger at least - not sure about gdb.
[*]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 - 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.
[*]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 - 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.
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!)
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!
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!
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).
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 …
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.
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 :-).
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 :-).
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
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.
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.
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.
- this should be true in the kernel debugger at least - not sure about gdb.