Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote > On Thursday 29 March 2007 23:16, Linus Torvalds wrote: > > > > On Thu, 29 Mar 2007, Andi Kleen wrote: > > > > > > Here's a patch. I don't have a system with C1E, so i only tested that > > > the apic timer still works on a older AMD box. > > > > I think this looks better than what we have now, but it would look even > > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we > > simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. > > > > And then the apic.c code would just check > > > > if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC)) > > return -1; > > > > or similar. > > Ok fair point. Here's an updated patch. I've tested this patch little bit more on my nx6325 and I've found scenario in which my box works slow. When I boot HP with connected AC (it boots fast), and then after boot I unplug AC and try to power HP off it's working very slow (powering off process take few minutes). On battery it's always booting and powering off fast. Can enybody with nx6325 confirm this ? -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote On Thursday 29 March 2007 23:16, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. And then the apic.c code would just check if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC)) return -1; or similar. Ok fair point. Here's an updated patch. I've tested this patch little bit more on my nx6325 and I've found scenario in which my box works slow. When I boot HP with connected AC (it boots fast), and then after boot I unplug AC and try to power HP off it's working very slow (powering off process take few minutes). On battery it's always booting and powering off fast. Can enybody with nx6325 confirm this ? -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote > On Thursday 29 March 2007 23:16, Linus Torvalds wrote: > > > > On Thu, 29 Mar 2007, Andi Kleen wrote: > > > > > > Here's a patch. I don't have a system with C1E, so i only tested that > > > the apic timer still works on a older AMD box. > > > > I think this looks better than what we have now, but it would look even > > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we > > simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. > > > > And then the apic.c code would just check > > > > if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC)) > > return -1; > > > > or similar. > > Ok fair point. Here's an updated patch. This patch also works. If You want bootlog or output of /proc/interrupts I can post it. -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Fri, 30 Mar 2007 00:05:39 +0200, Andi Kleen wrote On Thursday 29 March 2007 23:16, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. And then the apic.c code would just check if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC)) return -1; or similar. Ok fair point. Here's an updated patch. This patch also works. If You want bootlog or output of /proc/interrupts I can post it. -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Thursday 29 March 2007 23:16, Linus Torvalds wrote:
>
> On Thu, 29 Mar 2007, Andi Kleen wrote:
> >
> > Here's a patch. I don't have a system with C1E, so i only tested that
> > the apic timer still works on a older AMD box.
>
> I think this looks better than what we have now, but it would look even
> better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we
> simply had X86_FEATURE_BROKEN_C1_LAPIC etc..
>
> And then the apic.c code would just check
>
> if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC))
> return -1;
>
> or similar.
Ok fair point. Here's an updated patch.
>
> Doing the same for C2 and C3 gives us a clean way to have all these
> per-vendor things in their relevant places, rather than having various
> vendor-specific checks sprinkled in random places..
>
> That's *especially* true for something like this that can hit both on
> x86-64 and i386, where the cpuid logic is shared,
It's not shared.
> but the APIC logic is
> *not* shared. If I read your patch correctly, this only fixes it on 32-bit
> platforms, and I don't think the problem is in any way 32-bit specific, is
> it?
It is because 64bit doesn't have dyntick yet and doesn't try to use the lapic
timer only by default. It has a "apicmaintimer" option, but that is never set
automatically. When dyntick is ported over it will be needed there too.
-Andi
Disable local APIC timer use on AMD systems with C1E
AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper. But not all of these systems report support C2.
Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.
This supercedes an earlier workaround using DMI detection of specific systems.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/i386/kernel/apic.c
===
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -272,32 +272,6 @@ static void __devinit setup_APIC_timer(v
}
/*
- * Detect systems with known broken BIOS implementations
- */
-static int __init lapic_check_broken_bios(struct dmi_system_id *d)
-{
- printk(KERN_NOTICE "%s detected: disabling lapic timer.\n",
- d->ident);
- local_apic_timer_disabled = 1;
- return 0;
-}
-
-static struct dmi_system_id __initdata broken_bios_dmi_table[] = {
- {
- /*
-* BIOS exports only C1 state, but uses deeper power
-* modes behind the kernels back.
-*/
- .callback = lapic_check_broken_bios,
- .ident = "HP nx6325",
- .matches = {
- DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
- },
-},
-{}
-};
-
-/*
* In this functions we calibrate APIC bus clocks to the external timer.
*
* We want to do the calibration only once since we want to have local timer
@@ -372,12 +346,12 @@ void __init setup_boot_APIC_clock(void)
long delta, deltapm;
int pm_referenced = 0;
- /* Detect know broken systems */
- dmi_check_system(broken_bios_dmi_table);
+ if (boot_cpu_has(X86_FEATURE_LAPIC_TIMER_BROKEN))
+ local_apic_timer_disabled = 1;
/*
* The local apic timer can be disabled via the kernel
-* commandline or from the dmi quirk above. Register the lapic
+* commandline or from the test above. Register the lapic
* timer as a dummy clock event source on SMP systems, so the
* broadcast mechanism is used. On UP systems simply ignore it.
*/
Index: linux/include/asm-i386/msr.h
===
--- linux.orig/include/asm-i386/msr.h
+++ linux/include/asm-i386/msr.h
@@ -275,6 +275,8 @@ static inline void wrmsr_on_cpu(unsigned
#define MSR_K7_FID_VID_CTL 0xC0010041
#define MSR_K7_FID_VID_STATUS 0xC0010042
+#define MSR_K8_ENABLE_C1E 0xC0010055
+
/* extended feature register */
#define MSR_EFER 0xc080
Index: linux/arch/i386/kernel/cpu/amd.c
===
--- linux.orig/arch/i386/kernel/cpu/amd.c
+++ linux/arch/i386/kernel/cpu/amd.c
@@ -22,6 +22,37 @@
extern void vide(void);
__asm__(".align 4\nvide: ret");
+#define ENABLE_C1E_MASK 0x1800
+#define CPUID_PROCESSOR_SIGNATURE 1
+#define CPUID_XFAM 0x0ff0
+#define CPUID_XFAM_K8 0x
+#define CPUID_XFAM_10H 0x0010
+#define CPUID_XFAM_11H 0x0020
+#define CPUID_XMOD 0x000f
+#define CPUID_XMOD_REV_F0x0004
+
+/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
+static __cpuinit int amd_apic_timer_broken(void)
+{
+ u32 lo, hi;
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Thursday 29 March 2007 23:45, Andreas Mohr wrote: > Hi, > > On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote: > > > > > > On Thu, 29 Mar 2007, Andi Kleen wrote: > > > > > > Here's a patch. I don't have a system with C1E, so i only tested that > > > the apic timer still works on a older AMD box. > > > > I think this looks better than what we have now, but it would look even > > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we > > simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. > > Please don't, this would break the interface logically. We already have several of those. And negative is much easier. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Thu, 29 Mar 2007, Andreas Mohr wrote: > > Please don't, this would break the interface logically. > X86_FEATURE_xxx usually denotes a *feature*, not a "feature" > (Micro$oft speak for "bug" ;). Sure, we could make it positive instead, and I agree it would make code nicer to read. > Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK? I have no trouble at all with something like that instead. Anybody willing to cook up a patch? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Thu, 29 Mar 2007 23:43:28 +0200, Grzegorz Chwesewicz wrote > On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote > > > Reviewed but not tested. Needs to be wrapped in an AMD specific > > > call. > > > > Here's a patch. I don't have a system with C1E, so i only tested that > > the apic timer still works on a older AMD box. > > > > Would be good if someone with a Turion laptop, especially the HP nx6325 > > could test it with CONFIG_NO_HZ enabled. > > I have nx6325 with Turion. > > ensima-hp linux-2.6 # cat .config|grep NO_HZ > CONFIG_NO_HZ=y > > After patching system works ok on battery and on AC. > Bootlogs on AC and battery can be found here: http://bugzilla.kernel.org/show_bug.cgi?id=8235 -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
Hi, On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote: > > > On Thu, 29 Mar 2007, Andi Kleen wrote: > > > > Here's a patch. I don't have a system with C1E, so i only tested that > > the apic timer still works on a older AMD box. > > I think this looks better than what we have now, but it would look even > better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we > simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. Please don't, this would break the interface logically. X86_FEATURE_xxx usually denotes a *feature*, not a "feature" (Micro$oft speak for "bug" ;). IOW most flags express a positive attribute, not a negative one. An exception to this probably is X86_FEATURE_FXSAVE_LEAK and X86_FEATURE_CMP_LEGACY, but all others seem to be positive, so we might want to enforce this rule. Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK? Or is this less precise from a "C1 working ok" detection point of view? (i.e. we'd just assume by default that most machines are ok except the ones where we have issue detection code for, which might be too fuzzy) Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote > > Reviewed but not tested. Needs to be wrapped in an AMD specific > > call. > > Here's a patch. I don't have a system with C1E, so i only tested that > the apic timer still works on a older AMD box. > > Would be good if someone with a Turion laptop, especially the HP nx6325 > could test it with CONFIG_NO_HZ enabled. I have nx6325 with Turion. ensima-hp linux-2.6 # cat .config|grep NO_HZ CONFIG_NO_HZ=y After patching system works ok on battery and on AC. On battery: cat /proc/interrupts CPU0 CPU1 0: 115771 0 local-APIC-edge-fasteoi timer 1:508 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 4538116 IO-APIC-fasteoi eth0 18: 1697 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 21: 30 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 0 115601 ERR: 1 MIS: 0 sleep 10 CPU0 CPU1 0: 125777 0 local-APIC-edge-fasteoi timer 1:509 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 4749116 IO-APIC-fasteoi eth0 18: 1704 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 21: 30 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 0 125607 ERR: 1 MIS: 0 ### On AC: cat /proc/interrupts CPU0 CPU1 0:261 0 local-APIC-edge-fasteoi timer 1:346 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 1135115 IO-APIC-fasteoi eth0 18: 1620 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ehci_hcd:usb2, ohci_hcd:usb3 21: 24 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 7562 9007 ERR: 0 MIS: 0 sleep 10 CPU0 CPU1 0:261 0 local-APIC-edge-fasteoi timer 1:347 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 1411115 IO-APIC-fasteoi eth0 18: 1627 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ehci_hcd:usb2, ohci_hcd:usb3 21: 24 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 7592 9184 ERR: 0 MIS: 0 -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Thu, 29 Mar 2007, Andi Kleen wrote: > > Here's a patch. I don't have a system with C1E, so i only tested that > the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. And then the apic.c code would just check if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC)) return -1; or similar. Doing the same for C2 and C3 gives us a clean way to have all these per-vendor things in their relevant places, rather than having various vendor-specific checks sprinkled in random places.. That's *especially* true for something like this that can hit both on x86-64 and i386, where the cpuid logic is shared, but the APIC logic is *not* shared. If I read your patch correctly, this only fixes it on 32-bit platforms, and I don't think the problem is in any way 32-bit specific, is it? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
> Reviewed but not tested. Needs to be wrapped in an AMD specific
> call.
Here's a patch. I don't have a system with C1E, so i only tested that
the apic timer still works on a older AMD box.
Would be good if someone with a Turion laptop, especially the HP nx6325
could test it with CONFIG_NO_HZ enabled.
-Andi
Disable local APIC timer use on AMD systems with C1E
AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper. But not all of these systems report support C2.
Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.
This supercedes an earlier workaround using DMI detection of specific systems.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Index: linux/arch/i386/kernel/apic.c
===
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -272,32 +272,6 @@ static void __devinit setup_APIC_timer(v
}
/*
- * Detect systems with known broken BIOS implementations
- */
-static int __init lapic_check_broken_bios(struct dmi_system_id *d)
-{
- printk(KERN_NOTICE "%s detected: disabling lapic timer.\n",
- d->ident);
- local_apic_timer_disabled = 1;
- return 0;
-}
-
-static struct dmi_system_id __initdata broken_bios_dmi_table[] = {
- {
- /*
-* BIOS exports only C1 state, but uses deeper power
-* modes behind the kernels back.
-*/
- .callback = lapic_check_broken_bios,
- .ident = "HP nx6325",
- .matches = {
- DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
- },
-},
-{}
-};
-
-/*
* In this functions we calibrate APIC bus clocks to the external timer.
*
* We want to do the calibration only once since we want to have local timer
@@ -357,6 +331,44 @@ static void __init lapic_cal_handler(str
}
}
+#define ENABLE_C1E_MASK 0x1800
+#define CPUID_PROCESSOR_SIGNATURE 1
+#define CPUID_XFAM 0x0ff0
+#define CPUID_XFAM_K8 0x
+#define CPUID_XFAM_10H 0x0010
+#define CPUID_XFAM_11H 0x0020
+#define CPUID_XMOD 0x000f
+#define CPUID_XMOD_REV_F0x0004
+
+/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
+static __init int amd_apic_timer_broken(void)
+{
+ u32 lo, hi;
+ u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
+ switch (eax & CPUID_XFAM) {
+ case CPUID_XFAM_K8:
+ if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
+ break;
+ case CPUID_XFAM_10H:
+ case CPUID_XFAM_11H:
+ rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
+ if (lo & ENABLE_C1E_MASK)
+ return 1;
+break;
+default:
+/* err on the side of caution */
+ return 1;
+}
+ return 0;
+}
+
+static __init int apic_timer_broken(void)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ return amd_apic_timer_broken();
+ return 0;
+}
+
/*
* Setup the boot APIC
*
@@ -372,12 +384,12 @@ void __init setup_boot_APIC_clock(void)
long delta, deltapm;
int pm_referenced = 0;
- /* Detect know broken systems */
- dmi_check_system(broken_bios_dmi_table);
+ if (apic_timer_broken())
+ local_apic_timer_disabled = 1;
/*
* The local apic timer can be disabled via the kernel
-* commandline or from the dmi quirk above. Register the lapic
+* commandline or from the test above. Register the lapic
* timer as a dummy clock event source on SMP systems, so the
* broadcast mechanism is used. On UP systems simply ignore it.
*/
Index: linux/include/asm-i386/msr.h
===
--- linux.orig/include/asm-i386/msr.h
+++ linux/include/asm-i386/msr.h
@@ -275,6 +275,8 @@ static inline void wrmsr_on_cpu(unsigned
#define MSR_K7_FID_VID_CTL 0xC0010041
#define MSR_K7_FID_VID_STATUS 0xC0010042
+#define MSR_K8_ENABLE_C1E 0xC0010055
+
/* extended feature register */
#define MSR_EFER 0xc080
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
Andi Kleen wrote:
"Langsdorf, Mark" <[EMAIL PROTECTED]> writes:
If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.
Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.
The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the "nolapic_timer" patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
... and that seems to break the local APIC timer.
Yes. The APIC timer still runs, but no longer has an HT link
to send the signal on.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
Just a snippet to detect it would be great. Then the dmi scan
could be removed and replaced with that. This would be a 2.6.21
candidate imho over the DMI hack.
Reviewed but not tested. Needs to be wrapped in an AMD specific
call.
#define ENABLE_C1E_MASK 0x1800
#define CPUID_PROCESSOR_SIGNATURE 1
#define CPUID_XFAM 0x0ff0
#define CPUID_XFAM_K8 0x
#define CPUID_XFAM_10H 0x0010
#define CPUID_XFAM_11H 0x0020
#define CPUID_XMOD 0x000f
#define CPUID_XMOD_REV_F0x0004
int safe_c1 = 1;
u32 eax, lo, hi;
eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE)
switch (eax & CPUID_XFAM) {
case CPUID_XFAM_K8:
if ((eax & CPUID_XMOD) < CPUID_XMOD_REV_F)
break;
case CPUID_XFAM_10H:
case CPUID_XFAM_11H:
rdmsr(MSR_ENABLE_C1E, lo, hi);
if (lo & ENABLE_C1E_MASK)
safe_c1 = 0;
break;
default:
/* err on the side of caution */
safe_c1 = 0;
}
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
"Langsdorf, Mark" <[EMAIL PROTECTED]> writes: > > > If we really care about using the LAPIC timer on systems with deeper > > > than C1 support, the only alternative seems to be to test > > > if it actually works or not at boot and run-time. > > > Otherwise, we wait for future hardware with guaranteed > > > not to break under any (BIOS) conditions ships, and check for that. > > > > > > Based on what I read of the HP nx6325 where the LAPIC timer > > > is breaking C1, AMD is in the same boat. > > > > The nx6325 (Turion 64 X2) exports only C1. > > I'm not sure how the conclusion was drawn that it has > > a broken lapic timer as reflected in the "nolapic_timer" patch: > > If both cores goes into C1 at the same time, the chipset > can move the processor into a C3 like state called C1e. ... and that seems to break the local APIC timer. > AMD can craft a patch to sort this out as soon as we have > an idea what the framework is going to look like. Just a snippet to detect it would be great. Then the dmi scan could be removed and replaced with that. This would be a 2.6.21 candidate imho over the DMI hack. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
> > If we really care about using the LAPIC timer on systems with deeper
> > than C1 support, the only alternative seems to be to test
> > if it actually works or not at boot and run-time.
> > Otherwise, we wait for future hardware with guaranteed
> > not to break under any (BIOS) conditions ships, and check for that.
> >
> > Based on what I read of the HP nx6325 where the LAPIC timer
> > is breaking C1, AMD is in the same boat.
>
> The nx6325 (Turion 64 X2) exports only C1.
> I'm not sure how the conclusion was drawn that it has
> a broken lapic timer as reflected in the "nolapic_timer" patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
> + /*
> +* BIOS exports only C1 state, but uses deeper power
> +* modes behind the kernels back.
> +*/
> + .callback = lapic_check_broken_bios,
> + .ident = "HP nx6325",
> + .matches = {
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP
> Compaq nx6325"),
> + },
> +},
>
> But if this is true, then I don't know how to determine on
> an AMD system if the LAPIC timer is guaranteed to work --
> even for systems with just C1.
>
> Jordan, William, can you clarify?
For K7 and K8 through and including revision E, the LAPIC
timer is guaranteed to work in C1.
For K8 revisions F and G, and for upcoming family 0x10 and
0x11 parts, if either bit in MSRC001_0055[28:27] is set,
C1e is enabled and the LAPIC timer cannot be trusted in
C1.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Tue, 27 Mar 2007, Len Brown wrote: > > > > I think the only fool-proof way to do this automatically is to > > Why not just take the known-good CPUID signature? I didn't think we could reliably distingush mobile cpus with C2+ versus desktop CPUs without it. Or rather you would need a table for each new CPU revision Intel/AMD put out. That would be probably quite nightmarish to maintain. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
Len Brown <[EMAIL PROTECTED]> writes: > On an Intel processor, it seems that the safe and simple route > is if the system exports C2 or deeper, don't use the LAPIC timer. > (which is what 2.6.21-rc5 is doing as of this moment) > We may be able to white-list some systems over time. On AMD it is the same, except that there seems to be at least one system that does C2 like things while only exporting C1. That is why i proposed to check for a battery too -- if there is one always disable it too. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Len Brown [EMAIL PROTECTED] writes: On an Intel processor, it seems that the safe and simple route is if the system exports C2 or deeper, don't use the LAPIC timer. (which is what 2.6.21-rc5 is doing as of this moment) We may be able to white-list some systems over time. On AMD it is the same, except that there seems to be at least one system that does C2 like things while only exporting C1. That is why i proposed to check for a battery too -- if there is one always disable it too. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Linus Torvalds [EMAIL PROTECTED] writes: On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? I didn't think we could reliably distingush mobile cpus with C2+ versus desktop CPUs without it. Or rather you would need a table for each new CPU revision Intel/AMD put out. That would be probably quite nightmarish to maintain. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] i386: add command line option local_apic_timer_c2_ok
If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.
Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.
The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the nolapic_timer patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
+ /*
+* BIOS exports only C1 state, but uses deeper power
+* modes behind the kernels back.
+*/
+ .callback = lapic_check_broken_bios,
+ .ident = HP nx6325,
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, HP
Compaq nx6325),
+ },
+},
But if this is true, then I don't know how to determine on
an AMD system if the LAPIC timer is guaranteed to work --
even for systems with just C1.
Jordan, William, can you clarify?
For K7 and K8 through and including revision E, the LAPIC
timer is guaranteed to work in C1.
For K8 revisions F and G, and for upcoming family 0x10 and
0x11 parts, if either bit in MSRC001_0055[28:27] is set,
C1e is enabled and the LAPIC timer cannot be trusted in
C1.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Langsdorf, Mark [EMAIL PROTECTED] writes: If we really care about using the LAPIC timer on systems with deeper than C1 support, the only alternative seems to be to test if it actually works or not at boot and run-time. Otherwise, we wait for future hardware with guaranteed not to break under any (BIOS) conditions ships, and check for that. Based on what I read of the HP nx6325 where the LAPIC timer is breaking C1, AMD is in the same boat. The nx6325 (Turion 64 X2) exports only C1. I'm not sure how the conclusion was drawn that it has a broken lapic timer as reflected in the nolapic_timer patch: If both cores goes into C1 at the same time, the chipset can move the processor into a C3 like state called C1e. ... and that seems to break the local APIC timer. AMD can craft a patch to sort this out as soon as we have an idea what the framework is going to look like. Just a snippet to detect it would be great. Then the dmi scan could be removed and replaced with that. This would be a 2.6.21 candidate imho over the DMI hack. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Andi Kleen wrote:
Langsdorf, Mark [EMAIL PROTECTED] writes:
If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.
Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.
The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the nolapic_timer patch:
If both cores goes into C1 at the same time, the chipset
can move the processor into a C3 like state called C1e.
... and that seems to break the local APIC timer.
Yes. The APIC timer still runs, but no longer has an HT link
to send the signal on.
AMD can craft a patch to sort this out as soon as we have
an idea what the framework is going to look like.
Just a snippet to detect it would be great. Then the dmi scan
could be removed and replaced with that. This would be a 2.6.21
candidate imho over the DMI hack.
Reviewed but not tested. Needs to be wrapped in an AMD specific
call.
#define ENABLE_C1E_MASK 0x1800
#define CPUID_PROCESSOR_SIGNATURE 1
#define CPUID_XFAM 0x0ff0
#define CPUID_XFAM_K8 0x
#define CPUID_XFAM_10H 0x0010
#define CPUID_XFAM_11H 0x0020
#define CPUID_XMOD 0x000f
#define CPUID_XMOD_REV_F0x0004
int safe_c1 = 1;
u32 eax, lo, hi;
eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE)
switch (eax CPUID_XFAM) {
case CPUID_XFAM_K8:
if ((eax CPUID_XMOD) CPUID_XMOD_REV_F)
break;
case CPUID_XFAM_10H:
case CPUID_XFAM_11H:
rdmsr(MSR_ENABLE_C1E, lo, hi);
if (lo ENABLE_C1E_MASK)
safe_c1 = 0;
break;
default:
/* err on the side of caution */
safe_c1 = 0;
}
-Mark Langsdorf
Operating Systems Research Center
AMD, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Reviewed but not tested. Needs to be wrapped in an AMD specific
call.
Here's a patch. I don't have a system with C1E, so i only tested that
the apic timer still works on a older AMD box.
Would be good if someone with a Turion laptop, especially the HP nx6325
could test it with CONFIG_NO_HZ enabled.
-Andi
Disable local APIC timer use on AMD systems with C1E
AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper. But not all of these systems report support C2.
Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.
This supercedes an earlier workaround using DMI detection of specific systems.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/arch/i386/kernel/apic.c
===
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -272,32 +272,6 @@ static void __devinit setup_APIC_timer(v
}
/*
- * Detect systems with known broken BIOS implementations
- */
-static int __init lapic_check_broken_bios(struct dmi_system_id *d)
-{
- printk(KERN_NOTICE %s detected: disabling lapic timer.\n,
- d-ident);
- local_apic_timer_disabled = 1;
- return 0;
-}
-
-static struct dmi_system_id __initdata broken_bios_dmi_table[] = {
- {
- /*
-* BIOS exports only C1 state, but uses deeper power
-* modes behind the kernels back.
-*/
- .callback = lapic_check_broken_bios,
- .ident = HP nx6325,
- .matches = {
- DMI_MATCH(DMI_PRODUCT_NAME, HP Compaq nx6325),
- },
-},
-{}
-};
-
-/*
* In this functions we calibrate APIC bus clocks to the external timer.
*
* We want to do the calibration only once since we want to have local timer
@@ -357,6 +331,44 @@ static void __init lapic_cal_handler(str
}
}
+#define ENABLE_C1E_MASK 0x1800
+#define CPUID_PROCESSOR_SIGNATURE 1
+#define CPUID_XFAM 0x0ff0
+#define CPUID_XFAM_K8 0x
+#define CPUID_XFAM_10H 0x0010
+#define CPUID_XFAM_11H 0x0020
+#define CPUID_XMOD 0x000f
+#define CPUID_XMOD_REV_F0x0004
+
+/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
+static __init int amd_apic_timer_broken(void)
+{
+ u32 lo, hi;
+ u32 eax = cpuid_eax(CPUID_PROCESSOR_SIGNATURE);
+ switch (eax CPUID_XFAM) {
+ case CPUID_XFAM_K8:
+ if ((eax CPUID_XMOD) CPUID_XMOD_REV_F)
+ break;
+ case CPUID_XFAM_10H:
+ case CPUID_XFAM_11H:
+ rdmsr(MSR_K8_ENABLE_C1E, lo, hi);
+ if (lo ENABLE_C1E_MASK)
+ return 1;
+break;
+default:
+/* err on the side of caution */
+ return 1;
+}
+ return 0;
+}
+
+static __init int apic_timer_broken(void)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ return amd_apic_timer_broken();
+ return 0;
+}
+
/*
* Setup the boot APIC
*
@@ -372,12 +384,12 @@ void __init setup_boot_APIC_clock(void)
long delta, deltapm;
int pm_referenced = 0;
- /* Detect know broken systems */
- dmi_check_system(broken_bios_dmi_table);
+ if (apic_timer_broken())
+ local_apic_timer_disabled = 1;
/*
* The local apic timer can be disabled via the kernel
-* commandline or from the dmi quirk above. Register the lapic
+* commandline or from the test above. Register the lapic
* timer as a dummy clock event source on SMP systems, so the
* broadcast mechanism is used. On UP systems simply ignore it.
*/
Index: linux/include/asm-i386/msr.h
===
--- linux.orig/include/asm-i386/msr.h
+++ linux/include/asm-i386/msr.h
@@ -275,6 +275,8 @@ static inline void wrmsr_on_cpu(unsigned
#define MSR_K7_FID_VID_CTL 0xC0010041
#define MSR_K7_FID_VID_STATUS 0xC0010042
+#define MSR_K8_ENABLE_C1E 0xC0010055
+
/* extended feature register */
#define MSR_EFER 0xc080
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. And then the apic.c code would just check if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC)) return -1; or similar. Doing the same for C2 and C3 gives us a clean way to have all these per-vendor things in their relevant places, rather than having various vendor-specific checks sprinkled in random places.. That's *especially* true for something like this that can hit both on x86-64 and i386, where the cpuid logic is shared, but the APIC logic is *not* shared. If I read your patch correctly, this only fixes it on 32-bit platforms, and I don't think the problem is in any way 32-bit specific, is it? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote Reviewed but not tested. Needs to be wrapped in an AMD specific call. Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. Would be good if someone with a Turion laptop, especially the HP nx6325 could test it with CONFIG_NO_HZ enabled. I have nx6325 with Turion. ensima-hp linux-2.6 # cat .config|grep NO_HZ CONFIG_NO_HZ=y After patching system works ok on battery and on AC. On battery: cat /proc/interrupts CPU0 CPU1 0: 115771 0 local-APIC-edge-fasteoi timer 1:508 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 4538116 IO-APIC-fasteoi eth0 18: 1697 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 21: 30 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 0 115601 ERR: 1 MIS: 0 sleep 10 CPU0 CPU1 0: 125777 0 local-APIC-edge-fasteoi timer 1:509 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 4749116 IO-APIC-fasteoi eth0 18: 1704 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 21: 30 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 0 125607 ERR: 1 MIS: 0 ### On AC: cat /proc/interrupts CPU0 CPU1 0:261 0 local-APIC-edge-fasteoi timer 1:346 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 1135115 IO-APIC-fasteoi eth0 18: 1620 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ehci_hcd:usb2, ohci_hcd:usb3 21: 24 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 7562 9007 ERR: 0 MIS: 0 sleep 10 CPU0 CPU1 0:261 0 local-APIC-edge-fasteoi timer 1:347 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12:147 2 IO-APIC-edge i8042 14: 36 1 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 1411115 IO-APIC-fasteoi eth0 18: 1627 6 IO-APIC-fasteoi libata, HDA Intel 19: 50 1 IO-APIC-fasteoi ohci_hcd:usb1, ehci_hcd:usb2, ohci_hcd:usb3 21: 24 9 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 7592 9184 ERR: 0 MIS: 0 -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Hi, On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. Please don't, this would break the interface logically. X86_FEATURE_xxx usually denotes a *feature*, not a feature (Micro$oft speak for bug ;). IOW most flags express a positive attribute, not a negative one. An exception to this probably is X86_FEATURE_FXSAVE_LEAK and X86_FEATURE_CMP_LEGACY, but all others seem to be positive, so we might want to enforce this rule. Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK? Or is this less precise from a C1 working ok detection point of view? (i.e. we'd just assume by default that most machines are ok except the ones where we have issue detection code for, which might be too fuzzy) Andreas Mohr - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Thu, 29 Mar 2007 23:43:28 +0200, Grzegorz Chwesewicz wrote On Thu, 29 Mar 2007 22:49:37 +0200, Andi Kleen wrote Reviewed but not tested. Needs to be wrapped in an AMD specific call. Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. Would be good if someone with a Turion laptop, especially the HP nx6325 could test it with CONFIG_NO_HZ enabled. I have nx6325 with Turion. ensima-hp linux-2.6 # cat .config|grep NO_HZ CONFIG_NO_HZ=y After patching system works ok on battery and on AC. cut Bootlogs on AC and battery can be found here: http://bugzilla.kernel.org/show_bug.cgi?id=8235 -- Greetings - CeHo - Grzegorz Chwesewicz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Thu, 29 Mar 2007, Andreas Mohr wrote: Please don't, this would break the interface logically. X86_FEATURE_xxx usually denotes a *feature*, not a feature (Micro$oft speak for bug ;). Sure, we could make it positive instead, and I agree it would make code nicer to read. Thus, how about e.g. X86_FEATURE_LAPIC_C1_OK? I have no trouble at all with something like that instead. Anybody willing to cook up a patch? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Thursday 29 March 2007 23:45, Andreas Mohr wrote: Hi, On Thu, Mar 29, 2007 at 02:16:54PM -0700, Linus Torvalds wrote: On Thu, 29 Mar 2007, Andi Kleen wrote: Here's a patch. I don't have a system with C1E, so i only tested that the apic timer still works on a older AMD box. I think this looks better than what we have now, but it would look even better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we simply had X86_FEATURE_BROKEN_C1_LAPIC etc.. Please don't, this would break the interface logically. We already have several of those. And negative is much easier. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Thursday 29 March 2007 23:16, Linus Torvalds wrote:
On Thu, 29 Mar 2007, Andi Kleen wrote:
Here's a patch. I don't have a system with C1E, so i only tested that
the apic timer still works on a older AMD box.
I think this looks better than what we have now, but it would look even
better if the core CPUID stuff was in arch/i386/kernel/cpu/amd.c, and we
simply had X86_FEATURE_BROKEN_C1_LAPIC etc..
And then the apic.c code would just check
if (boot_cpu_has(X86_FEATURE_BROKEN_C1_LAPIC))
return -1;
or similar.
Ok fair point. Here's an updated patch.
Doing the same for C2 and C3 gives us a clean way to have all these
per-vendor things in their relevant places, rather than having various
vendor-specific checks sprinkled in random places..
That's *especially* true for something like this that can hit both on
x86-64 and i386, where the cpuid logic is shared,
It's not shared.
but the APIC logic is
*not* shared. If I read your patch correctly, this only fixes it on 32-bit
platforms, and I don't think the problem is in any way 32-bit specific, is
it?
It is because 64bit doesn't have dyntick yet and doesn't try to use the lapic
timer only by default. It has a apicmaintimer option, but that is never set
automatically. When dyntick is ported over it will be needed there too.
-Andi
Disable local APIC timer use on AMD systems with C1E
AMD dual core laptops with C1E do not run the APIC timer correctly
when they go idle. Previously the code assumed this only happened
on C2 or deeper. But not all of these systems report support C2.
Use a AMD supplied snippet to detect C1E being enabled and then disable
local apic timer use.
This supercedes an earlier workaround using DMI detection of specific systems.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/arch/i386/kernel/apic.c
===
--- linux.orig/arch/i386/kernel/apic.c
+++ linux/arch/i386/kernel/apic.c
@@ -272,32 +272,6 @@ static void __devinit setup_APIC_timer(v
}
/*
- * Detect systems with known broken BIOS implementations
- */
-static int __init lapic_check_broken_bios(struct dmi_system_id *d)
-{
- printk(KERN_NOTICE %s detected: disabling lapic timer.\n,
- d-ident);
- local_apic_timer_disabled = 1;
- return 0;
-}
-
-static struct dmi_system_id __initdata broken_bios_dmi_table[] = {
- {
- /*
-* BIOS exports only C1 state, but uses deeper power
-* modes behind the kernels back.
-*/
- .callback = lapic_check_broken_bios,
- .ident = HP nx6325,
- .matches = {
- DMI_MATCH(DMI_PRODUCT_NAME, HP Compaq nx6325),
- },
-},
-{}
-};
-
-/*
* In this functions we calibrate APIC bus clocks to the external timer.
*
* We want to do the calibration only once since we want to have local timer
@@ -372,12 +346,12 @@ void __init setup_boot_APIC_clock(void)
long delta, deltapm;
int pm_referenced = 0;
- /* Detect know broken systems */
- dmi_check_system(broken_bios_dmi_table);
+ if (boot_cpu_has(X86_FEATURE_LAPIC_TIMER_BROKEN))
+ local_apic_timer_disabled = 1;
/*
* The local apic timer can be disabled via the kernel
-* commandline or from the dmi quirk above. Register the lapic
+* commandline or from the test above. Register the lapic
* timer as a dummy clock event source on SMP systems, so the
* broadcast mechanism is used. On UP systems simply ignore it.
*/
Index: linux/include/asm-i386/msr.h
===
--- linux.orig/include/asm-i386/msr.h
+++ linux/include/asm-i386/msr.h
@@ -275,6 +275,8 @@ static inline void wrmsr_on_cpu(unsigned
#define MSR_K7_FID_VID_CTL 0xC0010041
#define MSR_K7_FID_VID_STATUS 0xC0010042
+#define MSR_K8_ENABLE_C1E 0xC0010055
+
/* extended feature register */
#define MSR_EFER 0xc080
Index: linux/arch/i386/kernel/cpu/amd.c
===
--- linux.orig/arch/i386/kernel/cpu/amd.c
+++ linux/arch/i386/kernel/cpu/amd.c
@@ -22,6 +22,37 @@
extern void vide(void);
__asm__(.align 4\nvide: ret);
+#define ENABLE_C1E_MASK 0x1800
+#define CPUID_PROCESSOR_SIGNATURE 1
+#define CPUID_XFAM 0x0ff0
+#define CPUID_XFAM_K8 0x
+#define CPUID_XFAM_10H 0x0010
+#define CPUID_XFAM_11H 0x0020
+#define CPUID_XMOD 0x000f
+#define CPUID_XMOD_REV_F0x0004
+
+/* AMD systems with C1E don't have a working lAPIC timer. Check for that. */
+static __cpuinit int amd_apic_timer_broken(void)
+{
+ u32 lo, hi;
+ u32 eax =
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Tuesday 27 March 2007 18:16, Len Brown wrote:
> On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
> >
> > On Tue, 27 Mar 2007, Len Brown wrote:
> > >
> > > I think the only fool-proof way to do this automatically is to
> >
> > Why not just take the known-good CPUID signature?
> >
> > Screw firmware or ACPI tables. They're going to be occasionally wrong.
> >
> > If we know that "Core 2, version X" has a good local APIC timer, we use
> > it. Otherwise we don't.
> >
> > That's generally how we handle other APIC bugs too (the read-after-write
> > thing, for example, or the differences between integrated and off-chip
> > APIC's). Sometimes we check the APIC version itself, sometimes we check
> > the CPUID information, and sometimes we check both ("modern_apic()").
>
> Yep, this is what we tried to do last week.
> It failed, and the patch was reverted.
>
> I agree, the BIOS vendor can lie with ACPI tables.
> In particular, they can map any hardware C-state
> to any ACPI C-state. Our expectation that they
> would not map hardware C3 to ACPI C2
> appears at this point to have been invalid.
>
> So, speaking for Intel parts, every single one that supports
> HW C3 from the beginning of history through today has a broken
> LAPIC timer. (and a few listed in that patch are known to
> be broken in HW C2) If we can't guarantee that the BIOS vendor
> will not map that broken HW C3 to ACPI C2 (or even C1 via SMM)
> then we have to not use the LAPIC timer except for systems with
> a "known-good" signature = "part supports only C1".
On an Intel processor, it seems that the safe and simple route
is if the system exports C2 or deeper, don't use the LAPIC timer.
(which is what 2.6.21-rc5 is doing as of this moment)
We may be able to white-list some systems over time.
> If we really care about using the LAPIC timer on systems with deeper
> than C1 support, the only alternative seems to be to test
> if it actually works or not at boot and run-time.
> Otherwise, we wait for future hardware with guaranteed
> not to break under any (BIOS) conditions ships, and check for that.
>
> Based on what I read of the HP nx6325 where the LAPIC timer
> is breaking C1, AMD is in the same boat.
The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the "nolapic_timer" patch:
+ /*
+* BIOS exports only C1 state, but uses deeper power
+* modes behind the kernels back.
+*/
+ .callback = lapic_check_broken_bios,
+ .ident = "HP nx6325",
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"),
+ },
+},
But if this is true, then I don't know how to determine on
an AMD system if the LAPIC timer is guaranteed to work --
even for systems with just C1.
Jordan, William,
can you clarify?
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
>
> On Tue, 27 Mar 2007, Len Brown wrote:
> >
> > I think the only fool-proof way to do this automatically is to
>
> Why not just take the known-good CPUID signature?
>
> Screw firmware or ACPI tables. They're going to be occasionally wrong.
>
> If we know that "Core 2, version X" has a good local APIC timer, we use
> it. Otherwise we don't.
>
> That's generally how we handle other APIC bugs too (the read-after-write
> thing, for example, or the differences between integrated and off-chip
> APIC's). Sometimes we check the APIC version itself, sometimes we check
> the CPUID information, and sometimes we check both ("modern_apic()").
Yep, this is what we tried to do last week.
It failed, and the patch was reverted.
I agree, the BIOS vendor can lie with ACPI tables.
In particular, they can map any hardware C-state
to any ACPI C-state. Our expectation that they
would not map hardware C3 to ACPI C2
appears at this point to have been invalid.
So, speaking for Intel parts, every single one that supports
HW C3 from the beginning of history through today has a broken
LAPIC timer. (and a few listed in that patch are known to
be broken in HW C2) If we can't guarantee that the BIOS vendor
will not map that broken HW C3 to ACPI C2 (or even C1 via SMM)
then we have to not use the LAPIC timer except for systems with
a "known-good" signature = "part supports only C1".
If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.
Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Tue, 27 Mar 2007, Len Brown wrote:
>
> I think the only fool-proof way to do this automatically is to
Why not just take the known-good CPUID signature?
Screw firmware or ACPI tables. They're going to be occasionally wrong.
If we know that "Core 2, version X" has a good local APIC timer, we use
it. Otherwise we don't.
That's generally how we handle other APIC bugs too (the read-after-write
thing, for example, or the differences between integrated and off-chip
APIC's). Sometimes we check the APIC version itself, sometimes we check
the CPUID information, and sometimes we check both ("modern_apic()").
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Monday 26 March 2007 09:52, Thomas Gleixner wrote: > On Mon, 2007-03-26 at 12:31 +, Pavel Machek wrote: > > > + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in > > > + C2 power state. > > > + > I still twist my brain how to autodetect that in a safe way, which would > make it really useful for the firmware tester. I think the only fool-proof way to do this automatically is to 1. do a boot-time calibration vs HPET, RTC, or 8254 to make sure it starts sane. ideally, this boot time test would enter the deepest available C-state -- as that would catch 99% of the failures. 2. do a _continuous_ sanity check against the same time to make sure it never gets off track. It has to be continuous because we apparently have no control over when the BIOS breaks it on some systems. However, continuous really means "long term" here, because over the uptime of the system we'd probably notice the drift between different timers etc, so we'd have to reset the sanity check periodically to not get fooled by that. If this worked, then we could delete the new DMI entry for the nx6325, as that would get detected and disable the lapic timer use automatically. We could also delete the check for C2 and the check for C3 to disable the lapic timer. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Monday 26 March 2007 09:52, Thomas Gleixner wrote: On Mon, 2007-03-26 at 12:31 +, Pavel Machek wrote: + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in + C2 power state. + I still twist my brain how to autodetect that in a safe way, which would make it really useful for the firmware tester. I think the only fool-proof way to do this automatically is to 1. do a boot-time calibration vs HPET, RTC, or 8254 to make sure it starts sane. ideally, this boot time test would enter the deepest available C-state -- as that would catch 99% of the failures. 2. do a _continuous_ sanity check against the same time to make sure it never gets off track. It has to be continuous because we apparently have no control over when the BIOS breaks it on some systems. However, continuous really means long term here, because over the uptime of the system we'd probably notice the drift between different timers etc, so we'd have to reset the sanity check periodically to not get fooled by that. If this worked, then we could delete the new DMI entry for the nx6325, as that would get detected and disable the lapic timer use automatically. We could also delete the check for C2 and the check for C3 to disable the lapic timer. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? Screw firmware or ACPI tables. They're going to be occasionally wrong. If we know that Core 2, version X has a good local APIC timer, we use it. Otherwise we don't. That's generally how we handle other APIC bugs too (the read-after-write thing, for example, or the differences between integrated and off-chip APIC's). Sometimes we check the APIC version itself, sometimes we check the CPUID information, and sometimes we check both (modern_apic()). Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Tuesday 27 March 2007 17:34, Linus Torvalds wrote: On Tue, 27 Mar 2007, Len Brown wrote: I think the only fool-proof way to do this automatically is to Why not just take the known-good CPUID signature? Screw firmware or ACPI tables. They're going to be occasionally wrong. If we know that Core 2, version X has a good local APIC timer, we use it. Otherwise we don't. That's generally how we handle other APIC bugs too (the read-after-write thing, for example, or the differences between integrated and off-chip APIC's). Sometimes we check the APIC version itself, sometimes we check the CPUID information, and sometimes we check both (modern_apic()). Yep, this is what we tried to do last week. It failed, and the patch was reverted. I agree, the BIOS vendor can lie with ACPI tables. In particular, they can map any hardware C-state to any ACPI C-state. Our expectation that they would not map hardware C3 to ACPI C2 appears at this point to have been invalid. So, speaking for Intel parts, every single one that supports HW C3 from the beginning of history through today has a broken LAPIC timer. (and a few listed in that patch are known to be broken in HW C2) If we can't guarantee that the BIOS vendor will not map that broken HW C3 to ACPI C2 (or even C1 via SMM) then we have to not use the LAPIC timer except for systems with a known-good signature = part supports only C1. If we really care about using the LAPIC timer on systems with deeper than C1 support, the only alternative seems to be to test if it actually works or not at boot and run-time. Otherwise, we wait for future hardware with guaranteed not to break under any (BIOS) conditions ships, and check for that. Based on what I read of the HP nx6325 where the LAPIC timer is breaking C1, AMD is in the same boat. -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Tuesday 27 March 2007 18:16, Len Brown wrote:
On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
On Tue, 27 Mar 2007, Len Brown wrote:
I think the only fool-proof way to do this automatically is to
Why not just take the known-good CPUID signature?
Screw firmware or ACPI tables. They're going to be occasionally wrong.
If we know that Core 2, version X has a good local APIC timer, we use
it. Otherwise we don't.
That's generally how we handle other APIC bugs too (the read-after-write
thing, for example, or the differences between integrated and off-chip
APIC's). Sometimes we check the APIC version itself, sometimes we check
the CPUID information, and sometimes we check both (modern_apic()).
Yep, this is what we tried to do last week.
It failed, and the patch was reverted.
I agree, the BIOS vendor can lie with ACPI tables.
In particular, they can map any hardware C-state
to any ACPI C-state. Our expectation that they
would not map hardware C3 to ACPI C2
appears at this point to have been invalid.
So, speaking for Intel parts, every single one that supports
HW C3 from the beginning of history through today has a broken
LAPIC timer. (and a few listed in that patch are known to
be broken in HW C2) If we can't guarantee that the BIOS vendor
will not map that broken HW C3 to ACPI C2 (or even C1 via SMM)
then we have to not use the LAPIC timer except for systems with
a known-good signature = part supports only C1.
On an Intel processor, it seems that the safe and simple route
is if the system exports C2 or deeper, don't use the LAPIC timer.
(which is what 2.6.21-rc5 is doing as of this moment)
We may be able to white-list some systems over time.
If we really care about using the LAPIC timer on systems with deeper
than C1 support, the only alternative seems to be to test
if it actually works or not at boot and run-time.
Otherwise, we wait for future hardware with guaranteed
not to break under any (BIOS) conditions ships, and check for that.
Based on what I read of the HP nx6325 where the LAPIC timer
is breaking C1, AMD is in the same boat.
The nx6325 (Turion 64 X2) exports only C1.
I'm not sure how the conclusion was drawn that it has
a broken lapic timer as reflected in the nolapic_timer patch:
+ /*
+* BIOS exports only C1 state, but uses deeper power
+* modes behind the kernels back.
+*/
+ .callback = lapic_check_broken_bios,
+ .ident = HP nx6325,
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_NAME, HP Compaq nx6325),
+ },
+},
But if this is true, then I don't know how to determine on
an AMD system if the LAPIC timer is guaranteed to work --
even for systems with just C1.
Jordan, William,
can you clarify?
thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
On Mon, 2007-03-26 at 12:31 +, Pavel Machek wrote: > > + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in > > + C2 power state. > > + > > Could you add comment saying that this is always ok on non-broken > systems? That way perhaps it can be added to linux-firmware-test-cd, > etc. Yep, post .21. I still twist my brain how to autodetect that in a safe way, which would make it really useful for the firmware tester. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option "local_apic_timer_c2_ok"
Hi! > It turned out that it is almost impossible to trust ACPI, BIOS & Co. > regarding the C states. This was the reason to switch the local apic > timer off in C2 state already. OTOH there are sane and well behaving > systems, which get punished by that decision. > > Allow the user to confirm that the local apic timer is trustworthy in C2 > state. This keeps the default behaviour on the safe side. ... > @@ -780,6 +780,9 @@ and is between 256 and 4096 characters. It is defined in > the file > lapic [IA-32,APIC] Enable the local APIC even if BIOS > disabled it. > > + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in > + C2 power state. > + Could you add comment saying that this is always ok on non-broken systems? That way perhaps it can be added to linux-firmware-test-cd, etc. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
Hi! It turned out that it is almost impossible to trust ACPI, BIOS Co. regarding the C states. This was the reason to switch the local apic timer off in C2 state already. OTOH there are sane and well behaving systems, which get punished by that decision. Allow the user to confirm that the local apic timer is trustworthy in C2 state. This keeps the default behaviour on the safe side. ... @@ -780,6 +780,9 @@ and is between 256 and 4096 characters. It is defined in the file lapic [IA-32,APIC] Enable the local APIC even if BIOS disabled it. + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in + C2 power state. + Could you add comment saying that this is always ok on non-broken systems? That way perhaps it can be added to linux-firmware-test-cd, etc. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: add command line option local_apic_timer_c2_ok
On Mon, 2007-03-26 at 12:31 +, Pavel Machek wrote: + lapic_timer_c2_ok [IA-32,APIC] trust the local apic timer in + C2 power state. + Could you add comment saying that this is always ok on non-broken systems? That way perhaps it can be added to linux-firmware-test-cd, etc. Yep, post .21. I still twist my brain how to autodetect that in a safe way, which would make it really useful for the firmware tester. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
