Re: [PATCH] x86: set Pentium M as PAE capable

Re: [PATCH] x86: set Pentium M as PAE capable

[Roland Kletzing]

great to see that we have an enhaced version of the initial quick`n`dirty patch
now. i just tested it on ubuntu 13.10 with kernel from 14.04 repository (complete 
package build).

works as expected ! hopefully ubuntu #930447 can now be closed soon and the patch
will quickly find it´s way into trusty tahr. this is important, because windows xp 
is EOL`ed on 8th of april, and there will probably be lot`s of users with older 
notebooks try switching to lubuntu/xubuntu or whatever "PAE-only distro". 
( https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule )

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

Thanks for your work !

Tested-by: Roland Kletzing <devzero@web.de>


root@ubuntu:/etc# uname -a
Linux ubuntu 3.13.0-14-generic #34 SMP Sat Mar 1 21:27:33 CET 2014 i686 i686 i686 GNU/Linux
root@ubuntu:/etc# dmesg |grep -C2 -i pae
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 127870
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-14-generic root=UUID=9ee2e971-296c-4605-a26a-4f9854106ef8 ro crashkernel=384M-2G:64M,2G-:128M acpi=off forcepae
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
--
[    0.005403] Initializing cgroup subsys perf_event
[    0.005465] Initializing cgroup subsys hugetlb
[    0.005571] PAE forced!
[    0.005627] Disabling lock debugging due to kernel taint
[    0.005697] mce: CPU supports 5 MCE banks

root@ubuntu:/etc# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Celeron(R) M processor         1300MHz
stepping        : 5
microcode       : 0x45
cpu MHz         : 1300.136
cache size      : 512 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 tm pbe bts
bogomips        : 2600.27
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 32 bits virtual
power management:



On Fri, Feb 28, 2014 at 03:27:50PM +0300, Dennis Mungai wrote:
> 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.

Good point, patch updated to not show the warning if PAE is already
enabled.

Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>

 	 */

Re: [PATCH] x86: set Pentium M as PAE capable

[One Thousand Gnomes]

> 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.

Can't speak for AMD devices but I would be curious to know more on the
Intel side about this and how you measured and analysed it.

Are you running with any hyperthreading disabled, a firmware which is not
using SMM, and with any critical code pinned in cache ? How do you have
power management set up ?

(probably best taken off list)

Alan

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 02/26/2014 09:57 AM, H. Peter Anvin wrote:
> On 02/26/2014 09:10 AM, Matthew Garrett wrote:
>> On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
>>
>>> 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.
> 

Hmm... this doesn't seem to actually be the case.  I recently did a F20
install on a clean system, and it still uses linux/initrd.  So unless
you changed the meaning of linux/initrd inside of Grub2, it is still
doing the pointless bypass.

	-hpa

Re: [PATCH] x86: set Pentium M as PAE capable

[Gene Heskett]

On Sunday 02 March 2014, Dave Jones wrote:
>On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:
> > (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

There is a fly in that soup Dave, and that is the speed in a truly real 
time required environment.  IRQ latencies once the 32 bit scene have been 
left behind, either by PAE or a full 64 bit build are not at all well 
defined, and are of sufficient magnitudes in terms of the timing jitter, as 
to nearly destroy our ability to use software step generation to control 
our machine tools.  A motor being stepped every 200 microseconds (thats 
actually slow) will lose 50% of its available torque if the timing jitter 
in the step issuance is 10% of the period.

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.

OTOH, we (LinuxCNC) are a very small user group. I just want to make you 
aware that we exist. We do retrofits mostly, because our software can make 
the part faster, but I would estimate there are 5 to 10k machines out there 
in the major manufacturing scene running our software, and that they 
include some of the heaviest hitters in the auto making business.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

Re: [PATCH] x86: set Pentium M as PAE capable

[Andreas Mohr]

On Sun, Mar 02, 2014 at 10:04:19PM +0100, Borislav Petkov wrote:
> On Sun, Mar 02, 2014 at 04:02:01PM -0500, Dave Jones wrote:
> > 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!

Did I just smell two or three historically burnt fingers? ;)

While that was slightly disheartening, thanks for the very fast clarification,
Dave et al.!

Andreas Mohr

Re: [PATCH] x86: set Pentium M as PAE capable

[Borislav Petkov]

On Sun, Mar 02, 2014 at 04:02:01PM -0500, Dave Jones wrote:
> 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!

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86: set Pentium M as PAE capable

[Dave Jones]

