x86: set Pentium M as PAE capable

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

Quoted 7 lines · Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

1. This patch doesn't match the discussion in the link.
2. You would have to also enable this in the cpu testing code in arch/x86/boot.
3. At the very least we need to print a serious warning that the CPU is being run outside its specifications. I have no personal information about why this CPUID bit was disabled, but it could be that it was discovered in testing that it didn't work correctly in all circumstances (e.g. high temperature.) This is very much "use at your own risk..."; you could get data corruption or even hardware damage.

We should probably also taint the kernel.

Quoted 7 lines · Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

1. This patch doesn't match the discussion in the link.
2. You would have to also enable this in the cpu testing code in

    arch/x86/boot.

3. At the very least we need to print a serious warning that the CPU is being run outside its specifications. I have no personal information about why this CPUID bit was disabled, but it could be that it was discovered in testing that it didn't work correctly in all circumstances (e.g. high temperature.) This is very much "use at your own risk..."; you could get data corruption or even hardware damage.

We should probably also taint the kernel.

Quoted 7 lines · Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

1. This patch doesn't match the discussion in the link.
2. You would have to also enable this in the cpu testing code in

    arch/x86/boot.

3. At the very least we need to print a serious warning that the CPU is being run outside its specifications. I have no personal information about why this CPUID bit was disabled, but it could be that it was discovered in testing that it didn't work correctly in all circumstances (e.g. high temperature.) This is very much "use at your own risk..."; you could get data corruption or even hardware damage.

Quoted 7 lines · Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

1. This patch doesn't match the discussion in the link.
2. You would have to also enable this in the cpu testing code in

    arch/x86/boot.

3. At the very least we need to print a serious warning that the CPU is being run outside its specifications. I have no personal information about why this CPUID bit was disabled, but it could be that it was discovered in testing that it didn't work correctly in all circumstances (e.g. high temperature.) This is very much "use at your own risk..."; you could get data corruption or even hardware damage.

Quoted 11 lines · H. Peter Anvin

Quoted 7 lines · Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

1. This patch doesn't match the discussion in the link.
2. You would have to also enable this in the cpu testing code in

Quoted 8 lines

    arch/x86/boot.

3. At the very least we need to print a serious warning that the CPU is being run outside its specifications. I have no personal information about why this CPUID bit was disabled, but it could be that it was discovered in testing that it didn't work correctly in all circumstances (e.g. high temperature.) This is very much "use at your own risk..."; you could get data corruption or even hardware damage.

About six years ago, we almost went down this same path for Fedora, and I'm fairly sure the only reason we backed off and decided to not pursue it was that we found some Pentium M's where it just didn't work.

Quoted 21 lines · Dave Jones

Quoted 11 lines · H. Peter Anvin

Quoted 7 lines · Chris Bainbridge

Pentium M is PAE capable but does not indicate so in the CPUID response. This is an issue now that some distributions are no longer shipping non-PAE kernels (those distributions no longer boot on Pentium M). This small patch fixes the issue by forcing the PAE capability on Pentium M.

For more discussion see https://bugs.launchpad.net/baltix/+bug/930447

1. This patch doesn't match the discussion in the link.
2. You would have to also enable this in the cpu testing code in

Quoted 8 lines

    arch/x86/boot.

3. At the very least we need to print a serious warning that the CPU is being run outside its specifications. I have no personal information about why this CPUID bit was disabled, but it could be that it was discovered in testing that it didn't work correctly in all circumstances (e.g. high temperature.) This is very much "use at your own risk..."; you could get data corruption or even hardware damage.

Quoted 4 lines

About six years ago, we almost went down this same path for Fedora, and I'm fairly sure the only reason we backed off and decided to not pursue it was that we found some Pentium M's where it just didn't work.

OK, that *definitely* means that if we're doing this at all we're doing it via an explicit opt-in on the command line, and tainting the kernel in the process.

I don't know if anyone (Chris?) is interested enough in the problem to do such a patch, though. I know I'm not too interested in spending a bunch of time on.

-hpa

