aboutsummaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorRobin Holt <holt@sgi.com>2007-08-10 16:00:43 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-08-11 18:47:39 -0400
commitb291aa7a6564e859af144e1bd14ffa463519b198 (patch)
treeeefc4a01e77e4903b45137337196de9bbae354c8 /arch
parentd31c5ab147e0b17b9ec0daa5e4d1fc0bd6b19974 (diff)
x86_64: fix HPET init race
I have had four seperate system lockups attributable to this exact problem in two days of testing. Instead of trying to handle all the weird end cases and wrap, how about changing it to look for exactly what we appear to want. The following patch removes a couple races in setup_APIC_timer. One occurs when the HPET advances the COUNTER past the T0_CMP value between the time the T0_CMP was originally read and when COUNTER is read. This results in a delay waiting for the counter to wrap. The other results from the counter wrapping. This change takes a snapshot of T0_CMP at the beginning of the loop and simply loops until T0_CMP has changed (a tick has happened). <later> I have one small concern about the patch. I am not sure it meets the intent as well as it should. I think we are trying to match APIC timer interrupts up with the hpet counter increment. The event which appears to be disturbing this loop in our test environment is the NMI watchdog. What we believe has been happening with the existing code is the setup_APIC_timer loop has read the CMP value, and the NMI watchdog code fires for the first time. This results in a series of icache miss slowdowns and by the time we get back to things it has wrapped. I think this code is trying to get the CMP as close to the counter value as possible. If that is the intent, maybe we should really be testing against a "window" around the CMP. Something like COUNTER = CMP+/2. It appears COUNTER should get advanced every 89nSec (IIRC). The above seems like an unreasonably small window, but may be necessary. Without documentation, I am not sure of the original intent with this code. In summary, this code fixes my boot hangs, but since I am not certain of the intent of the existing code, I am not certain this has not introduced new bugs or unexpected behaviors. Signed-off-by: Robin Holt <holt@sgi.com> Acked-by: Andi Kleen <ak@suse.de> Cc: Vojtech Pavlik <vojtech@suse.cz> Cc: "Aaron Durbin" <adurbin@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch')
-rw-r--r--arch/x86_64/kernel/apic.c6
1 files changed, 2 insertions, 4 deletions
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 900ff38d68de..925758dbca0c 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -791,10 +791,8 @@ static void setup_APIC_timer(unsigned int clocks)
791 791
792 /* wait for irq slice */ 792 /* wait for irq slice */
793 if (hpet_address && hpet_use_timer) { 793 if (hpet_address && hpet_use_timer) {
794 int trigger = hpet_readl(HPET_T0_CMP); 794 u32 trigger = hpet_readl(HPET_T0_CMP);
795 while (hpet_readl(HPET_COUNTER) >= trigger) 795 while (hpet_readl(HPET_T0_CMP) == trigger)
796 /* do nothing */ ;
797 while (hpet_readl(HPET_COUNTER) < trigger)
798 /* do nothing */ ; 796 /* do nothing */ ;
799 } else { 797 } else {
800 int c1, c2; 798 int c1, c2;