On Sun, Mar 02, 2014 at 09:56:19PM +0100, Andreas Mohr wrote:

 > (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

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 03/02/2014 12:56 PM, Andreas Mohr wrote:
> 
> (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 :-((()
> 

As far as I know the "static boottime flag" in Windows simply loads one
of several possible kernels.

	-hpa

Re: [PATCH] x86: set Pentium M as PAE capable

[Chris Bainbridge]

On Fri, Feb 28, 2014 at 03:27:50PM +0300, Dennis Mungai wrote:
> 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.

Good point, patch updated to not show the warning if PAE is already
enabled.

Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
---
diff --git a/arch/x86/boot/cpucheck.c b/arch/x86/boot/cpucheck.c
index 4d3ff03..3fd12bc 100644
--- a/arch/x86/boot/cpucheck.c
+++ b/arch/x86/boot/cpucheck.c
@@ -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,21 @@ 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_flags();
+	} 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("forcepae")) {
+			puts("WARNING: Forcing PAE in CPU flags\n");
+			set_bit(X86_FEATURE_PAE, cpu.flags);
+			err = check_flags();
+		}
+		else {
+			puts("Pentium M: PAE is disabled, "
+			     "enable it with kernel argument \"forcepae\"\n"
+			     "(this will taint the kernel)\n");
+		}
 	}
 
 	if (err_flags_ptr)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index bbe1b8b..873cf3b 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -196,6 +196,14 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
 	}
 }
 
+static int forcepae;
+static int __init forcepae_setup(char *__unused)
+{
+	forcepae = 1;
+	return 1;
+}
+__setup("forcepae", forcepae_setup);
+
 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
 	unsigned long lo, hi;
@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 
 	/*
+	 * 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_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
+	}
+
+	/*
 	 * P4 Xeon errata 037 workaround.
 	 * Hardware prefetcher may cause stale data to be loaded into the cache.
 	 */

Re: [PATCH] x86: set Pentium M as PAE capable

[Chris Bainbridge]

On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
> On Wed, Feb 26, 2014 at 02:18:52PM +0100, Borislav Petkov wrote:
>  > On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
>  > > @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>  > >  		clear_cpu_cap(c, X86_FEATURE_SEP);
>  > >  
>  > >  	/*
>  > > +	 * 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

Patch looks fine. Is the patch I previously posted, combined with this
patch, sufficient for inclusion in the kernel? Or is there anything else
I need to do?

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 02/26/2014 09:10 AM, Matthew Garrett wrote:
> On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:
> 
>> 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.

	-hpa

Re: [PATCH] x86: set Pentium M as PAE capable

[Borislav Petkov]

On Wed, Feb 26, 2014 at 12:20:10PM -0500, Dave Jones wrote:
> Then it's definitely a good idea :-)

LOL!

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86: set Pentium M as PAE capable

[Dave Jones]

On Wed, Feb 26, 2014 at 06:18:17PM +0100, Borislav Petkov wrote:
 > On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
 > > 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/20140225113524.GA23256@pd.tnic

Then it's definitely a good idea :-)

	Dave

 

Re: [PATCH] x86: set Pentium M as PAE capable

[Borislav Petkov]

On Wed, Feb 26, 2014 at 10:49:49AM -0500, Dave Jones wrote:
> 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/20140225113524.GA23256@pd.tnic

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86: set Pentium M as PAE capable

[Matthew Garrett]

On Wed, Feb 26, 2014 at 08:45:41AM -0800, H. Peter Anvin wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 02/26/2014 05:18 AM, Borislav Petkov wrote:
> On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
>> @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>>  		clear_cpu_cap(c, X86_FEATURE_SEP);
>>  
>>  	/*
>> +	 * 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 liked your proposal:

> 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. 

	-hpa

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 02/26/2014 08:44 AM, Matthew Garrett wrote:
> On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
> 
>> 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.
> 

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

There are much worse problems with that.

	-hpa

Re: [PATCH] x86: set Pentium M as PAE capable

[Matthew Garrett]

On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] x86: set Pentium M as PAE capable

[Dave Jones]

On Wed, Feb 26, 2014 at 02:18:52PM +0100, Borislav Petkov wrote:
 > On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
 > > @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 > >  		clear_cpu_cap(c, X86_FEATURE_SEP);
 > >  
 > >  	/*
 > > +	 * 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

Rename TAINT_UNSAFE_SMP to TAINT_CPU_OUT_OF_SPEC, so we can repurpose the
flag to encompass a wider range of problems.

Signed-off-by: Dave Jones <davej@fedoraproject.org>

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index c67ffa686064..7ec4119b381c 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -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)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 196d1ea86df0..08fb02477641 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -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
diff --git a/kernel/module.c b/kernel/module.c
index d24fcf29cb64..ca2c1aded7ee 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -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;
diff --git a/kernel/panic.c b/kernel/panic.c
index 2feab00c73ba..6900b83d17f5 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -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', ' ' },

Re: [PATCH] x86: set Pentium M as PAE capable

[Borislav Petkov]

On Wed, Feb 26, 2014 at 07:12:59PM +0700, Chris Bainbridge wrote:
> @@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>  		clear_cpu_cap(c, X86_FEATURE_SEP);
>  
>  	/*
> +	 * 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.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86: set Pentium M as PAE capable

[Chris Bainbridge]

On Tue, Feb 25, 2014 at 09:16:02AM -0800, H. Peter Anvin wrote:
> On 02/25/2014 08:26 AM, Dave Jones wrote:
> > On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
> >  > On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> >  > > 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.
> > 
> > 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.

In all of the testing reported on the Launchpad bug and elsewhere, every
user who managed to boot a PAE kernel on Pentium M reported success.
There was a single report of failure, but the user encountered the "This
kernel requires the following features" message, so the failure was
caused by some issue of his boot setup not skipping the cpu validation
code, rather than a PAE failure in the Pentium M.

It is possible that PAE was disabled for technical reasons, or for
commercial reasons (e.g. to discourage vendors from building Pentium M
servers). We don't know. What we do know is that people are using PAE
kernels on Pentium M systems, and that not all are aware of the
implications (for a user with an existing install of Debian who apt-gets a
PAE kernel, it will install and boot (thanks to Grub) and no errors or
warnings will have been shown to indicate that their system is now
running "out of spec")

I have made the requested changes to the patch:
---
diff --git a/arch/x86/boot/cpucheck.c b/arch/x86/boot/cpucheck.c
index 4d3ff03..3220734 100644
--- a/arch/x86/boot/cpucheck.c
+++ b/arch/x86/boot/cpucheck.c
@@ -151,6 +151,16 @@ static void get_flags(void)
 			    : : "ebx");
 		}
 	}
+
+	if (cmdline_find_option_bool("forcepae")) {
+		puts("WARNING: Forcing PAE in CPU flags\n");
+		set_bit(X86_FEATURE_PAE, cpu.flags);
+	}
+	else if ((cpu.level == 6) && ((cpu.model == 9) || (cpu.model == 13))) {
+		puts("Pentium M: PAE is disabled, "
+		     "enable it with kernel argument \"forcepae\"\n"
+		     "(\"forcepae\" is unsupported and will taint the kernel)\n");
+	}
 }
 
 /* Returns a bitmask of which words we have error bits in */
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index bbe1b8b..1047098 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -196,6 +196,14 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
 	}
 }
 
