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 <[email protected]>
---
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.
*/
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
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.
--
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
On Tue, 25 Feb 2014 02:45:57 -0800
"H. Peter Anvin" <[email protected]> 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
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
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
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.
*/
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.
--
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 | [email protected]
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
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
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 <[email protected]>
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', ' ' },
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 | [email protected]
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/[email protected]
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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/[email protected]
Then it's definitely a good idea :-)
Dave
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.
--
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
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?
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 <[email protected]>
---
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.
*/