Bug 2560

Summary:	LAPIC timer loses time if C3 enabled
Product:	ACPI	Reporter:	Shaohua (shaohua.li)
Component:	Power-Processor	Assignee:	Venkatesh Pallipadi (venki)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	acpi-bugzilla, john.stultz, venki, yi.zhu, zwane
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.5	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	patch for the problem proposed patch patch to disable lapic timer updated pach to handle x86-64 as well Patch [1/3] : Remove profiling fine control Patch [2/3] : timer broadcast i386 Patch [3/3] : timer broadcast x86_64 Patch [2/3] : timer broadcast i386 Patch [3/3] : timer broadcast x86_64

Description Shaohua 2004-04-21 19:24:11 UTC

With the processor in C3-state, we miss local APIC timer interrupts. 
I presume the reason is, in C3-state local APIC clock is stopped.
This results in strange situation when I have LAPIC enabled 
(or use SMP kernel), on a system that supports C3 state (T40).
In the above case, HZ will be incremented based on timer interrupts
from PIT. So, that will go at a normal rate (100 per sec). But, the 
LAPIC timer interrupt, which is used for scheduler purposes and process 
time accounting in the kernel, will run at a much lower speed (something 
like 1/2 or 1/4th of HZ). 

How to identify the problem:
Run SMP kernel on T40.
cat /proc/interrupts
Normally number for timer and LOC should be nearly same, but in this 
case we see them widely different.

Comment 1 Shaohua 2004-04-21 19:25:11 UTC

Created attachment 2639 [details]
patch for the problem

proposed patch. it disable C3 state if lapic is enabled.

Comment 2 Len Brown 2004-04-28 21:34:27 UTC

patch doesn't look right, will still disable C3 when lapic disabled via dmi-scan. 
(perhaps the correct thing to do is to fix dmi_scan to act like "nolapic") 
But won't the patch also disable C3 on an HPET timer system?

Comment 3 Shaohua 2004-06-06 21:55:11 UTC

Created attachment 3100 [details]
proposed patch

Ok, Len, how about this one? or did you have any other good idea? Thanks.

Comment 4 Len Brown 2004-11-10 18:30:29 UTC

Unclear that disabling C3 when LAPIC timer is enabled is the solution.

This would be a deal-killer for SMP C3 mode, which we eventually want to 
support.

Comment 5 Venkatesh Pallipadi 2004-11-17 09:55:47 UTC

Instead of just disabling LAPIC or C3, we can probably offset the LAPIC timer 
after C3 wakeup, using PM_TIMER. We already read the PM_timer before and after 
C3 anyway. Only issue can be how well APIC timer_function can handle the lost 
interrupts.

Comment 6 Shaohua 2004-12-20 21:16:44 UTC

Today I did an experiment, which tries to adjust LAPIC timer according to 
PM_Timer. But it can't help. There are still lost interrupts.

Comment 7 Venkatesh Pallipadi 2005-04-07 18:33:35 UTC

Created attachment 4881 [details]
patch to disable lapic timer

comments inside the patch

Comment 8 Venkatesh Pallipadi 2005-04-20 18:58:49 UTC

Created attachment 4960 [details]
updated pach to handle x86-64 as well

Comment 9 James Pattinson 2005-10-19 05:21:51 UTC

Hi Venkatesh

I believe I am seeing this issue, although my timer and LOC interrups aren't
*TOO* out of sync. What do you think?

I am running 2.6.13 on x86_64 but your patch does not apply cleanly to
arch/x86_64/kernel/nmi.c - it all looks a bit different.

Thanks
James

crocodile linux # cat /proc/interrupts 
           CPU0       
  0:     282512    IO-APIC-edge  timer
  1:         10    IO-APIC-edge  i8042
  8:          0    IO-APIC-edge  rtc
 12:        113    IO-APIC-edge  i8042
 15:         25    IO-APIC-edge  ide1
177:          0   IO-APIC-level  acpi
185:       1321   IO-APIC-level  libata
193:          4   IO-APIC-level  libata
201:          2   IO-APIC-level  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
209:       2628   IO-APIC-level  eth0
NMI:         42 
LOC:     282456 
ERR:          0
MIS:          0

crocodile linux # cat /var/log/messages  | grep time

Oct 19 12:58:10 crocodile time.c: Lost 1 timer tick(s)! rip
_spin_unlock_irqrestore+0x5/0x10)
Oct 19 12:58:10 crocodile time.c: Lost 129 timer tick(s)! rip
_spin_unlock_irqrestore+0x5/0x10)
Oct 19 12:58:10 crocodile time.c: Lost 1 timer tick(s)! rip
release_console_sem+0x14d/0x1e0)
Oct 19 12:58:10 crocodile time.c: Lost 2 timer tick(s)! rip msleep+0x4/0x50)
Oct 19 12:58:10 crocodile time.c: Lost 2 timer tick(s)! rip msleep+0x4/0x50)
Oct 19 13:18:13 crocodile time.c: Lost 1 timer tick(s)! rip 0x2aaaaabcc5db)

Comment 10 Venkatesh Pallipadi 2005-10-19 05:39:36 UTC

Do you have C3 state supported on this system. If no, you don't have to worry
about loosing Local APIC timer tick. 

Lost timer tick seems to be a issue though. may ont be related to this issue.
Can you post the complete dmesg.

Comment 11 Dominik Brodowski 2005-11-16 13:31:20 UTC

@James Pattinson: do you have an AMD k8 system? If so, the bug you're seeing
might be related to bug 5303

Comment 12 Venkatesh Pallipadi 2005-12-12 15:42:08 UTC

We have a newer approach at solving this problem here:

http://www.ussg.iu.edu/hypermail/linux/kernel/0512.1/0300.html

Comment 13 Venkatesh Pallipadi 2005-12-12 15:44:05 UTC

Patches in link at comment #12 has some issues with suspend-resume. The 
attached patches below are updated patches (from the ones sent to mailing 
list) that handle suspend-resume and online-offline properly.

Comment 14 Venkatesh Pallipadi 2005-12-12 15:51:20 UTC

Created attachment 6802 [details]
Patch [1/3] : Remove profiling fine control

Comment 15 Venkatesh Pallipadi 2005-12-12 16:03:10 UTC

Created attachment 6803 [details]
Patch [2/3] : timer broadcast i386

Comment 16 Venkatesh Pallipadi 2005-12-12 16:04:28 UTC

Created attachment 6804 [details]
Patch [3/3] : timer broadcast x86_64

Comment 17 Venkatesh Pallipadi 2005-12-13 09:50:24 UTC

Created attachment 6815 [details]
Patch [2/3] : timer broadcast i386

Comment 18 Venkatesh Pallipadi 2005-12-13 09:51:08 UTC

Created attachment 6816 [details]
Patch [3/3] : timer broadcast x86_64

Comment 19 Len Brown 2006-02-15 18:36:42 UTC

Shipped in 2.6.16-rc3
closing