+static int forcepae;
+static int __init forcepae_setup(char *__unused)
+{
+	forcepae = 1;
+	return 1;
+}
+__setup("forcepae", forcepae_setup);
+
 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
 	unsigned long lo, hi;
@@ -226,6 +234,15 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 
 	/*
+	 * 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);
+	}
+
+	/*
 	 * P4 Xeon errata 037 workaround.
 	 * Hardware prefetcher may cause stale data to be loaded into the cache.
 	 */

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 02/25/2014 08:26 AM, Dave Jones wrote:
> On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
>  > On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
>  > > 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.
> 
> 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

Re: [PATCH] x86: set Pentium M as PAE capable

[Dave Jones]

On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
 > On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
 > > 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.

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.

	Dave

Re: [PATCH] x86: set Pentium M as PAE capable

[One Thousand Gnomes]

On Tue, 25 Feb 2014 02:45:57 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> > 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.

A hang with an extended version of the no PAE message that warns you
and then says "Boot with the option "forcepae" to bypass this check",
would, IMHO, be a bit wiser, unless someone can actually dig out the
reason it does not advertise the flag.

Alan

Re: [PATCH] x86: set Pentium M as PAE capable

[Peter Hurley]

On 02/25/2014 05:45 AM, H. Peter Anvin wrote:
> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
>> 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.

Perhaps obviously, this should require either command line or build opt-in.

Regards,
Peter Hurley

Re: [PATCH] x86: set Pentium M as PAE capable

[Borislav Petkov]

On Tue, Feb 25, 2014 at 02:45:57AM -0800, H. Peter Anvin wrote:
> On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> >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.

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. :-)

Hmm.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
> 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.

	-hpa

[PATCH] x86: set Pentium M as PAE capable

[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

Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>

---

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index bbe1b8b..97996aa 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -226,6 +226,12 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 		clear_cpu_cap(c, X86_FEATURE_SEP);
 
 	/*
+	 * PAE CPUID bug: Pentium M reports no PAE but has PAE
+	 */
+	if ((c->x86 == 6) && ((c->x86_model == 9) || (c->x86_model == 13)))
+		set_cpu_cap(c, X86_FEATURE_PAE);
+
+	/*
 	 * P4 Xeon errata 037 workaround.
 	 * Hardware prefetcher may cause stale data to be loaded into the cache.
 	 */