The basic findings of the bug discussion is that people are successfully running PAE kernels on Pentium M (for some unknown reason Grub skips the validate_cpu code in the kernel, so existing PAE kernels will run unmodified, although they do fail when booted with syslinux), and people are using a user-space hack to add "pae" to /proc/cpuinfo.

Quoted 5 lines · Chris Bainbridge

The basic findings of the bug discussion is that people are successfully running PAE kernels on Pentium M (for some unknown reason Grub skips the validate_cpu code in the kernel, so existing PAE kernels will run unmodified, although they do fail when booted with syslinux), and people are using a user-space hack to add "pae" to /proc/cpuinfo.

grub is jumping to the 32-bit entry point and skipping the entire real mode setup code. Bad grub.

Quoted 3 lines · Chris Bainbridge

arch/x86/kernel/cpu/intel.c +0 -0

@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 

arch/x86/kernel/cpu/intel.c static void intel_workarounds(struct cpuinfo_x86 *c) · line 242

Quoted 7 lines

arch/x86/kernel/cpu/intel.c +6 -0

 	/*
+	 * PAE CPUID bug: Pentium M reports no PAE but has PAE
+	 */
+	if (forcepae) {
+		printk(KERN_WARNING "PAE forced!\n");
+		set_cpu_cap(c, X86_FEATURE_PAE);
+		add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);

This is certainly the wrong taint flag. We'd need a new one or to repurpose another one as I suggested in a previous mail.

Right, I was about to say that. And since there's no special bit for running "out-of-spec", we could probably repurpose

TAINT_UNSAFE_SMP - 'S' - SMP with CPUs not designed for SMP.

to

TAINT_UNSAFE_OUT_OF_SPEC (the letter S fits still) and add that taint everytime we're enforcing functionality against doctor's orders, so to speak.

Quoted 3 lines · Chris Bainbridge

(quoted diff) +0 -0

@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 

Review static void intel_workarounds(struct cpuinfo_x86 *c) · line 242

Quoted 7 lines

(quoted diff) +6 -0

 	/*
+	 * PAE CPUID bug: Pentium M reports no PAE but has PAE
+	 */
+	if (forcepae) {
+		printk(KERN_WARNING "PAE forced!\n");
+		set_cpu_cap(c, X86_FEATURE_PAE);
+		add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);

This is certainly the wrong taint flag. We'd need a new one or to repurpose another one as I suggested in a previous mail.

Yes. Grub can be made to behave sanely by using "linux16" and "initrd16", but of course none of the distros do it that way.

I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean "out of Spec". We currently only use that flag on some ancient athlon xp, so there's not going to be any kind of collision.

Quoted 3 lines · Dave Jones

I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean "out of Spec". We currently only use that flag on some ancient athlon xp, so there's not going to be any kind of collision.

Hahaa, I said that yesterday already:

http://lkml.kernel.org/r/[email protected]

Then it's definitely a good idea :-)

Quoted 2 lines · H. Peter Anvin

Yes. Grub can be made to behave sanely by using "linux16" and "initrd16", but of course none of the distros do it that way.

Fedora does as of F20, but yeah, point taken.

Quoted 4 lines · Borislav Petkov

Quoted 3 lines · Chris Bainbridge

(quoted diff) +0 -0

@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 

Quoted 10 lines

Review static void intel_workarounds(struct cpuinfo_x86 *c) · line 242

Quoted 7 lines

(quoted diff) +6 -0

 	/*
+	 * PAE CPUID bug: Pentium M reports no PAE but has PAE
+	 */
+	if (forcepae) {
+		printk(KERN_WARNING "PAE forced!\n");
+		set_cpu_cap(c, X86_FEATURE_PAE);
+		add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);

This is certainly the wrong taint flag. We'd need a new one or to repurpose another one as I suggested in a previous mail.

I'd suggest repurposing 'S'. Instead of 'unsafe smp', it could mean "out of Spec". We currently only use that flag on some ancient athlon xp, so there's not going to be any kind of collision.

Start with the below maybe ?

Dave

Hello people,

