Description of problem: Kernel panic on boot of Fedora 7 in a QEMU 0.8.2 VM using kqemu acceleration. Version-Release number of selected component (if applicable): kernel-2.6.21-1.3194.fc7 How reproducible: Always Steps to Reproduce: 1. Install QEMU 0.8.2 on host. 2. Install dkms-kqemu on host. 3. modprobe kqemu 4. Create QEMU raw image file. 5. Install F7 in QEMU 0.8.2 image file. 6. Enable kqemu by adding -kernel-kqemu arg to qemu command. 7. Boot QEMU F7 image file. Actual results: Kernel panics. Expected results: System boots. Additional info:
Created attachment 156368 [details] 50-line screenshot of boot
The host system is FC6.
F7 will boot without -kernel-kqemu argument but then runs too slow to be usable.
KVM in FC6 is not supported -- it is too old and has a lot of bugs. And this is an FC6 bug -- this should work fine with FC7 as the host.
We are not talking about KVM here. KVM is not present on FC6. But kqemu acceleration for QEMU in FC6 is and has been working just fine. I have many OS installed in QEMU 0.8.2 on FC6 that are working just fine with -kernel-kqemu acceleration. Even one of the most difficult which is Windows XP is running fine. I'm going to attach some screenshots so you can see this. This is an F7 problem, not FC6. The F7 kernel is having some type of hardware driver problem would be my guess. libata maybe? If kqemu were having problems with other OS then maybe problem could be FC6. But that's not the case. So problem is an F7 problem.
Created attachment 156528 [details] screenshot showing kernel-kqemu status on FC6
Created attachment 156529 [details] screenshot showing Windows XP running in QEMU on FC6 w/kernel-kqemu
This is a kqemu bug, then. Unless someone can demonstrate a problem on real hardware we cannot possibly fix it or we'd be chasing emulator bugs forever. If it's an emulator we ship and support then we can fix it. FWIW: b2 02 mov $0x2,%dl 66 98 cbtw f6 fa idiv %dl <======= oops here The value 2 was moved to dl in the first instruction but there is now a zero there. (edx == c06e0000) This is either a broken CPU or an emulator bug.