Hi everybody,
Abour rhis warnning in boot log:
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
?
I
searched a lot however didn't find a clear solution. Does AMD new
processors (62XX) have problems with new kernels or old kernels??
Mine is:
Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
Should I upgrade?
~MN
On Tue, 12 Jun 2012 02:37:40 -0700 (PDT)
Mahmood Naderan <[email protected]> wrote:
> Hi everybody,
> Abour rhis warnning in boot log:
>
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
^^^^^ Note what it says here
> Should I upgrade?
Your BIOS perhaps.
BIOS has the latest version. We bought it 2 weeks ago.
I have to say, the BIOS has an option, IOMMU. If it is disabled, in the boot log, there is a message that explicitly state you have to enable the IOMMU from BIOS.
After enabling that, in the boot log it doesn't comlain about IOMMU. However it says that warnning.
One thing that I want to know, is that if it is really a warnning, then there should be someway to bypass that.
I think this is related to OS (here kernel I think). However I am not sure.
~MN
----- Original Message -----
From: Alan Cox <[email protected]>
To: Mahmood Naderan <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Tuesday, June 12, 2012 2:42 PM
Subject: Re: CPU MTRRs and linux kernel
On Tue, 12 Jun 2012 02:37:40 -0700 (PDT)
Mahmood Naderan <[email protected]> wrote:
> Hi everybody,
> Abour rhis warnning in boot log:
>
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
? ? ? ? ?? ^^^^^ Note what it says here
> Should I upgrade?
Your BIOS perhaps.
On Tue, Jun 12, 2012 at 02:37:40AM -0700, Mahmood Naderan wrote:
> Hi everybody,
> Abour rhis warnning in boot log:
>
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
>
>
> I
> searched a lot however didn't find a clear solution. Does AMD new
> processors (62XX) have problems with new kernels or old kernels??
> Mine is:
>
> Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
>
> Should I upgrade?
Yes, fix is below and it got backported to -stable AFAICT but obviously
the ubuntus don't have it in the kernel you cite above.
commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d
Author: Andreas Herrmann <[email protected]>
Date: Thu Sep 30 14:32:35 2010 +0200
x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
Instead of adapting the CPU family check in amd_special_default_mtrr()
for each new CPU family assume that all new AMD CPUs support the
necessary bits in SYS_CFG MSR.
Tom2Enabled is architectural (defined in APM Vol.2).
Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
In pre K8-NPT BKDG this bit is reserved (read as zero).
W/o this adaption Linux would unnecessarily complain about bad MTRR
settings on every new AMD CPU family, e.g.
[ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.
Cc: [email protected] # .32.x, .35.x
Signed-off-by: Andreas Herrmann <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index c5f59d071425..ac140c7be396 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
return 0;
- if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
+ if (boot_cpu_data.x86 < 0xf)
return 0;
/* In case some hypervisor doesn't pass SYSCFG through: */
if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
--
Regards/Gruss,
Boris.
Thanks Borislav,
I want to know, should I upgrade to the latest kernel or it is possible to download the source of 2.6.32-24 from repository and modify cleanup.c and then recompile?
~MN
----- Original Message -----
From: Borislav Petkov <[email protected]>
To: Mahmood Naderan <[email protected]>
Cc: "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
Sent: Tuesday, June 12, 2012 3:09 PM
Subject: Re: CPU MTRRs and linux kernel
On Tue, Jun 12, 2012 at 02:37:40AM -0700, Mahmood Naderan wrote:
> Hi everybody,
> Abour rhis warnning in boot log:
>
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
>
> ?
> I
>? searched a lot however didn't find a clear solution. Does AMD new
> processors (62XX) have problems with new kernels or old kernels??
> Mine is:
>
> Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
>
> Should I upgrade?
Yes, fix is below and it got backported to -stable AFAICT but obviously
the ubuntus don't have it in the kernel you cite above.
commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d
Author: Andreas Herrmann <[email protected]>
Date:? Thu Sep 30 14:32:35 2010 +0200
? ? x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
? ?
? ? Instead of adapting the CPU family check in amd_special_default_mtrr()
? ? for each new CPU family assume that all new AMD CPUs support the
? ? necessary bits in SYS_CFG MSR.
? ?
? ? Tom2Enabled is architectural (defined in APM Vol.2).
? ? Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
? ? In pre K8-NPT BKDG this bit is reserved (read as zero).
? ?
? ? W/o this adaption Linux would unnecessarily complain about bad MTRR
? ? settings on every new AMD CPU family, e.g.
? ?
? ? [? ? 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.
? ?
? ? Cc: [email protected] # .32.x, .35.x
? ? Signed-off-by: Andreas Herrmann <[email protected]>
? ? LKML-Reference: <[email protected]>
? ? Signed-off-by: H. Peter Anvin <[email protected]>
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index c5f59d071425..ac140c7be396 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
? ? ? ? if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
? ? ? ? ? ? ? ? return 0;
-? ? ? if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
+? ? ? if (boot_cpu_data.x86 < 0xf)
? ? ? ? ? ? ? ? return 0;
? ? ? ? /* In case some hypervisor doesn't pass SYSCFG through: */
? ? ? ? if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
--
Regards/Gruss,
Boris.
On Tue, Jun 12, 2012 at 06:48:10AM -0700, Mahmood Naderan wrote:
> Thanks Borislav, I want to know, should I upgrade to the latest kernel
> or it is possible to download the source of 2.6.32-24 from repository
> and modify cleanup.c and then recompile?
Whatever you decide.
If it were me and I didn't have any particular reason to stick with
2.6.32, I'd always go for the latest kernel.
In any case, no matter which kernel you're installing, just make sure it
contains the aforementioned patch which should fix your problem.
HTH.
--
Regards/Gruss,
Boris.
On Tue, Jun 12, 2012 at 06:48:10AM -0700, Mahmood Naderan wrote:
> Thanks Borislav,
> I want to know, should I upgrade to the latest kernel or it is
> possible to download the source of 2.6.32-24 from repository and
> modify cleanup.c and then recompile?
Trying to update to latest kernel package is the first thing to do. I
think they've provided kernels >=2.6.32-35 or so.
So chances are high that they already have picked up the fix from
2.6.32-stable tree updates.
Regards,
Andreas
On 12.06.2012 15:48, Mahmood Naderan wrote:
> Thanks Borislav,
> I want to know, should I upgrade to the latest kernel or it is possible to download the source of 2.6.32-24 from repository and modify cleanup.c and then recompile?
>
Just update to the latest kernel. 2.6.32-24.39 is way old. The fix Boris
mentioned was in 2.6.32-27.49. And the latest kernel is 2.6.32-41.89 by now...
-Stefan
> ~MN
>
> ----- Original Message -----
> From: Borislav Petkov <[email protected]>
> To: Mahmood Naderan <[email protected]>
> Cc: "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
> Sent: Tuesday, June 12, 2012 3:09 PM
> Subject: Re: CPU MTRRs and linux kernel
>
> On Tue, Jun 12, 2012 at 02:37:40AM -0700, Mahmood Naderan wrote:
>> Hi everybody,
>> Abour rhis warnning in boot log:
>>
>> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
>>
>>
>> I
>> searched a lot however didn't find a clear solution. Does AMD new
>> processors (62XX) have problems with new kernels or old kernels??
>> Mine is:
>>
>> Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
>>
>> Should I upgrade?
>
> Yes, fix is below and it got backported to -stable AFAICT but obviously
> the ubuntus don't have it in the kernel you cite above.
>
>
> commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d
> Author: Andreas Herrmann <[email protected]>
> Date: Thu Sep 30 14:32:35 2010 +0200
>
> x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
>
> Instead of adapting the CPU family check in amd_special_default_mtrr()
> for each new CPU family assume that all new AMD CPUs support the
> necessary bits in SYS_CFG MSR.
>
> Tom2Enabled is architectural (defined in APM Vol.2).
> Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
> In pre K8-NPT BKDG this bit is reserved (read as zero).
>
> W/o this adaption Linux would unnecessarily complain about bad MTRR
> settings on every new AMD CPU family, e.g.
>
> [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.
>
> Cc: [email protected] # .32.x, .35.x
> Signed-off-by: Andreas Herrmann <[email protected]>
> LKML-Reference: <[email protected]>
> Signed-off-by: H. Peter Anvin <[email protected]>
>
> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
> index c5f59d071425..ac140c7be396 100644
> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> @@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
>
> if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> return 0;
> - if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
> + if (boot_cpu_data.x86 < 0xf)
> return 0;
> /* In case some hypervisor doesn't pass SYSCFG through: */
> if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
>
>And the latest kernel is 2.6.32-41.89 by now...
Sorry 3.4.2 ???
?
// Naderan *Mahmood;
----- Original Message -----
From: Stefan Bader <[email protected]>
To: Mahmood Naderan <[email protected]>
Cc: Borislav Petkov <[email protected]>; "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
Sent: Tuesday, June 12, 2012 7:43 PM
Subject: Re: CPU MTRRs and linux kernel
On 12.06.2012 15:48, Mahmood Naderan wrote:
> Thanks Borislav,
> I want to know, should I upgrade to the latest kernel or it is possible to download the source of 2.6.32-24 from repository and modify cleanup.c and then recompile?
>
Just update to the latest kernel. 2.6.32-24.39 is way old. The fix Boris
mentioned was in 2.6.32-27.49. And the latest kernel is 2.6.32-41.89 by now...
-Stefan
> ~MN
>
> ----- Original Message -----
> From: Borislav Petkov <[email protected]>
> To: Mahmood Naderan <[email protected]>
> Cc: "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
> Sent: Tuesday, June 12, 2012 3:09 PM
> Subject: Re: CPU MTRRs and linux kernel
>
> On Tue, Jun 12, 2012 at 02:37:40AM -0700, Mahmood Naderan wrote:
>> Hi everybody,
>> Abour rhis warnning in boot log:
>>
>> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
>>
>>?
>> I
>>? searched a lot however didn't find a clear solution. Does AMD new
>> processors (62XX) have problems with new kernels or old kernels??
>> Mine is:
>>
>> Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
>>
>> Should I upgrade?
>
> Yes, fix is below and it got backported to -stable AFAICT but obviously
> the ubuntus don't have it in the kernel you cite above.
>
>
> commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d
> Author: Andreas Herrmann <[email protected]>
> Date:? Thu Sep 30 14:32:35 2010 +0200
>
>? ? x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
>? ?
>? ? Instead of adapting the CPU family check in amd_special_default_mtrr()
>? ? for each new CPU family assume that all new AMD CPUs support the
>? ? necessary bits in SYS_CFG MSR.
>? ?
>? ? Tom2Enabled is architectural (defined in APM Vol.2).
>? ? Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
>? ? In pre K8-NPT BKDG this bit is reserved (read as zero).
>? ?
>? ? W/o this adaption Linux would unnecessarily complain about bad MTRR
>? ? settings on every new AMD CPU family, e.g.
>? ?
>? ? [? ? 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.
>? ?
>? ? Cc: [email protected] # .32.x, .35.x
>? ? Signed-off-by: Andreas Herrmann <[email protected]>
>? ? LKML-Reference: <[email protected]>
>? ? Signed-off-by: H. Peter Anvin <[email protected]>
>
> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
> index c5f59d071425..ac140c7be396 100644
> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> @@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
>
>? ? ? ? if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
>? ? ? ? ? ? ? ? return 0;
> -? ? ? if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
> +? ? ? if (boot_cpu_data.x86 < 0xf)
>? ? ? ? ? ? ? ? return 0;
>? ? ? ? /* In case some hypervisor doesn't pass SYSCFG through: */
>? ? ? ? if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
>
On Tue, Jun 12, 2012 at 08:15:28AM -0700, Mahmood Naderan wrote:
> >And the latest kernel is 2.6.32-41.89 by now...
>
> Sorry 3.4.2 ???
He means the latest 2.6.32.x Ubuntu kernel which you can get from the
Ubuntu repositories, I assume.
--
Regards/Gruss,
Boris.
>He means the latest 2.6.32.x Ubuntu kernel which you can get from the
>Ubuntu repositories, I assume.
?
ok I understand
~MN
----- Original Message -----
From: Borislav Petkov <[email protected]>
To: Mahmood Naderan <[email protected]>
Cc: Stefan Bader <[email protected]>; ""[email protected]"" <[email protected]>; Andreas Herrmann <[email protected]>
Sent: Tuesday, June 12, 2012 7:47 PM
Subject: Re: CPU MTRRs and linux kernel
On Tue, Jun 12, 2012 at 08:15:28AM -0700, Mahmood Naderan wrote:
> >And the latest kernel is 2.6.32-41.89 by now...
>
> Sorry 3.4.2 ???
He means the latest 2.6.32.x Ubuntu kernel which you can get from the
Ubuntu repositories, I assume.
--
Regards/Gruss,
Boris.
>If it were me and I didn't have any particular reason to stick with
>2.6.32, I'd always go for the latest kernel
?
One thing is not clear for me. Did you make the following change in the latest version today? I want to know, should I wait until it is pushed in to ubuntu repository?
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index c5f59d071425..ac140c7be396 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
? ? ? ? if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
? ? ? ? ? ? ? ? return 0;
-? ? ? if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
+? ? ? if (boot_cpu_data.x86 < 0xf)
? ? ? ? ? ? ? ? return 0;
? ? ? ? /* In case some hypervisor doesn't pass SYSCFG through: */
? ? ? ? if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
// Naderan *Mahmood;
----- Original Message -----
From: Borislav Petkov <[email protected]>
To: Mahmood Naderan <[email protected]>
Cc: LKML <[email protected]>; Andreas Herrmann <[email protected]>
Sent: Tuesday, June 12, 2012 6:27 PM
Subject: Re: CPU MTRRs and linux kernel
On Tue, Jun 12, 2012 at 06:48:10AM -0700, Mahmood Naderan wrote:
> Thanks Borislav, I want to know, should I upgrade to the latest kernel
> or it is possible to download the source of 2.6.32-24 from repository
> and modify cleanup.c and then recompile?
Whatever you decide.
If it were me and I didn't have any particular reason to stick with
2.6.32, I'd always go for the latest kernel.
In any case, no matter which kernel you're installing, just make sure it
contains the aforementioned patch which should fix your problem.
HTH.
--
Regards/Gruss,
Boris.
On 12.06.2012 17:15, Mahmood Naderan wrote:
>> And the latest kernel is 2.6.32-41.89 by now...
>
> Sorry 3.4.2 ???
Not sure what this is intended to mean. From the kernel version you gave in the
initial post I take you are using a Ubuntu 10.04 server installation. And the
latest kernel for that release is 2.6.32-41.89 (which should replace any older
kernel if you do updates).
-Stefan
>
>
> // Naderan *Mahmood;
>
>
> ----- Original Message -----
> From: Stefan Bader <[email protected]>
> To: Mahmood Naderan <[email protected]>
> Cc: Borislav Petkov <[email protected]>; "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
> Sent: Tuesday, June 12, 2012 7:43 PM
> Subject: Re: CPU MTRRs and linux kernel
>
> On 12.06.2012 15:48, Mahmood Naderan wrote:
>> Thanks Borislav,
>> I want to know, should I upgrade to the latest kernel or it is possible to download the source of 2.6.32-24 from repository and modify cleanup.c and then recompile?
>>
> Just update to the latest kernel. 2.6.32-24.39 is way old. The fix Boris
> mentioned was in 2.6.32-27.49. And the latest kernel is 2.6.32-41.89 by now...
>
> -Stefan
>
>> ~MN
>>
>> ----- Original Message -----
>> From: Borislav Petkov <[email protected]>
>> To: Mahmood Naderan <[email protected]>
>> Cc: "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
>> Sent: Tuesday, June 12, 2012 3:09 PM
>> Subject: Re: CPU MTRRs and linux kernel
>>
>> On Tue, Jun 12, 2012 at 02:37:40AM -0700, Mahmood Naderan wrote:
>>> Hi everybody,
>>> Abour rhis warnning in boot log:
>>>
>>> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
>>>
>>>
>>> I
>>> searched a lot however didn't find a clear solution. Does AMD new
>>> processors (62XX) have problems with new kernels or old kernels??
>>> Mine is:
>>>
>>> Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
>>>
>>> Should I upgrade?
>>
>> Yes, fix is below and it got backported to -stable AFAICT but obviously
>> the ubuntus don't have it in the kernel you cite above.
>>
>>
>> commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d
>> Author: Andreas Herrmann <[email protected]>
>> Date: Thu Sep 30 14:32:35 2010 +0200
>>
>> x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
>>
>> Instead of adapting the CPU family check in amd_special_default_mtrr()
>> for each new CPU family assume that all new AMD CPUs support the
>> necessary bits in SYS_CFG MSR.
>>
>> Tom2Enabled is architectural (defined in APM Vol.2).
>> Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
>> In pre K8-NPT BKDG this bit is reserved (read as zero).
>>
>> W/o this adaption Linux would unnecessarily complain about bad MTRR
>> settings on every new AMD CPU family, e.g.
>>
>> [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.
>>
>> Cc: [email protected] # .32.x, .35.x
>> Signed-off-by: Andreas Herrmann <[email protected]>
>> LKML-Reference: <[email protected]>
>> Signed-off-by: H. Peter Anvin <[email protected]>
>>
>> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
>> index c5f59d071425..ac140c7be396 100644
>> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
>> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
>> @@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
>>
>> if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
>> return 0;
>> - if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
>> + if (boot_cpu_data.x86 < 0xf)
>> return 0;
>> /* In case some hypervisor doesn't pass SYSCFG through: */
>> if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
>>
> --
> 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/
>From the kernel version you gave in the
>initial post I take you are using a Ubuntu 10.04 server installation. And the
>latest kernel for that release is 2.6.32-41.89 (which should replace any older
>kernel if you do updates).
?
ok I got it. thanks
~MN
----- Original Message -----
From: Stefan Bader <[email protected]>
To: Mahmood Naderan <[email protected]>
Cc: Borislav Petkov <[email protected]>; "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
Sent: Tuesday, June 12, 2012 8:01 PM
Subject: Re: CPU MTRRs and linux kernel
On 12.06.2012 17:15, Mahmood Naderan wrote:
>> And the latest kernel is 2.6.32-41.89 by now...
>
> Sorry 3.4.2 ???
Not sure what this is intended to mean. From the kernel version you gave in the
initial post I take you are using a Ubuntu 10.04 server installation. And the
latest kernel for that release is 2.6.32-41.89 (which should replace any older
kernel if you do updates).
-Stefan
>?
>
> // Naderan *Mahmood;
>
>
> ----- Original Message -----
> From: Stefan Bader <[email protected]>
> To: Mahmood Naderan <[email protected]>
> Cc: Borislav Petkov <[email protected]>; "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
> Sent: Tuesday, June 12, 2012 7:43 PM
> Subject: Re: CPU MTRRs and linux kernel
>
> On 12.06.2012 15:48, Mahmood Naderan wrote:
>> Thanks Borislav,
>> I want to know, should I upgrade to the latest kernel or it is possible to download the source of 2.6.32-24 from repository and modify cleanup.c and then recompile?
>>
> Just update to the latest kernel. 2.6.32-24.39 is way old. The fix Boris
> mentioned was in 2.6.32-27.49. And the latest kernel is 2.6.32-41.89 by now...
>
> -Stefan
>
>> ~MN
>>
>> ----- Original Message -----
>> From: Borislav Petkov <[email protected]>
>> To: Mahmood Naderan <[email protected]>
>> Cc: "[email protected]" <[email protected]>; Andreas Herrmann <[email protected]>
>> Sent: Tuesday, June 12, 2012 3:09 PM
>> Subject: Re: CPU MTRRs and linux kernel
>>
>> On Tue, Jun 12, 2012 at 02:37:40AM -0700, Mahmood Naderan wrote:
>>> Hi everybody,
>>> Abour rhis warnning in boot log:
>>>
>>> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 61952MB of RAM
>>>
>>>?
>>> I
>>>? ? searched a lot however didn't find a clear solution. Does AMD new
>>> processors (62XX) have problems with new kernels or old kernels??
>>> Mine is:
>>>
>>> Linux n1 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux
>>>
>>> Should I upgrade?
>>
>> Yes, fix is below and it got backported to -stable AFAICT but obviously
>> the ubuntus don't have it in the kernel you cite above.
>>
>>
>> commit 3fdbf004c1706480a7c7fac3c9d836fa6df20d7d
>> Author: Andreas Herrmann <[email protected]>
>> Date:? Thu Sep 30 14:32:35 2010 +0200
>>
>>? ? ? x86, mtrr: Assume SYS_CFG[Tom2ForceMemTypeWB] exists on all future AMD CPUs
>>? ?
>>? ? ? Instead of adapting the CPU family check in amd_special_default_mtrr()
>>? ? ? for each new CPU family assume that all new AMD CPUs support the
>>? ? ? necessary bits in SYS_CFG MSR.
>>? ?
>>? ? ? Tom2Enabled is architectural (defined in APM Vol.2).
>>? ? ? Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT.
>>? ? ? In pre K8-NPT BKDG this bit is reserved (read as zero).
>>? ?
>>? ? ? W/o this adaption Linux would unnecessarily complain about bad MTRR
>>? ? ? settings on every new AMD CPU family, e.g.
>>? ?
>>? ? ? [? ? 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM.
>>? ?
>>? ? ? Cc: [email protected] # .32.x, .35.x
>>? ? ? Signed-off-by: Andreas Herrmann <[email protected]>
>>? ? ? LKML-Reference: <[email protected]>
>>? ? ? Signed-off-by: H. Peter Anvin <[email protected]>
>>
>> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
>> index c5f59d071425..ac140c7be396 100644
>> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
>> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
>> @@ -827,7 +827,7 @@ int __init amd_special_default_mtrr(void)
>>
>>? ? ? ? ? if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
>>? ? ? ? ? ? ? ? ? return 0;
>> -? ? ? if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
>> +? ? ? if (boot_cpu_data.x86 < 0xf)
>>? ? ? ? ? ? ? ? ? return 0;
>>? ? ? ? ? /* In case some hypervisor doesn't pass SYSCFG through: */
>>? ? ? ? ? if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
>>
> --
> 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/