Note that revisions of the Dothan core were released in the first quarter of 2005 with the *Sonoma* chipsets and supported a 533 MT/s FSB and NX-bit (and PAE support required for it was enabled, unlike earlier Pentium Ms that had it disabled). These processors include the 730M (1.6 GHz), 740M (1.73 GHz), 750M (1.86 GHz), 760M (2.0 GHz) and 770M (2.13 GHz). These models all have a TDP of 27 W and a 2 MB L2 cache.

These CPUs should have PAE enabled. Only earlier versions of the Pentium M ( Older Dothans and the Banias core) do not have PAE support, officially.

-Dennis.

(BTW, would it be possible to transform Linux's PAE support into boot-config or even fully runtime-detectable boot switching to (non-)PAE, similar to or exceeding what XP offers with its static boot-time flag?
Last time I checked PAE support config defines were spread over ~ 40 kernel source files though :-((()

(BTW, would it be possible to transform Linux's PAE support into boot-config or even fully runtime-detectable boot switching to (non-)PAE, similar to or exceeding what XP offers with its static boot-time flag?
Last time I checked PAE support config defines were spread over ~ 40 kernel source files though :-((()

It would be a considerable amount of work to make it a runtime thing. Ten years ago, maybe it would be worth the effort perhaps, but I'd suggest just letting 32-bit slowly die instead of doing dramatic overhauls that will no doubt introduce a bunch of regressions in code that's been notoriously awful to debug issues in during the past.

Quoted 5 lines · Dave Jones

It would be a considerable amount of work to make it a runtime thing. Ten years ago, maybe it would be worth the effort perhaps, but I'd suggest just letting 32-bit slowly die instead of doing dramatic overhauls that will no doubt introduce a bunch of regressions in code that's been notoriously awful to debug issues in during the past.

Amen!

Quoted 6 lines · Andreas Mohr

(BTW, would it be possible to transform Linux's PAE support into boot-config or even fully runtime-detectable boot switching to (non-)PAE, similar to or exceeding what XP offers with its static boot-time flag?
Last time I checked PAE support config defines were spread over ~ 40 kernel source files though :-((()

It would be a considerable amount of work to make it a runtime thing. Ten years ago, maybe it would be worth the effort perhaps, but I'd suggest just letting 32-bit slowly die instead of doing dramatic overhauls that will no doubt introduce a bunch of regressions in code that's been notoriously awful to debug issues in during the past.

Dave

Quoted 7 lines · Matthew Garrett

Quoted 2 lines · H. Peter Anvin

Yes. Grub can be made to behave sanely by using "linux16" and "initrd16", but of course none of the distros do it that way.

Fedora does as of F20, but yeah, point taken.

Oh, good to hear.

Hi,

Review

Quoted 3 lines

(quoted diff) +2 -0

 	/*
+	 * PAE CPUID bug: Pentium M reports no PAE but has PAE
+	 */

Ain't that a tad strongly/incorrectly worded?

i would recommend adding the newly introduced param to Documentation/kernel-
parameters.txt , though.

We routinely expect 2 to 3 u-s jitters on an Atom board running a 32 bit, RTAI enhanced build of what is by now a 5 year old kernel. This is extremely board sensitive, and that same kernel running on this 4 core phenom, cannot stay inside of 40 u-s. A case of more horsepower not being a good deal at all.

Quoted 3 lines · Roland Kletzing

i would recommend adding the newly introduced param to Documentation/kernel-
parameters.txt , though.

Done.

Signed-off-by Chris Bainbridge <[email protected]>

---

Documentation/kernel-parameters.txt +0 -0

index b9e9bd8..388b5e9 100644

Documentation/kernel-parameters.txt +2 -0

+			problems, and will taint the kernel.
+
 	ftrace=[tracer]
 			[FTRACE] will set and start the specified tracer
 			as early as possible in order to facilitate early

arch/x86/boot/cpucheck.c +7 -0

index 4d3ff03..93ba160 100644
@@ -69,6 +69,13 @@ static int is_transmeta(void)
 	       cpu_vendor[2] == A32('M', 'x', '8', '6');
 }
 
+static int is_intel(void)
+{
+	return cpu_vendor[0] == A32('G', 'e', 'n', 'u') &&
+	       cpu_vendor[1] == A32('i', 'n', 'e', 'I') &&
+	       cpu_vendor[2] == A32('n', 't', 'e', 'l');
+}
+
 static int has_fpu(void)
 {
 	u16 fcw = -1, fsw = -1;

@@ -239,6 +246,24 @@ int check_cpu(int *cpu_level_ptr, int *req_level_ptr, u32 **err_flags_ptr)
 		asm("wrmsr" : : "a" (eax), "d" (edx), "c" (ecx));
 

arch/x86/boot/cpucheck.c +1 -0

+		}
 	}
 
 	if (err_flags_ptr)

arch/x86/kernel/cpu/intel.c +0 -0

index bbe1b8b..271686d 100644

arch/x86/kernel/cpu/intel.c +1 -0

+
 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
 	unsigned long lo, hi;

@@ -226,6 +234,17 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);

Quoted 17 lines · Chris Bainbridge

Quoted 3 lines · Roland Kletzing

i would recommend adding the newly introduced param to Documentation/kernel-
parameters.txt , though.

Done.

Signed-off-by Chris Bainbridge <[email protected]>

---

Documentation/kernel-parameters.txt +0 -0

index b9e9bd8..388b5e9 100644
@@ -962,6 +962,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			parameter will force ia64_sal_cache_flush to call
 			ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
 

Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can also be entirely omitted. · line 969

Quoted 5 lines

Documentation/kernel-parameters.txt +5 -0

+	forcepae [X86-32]
+			Forcefully enable Physical Address Extension (PAE).
+			Many Pentium M systems disable PAE but may have a
+			functionally usable PAE implementation.
+			Note: This parameter is unsupported, may cause unknown

What does "unsupported" mean here exactly?

This function is called check_cpuflags() now. You probably want to redo your patch against tip/master, i.e.:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git#master

Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can also be entirely omitted.

Quoted 8 lines

Documentation/kernel-parameters.txt +8 -0

+		}
+		else {
+			puts("ERROR: PAE is disabled on this Pentium M\n"
+				"(PAE can potentially be enabled with "
+				"kernel parameter\n"
+				"\"forcepae\" - this is unsupported, may "
+				"cause unknown\n"
+				"problems, and will taint the kernel)\n");

This string could definitely violate the 80 cols rule so that it is much more readable:

		}
		else
			puts("WARNING: PAE disabled. Use \"forcepae\" to enable at your own risk!\n");

I've shortened it to the most relevant info only. No need to say we're tainting the kernel because LOCKDEP_NOW_UNRELIABLE will cause that anyway below.

Quoted 8 lines

arch/x86/kernel/cpu/intel.c +0 -0

index bbe1b8b..271686d 100644
@@ -196,6 +196,14 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
 	}
 }
 

arch/x86/kernel/cpu/intel.c static void intel_smp_check(struct cpuinfo_x86 *c) · line 205

Quoted 7 lines

arch/x86/kernel/cpu/intel.c +7 -0

+static int forcepae;
+static int __init forcepae_setup(char *__unused)
+{
+	forcepae = 1;
+	return 1;
+}
+__setup("forcepae", forcepae_setup);

Yeah, why not simply call it "pae"? It is smaller and the letter combination is not used yet and it means the same.

Quoted 6 lines

arch/x86/kernel/cpu/intel.c +0 -0

 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
 	unsigned long lo, hi;

@@ -226,6 +234,17 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 

arch/x86/kernel/cpu/intel.c static void intel_workarounds(struct cpuinfo_x86 *c) · line 244

Quoted 9 lines

arch/x86/kernel/cpu/intel.c +8 -0

 	/*
+	 * PAE CPUID issue: many Pentium M report no PAE but may have a
+	 * functionally usable PAE implementation.
+	 * Forcefully enable PAE if kernel parameter "forcepae" is present.
+	 */
+	if (forcepae) {
+		printk(KERN_WARNING "PAE forced!\n");
+		set_cpu_cap(c, X86_FEATURE_PAE);
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);

Right, this implies Dave's patch is preceding yours. I guess hpa can fish it out from the thread when applying.

Quoted 11 lines · Borislav Petkov

Review

Quoted 10 lines · Chris Bainbridge

Quoted 3 lines · Roland Kletzing

i would recommend adding the newly introduced param to Documentation/kernel-
parameters.txt , though.

Done.

Signed-off-by Chris Bainbridge <[email protected]>

---

(quoted diff) +0 -0

b/Documentation/kernel-parameters.txt

Quoted 4 lines

Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can

Quoted 4 lines

index b9e9bd8..388b5e9 100644

Documentation/kernel-parameters.txt +0 -0

@@ -962,6 +962,13 @@ bytes respectively. Such letter suffixes can

also be entirely omitted.

Quoted 10 lines

Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can also be entirely omitted.

Quoted 8 lines

Documentation/kernel-parameters.txt +5 -0

 			parameter will force ia64_sal_cache_flush to call
 			ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
 
+	forcepae [X86-32]
+			Forcefully enable Physical Address Extension (PAE).
+			Many Pentium M systems disable PAE but may have a
+			functionally usable PAE implementation.
+			Note: This parameter is unsupported, may cause unknown

What does "unsupported" mean here exactly?

It was supposed to have the dual meaning that neither the kernel developers or Intel are going to help you if it doesn't work. But perhaps it is unnecessary - being tainted implies that the kernel developers won't help, and Intel certainly won't be interested.

Quoted 2 lines

This function is called check_cpuflags() now. You probably want to

redo

Quoted 4 lines

your patch against tip/master, i.e.:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git#master

Done, new patch is against tip.

Quoted 10 lines

Documentation/kernel-parameters.txt bytes respectively. Such letter suffixes can

Quoted 8 lines

Documentation/kernel-parameters.txt +8 -0

+		}
+		else {
+			puts("ERROR: PAE is disabled on this Pentium M\n"
+				"(PAE can potentially be enabled with "
+				"kernel parameter\n"
+				"\"forcepae\" - this is unsupported, may "
+				"cause unknown\n"
+				"problems, and will taint the kernel)\n");

This string could definitely violate the 80 cols rule so that it is

much

Quoted 5 lines

more readable:

		}
		else
			puts("WARNING: PAE disabled. Use \"forcepae\" to enable at your

own risk!\n");

Quoted 2 lines

I've shortened it to the most relevant info only. No need to say

we're

Quoted 2 lines

tainting the kernel because LOCKDEP_NOW_UNRELIABLE will cause that anyway below.

Ok I changed it to: "WARNING: PAE disabled. Use parameter 'pae' to enable at your own risk!\n""

Quoted 1 line

Review

Quoted 1 line

(quoted diff) +0 -0

b/arch/x86/kernel/cpu/intel.c

Quoted 4 lines

arch/x86/kernel/cpu/intel.c static void intel_smp_check(struct cpuinfo_x86

Quoted 4 lines

index bbe1b8b..271686d 100644

arch/x86/kernel/cpu/intel.c +0 -0

@@ -196,6 +196,14 @@ static void intel_smp_check(struct cpuinfo_x86

*c)

Quoted 13 lines

arch/x86/kernel/cpu/intel.c static void intel_smp_check(struct cpuinfo_x86 *c)

Quoted 10 lines

arch/x86/kernel/cpu/intel.c +7 -0

 	}
 }
 
+static int forcepae;
+static int __init forcepae_setup(char *__unused)
+{
+	forcepae = 1;
+	return 1;
+}
+__setup("forcepae", forcepae_setup);

Yeah, why not simply call it "pae"? It is smaller and the letter combination is not used yet and it means the same.

I don't see any reason not to just use "pae" "forcepae" is perhaps a bit
more descriptive but the other text in the patch clearly describes the parameter so it doesn't really matter.

Quoted 4 lines

arch/x86/kernel/cpu/intel.c static void intel_workarounds(struct

Quoted 4 lines

arch/x86/kernel/cpu/intel.c +0 -0

 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
 	unsigned long lo, hi;

@@ -226,6 +234,17 @@ static void intel_workarounds(struct

cpuinfo_x86 *c)

Quoted 6 lines

arch/x86/kernel/cpu/intel.c static void intel_workarounds(struct cpuinfo_x86 *c)

Quoted 6 lines

arch/x86/kernel/cpu/intel.c +3 -0

 		clear_cpu_cap(c, X86_FEATURE_SEP);
 
 	/*
+	 * PAE CPUID issue: many Pentium M report no PAE but may have a
+	 * functionally usable PAE implementation.
+	 * Forcefully enable PAE if kernel parameter "forcepae" is

present.

Quoted 8 lines

arch/x86/kernel/cpu/intel.c static void intel_workarounds(struct cpuinfo_x86 *c) · line 243

Quoted 5 lines

arch/x86/kernel/cpu/intel.c +5 -0

+	 */
+	if (forcepae) {
+		printk(KERN_WARNING "PAE forced!\n");
+		set_cpu_cap(c, X86_FEATURE_PAE);
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);

Right, this implies Dave's patch is preceding yours. I guess hpa can fish it out from the thread when applying.

I will include Dave's patch, it is trivial.

New patch with all above changes follows.

Signed-off-by Chris Bainbridge <[email protected]>

---

Documentation/kernel-parameters.txt +0 -0

index 580a60c..7d57a5a 100644
@@ -2307,6 +2307,13 @@ bytes respectively. Such letter suffixes can

also be entirely omitted.

	OSS		[HW,OSS]
			See Documentation/sound/oss/oss-parameters.txt

Documentation/kernel-parameters.txt +7 -0

+	pae [X86-32]
+			Forcefully enable Physical Address Extension (PAE).
+			Many Pentium M systems disable PAE but may have a
+			functionally usable PAE implementation.
+			Warning: use of this parameter will taint the kernel
+			and may cause unknown problems.
+

panic= [KNL] Kernel behaviour on panic: delay <timeout>
timeout > 0: seconds before rebooting timeout = 0: wait forever

arch/x86/boot/cpucheck.c +20 -0

index 100a9a1..740d2d1 100644
@@ -67,6 +67,13 @@ static int is_transmeta(void)
 	       cpu_vendor[2] == A32('M', 'x', '8', '6');
 }
 
+static int is_intel(void)
+{
+	return cpu_vendor[0] == A32('G', 'e', 'n', 'u') &&
+	       cpu_vendor[1] == A32('i', 'n', 'e', 'I') &&
+	       cpu_vendor[2] == A32('n', 't', 'e', 'l');
+}
+
 /* Returns a bitmask of which words we have error bits in */
 static int check_cpuflags(void)
 {

@@ -153,6 +160,19 @@ int check_cpu(int *cpu_level_ptr, int
 *req_level_ptr, u32 **err_flags_ptr)
 		asm("wrmsr" : : "a" (eax), "d" (edx), "c" (ecx));
 
 		err = check_cpuflags();
+	} else if (err == 0x01 &&
+		   !(err_flags[0] & ~(1 << X86_FEATURE_PAE)) &&
+		   is_intel() && cpu.level == 6 &&
+		   (cpu.model == 9 || cpu.model == 13)) {
+		/* PAE is disabled on this Pentium M but can be forced */
+		if (cmdline_find_option_bool("pae")) {
+			puts("WARNING: Forcing PAE in CPU flags\n");
+			set_bit(X86_FEATURE_PAE, cpu.flags);
+			err = check_cpuflags();
+		}
+		else {
+			puts("WARNING: PAE disabled. Use parameter 'pae' to enable at your
 own risk!\n");
+		}
 	}

if (err_flags_ptr)

arch/x86/kernel/cpu/amd.c +1 -1

index c67ffa6..7ec4119 100644
@@ -218,7 +218,7 @@ static void amd_k7_smp_check(struct cpuinfo_x86 *c)
 	 */
 	WARN_ONCE(1, "WARNING: This combination of AMD"
 		" processors is not suitable for SMP.\n");
-	add_taint(TAINT_UNSAFE_SMP, LOCKDEP_NOW_UNRELIABLE);
+	add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
 }
 
 static void init_amd_k7(struct cpuinfo_x86 *c)

arch/x86/kernel/cpu/intel.c +19 -0

index ea56e7c..cc0d048 100644
@@ -195,6 +195,14 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
 	}
 }
 
