I have a X86_64 laptop (Compaq Presario R3240) with all BIOS updates in place. I routinely get the "Warning : many lost ticks" message in dmesg.
I booted with report_lost_ticks after seeing the source of arch/x86_86/kernel/time.c:handle_lost_ticks and it reported that rip was at acpi_ec_read most of the times.
Why is this warning caused and what's the effect? In handle_lost_ticks, it does not seem to compensate for the lost ticks..
Parry.
dmesg with report_lost_ticks=1
========================================================
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
ip_tables: (C) 2000-2002 Netfilter core team
ip_tables: (C) 2000-2002 Netfilter core team
eth0: link up, 10Mbps, half-duplex, lpa 0x0000
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
i2c /dev entries driver
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 3 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
eth0: no IPv6 routers present
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
input: PS/2 Generic Mouse on isa0060/serio4
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 2 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 2 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 2 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 4 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 4 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 4 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 2 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 2 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 2 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip __do_softirq+0x41/0xa2
time.c: Lost 1 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 5 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 2 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 4 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
time.c: Lost 5 timer tick(s)! rip acpi_ec_read+0xce/0xed)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x41/0xa2)
It might help if I provided the kernel version :)
I have tested with stock kernel 2.6.9 and Fedora Core 3 kernel - problem happens with both of them. Here is the CPU info, and /proc/interrupts -
/proc/cpuinfo
=============
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 4
model name : AMD Athlon(tm) 64 Processor 3200+
stepping : 8
cpu MHz : 797.954
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips : 1581.05
TLB size : 1088 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
/proc/interrupts
============================
CPU0
0: 2073747 XT-PIC timer
1: 5602 XT-PIC i8042
2: 0 XT-PIC cascade
8: 0 XT-PIC rtc
9: 2791 XT-PIC acpi
10: 9921 XT-PIC NVidia nForce3 Modem, ehci_hcd, ohci_hcd, yenta, eth0
11: 129885 XT-PIC NVidia nForce3, ohci_hcd, yenta, ohci1394, nvidia
12: 53655 XT-PIC i8042
14: 24671 XT-PIC ide0
15: 18174 XT-PIC ide1
NMI: 485
LOC: 2069605
ERR: 1
MIS: 0
On Thu, Nov 18, 2004 at 04:02:55AM +0000, [email protected] wrote:
> I have a X86_64 laptop (Compaq Presario R3240) with all BIOS updates in place. I routinely get the "Warning : many lost ticks" message in dmesg.
Known problem. ACPI uses a broken way to access the EC register,
and VIA chipsets take extremly long for this operation. This
happens regularly to read the system temperature.
A fix is currently being discussed.
-Andi
On Thu, 18 Nov 2004, Andi Kleen wrote:
> On Thu, Nov 18, 2004 at 04:02:55AM +0000, [email protected] wrote:
> > I have a X86_64 laptop (Compaq Presario R3240) with all BIOS updates in place. I routinely get the "Warning : many lost ticks" message in dmesg.
>
> Known problem. ACPI uses a broken way to access the EC register,
> and VIA chipsets take extremly long for this operation. This
> happens regularly to read the system temperature.
> A fix is currently being discussed.
It's an nforce3, do those also have a similar issue? I have similar
hardware and rarely see it, could you test a newer kernel?
I tried all the newer kernels including -ac. All have the same problem.
Andi - On a side note, your change "NVidia ACPI timer override" present in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a unusual power management setup?") and DMA timeouts - happens regularly.
Parry.
> On Thu, 18 Nov 2004, Andi Kleen wrote:
>
> > On Thu, Nov 18, 2004 at 04:02:55AM +0000, [email protected] wrote:
> > > I have a X86_64 laptop (Compaq Presario R3240) with all BIOS updates in
> place. I routinely get the "Warning : many lost ticks" message in dmesg.
> >
> > Known problem. ACPI uses a broken way to access the EC register,
> > and VIA chipsets take extremly long for this operation. This
> > happens regularly to read the system temperature.
> > A fix is currently being discussed.
>
> It's an nforce3, do those also have a similar issue? I have similar
> hardware and rarely see it, could you test a newer kernel?
I will send it shorltly - Till then another update - I disabled ACPI Thermal stuff and the Lost ticks due to acpi_ec_read got cured. (This was without Andi's NVIDIA Timer override patch.)
Parry.
> On Thu, 18 Nov 2004 [email protected] wrote:
>
> > I tried all the newer kernels including -ac. All have the same problem.
> >
> > Andi - On a side note, your change "NVidia ACPI timer override" present
> > in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a
> > unusual power management setup?") and DMA timeouts - happens regularly.
>
> Interesting, could you send your dmesg, from booting with the 'debug'
> kernel parameter. Also the output from dmidecode and lspci would be nice.
>
> Thanks,
> Zwane
>
On Iau, 2004-11-18 at 17:02, [email protected] wrote:
> I tried all the newer kernels including -ac. All have the same problem.
>
> Andi - On a side note, your change "NVidia ACPI timer override" present in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a unusual power management setup?") and DMA timeouts - happens regularly.
Ok ACPI timer override probably goes back into the broken bucket and out
of -ac in -ac11 then.
On Thu, 18 Nov 2004, Alan Cox wrote:
> On Iau, 2004-11-18 at 17:02, [email protected] wrote:
> > I tried all the newer kernels including -ac. All have the same
> > problem.
> >
> > Andi - On a side note, your change "NVidia ACPI timer override"
> > present in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do
> > you have a unusual power management setup?") and DMA timeouts -
> > happens regularly.
>
> Ok ACPI timer override probably goes back into the broken bucket and out
> of -ac in -ac11 then.
I think it's more a broken system, booting with noapic (as is what
happened before) should get things back to normal. Parry, have you updated
the BIOS on your laptop?
Thanks,
Zwane
On Thu, Nov 18, 2004 at 05:02:37PM +0000, [email protected] wrote:
> I tried all the newer kernels including -ac. All have the same problem.
>
> Andi - On a side note, your change "NVidia ACPI timer override" present in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a unusual power management setup?") and DMA timeouts - happens regularly.
Hmm, I was told Timer overrides are always bogus on Nvidia and
that it was the last remaining known apic bug.
But perhaps there are other APIC bugs in there.
Can you submit a full boot.msg of the problem?
-Andi
Andi, Zwane
I will send in the following by evening -
1) dmidecode output
2) normal dmesg output (No Timer override, with ACPI with thermal stuff) - This gives me many lost ticks
3) dmesg output with NV Timer override with apic - This gives me NMI errors and IDE DMA timeouts
4) dmesg output with NV Timer override with noapic - Not tried yet
5) lspci output
Let me know if anything else is needed.
Thanks!
Parry
> On Thu, Nov 18, 2004 at 05:02:37PM +0000, [email protected] wrote:
> > I tried all the newer kernels including -ac. All have the same problem.
> >
> > Andi - On a side note, your change "NVidia ACPI timer override" present in
> 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a unusual
> power management setup?") and DMA timeouts - happens regularly.
>
> Hmm, I was told Timer overrides are always bogus on Nvidia and
> that it was the last remaining known apic bug.
> But perhaps there are other APIC bugs in there.
>
> Can you submit a full boot.msg of the problem?
>
> -Andi
On Thu, Nov 18, 2004 at 05:10:17PM +0000, Alan Cox wrote:
> On Iau, 2004-11-18 at 17:02, [email protected] wrote:
> > I tried all the newer kernels including -ac. All have the same problem.
> >
> > Andi - On a side note, your change "NVidia ACPI timer override" present in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a unusual power management setup?") and DMA timeouts - happens regularly.
>
> Ok ACPI timer override probably goes back into the broken bucket and out
> of -ac in -ac11 then.
The timer override should be fine (I have confirmation from Nvidia
about this). The only thing that you can take out if you're conservative
is the change to not disable the IOAPIC by default when Nvidia
is detected (in check_ioapic())
-Andi
I haven't tried Andi's patch with noapic yet. Will do that to see if it fixes the NMI and DMA timeouts.
And I have the latest available BIOS update applied.
May be related - once in 10 reboots (approx.) I get the K8 Errata #93 missing warning even with the updated BIOS - it's not consistent.
> On Thu, 18 Nov 2004, Alan Cox wrote:
>
> > On Iau, 2004-11-18 at 17:02, [email protected] wrote:
> > > I tried all the newer kernels including -ac. All have the same
> > > problem.
> > >
> > > Andi - On a side note, your change "NVidia ACPI timer override"
> > > present in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do
> > > you have a unusual power management setup?") and DMA timeouts -
> > > happens regularly.
> >
> > Ok ACPI timer override probably goes back into the broken bucket and out
> > of -ac in -ac11 then.
>
> I think it's more a broken system, booting with noapic (as is what
> happened before) should get things back to normal. Parry, have you updated
> the BIOS on your laptop?
>
> Thanks,
> Zwane
>
Andi / Zwane
Ignore my earlier mail about the DMA timeouts and NMI errors after applying
the ACPI timer override patch. My bad. I forgot to recompile the modules
after I applied your patch - and I believe thats what caused those errors.
I recompiled and reinstalled the modules this time and no errors [well, apart
from those lost ticks, which anyway is a separate issue] with the ACPI Timer
override for NVIDIA chipset.
Alan - Needless to say you should keep Andi's NVIDIA ACPI Timer override patch
in -ac. It works.
Sorry for the confusion!
Parry
On Thursday 18 November 2004 13:49, Andi Kleen wrote:
> On Thu, Nov 18, 2004 at 05:02:37PM +0000, [email protected] wrote:
> > I tried all the newer kernels including -ac. All have the same problem.
> >
> > Andi - On a side note, your change "NVidia ACPI timer override" present
> > in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a
> > unusual power management setup?") and DMA timeouts - happens regularly.
>
> Hmm, I was told Timer overrides are always bogus on Nvidia and
> that it was the last remaining known apic bug.
> But perhaps there are other APIC bugs in there.
>
> Can you submit a full boot.msg of the problem?
>
> -Andi
On Thu, 18 Nov 2004 [email protected] wrote:
> I tried all the newer kernels including -ac. All have the same problem.
>
> Andi - On a side note, your change "NVidia ACPI timer override" present
> in 2.6.9-ac8 breaks on my laptop - I get some NMI errors ("Do you have a
> unusual power management setup?") and DMA timeouts - happens regularly.
Interesting, could you send your dmesg, from booting with the 'debug'
kernel parameter. Also the output from dmidecode and lspci would be nice.
Thanks,
Zwane
On Thu, 18 Nov 2004 at 19:50:32 +0100, Andi Kleen wrote:
> On Thu, Nov 18, 2004 at 05:10:17PM +0000, Alan Cox wrote:
>
> > Ok ACPI timer override probably goes back into the broken bucket and out
> > of -ac in -ac11 then.
>
> The timer override should be fine (I have confirmation from Nvidia
> about this). The only thing that you can take out if you're conservative
> is the change to not disable the IOAPIC by default when Nvidia
> is detected (in check_ioapic())
I did that long ago; the below patch is dated Oct 28 on my fileserver.
Alan could save himself some work if we shared patches... I already
backported even more of the networking stuff to 2.6.9 than he did.
# ioapic_on_nvidia_boards.patch
#
# Originally suggested by Zwane Mwaikumbo
#
# Ignore all ACPI timer overrides on all Nvidia boards. The fallback doesn't
# work and no Nvidia boards needs a timer override. But some buggy BIOS have
# it anyways.
#
# Thanks to Andy Currid for confirming this.
#
# Original patch enabled the IO-APIC.
# Enable of IO-APIC removed by Chuck Ebbert <[email protected]>
#
# Signed-off-by: Andi Kleen <[email protected]>
# Signed-off-by: Andrew Morton <[email protected]>
# Signed-off-by: Chuck Ebbert <[email protected]>
#
--- 2.6.9/arch/x86_64/kernel/io_apic.c
+++ 2.6.9.1/arch/x86_64/kernel/io_apic.c
@@ -271,6 +271,14 @@ void __init check_ioapic(void)
num,slot,vendor);
skip_ioapic_setup = 1;
#endif
+#ifdef CONFIG_ACPI
+ /* All timer overrides on Nvidia
+ seem to be wrong. Skip them. */
+ printk(KERN_INFO
+ "Nvidia board detected. Ignoring ACPI timer override.\n");
+ acpi_skip_timer_override = 1;
+ /* RED-PEN skip them on mptables too? */
+#endif
return;
}
--- 2.6.9/include/asm-x86_64/acpi.h
+++ 2.6.9.1/include/asm-x86_64/acpi.h
@@ -166,6 +166,8 @@ extern int acpi_pci_disabled;
extern u8 x86_acpiid_to_apicid[];
+extern int acpi_skip_timer_override;
+
#endif /*__KERNEL__*/
#endif /*_ASM_ACPI_H*/
--Chuck Ebbert 19-Nov-04 03:19:18
On Thu, 18 Nov 2004, kernel-stuff wrote:
> Ignore my earlier mail about the DMA timeouts and NMI errors after applying
> the ACPI timer override patch. My bad. I forgot to recompile the modules
> after I applied your patch - and I believe thats what caused those errors.
> I recompiled and reinstalled the modules this time and no errors [well, apart
> from those lost ticks, which anyway is a separate issue] with the ACPI Timer
> override for NVIDIA chipset.
>
> Alan - Needless to say you should keep Andi's NVIDIA ACPI Timer override patch
> in -ac. It works.
>
> Sorry for the confusion!
Thanks for confirming that Parry, so your system definitely is using the
IOAPIC now (/proc/interrupts output should suffice)?
Zwane
On Fri, 19 Nov 2004, Chuck Ebbert wrote:
> On Thu, 18 Nov 2004 at 19:50:32 +0100, Andi Kleen wrote:
>
> > On Thu, Nov 18, 2004 at 05:10:17PM +0000, Alan Cox wrote:
> >
> > > Ok ACPI timer override probably goes back into the broken bucket and out
> > > of -ac in -ac11 then.
> >
> > The timer override should be fine (I have confirmation from Nvidia
> > about this). The only thing that you can take out if you're conservative
> > is the change to not disable the IOAPIC by default when Nvidia
> > is detected (in check_ioapic())
>
>
> I did that long ago; the below patch is dated Oct 28 on my fileserver.
>
> Alan could save himself some work if we shared patches... I already
> backported even more of the networking stuff to 2.6.9 than he did.
The thing is, without the IOAPIC enable it's essentially a no operation
since i8259 mode wouldn't use the pin information.
On Friday 19 November 2004 10:57, Zwane Mwaikambo wrote:
> Thanks for confirming that Parry, so your system definitely is using the
> IOAPIC now (/proc/interrupts output should suffice)?
>
Yes it does seem so. Here goes /proc/interrupts
CPU0
0: 138237 IO-APIC-edge timer
1: 77 IO-APIC-edge i8042
8: 0 IO-APIC-edge rtc
9: 198 IO-APIC-level acpi
12: 1427 IO-APIC-edge i8042
14: 11445 IO-APIC-edge ide0
15: 193 IO-APIC-edge ide1
177: 0 IO-APIC-level ehci_hcd
185: 382 IO-APIC-level NVidia nForce3, ohci_hcd
193: 0 IO-APIC-level NVidia nForce3 Modem, ohci_hcd
201: 4 IO-APIC-level yenta, ohci1394
209: 289 IO-APIC-level yenta, eth0
225: 7247 IO-APIC-level nvidia
NMI: 59
LOC: 138123
ERR: 0
MIS: 0
On Gwe, 2004-11-19 at 01:56, kernel-stuff wrote:
> Alan - Needless to say you should keep Andi's NVIDIA ACPI Timer override patch
> in -ac. It works.
Thanks for chasing it down
Zwane Mwaikambo wrote:
> The thing is, without the IOAPIC enable it's essentially a no operation
> since i8259 mode wouldn't use the pin information.
...until the user force-enables the IOAPIC. Then the timer pin
overrides will be ignored as they should be.
My goal was to fix bugs without altering default behavior, so anyone with
broken IOAPIC mode would not suddenly see problems unless they changed a
startup parameter.
--Chuck Ebbert 20-Nov-04 23:58:19