Dmitry Eremin-Solenikov wrote: > Jan Kiszka пишет: >> Dmitry Eremin-Solenikov wrote: >>> Jan Kiszka пишет: >>>> Dmitry Eremin-Solenikov wrote: >>>>> Gleb Natapov wrote: >>>>>> On Wed, Apr 15, 2009 at 01:30:29PM +0400, Dmitry Eremin-Solenikov >>>>>> wrote: >>>>>>> qemu-x86_64 version 0.10.2 running on i386 >>>>>>> Due to problems with qemu-x86_64 I have to boot the 'host' kernel >>>>>>> with 'noapic'. >>>>>> Do you mean boot 'guest' kernel with noapic? The guest is what runs >>>>>> inside qemu. So you are able to boot guest with 'noapic'? >>>>>> >>>>>> What is the command line you are using. >>>>> Well, since this caused lot's of questions, here is my setup: >>>>> >>>>> Main host: Debian squeeze, kernel 2.6.28 or .29 (doesn't matter), >>>>> qemu-system-x86_64 version 0.10.2 >>>>> >>>>> KVM kernel run inside qemu: e3dbe3f408a46a045012f1882e9f62b27b8a616c >>>>> from Avi's tree (KVM: x86 emulator: fix call near emulation) + these >>>>> patches. I have to boot the kernels (both this kernel and 2.6.26 from >>>>> debian) with noapic to w/around APIC problems (I dunno if it's qemu or >>>>> bochsbios problem). >>>> And the bios you are using with 0.10.2 is from 0.10.2 (when in doubt, >>>> specify explicitly with -bios and/or -L)? Then this would be a QEMU >>>> upstream bug. >>> Indeed, there seem to be problems with upstream qemu bios. I was using >>> the image from the debian's bochsbios package. >> >> Bochsbios is typically lacking some patches qemu needs, therefore that >> bios patch queue in qemu. > > Debian's bochsbios provides two bios versions: one for bochs and one > patched with qemu (maybe not the latest patches though) > >>> I asked qemu to use the >>> bios from 0.10.2 release and got slightly different messages. Attached >>> the kernel log >>> >> >> ... >> >>> init IO_APIC IRQs >>> 1-0 (apicid-pin) not connected >>> IOAPIC[0]: Set routing entry (1-1 -> 0x31 -> IRQ 1 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-2 -> 0x30 -> IRQ 0 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-3 -> 0x33 -> IRQ 3 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-4 -> 0x34 -> IRQ 4 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-5 -> 0x35 -> IRQ 5 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-6 -> 0x36 -> IRQ 6 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-7 -> 0x37 -> IRQ 7 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-8 -> 0x38 -> IRQ 8 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-9 -> 0x39 -> IRQ 9 Mode:1 Active:1) >>> IOAPIC[0]: Set routing entry (1-10 -> 0x3a -> IRQ 10 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-11 -> 0x3b -> IRQ 11 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-12 -> 0x3c -> IRQ 12 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-13 -> 0x3d -> IRQ 13 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-14 -> 0x3e -> IRQ 14 Mode:0 Active:0) >>> IOAPIC[0]: Set routing entry (1-15 -> 0x3f -> IRQ 15 Mode:0 Active:0) >>> 1-16 1-17 1-18 1-19 1-20 1-21 1-22 1-23 (apicid-pin) not connected >>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 >>> ..MP-BIOS bug: 8254 timer not connected to IO-APIC >>> ...trying to set up timer (IRQ0) through the 8259A ... >>> ..... (found apic 0 pin 2) ... >>> ....... failed. >>> ...trying to set up timer as Virtual Wire IRQ... >>> ..... failed. >>> ...trying to set up timer as ExtINT IRQ... >>> ..... failed :( . >>> Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with >>> apic=debug and send a report. Then try booting with the 'noapic' >>> option. >> >> This looks a bit like [1, 2] on first glance... >> >> Jan >> >> [1] http://permalink.gmane.org/gmane.comp.emulators.qemu/41300 >> [2] http://permalink.gmane.org/gmane.comp.emulators.qemu/41433 > > Looks like a part of this changes. You mean the kernel boots for you now? > However I don't quite understand: > these patches should address non-ACPI OS, but linux is surely and ACPI os! That's what I also do not understand ATM. I've once seen the above error as well, but with a !CONFIG_ACPI kernel. However, I'd suggest to move the issue (if it still exists) to qemu-devel until we reach KVM specifics again. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
