Re: 2.6.27.5 guest boot failure using in-kernel PIT
On Fri, Nov 21, 2008 at 3:10 PM, Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> Hi Jan,
>
> On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote:
>> Eduardo Habkost wrote:
>> > On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote:
>> >> Hi,
>> >>
>> >> When using a kvm.git kernel as host, I am getting guest boot failures
>> >> when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest
>> >> stops booting at:
>> >>
>> >> ENABLING IO-APIC IRQs
>> >> ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ...
>> >> ... failed.
>> >> ...trying to set up timer as Virtual Wire IRQ...
>> >> . failed.
>> >> ...trying to set up timer as ExtINT IRQ...
>> >
>> > I've just found out this problem happens because the guest has HZ=1000
>> > and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS.
>> >
>> > With this setup, the host is not managing to inject enough timer
>> > interrupts during the mdelay() loop on timer_irq_works().
>> >
>>
>> Interesting, and plausible.
>>
>> My observation so far is a sporadic test failure, often correlating with
>> some raised host OS load. I'm running a high-res kernel, but that cannot
>> prevent that this only 10 ticks long loop of the guest may obtain too
>> few CPU cycles to handle enough of them once in a while (IIRC, it needs
>> 4 out of the 10 ticks to declare the timer routing functional).
>
> Using in-kernel PIT?
>
> This is a potential problem which can be worked around by disabling the
> whole thing either via no_timer_check or paravirt equivalent (Glauber?)
> but for the non-paravirt case it seems its not the culprit. Possible
> failure scenarios:
For KVM_CLOCK case, I believe there's absolutely no reason to be more
complicated than than that:
+extern int no_timer_check;
+
void __init kvmclock_init(void)
{
if (!kvm_para_available())
@@ -178,6 +180,8 @@ void __init kvmclock_init(void)
if (kvmclock && kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE)) {
if (kvm_register_clock("boot clock"))
return;
+
+ no_timer_check = 1;
pv_time_ops.get_wallclock = kvm_get_wallclock;
pv_time_ops.set_wallclock = kvm_set_wallclock;
pv_time_ops.sched_clock = kvm_clock_read;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27.5 guest boot failure using in-kernel PIT
Hi Jan, On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote: > Eduardo Habkost wrote: > > On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: > >> Hi, > >> > >> When using a kvm.git kernel as host, I am getting guest boot failures > >> when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest > >> stops booting at: > >> > >> ENABLING IO-APIC IRQs > >> ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... > >> ... failed. > >> ...trying to set up timer as Virtual Wire IRQ... > >> . failed. > >> ...trying to set up timer as ExtINT IRQ... > > > > I've just found out this problem happens because the guest has HZ=1000 > > and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. > > > > With this setup, the host is not managing to inject enough timer > > interrupts during the mdelay() loop on timer_irq_works(). > > > > Interesting, and plausible. > > My observation so far is a sporadic test failure, often correlating with > some raised host OS load. I'm running a high-res kernel, but that cannot > prevent that this only 10 ticks long loop of the guest may obtain too > few CPU cycles to handle enough of them once in a while (IIRC, it needs > 4 out of the 10 ticks to declare the timer routing functional). Using in-kernel PIT? This is a potential problem which can be worked around by disabling the whole thing either via no_timer_check or paravirt equivalent (Glauber?) but for the non-paravirt case it seems its not the culprit. Possible failure scenarios: 1) lpj miscalibration (SMP guests), which kvm-clock deals with. 2) proper lpj calibration, so m/udelay behave as expected, but not enough interrupts can be injected due to CPU starvation as you mention. On my testbox, with each pCPU running a cycle hog on nice -10, the first timer_irq_works call (via IOAPIC) won't fail (guest is truly starved). Host with both CONFIG_PREEMPT/CONFIG_PREEMPT_VOLUNTARY. And moreover, code attempts to first deliver via IOAPIC, then 8259A, then virtual wire. Reports show all three failing. 3) Failure to inject the interrupt will break the in-kernel PIT ack logic. The VMX NMI/IRQ race you fixed can certainly cause this. Can you reproduce it with the fix (and CONFIG_KVM_CLOCK=y) ? Any other possibilities? > Maybe Gleb's anti-coalesce patches for the PIC can also deal with your > timer resolution conflict. At least worth a try... > > Jan > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27.5 guest boot failure using in-kernel PIT
On Fri, Nov 21, 2008 at 02:39:22PM -0200, Eduardo Habkost wrote: > On Fri, Nov 21, 2008 at 04:41:00PM +0100, Jan Kiszka wrote: > > Eduardo Habkost wrote: > > > I am seeing the problem here > > > when using the in-kernel PIT, but (surprisingly) my setup works when > > > using -no-kvm-pit. > > > > Weird, makes no sense to me as well ATM. > > The qemu PIT seems to calculate the timeout for its timer as a function > of the time where the PIT timer was set up (count_load_time) and the > last timer set up (next_transition_time), without looking at the current > time. After missing some ticks and getting the timer triggered late, > it will set up a lot of "trigger on the past" timers before the guest > finished the mdelay() loop. > > The in-kernel PIT seems to try to do the same thing (it just calls > hrtimer_add_expires_ns() on the timer), but maybe the behaviour of the > kernel timers is different of the qemu timers when a timer is set up > to be triggered on the past. On my host-HZ=250 guest-HZ=1000 setup, > it was incrementing pit_timer.pending only once every 4 milliseconds. That's the case. From a probe on __pit_timer_fn.return: 19344471136382 timer_fn returning. timer expires now at: 19343448496177 19344475128359 timer_fn returning. timer expires now at: 19343449496025 19344479128694 timer_fn returning. timer expires now at: 19343450495873 19344483129394 timer_fn returning. timer expires now at: 19343451495721 The number at the beginning of the lines is ktime_get(). The timer expiration time is on the past, but the kernel keeps triggering the timer once every 4 ms. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27.5 guest boot failure using in-kernel PIT
On Fri, Nov 21, 2008 at 04:41:00PM +0100, Jan Kiszka wrote: > Eduardo Habkost wrote: > > On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote: > >> Eduardo Habkost wrote: > >>> On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: > Hi, > > When using a kvm.git kernel as host, I am getting guest boot failures > when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest > stops booting at: > > ENABLING IO-APIC IRQs > ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... > ... failed. > ...trying to set up timer as Virtual Wire IRQ... > . failed. > ...trying to set up timer as ExtINT IRQ... > >>> I've just found out this problem happens because the guest has HZ=1000 > >>> and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. > >>> > >>> With this setup, the host is not managing to inject enough timer > >>> interrupts during the mdelay() loop on timer_irq_works(). > >>> > >> Interesting, and plausible. > >> > >> My observation so far is a sporadic test failure, often correlating with > >> some raised host OS load. I'm running a high-res kernel, but that cannot > >> prevent that this only 10 ticks long loop of the guest may obtain too > >> few CPU cycles to handle enough of them once in a while (IIRC, it needs > >> 4 out of the 10 ticks to declare the timer routing functional). > >> > >> Maybe Gleb's anti-coalesce patches for the PIC can also deal with your > >> timer resolution conflict. At least worth a try... > > > > Aren't Gleb patches for the userspace PIT? > > Yeah, they are, so you won't benefit from them for in-kernel cases. But > with in-kernel emulation just the probability of coalesced ticks is a > bit lower, they cannot be avoided either. > > > I am seeing the problem here > > when using the in-kernel PIT, but (surprisingly) my setup works when > > using -no-kvm-pit. > > Weird, makes no sense to me as well ATM. The qemu PIT seems to calculate the timeout for its timer as a function of the time where the PIT timer was set up (count_load_time) and the last timer set up (next_transition_time), without looking at the current time. After missing some ticks and getting the timer triggered late, it will set up a lot of "trigger on the past" timers before the guest finished the mdelay() loop. The in-kernel PIT seems to try to do the same thing (it just calls hrtimer_add_expires_ns() on the timer), but maybe the behaviour of the kernel timers is different of the qemu timers when a timer is set up to be triggered on the past. On my host-HZ=250 guest-HZ=1000 setup, it was incrementing pit_timer.pending only once every 4 milliseconds. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27.5 guest boot failure using in-kernel PIT
Eduardo Habkost wrote: > On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote: >> Eduardo Habkost wrote: >>> On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: Hi, When using a kvm.git kernel as host, I am getting guest boot failures when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest stops booting at: ENABLING IO-APIC IRQs ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... ... failed. ...trying to set up timer as Virtual Wire IRQ... . failed. ...trying to set up timer as ExtINT IRQ... >>> I've just found out this problem happens because the guest has HZ=1000 >>> and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. >>> >>> With this setup, the host is not managing to inject enough timer >>> interrupts during the mdelay() loop on timer_irq_works(). >>> >> Interesting, and plausible. >> >> My observation so far is a sporadic test failure, often correlating with >> some raised host OS load. I'm running a high-res kernel, but that cannot >> prevent that this only 10 ticks long loop of the guest may obtain too >> few CPU cycles to handle enough of them once in a while (IIRC, it needs >> 4 out of the 10 ticks to declare the timer routing functional). >> >> Maybe Gleb's anti-coalesce patches for the PIC can also deal with your >> timer resolution conflict. At least worth a try... > > Aren't Gleb patches for the userspace PIT? Yeah, they are, so you won't benefit from them for in-kernel cases. But with in-kernel emulation just the probability of coalesced ticks is a bit lower, they cannot be avoided either. > I am seeing the problem here > when using the in-kernel PIT, but (surprisingly) my setup works when > using -no-kvm-pit. Weird, makes no sense to me as well ATM. Jan signature.asc Description: OpenPGP digital signature
Re: 2.6.27.5 guest boot failure using in-kernel PIT
On Fri, Nov 21, 2008 at 08:54:56AM +0100, Jan Kiszka wrote: > Eduardo Habkost wrote: > > On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: > >> Hi, > >> > >> When using a kvm.git kernel as host, I am getting guest boot failures > >> when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest > >> stops booting at: > >> > >> ENABLING IO-APIC IRQs > >> ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... > >> ... failed. > >> ...trying to set up timer as Virtual Wire IRQ... > >> . failed. > >> ...trying to set up timer as ExtINT IRQ... > > > > I've just found out this problem happens because the guest has HZ=1000 > > and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. > > > > With this setup, the host is not managing to inject enough timer > > interrupts during the mdelay() loop on timer_irq_works(). > > > > Interesting, and plausible. > > My observation so far is a sporadic test failure, often correlating with > some raised host OS load. I'm running a high-res kernel, but that cannot > prevent that this only 10 ticks long loop of the guest may obtain too > few CPU cycles to handle enough of them once in a while (IIRC, it needs > 4 out of the 10 ticks to declare the timer routing functional). > > Maybe Gleb's anti-coalesce patches for the PIC can also deal with your > timer resolution conflict. At least worth a try... Aren't Gleb patches for the userspace PIT? I am seeing the problem here when using the in-kernel PIT, but (surprisingly) my setup works when using -no-kvm-pit. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27.5 guest boot failure using in-kernel PIT
Eduardo Habkost wrote: > On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: >> Hi, >> >> When using a kvm.git kernel as host, I am getting guest boot failures >> when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest >> stops booting at: >> >> ENABLING IO-APIC IRQs >> ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... >> ... failed. >> ...trying to set up timer as Virtual Wire IRQ... >> . failed. >> ...trying to set up timer as ExtINT IRQ... > > I've just found out this problem happens because the guest has HZ=1000 > and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. > > With this setup, the host is not managing to inject enough timer > interrupts during the mdelay() loop on timer_irq_works(). > Interesting, and plausible. My observation so far is a sporadic test failure, often correlating with some raised host OS load. I'm running a high-res kernel, but that cannot prevent that this only 10 ticks long loop of the guest may obtain too few CPU cycles to handle enough of them once in a while (IIRC, it needs 4 out of the 10 ticks to declare the timer routing functional). Maybe Gleb's anti-coalesce patches for the PIC can also deal with your timer resolution conflict. At least worth a try... Jan signature.asc Description: OpenPGP digital signature
Re: 2.6.27.5 guest boot failure using in-kernel PIT
On Friday 21 November 2008 06:05:17 Eduardo Habkost wrote: > On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: > > Hi, > > > > When using a kvm.git kernel as host, I am getting guest boot failures > > when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest > > stops booting at: > > > > ENABLING IO-APIC IRQs > > ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... > > ... failed. > > ...trying to set up timer as Virtual Wire IRQ... > > . failed. > > ...trying to set up timer as ExtINT IRQ... > > I've just found out this problem happens because the guest has HZ=1000 > and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. > > With this setup, the host is not managing to inject enough timer > interrupts during the mdelay() loop on timer_irq_works(). So, do we need to depend on CONFIG_HIGH_RES_TIMERS? I think most modern machine should have this. -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.27.5 guest boot failure using in-kernel PIT
On Thu, Nov 20, 2008 at 12:22:53PM -0200, Eduardo Habkost wrote: > > Hi, > > When using a kvm.git kernel as host, I am getting guest boot failures > when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest > stops booting at: > > ENABLING IO-APIC IRQs > ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... > ... failed. > ...trying to set up timer as Virtual Wire IRQ... > . failed. > ...trying to set up timer as ExtINT IRQ... I've just found out this problem happens because the guest has HZ=1000 and the host had HZ=250 and no CONFIG_HIGH_RES_TIMERS. With this setup, the host is not managing to inject enough timer interrupts during the mdelay() loop on timer_irq_works(). -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.27.5 guest boot failure using in-kernel PIT
Hi, When using a kvm.git kernel as host, I am getting guest boot failures when booting Fedora Rawhide kernel (2.6.27.5-117.fc10.x86_64). Guest stops booting at: ENABLING IO-APIC IRQs ..TIMER: vector=0x30 apic1=0 pin1=0 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 0) ... ... failed. ...trying to set up timer as Virtual Wire IRQ... . failed. ...trying to set up timer as ExtINT IRQ... When using -no-kvm-pit on qemu command-line, the guest boots properly. The guest also boots properly when using 2.6.27.5-117.fc10.x86_64 as the host kernel. Guest dmesg from both cases are attached. Additional info: host kernel: kvm.git commit 30d95f352f0f7da8788016894db3b2a7efdd3674 host qemu: kvm-userspace.git commit 0cf57d569f3204182f768bc135c9dcc1c36a98bc qemu command lines: fails: qemu-system-x86_64 -m 512 -serial stdio -kernel /boot/vmlinuz-2.6.27.5-117.fc10.x86_64 -append 'console=ttyS0,115200 apic=debug' works: qemu-system-x86_64 -m 512 -serial stdio -kernel /boot/vmlinuz-2.6.27.5-117.fc10.x86_64 -append 'console=ttyS0,115200 apic=debug' -no-kvm-pit Some debugging using systemtap indicated that on some point kvm_pic_reset() runs but doesn't ack the timer IRQ for some reason, then kvm_inject_pit_timer_irqs() stops injecting IRQs because irq_ack is cleared. It looks like the bug commit fa7fed6d2dfa9f62c658414ca1a1be0b2cc94438 tried to fix, but somehow kvm_pic_reset() is still failing to ack the timer interrupts on my case. -- Eduardo Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.27.5-117.fc10.x86_64 ([EMAIL PROTECTED]) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Tue Nov 18 11:58:53 EST 2008 Command line: console=ttyS0,115200 apic=debug KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls PAT WC disabled due to known CPU erratum. BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 2000 (ACPI data) BIOS-e820: fffbd000 - 0001 (reserved) last_pfn = 0x1fff0 max_arch_pfn = 0x3 init_memory_mapping last_map_addr: 1fff end: 1fff DMI 2.4 present. ACPI: RSDP 000FBC80, 0014 (r0 QEMU ) ACPI: RSDT 1FFF, 002C (r1 QEMU QEMURSDT1 QEMU1) ACPI: FACP 1FFF002C, 0074 (r1 QEMU QEMUFACP1 QEMU1) ACPI: DSDT 1FFF0100, 24A4 (r1 BXPC BXDSDT1 INTL 20061109) ACPI: FACS 1FFF00C0, 0040 ACPI: APIC 1FFF25A8, 00E0 (r1 QEMU QEMUAPIC1 QEMU1) No NUMA configuration found Faking a node at -1fff Bootmem setup node 0 -1fff NODE_DATA [9000 - 0001dfff] bootmap [0001e000 - 00021fff] pages 4 (5 early reservations) ==> bootmem [00 - 001fff] #0 [00 - 001000] BIOS data page ==> [00 - 001000] #1 [006000 - 008000] TRAMPOLINE ==> [006000 - 008000] #2 [20 - a2b20c]TEXT DATA BSS ==> [20 - a2b20c] #3 [09fc00 - 10]BIOS reserved ==> [09fc00 - 10] #4 [008000 - 009000] PGTABLE ==> [008000 - 009000] Scan SMP from 8800 for 1024 bytes. Scan SMP from 8809fc00 for 1024 bytes. Scan SMP from 880f for 65536 bytes. found SMP MP-table at [880fbb60] 000fbb60 kvm-clock: cpu 0, msr 0:8de481, boot clock Zone PFN ranges: DMA 0x -> 0x1000 DMA320x1000 -> 0x0010 Normal 0x0010 -> 0x0010 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x -> 0x009f 0: 0x0100 -> 0x0001fff0 ACPI: PM-Timer IO Port: 0xb008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 0, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (b