+static int pae;
+static int __init pae_setup(char *__unused)
+{
+	pae = 1;
+	return 1;
+}
+__setup("pae", pae_setup);
+
 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
 	unsigned long lo, hi;

@@ -225,6 +233,17 @@ static void intel_workarounds(struct cpuinfo_x86
 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 
 	/*
+	 * PAE CPUID issue: many Pentium M report no PAE but may have a
+	 * functionally usable PAE implementation.
+	 * Forcefully enable PAE if kernel parameter "pae" is present.
+	 */
+	if (pae) {
+		printk(KERN_WARNING "PAE forced!\n");
+		set_cpu_cap(c, X86_FEATURE_PAE);
+		add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
+	}
+
+	/*
 	 * P4 Xeon errata 037 workaround.
 	 * Hardware prefetcher may cause stale data to be loaded into the

cache.

	 */

include/linux/kernel.h +1 -1

index 196d1ea..08fb024 100644
@@ -458,7 +458,7 @@ extern enum system_states {
 
 #define TAINT_PROPRIETARY_MODULE	0
 #define TAINT_FORCED_MODULE		1
-#define TAINT_UNSAFE_SMP		2
+#define TAINT_CPU_OUT_OF_SPEC		2
 #define TAINT_FORCED_RMMOD		3
 #define TAINT_MACHINE_CHECK		4
 #define TAINT_BAD_PAGE			5

kernel/module.c +1 -1

index b99e801..8dc7f5e 100644
@@ -1015,7 +1015,7 @@ static size_t module_flags_taint(struct module
 *mod, char *buf)
 		buf[l++] = 'C';
 	/*
 	 * TAINT_FORCED_RMMOD: could be added.
-	 * TAINT_UNSAFE_SMP, TAINT_MACHINE_CHECK, TAINT_BAD_PAGE don't
+	 * TAINT_CPU_OUT_OF_SPEC, TAINT_MACHINE_CHECK, TAINT_BAD_PAGE don't
 	 * apply to modules.
 	 */

	return l;

kernel/panic.c +1 -1

index 3eb0ffb..cca8a91 100644
@@ -199,7 +199,7 @@ struct tnt {
 static const struct tnt tnts[] = {
 	{ TAINT_PROPRIETARY_MODULE,	'P', 'G' },
 	{ TAINT_FORCED_MODULE,		'F', ' ' },
-	{ TAINT_UNSAFE_SMP,		'S', ' ' },
+	{ TAINT_CPU_OUT_OF_SPEC,	'S', ' ' },
 	{ TAINT_FORCED_RMMOD,		'R', ' ' },
 	{ TAINT_MACHINE_CHECK,		'M', ' ' },
 	{ TAINT_BAD_PAGE,		'B', ' ' },

forcepae is descriptive.

Quoted 1 line · H. Peter Anvin

forcepae is descriptive.

Back to forcepae.

Quoted 4 lines · Chris Bainbridge

Quoted 1 line · H. Peter Anvin

forcepae is descriptive.

Back to forcepae.

Ok, it looks ok to me after a quick look. Now you only have to ask Dave whether he's fine with you merging his patch into yours, write a nice commit message explaining why this patch is needed and give it a final test on your machine.

From: Chris Bainbridge <[email protected]>

Many Pentium M systems disable PAE but may have a functionally usable PAE implementation. This adds the "forcepae" parameter which bypasses the boot check for PAE, and sets the CPU as being PAE capable. Using this parameter will taint the kernel with TAINT_CPU_OUT_OF_SPEC.

Signed-off-by Chris Bainbridge <[email protected]>