Re: [PATCH] trim memory not covered by WB MTRRs
On Thu, 5 Jul 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
+ if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
+ printk(KERN_WARNING "***\n");
+ printk(KERN_WARNING " WARNING: likely BIOS bug\n");
+ printk(KERN_WARNING " MTRRs don't cover all of "
+ "memory, trimmed %ld pages\n", end_pfn -
+ (highest_addr >> PAGE_SHIFT));
+ printk(KERN_WARNING "***\n");
+ end_pfn = highest_addr >> PAGE_SHIFT;
I'd say using that many stars for KERN_WARNING printk is sign of
mental illness or something...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Will this patch make it into 2.6.23?
Been patching manually for a while with each -rc for 2.6.22..
Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Hi!
> On some machines, buggy BIOSes don't properly setup WB MTRRs to
> cover all available RAM, meaning the last few megs (or even gigs)
> of memory will be marked uncached. Since Linux tends to allocate
> from high memory addresses first, this causes the machine to be
> unusably slow as soon as the kernel starts really using memory
> (i.e. right around init time).
>
> This patch works around the problem by scanning the MTRRs at
> boot and figuring out whether the current end_pfn value (setup
> by early e820 code) goes beyond the highest WB MTRR range, and
> if so, trimming it to match. A fairly obnoxious KERN_WARNING
> is printed too, letting the user know that not all of their
> memory is available due to a likely BIOS bug.
>
> Something similar could be done on i386 if needed, but the boot
> ordering would be slightly different, since the MTRR code on i386
> depends on the boot_cpu_data structure being setup.
>
> This patch fixes a bug in the last patch that caused the code to
> run on non-Intel machines (AMD machines apparently don't need it
> and it's untested on other non-Intel machines, so best keep it
> off).
>
> akpm -- this one should replace all the mtrr patches currently
> in your tree.
>
> Yinghai, maybe you can test this on one of your AMD machines to
> make sure I got the CPU code right?
> + if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
> + printk(KERN_WARNING "***\n");
> + printk(KERN_WARNING " WARNING: likely BIOS bug\n");
> + printk(KERN_WARNING " MTRRs don't cover all of "
> +"memory, trimmed %ld pages\n", end_pfn -
> +(highest_addr >> PAGE_SHIFT));
> + printk(KERN_WARNING "***\n");
> + end_pfn = highest_addr >> PAGE_SHIFT;
I'd say using that many stars for KERN_WARNING printk is sign of
mental illness or something...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
+ if ((highest_addr PAGE_SHIFT) != end_pfn) {
+ printk(KERN_WARNING ***\n);
+ printk(KERN_WARNING WARNING: likely BIOS bug\n);
+ printk(KERN_WARNING MTRRs don't cover all of
+memory, trimmed %ld pages\n, end_pfn -
+(highest_addr PAGE_SHIFT));
+ printk(KERN_WARNING ***\n);
+ end_pfn = highest_addr PAGE_SHIFT;
I'd say using that many stars for KERN_WARNING printk is sign of
mental illness or something...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thu, 5 Jul 2007, Pavel Machek wrote:
Hi!
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
+ if ((highest_addr PAGE_SHIFT) != end_pfn) {
+ printk(KERN_WARNING ***\n);
+ printk(KERN_WARNING WARNING: likely BIOS bug\n);
+ printk(KERN_WARNING MTRRs don't cover all of
+ memory, trimmed %ld pages\n, end_pfn -
+ (highest_addr PAGE_SHIFT));
+ printk(KERN_WARNING ***\n);
+ end_pfn = highest_addr PAGE_SHIFT;
I'd say using that many stars for KERN_WARNING printk is sign of
mental illness or something...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Will this patch make it into 2.6.23?
Been patching manually for a while with each -rc for 2.6.22..
Justin.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: Yeah, that's what I needed. end_pfn looks ok, but I guess my test is a little too precise. It should be if ((highest_addr >> PAGE_SHIFT) < end_pfn) rather than !=. Right. That made the message disappear. Nice to know my BIOS is really fixed. Thanks, Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 10:02:35 Pim Zandbergen wrote:
> Jesse Barnes wrote:
> > It looks like end_pfn might be ~0UL now... can you print that out
> > in your configuration?
>
> Er, do you need the value of end_pfn ?
> Here's what I changed:
>
> if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
> printk(KERN_WARNING "***\n");
> printk(KERN_WARNING " WARNING: likely BIOS bug\n");
> printk(KERN_WARNING " MTRRs don't cover all of "
> "memory, trimmed %lu pages\n", end_pfn -
> (highest_addr >> PAGE_SHIFT));
> printk(KERN_WARNING " end_pfn before = %lu\n", end_pfn);
> end_pfn = highest_addr >> PAGE_SHIFT;
> printk(KERN_WARNING " end_pfn after = %lu\n", end_pfn);
> printk(KERN_WARNING "***\n");
> }
>
> Here's the result:
> ***
> WARNING: likely BIOS bug
> MTRRs don't cover all of memory, trimmed 18446744073709486080
> pages end_pfn before = 2293760
> end_pfn after = 2359296
> ***
>
> Hope that's what you needed.
Yeah, that's what I needed. end_pfn looks ok, but I guess my test is a
little too precise. It should be if ((highest_addr >> PAGE_SHIFT) <
end_pfn) rather than !=. That should keep it from trying to extend
your memory with bogus math. I thought that the two values should
always match, but I guess slightly different memory configurations
might break that assumption.
Thanks,
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote:
It looks like end_pfn might be ~0UL now... can you print that out in
your configuration?
Er, do you need the value of end_pfn ?
Here's what I changed:
if ((highest_addr >> PAGE_SHIFT) != end_pfn) {
printk(KERN_WARNING "***\n");
printk(KERN_WARNING " WARNING: likely BIOS bug\n");
printk(KERN_WARNING " MTRRs don't cover all of "
"memory, trimmed %lu pages\n", end_pfn -
(highest_addr >> PAGE_SHIFT));
printk(KERN_WARNING " end_pfn before = %lu\n", end_pfn);
end_pfn = highest_addr >> PAGE_SHIFT;
printk(KERN_WARNING " end_pfn after = %lu\n", end_pfn);
printk(KERN_WARNING "***\n");
}
Here's the result:
***
WARNING: likely BIOS bug
MTRRs don't cover all of memory, trimmed 18446744073709486080 pages
end_pfn before = 2293760
end_pfn after = 2359296
***
Hope that's what you needed.
Pim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 9:00:33 Pim Zandbergen wrote: > Jesse Barnes wrote: > > Yeah, you're right I should use an unsigned format string. Pim, if > > you change it to %lu does the printk in your dmesg look better? > > Er, no. > > MTRRs don't cover all of memory, trimmed 18446744073709486080 > pages It looks like end_pfn might be ~0UL now... can you print that out in your configuration? Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 9:00:33 Pim Zandbergen wrote: > Jesse Barnes wrote: > > Yeah, you're right I should use an unsigned format string. Pim, if > > you change it to %lu does the printk in your dmesg look better? > > Er, no. > > MTRRs don't cover all of memory, trimmed 18446744073709486080 > pages Hm, that's what I was afraid of. So something else is wrong. :) Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: Yeah, you're right I should use an unsigned format string. Pim, if you change it to %lu does the printk in your dmesg look better? Er, no. MTRRs don't cover all of memory, trimmed 18446744073709486080 pages Thanks, Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 7:22:24 Mauro Giachero wrote: > On 6/27/07, Pim Zandbergen <[EMAIL PROTECTED]> wrote: > > Now: > > Jesse released a new patch and I tried if for fun on 2.6.22-rc6 > > It looks like the patch is releasing memory rather than trimming > > it: > > > > [...] > > Jun 27 12:22:56 corneille kernel: MTRRs don't cover all of > > memory, trimmed -65536 pages > > [...] > > From Jesse's patch: > > + unsigned long i, base, size, highest_addr = 0, def, dummy; > > [...] > > + printk(KERN_WARNING " MTRRs don't cover all of > > " + "memory, trimmed %ld pages\n", end_pfn - + > > (highest_addr >> PAGE_SHIFT)); > > Since both end_pfn (from arch/x86_64/kernel/e820.c) and highest_addr > are unsigned long, maybe the problem is just that %ld in the kprintf > format string? Shouldn't that be %lu? Yeah, you're right I should use an unsigned format string. Pim, if you change it to %lu does the printk in your dmesg look better? Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/27/07, Pim Zandbergen <[EMAIL PROTECTED]> wrote: Now: Jesse released a new patch and I tried if for fun on 2.6.22-rc6 It looks like the patch is releasing memory rather than trimming it: [...] Jun 27 12:22:56 corneille kernel: MTRRs don't cover all of memory, trimmed -65536 pages [...] From Jesse's patch: + unsigned long i, base, size, highest_addr = 0, def, dummy; [...] + printk(KERN_WARNING " MTRRs don't cover all of " + "memory, trimmed %ld pages\n", end_pfn - + (highest_addr >> PAGE_SHIFT)); Since both end_pfn (from arch/x86_64/kernel/e820.c) and highest_addr are unsigned long, maybe the problem is just that %ld in the kprintf format string? Shouldn't that be %lu? Mauro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wed, 27 Jun 2007, Pim Zandbergen wrote: Andi Kleen wrote: That's impossible. Either it limited your RAM or it didn't change anything. OK, maybe it's cosmetic, but I would not expect a negative number With old BIOS it printed MTRRs don't cover all of memory, trimmed 196608 pages with new BIOS it prints MTRRs don't cover all of memory, trimmed -65536 pages Pim It works ok for me: [0.00] MTRRs don't cover all of memory, trimmed 16384 pages This is using his latest patch with 2.6.22-rc6. Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Andi Kleen wrote: That's impossible. Either it limited your RAM or it didn't change anything. OK, maybe it's cosmetic, but I would not expect a negative number With old BIOS it printed MTRRs don't cover all of memory, trimmed 196608 pages with new BIOS it prints MTRRs don't cover all of memory, trimmed -65536 pages Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wed, Jun 27, 2007 at 12:44:01PM +0200, Pim Zandbergen wrote: > Jesse saved my life by releasing a patch that made my GigaByte Intel G33 > based motherboard use all of its 8GB RAM and not be slow as hell. That's impossible. Either it limited your RAM or it didn't change anything. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
First: Jesse saved my life by releasing a patch that made my GigaByte Intel G33 based motherboard use all of its 8GB RAM and not be slow as hell. Then: GigaByte released a BIOS update that fixed the root of the problem. I went back from patched vanilla kernel to "official" Fedora kernel. Now: Jesse released a new patch and I tried if for fun on 2.6.22-rc6 It looks like the patch is releasing memory rather than trimming it: Jun 27 12:22:56 corneille kernel: Linux version 2.6.22-rc6 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Wed Jun 27 11:41:29 CEST 2007 Jun 27 12:22:56 corneille kernel: Command line: root=LABEL=/ console=ttyS0,38400 Jun 27 12:22:56 corneille kernel: BIOS-provided physical RAM map: Jun 27 12:22:56 corneille kernel: BIOS-e820: - 0009e800 (usable) Jun 27 12:22:56 corneille kernel: BIOS-e820: 0009f800 - 000a (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: 000f - 0010 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: 0010 - cf5e (usable) Jun 27 12:22:56 corneille kernel: BIOS-e820: cf5e - cf5e3000 (ACPI NVS) Jun 27 12:22:56 corneille kernel: BIOS-e820: cf5e3000 - cf5f (ACPI data) Jun 27 12:22:56 corneille kernel: BIOS-e820: cf5f - cf60 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: d000 - e000 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: fec0 - 0001 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: 0001 - 00023000 (usable) Jun 27 12:22:56 corneille kernel: end_pfn_map = 2293760 Jun 27 12:22:56 corneille kernel: *** Jun 27 12:22:56 corneille kernel: WARNING: likely BIOS bug Jun 27 12:22:56 corneille kernel: MTRRs don't cover all of memory, trimmed -65536 pages Jun 27 12:22:56 corneille kernel: *** I tried the earlier patch as well and it gives the same result. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
First: Jesse saved my life by releasing a patch that made my GigaByte Intel G33 based motherboard use all of its 8GB RAM and not be slow as hell. Then: GigaByte released a BIOS update that fixed the root of the problem. I went back from patched vanilla kernel to official Fedora kernel. Now: Jesse released a new patch and I tried if for fun on 2.6.22-rc6 It looks like the patch is releasing memory rather than trimming it: Jun 27 12:22:56 corneille kernel: Linux version 2.6.22-rc6 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Wed Jun 27 11:41:29 CEST 2007 Jun 27 12:22:56 corneille kernel: Command line: root=LABEL=/ console=ttyS0,38400 Jun 27 12:22:56 corneille kernel: BIOS-provided physical RAM map: Jun 27 12:22:56 corneille kernel: BIOS-e820: - 0009e800 (usable) Jun 27 12:22:56 corneille kernel: BIOS-e820: 0009f800 - 000a (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: 000f - 0010 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: 0010 - cf5e (usable) Jun 27 12:22:56 corneille kernel: BIOS-e820: cf5e - cf5e3000 (ACPI NVS) Jun 27 12:22:56 corneille kernel: BIOS-e820: cf5e3000 - cf5f (ACPI data) Jun 27 12:22:56 corneille kernel: BIOS-e820: cf5f - cf60 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: d000 - e000 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: fec0 - 0001 (reserved) Jun 27 12:22:56 corneille kernel: BIOS-e820: 0001 - 00023000 (usable) Jun 27 12:22:56 corneille kernel: end_pfn_map = 2293760 Jun 27 12:22:56 corneille kernel: *** Jun 27 12:22:56 corneille kernel: WARNING: likely BIOS bug Jun 27 12:22:56 corneille kernel: MTRRs don't cover all of memory, trimmed -65536 pages Jun 27 12:22:56 corneille kernel: *** I tried the earlier patch as well and it gives the same result. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wed, Jun 27, 2007 at 12:44:01PM +0200, Pim Zandbergen wrote: Jesse saved my life by releasing a patch that made my GigaByte Intel G33 based motherboard use all of its 8GB RAM and not be slow as hell. That's impossible. Either it limited your RAM or it didn't change anything. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Andi Kleen wrote: That's impossible. Either it limited your RAM or it didn't change anything. OK, maybe it's cosmetic, but I would not expect a negative number With old BIOS it printed MTRRs don't cover all of memory, trimmed 196608 pages with new BIOS it prints MTRRs don't cover all of memory, trimmed -65536 pages Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wed, 27 Jun 2007, Pim Zandbergen wrote: Andi Kleen wrote: That's impossible. Either it limited your RAM or it didn't change anything. OK, maybe it's cosmetic, but I would not expect a negative number With old BIOS it printed MTRRs don't cover all of memory, trimmed 196608 pages with new BIOS it prints MTRRs don't cover all of memory, trimmed -65536 pages Pim It works ok for me: [0.00] MTRRs don't cover all of memory, trimmed 16384 pages This is using his latest patch with 2.6.22-rc6. Justin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/27/07, Pim Zandbergen [EMAIL PROTECTED] wrote: Now: Jesse released a new patch and I tried if for fun on 2.6.22-rc6 It looks like the patch is releasing memory rather than trimming it: [...] Jun 27 12:22:56 corneille kernel: MTRRs don't cover all of memory, trimmed -65536 pages [...] From Jesse's patch: + unsigned long i, base, size, highest_addr = 0, def, dummy; [...] + printk(KERN_WARNING MTRRs don't cover all of + memory, trimmed %ld pages\n, end_pfn - + (highest_addr PAGE_SHIFT)); Since both end_pfn (from arch/x86_64/kernel/e820.c) and highest_addr are unsigned long, maybe the problem is just that %ld in the kprintf format string? Shouldn't that be %lu? Mauro - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 7:22:24 Mauro Giachero wrote: On 6/27/07, Pim Zandbergen [EMAIL PROTECTED] wrote: Now: Jesse released a new patch and I tried if for fun on 2.6.22-rc6 It looks like the patch is releasing memory rather than trimming it: [...] Jun 27 12:22:56 corneille kernel: MTRRs don't cover all of memory, trimmed -65536 pages [...] From Jesse's patch: + unsigned long i, base, size, highest_addr = 0, def, dummy; [...] + printk(KERN_WARNING MTRRs don't cover all of + memory, trimmed %ld pages\n, end_pfn - + (highest_addr PAGE_SHIFT)); Since both end_pfn (from arch/x86_64/kernel/e820.c) and highest_addr are unsigned long, maybe the problem is just that %ld in the kprintf format string? Shouldn't that be %lu? Yeah, you're right I should use an unsigned format string. Pim, if you change it to %lu does the printk in your dmesg look better? Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: Yeah, you're right I should use an unsigned format string. Pim, if you change it to %lu does the printk in your dmesg look better? Er, no. MTRRs don't cover all of memory, trimmed 18446744073709486080 pages Thanks, Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 9:00:33 Pim Zandbergen wrote: Jesse Barnes wrote: Yeah, you're right I should use an unsigned format string. Pim, if you change it to %lu does the printk in your dmesg look better? Er, no. MTRRs don't cover all of memory, trimmed 18446744073709486080 pages Hm, that's what I was afraid of. So something else is wrong. :) Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 9:00:33 Pim Zandbergen wrote: Jesse Barnes wrote: Yeah, you're right I should use an unsigned format string. Pim, if you change it to %lu does the printk in your dmesg look better? Er, no. MTRRs don't cover all of memory, trimmed 18446744073709486080 pages It looks like end_pfn might be ~0UL now... can you print that out in your configuration? Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote:
It looks like end_pfn might be ~0UL now... can you print that out in
your configuration?
Er, do you need the value of end_pfn ?
Here's what I changed:
if ((highest_addr PAGE_SHIFT) != end_pfn) {
printk(KERN_WARNING ***\n);
printk(KERN_WARNING WARNING: likely BIOS bug\n);
printk(KERN_WARNING MTRRs don't cover all of
memory, trimmed %lu pages\n, end_pfn -
(highest_addr PAGE_SHIFT));
printk(KERN_WARNING end_pfn before = %lu\n, end_pfn);
end_pfn = highest_addr PAGE_SHIFT;
printk(KERN_WARNING end_pfn after = %lu\n, end_pfn);
printk(KERN_WARNING ***\n);
}
Here's the result:
***
WARNING: likely BIOS bug
MTRRs don't cover all of memory, trimmed 18446744073709486080 pages
end_pfn before = 2293760
end_pfn after = 2359296
***
Hope that's what you needed.
Pim
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Wednesday, June 27, 2007 10:02:35 Pim Zandbergen wrote:
Jesse Barnes wrote:
It looks like end_pfn might be ~0UL now... can you print that out
in your configuration?
Er, do you need the value of end_pfn ?
Here's what I changed:
if ((highest_addr PAGE_SHIFT) != end_pfn) {
printk(KERN_WARNING ***\n);
printk(KERN_WARNING WARNING: likely BIOS bug\n);
printk(KERN_WARNING MTRRs don't cover all of
memory, trimmed %lu pages\n, end_pfn -
(highest_addr PAGE_SHIFT));
printk(KERN_WARNING end_pfn before = %lu\n, end_pfn);
end_pfn = highest_addr PAGE_SHIFT;
printk(KERN_WARNING end_pfn after = %lu\n, end_pfn);
printk(KERN_WARNING ***\n);
}
Here's the result:
***
WARNING: likely BIOS bug
MTRRs don't cover all of memory, trimmed 18446744073709486080
pages end_pfn before = 2293760
end_pfn after = 2359296
***
Hope that's what you needed.
Yeah, that's what I needed. end_pfn looks ok, but I guess my test is a
little too precise. It should be if ((highest_addr PAGE_SHIFT)
end_pfn) rather than !=. That should keep it from trying to extend
your memory with bogus math. I thought that the two values should
always match, but I guess slightly different memory configurations
might break that assumption.
Thanks,
Jesse
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: Yeah, that's what I needed. end_pfn looks ok, but I guess my test is a little too precise. It should be if ((highest_addr PAGE_SHIFT) end_pfn) rather than !=. Right. That made the message disappear. Nice to know my BIOS is really fixed. Thanks, Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/26/07, Andi Kleen <[EMAIL PROTECTED]> wrote: RevE had a new memory remapping scheme (memory hoisting) at least, which I think you refered to earlier. There might have been more changes in F. yes, REV E has hardware memory remapping. Rev F you don't need to use mtrr to set MEM to WE above 4G. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tue, Jun 26, 2007 at 10:06:41AM -0600, Eric W. Biederman wrote: > Andi Kleen <[EMAIL PROTECTED]> writes: > > >> For the K7 and K8 cores AMD systems are exactly like Intel systems > >> with respect to MTRRs (although AMD systems also have additional registers) > >> For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there > > > > It's called K8RevE, not K9 > > revF not revE. I think AMD was code-naming that K9 before the socket F > part was released. I didn't think so. > > revE was the last DDR rev of the K8 core. RevE had a new memory remapping scheme (memory hoisting) at least, which I think you refered to earlier. There might have been more changes in F. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Andi Kleen <[EMAIL PROTECTED]> writes: >> For the K7 and K8 cores AMD systems are exactly like Intel systems >> with respect to MTRRs (although AMD systems also have additional registers) >> For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there > > It's called K8RevE, not K9 revF not revE. I think AMD was code-naming that K9 before the socket F part was released. revE was the last DDR rev of the K8 core. >> is an additional mechanism that makes everything above 4G write-back >> cacheable without using any MTRRs. > > ... but not BIOS use this mechanism (often there are BIOS switches > for several MTRR models or it is just the wrong one hardcoded), so Linux > should detect the broken cases. Yes. They are and I have seen at least two motherboards that fit this description. I almost freaked out looking at a system with 16G and only 4G setup to be cached. The painful bit is I have also seen such a system with not all of the lower 4G cached. Which caused some interesting booting issues. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/26/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > For the K7 and K8 cores AMD systems are exactly like Intel systems > with respect to MTRRs (although AMD systems also have additional registers) > For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there It's called K8RevE, not K9 For K8 Rev F and later, if you are using TOM2, cpu will assume the mem between 4G and TOM2 is WB. I think rule could be: scan the var mtrrs to find out if there is any mtrr is used for 4G above is set to WB, if it is true, will use trimming tricks. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
> For the K7 and K8 cores AMD systems are exactly like Intel systems > with respect to MTRRs (although AMD systems also have additional registers) > For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there It's called K8RevE, not K9 > is an additional mechanism that makes everything above 4G write-back > cacheable without using any MTRRs. ... but not BIOS use this mechanism (often there are BIOS switches for several MTRR models or it is just the wrong one hardcoded), so Linux should detect the broken cases. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 26, 2007 8:02:49 am Andi Kleen wrote: > On Mon, Jun 25, 2007 at 04:36:52PM -0700, Jesse Barnes wrote: > > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: > > > > This patch fixes a bug in the last patch that caused the code to > > > > run on non-Intel machines (AMD machines apparently don't need it > > > > > > Actually the problem can happen on AMD too, but the symptoms can > > > be different and there can be more wrong than just the MTRRs. > > > > I should have been more specific in the changelog. My understanding is > > that AMD systems don't need it for memory above 4G, and since the code > > AMD systems need MTRRs to get cached memory too, or what is your point? My point is that yes, this problem can happen on AMD, but the code doesn't handle the problems that AMD systems might have, since it doesn't look for problems in low memory (e.g. if you have an AMD system with 6G of memory, the code will probably trim everything above 4G since it doesn't know about the new AMD mapping stuff from RevE), as Eric pointed out. Both you and Eric say you've seen AMD systems with problems, but handling them would make the code more complex than it is now, and I haven't seen the actual reports (memory maps & MTRR setups) so I can't really fix them anyway. And since this patch solves real problems as-is, it seems like we should push it upstream then rework it, if necessary (i.e. real user machines with this problem) later. What do you think? Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 26, 2007 8:07:45 am Jesse Barnes wrote: > On Tuesday, June 26, 2007 8:03:48 am Andi Kleen wrote: > > On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote: > > > Oh, and FYI I've seen new systems with a default mapping type of WB, > > > with a few uncached holes for MMIO. That means PAT will be absolutely > > > required on those systems if we want to use WC for the framebuffer or > > > other memory. > > > > Why? As long as there are still MTRRs free you could use them for > > WC even in this setup. > > According to the manual, you can't use WC or WT MTRRs on top of a WB MTRR > range. Only UC MTRRs can override WB MTRRs, but PAT doesn't have this > restriction. Actually, it looks like WT on top of WB is ok, but not WC on top of WB, quoting from the manual: > 1. If the physical address falls within the first 1 MByte of physical > memory and fixed MTRRs are enabled, the processor uses the memory type > stored for the appropriate fixed-range MTRR. > > 2. Otherwise, the processor attempts to match the physical address with a > memory type set by the variable-range MTRRs: > > a. If one variable memory range matches, the processor uses the memory >type stored in the IA32_MTRR_PHYSBASEn register for that range. > b. If two or more variable memory ranges match and the memory types are >identical, then that memory type is used. > c. If two or more variable memory ranges match and one of the memory >types is UC, the UC memory type used. > d. If two or more variable memory ranges match and the memory types are >WT and WB, the WT memory type is used. > e. For overlaps not defined by the above rules, processor behavior is >undefined. > > 3. If no fixed or variable memory range matches, the processor uses the > default memory type. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 26, 2007 8:03:48 am Andi Kleen wrote: > On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote: > > Oh, and FYI I've seen new systems with a default mapping type of WB, with > > a few uncached holes for MMIO. That means PAT will be absolutely > > required on those systems if we want to use WC for the framebuffer or > > other memory. > > Why? As long as there are still MTRRs free you could use them for > WC even in this setup. According to the manual, you can't use WC or WT MTRRs on top of a WB MTRR range. Only UC MTRRs can override WB MTRRs, but PAT doesn't have this restriction. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote: > Oh, and FYI I've seen new systems with a default mapping type of WB, with a > few uncached holes for MMIO. That means PAT will be absolutely required on > those systems if we want to use WC for the framebuffer or other memory. Why? As long as there are still MTRRs free you could use them for WC even in this setup. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, Jun 25, 2007 at 04:36:52PM -0700, Jesse Barnes wrote: > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: > > > This patch fixes a bug in the last patch that caused the code to > > > run on non-Intel machines (AMD machines apparently don't need it > > > > Actually the problem can happen on AMD too, but the symptoms can > > be different and there can be more wrong than just the MTRRs. > > I should have been more specific in the changelog. My understanding is > that AMD systems don't need it for memory above 4G, and since the code AMD systems need MTRRs to get cached memory too, or what is your point? There was a new memory remapping feature in RevE but I didn't think it obsoleted MTRRs. We've also had systems with this issue. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, Jun 25, 2007 at 04:36:52PM -0700, Jesse Barnes wrote: On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. I should have been more specific in the changelog. My understanding is that AMD systems don't need it for memory above 4G, and since the code AMD systems need MTRRs to get cached memory too, or what is your point? There was a new memory remapping feature in RevE but I didn't think it obsoleted MTRRs. We've also had systems with this issue. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote: Oh, and FYI I've seen new systems with a default mapping type of WB, with a few uncached holes for MMIO. That means PAT will be absolutely required on those systems if we want to use WC for the framebuffer or other memory. Why? As long as there are still MTRRs free you could use them for WC even in this setup. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 26, 2007 8:03:48 am Andi Kleen wrote: On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote: Oh, and FYI I've seen new systems with a default mapping type of WB, with a few uncached holes for MMIO. That means PAT will be absolutely required on those systems if we want to use WC for the framebuffer or other memory. Why? As long as there are still MTRRs free you could use them for WC even in this setup. According to the manual, you can't use WC or WT MTRRs on top of a WB MTRR range. Only UC MTRRs can override WB MTRRs, but PAT doesn't have this restriction. Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 26, 2007 8:07:45 am Jesse Barnes wrote: On Tuesday, June 26, 2007 8:03:48 am Andi Kleen wrote: On Mon, Jun 25, 2007 at 08:30:52PM -0700, Jesse Barnes wrote: Oh, and FYI I've seen new systems with a default mapping type of WB, with a few uncached holes for MMIO. That means PAT will be absolutely required on those systems if we want to use WC for the framebuffer or other memory. Why? As long as there are still MTRRs free you could use them for WC even in this setup. According to the manual, you can't use WC or WT MTRRs on top of a WB MTRR range. Only UC MTRRs can override WB MTRRs, but PAT doesn't have this restriction. Actually, it looks like WT on top of WB is ok, but not WC on top of WB, quoting from the manual: 1. If the physical address falls within the first 1 MByte of physical memory and fixed MTRRs are enabled, the processor uses the memory type stored for the appropriate fixed-range MTRR. 2. Otherwise, the processor attempts to match the physical address with a memory type set by the variable-range MTRRs: a. If one variable memory range matches, the processor uses the memory type stored in the IA32_MTRR_PHYSBASEn register for that range. b. If two or more variable memory ranges match and the memory types are identical, then that memory type is used. c. If two or more variable memory ranges match and one of the memory types is UC, the UC memory type used. d. If two or more variable memory ranges match and the memory types are WT and WB, the WT memory type is used. e. For overlaps not defined by the above rules, processor behavior is undefined. 3. If no fixed or variable memory range matches, the processor uses the default memory type. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tuesday, June 26, 2007 8:02:49 am Andi Kleen wrote: On Mon, Jun 25, 2007 at 04:36:52PM -0700, Jesse Barnes wrote: On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. I should have been more specific in the changelog. My understanding is that AMD systems don't need it for memory above 4G, and since the code AMD systems need MTRRs to get cached memory too, or what is your point? My point is that yes, this problem can happen on AMD, but the code doesn't handle the problems that AMD systems might have, since it doesn't look for problems in low memory (e.g. if you have an AMD system with 6G of memory, the code will probably trim everything above 4G since it doesn't know about the new AMD mapping stuff from RevE), as Eric pointed out. Both you and Eric say you've seen AMD systems with problems, but handling them would make the code more complex than it is now, and I haven't seen the actual reports (memory maps MTRR setups) so I can't really fix them anyway. And since this patch solves real problems as-is, it seems like we should push it upstream then rework it, if necessary (i.e. real user machines with this problem) later. What do you think? Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there It's called K8RevE, not K9 is an additional mechanism that makes everything above 4G write-back cacheable without using any MTRRs. ... but not BIOS use this mechanism (often there are BIOS switches for several MTRR models or it is just the wrong one hardcoded), so Linux should detect the broken cases. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/26/07, Andi Kleen [EMAIL PROTECTED] wrote: For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there It's called K8RevE, not K9 For K8 Rev F and later, if you are using TOM2, cpu will assume the mem between 4G and TOM2 is WB. I think rule could be: scan the var mtrrs to find out if there is any mtrr is used for 4G above is set to WB, if it is true, will use trimming tricks. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Andi Kleen [EMAIL PROTECTED] writes: For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there It's called K8RevE, not K9 revF not revE. I think AMD was code-naming that K9 before the socket F part was released. revE was the last DDR rev of the K8 core. is an additional mechanism that makes everything above 4G write-back cacheable without using any MTRRs. ... but not BIOS use this mechanism (often there are BIOS switches for several MTRR models or it is just the wrong one hardcoded), so Linux should detect the broken cases. Yes. They are and I have seen at least two motherboards that fit this description. I almost freaked out looking at a system with 16G and only 4G setup to be cached. The painful bit is I have also seen such a system with not all of the lower 4G cached. Which caused some interesting booting issues. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Tue, Jun 26, 2007 at 10:06:41AM -0600, Eric W. Biederman wrote: Andi Kleen [EMAIL PROTECTED] writes: For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there It's called K8RevE, not K9 revF not revE. I think AMD was code-naming that K9 before the socket F part was released. I didn't think so. revE was the last DDR rev of the K8 core. RevE had a new memory remapping scheme (memory hoisting) at least, which I think you refered to earlier. There might have been more changes in F. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/26/07, Andi Kleen [EMAIL PROTECTED] wrote: RevE had a new memory remapping scheme (memory hoisting) at least, which I think you refered to earlier. There might have been more changes in F. yes, REV E has hardware memory remapping. Rev F you don't need to use mtrr to set MEM to WE above 4G. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 8:29:35 pm Jesse Barnes wrote: > Is there an is_cpu() check to differentiate between those? Anyway I'd > rather not enable it unless we see reports though... So far I've only seen > reports of this problem on some recent Intel based systems. Oh, and FYI I've seen new systems with a default mapping type of WB, with a few uncached holes for MMIO. That means PAT will be absolutely required on those systems if we want to use WC for the framebuffer or other memory. I hope it's ready for mainline soon... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 5:54:49 pm Eric W. Biederman wrote: > Jesse Barnes <[EMAIL PROTECTED]> writes: > > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: > >> > This patch fixes a bug in the last patch that caused the code to > >> > run on non-Intel machines (AMD machines apparently don't need it > >> > >> Actually the problem can happen on AMD too, but the symptoms can > >> be different and there can be more wrong than just the MTRRs. > > > > I should have been more specific in the changelog. My understanding is > > that AMD systems don't need it for memory above 4G, and since the code > > doesn't handle holes (no test systems, nor any real reports that I've > > seen), it's not that useful for finding problems below 4G. We can > > always change that later if needed though. > > For the K7 and K8 cores AMD systems are exactly like Intel systems > with respect to MTRRs (although AMD systems also have additional registers) > For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there > is an additional mechanism that makes everything above 4G write-back > cacheable without using any MTRRs. > > So only on the very latest AMD cpus would this code not be applicable. Is there an is_cpu() check to differentiate between those? Anyway I'd rather not enable it unless we see reports though... So far I've only seen reports of this problem on some recent Intel based systems. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes <[EMAIL PROTECTED]> writes: > On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: >> > This patch fixes a bug in the last patch that caused the code to >> > run on non-Intel machines (AMD machines apparently don't need it >> >> Actually the problem can happen on AMD too, but the symptoms can >> be different and there can be more wrong than just the MTRRs. > > I should have been more specific in the changelog. My understanding is > that AMD systems don't need it for memory above 4G, and since the code > doesn't handle holes (no test systems, nor any real reports that I've > seen), it's not that useful for finding problems below 4G. We can > always change that later if needed though. For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there is an additional mechanism that makes everything above 4G write-back cacheable without using any MTRRs. So only on the very latest AMD cpus would this code not be applicable. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: > > This patch fixes a bug in the last patch that caused the code to > > run on non-Intel machines (AMD machines apparently don't need it > > Actually the problem can happen on AMD too, but the symptoms can > be different and there can be more wrong than just the MTRRs. I should have been more specific in the changelog. My understanding is that AMD systems don't need it for memory above 4G, and since the code doesn't handle holes (no test systems, nor any real reports that I've seen), it's not that useful for finding problems below 4G. We can always change that later if needed though. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
> This patch fixes a bug in the last patch that caused the code to > run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, 25 Jun 2007, Jesse Barnes wrote: On Monday, June 25, 2007 3:01:27 Andrew Morton wrote: On Mon, 25 Jun 2007 14:34:42 -0700 Jesse Barnes <[EMAIL PROTECTED]> wrote: akpm -- this one should replace all the mtrr patches currently in your tree. fear, uncertainty, doubt. box:/usr/src/25> grep mtrr series x86_64-mm-bug-in-i386-mtrr-initialization.patch x86-fix-section-mismatch-warnings-in-mtrr.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix-2.patch i386-mtrr-clean-up-usage_table.patch Not all of those, I'm sure. I think you're referring to the final four. I guess if it doesn't compile (again) I'll find out ;) Oops, correct. I forgot you were carrying some MTRR patches not authored by me. :) Yeah, the last four are the ones I meant. Thanks, Jesse Hi Jesse, Tested your patch against 2.6.22-rc6, working good so far! $ uname -r 2.6.22-rc6 Mem: 8039576k total, 1056500k used, 6983076k free, 2420k buffers Swap: 16787768k total,0k used, 16787768k free, 127128k cached Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 3:01:27 Andrew Morton wrote: > On Mon, 25 Jun 2007 14:34:42 -0700 > > Jesse Barnes <[EMAIL PROTECTED]> wrote: > > akpm -- this one should replace all the mtrr patches currently > > in your tree. > > fear, uncertainty, doubt. > > box:/usr/src/25> grep mtrr series > x86_64-mm-bug-in-i386-mtrr-initialization.patch > x86-fix-section-mismatch-warnings-in-mtrr.patch > i386-x86_64-trim-memory-not-covered-by-wb-mtrrs.patch > i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix.patch > i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix-2.patch > i386-mtrr-clean-up-usage_table.patch > > Not all of those, I'm sure. I think you're referring to the final > four. I guess if it doesn't compile (again) I'll find out ;) Oops, correct. I forgot you were carrying some MTRR patches not authored by me. :) Yeah, the last four are the ones I meant. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, 25 Jun 2007 14:34:42 -0700 Jesse Barnes <[EMAIL PROTECTED]> wrote: > akpm -- this one should replace all the mtrr patches currently > in your tree. fear, uncertainty, doubt. box:/usr/src/25> grep mtrr series x86_64-mm-bug-in-i386-mtrr-initialization.patch x86-fix-section-mismatch-warnings-in-mtrr.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix-2.patch i386-mtrr-clean-up-usage_table.patch Not all of those, I'm sure. I think you're referring to the final four. I guess if it doesn't compile (again) I'll find out ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Will try this patch shortly w/ 2.6.22-rc6.
p34:/usr/src/linux-2.6.22-rc6# patch -p1 < ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
patching file arch/i386/kernel/cpu/mtrr/mtrr.h
patching file arch/x86_64/kernel/bugs.c
patching file arch/x86_64/kernel/setup.c
patching file include/asm-x86_64/mtrr.h
p34:/usr/src/linux-2.6.22-rc6#
So far so good.
On Mon, 25 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5d0283c..642db9b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in
the file
See drivers/char/README.epca and
Documentation/digiepca.txt.
+ disable_mtrr_trim [X86-64, Intel only]
+ By default the kernel will trim any uncacheable
+ memory out of your available memory pool based on
+ MTRR settings. This parameter disables that behavior,
+ possibly causing your machine to run very slowly.
+
dmascc= [HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
support available.
Format: [,[,..]]
diff --git a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
index 6d59378..bf70d2d 100644
--- a/arch/i386/kernel/cpu/mtrr/generic.c
+++ b/arch/i386/kernel/cpu/mtrr/generic.c
@@ -13,7 +13,7 @@
#include "mtrr.h"
struct mtrr_state {
- struct mtrr_var_range *var_ranges;
+ struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
mtrr_type fixed_ranges[NUM_FIXED_RANGES];
unsigned char enabled;
unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
struct mtrr_var_range *vrs;
unsigned lo, dummy;
- if (!mtrr_state.var_ranges) {
- mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct
mtrr_var_range),
- GFP_KERNEL);
- if (!mtrr_state.var_ranges)
- return;
- }
vrs = mtrr_state.var_ranges;
rdmsr(MTRRcap_MSR, lo, dummy);
diff --git a/arch/i386/kernel/cpu/mtrr/if.c b/arch/i386/kernel/cpu/mtrr/if.c
index c7d8f17..1b3a09c 100644
--- a/arch/i386/kernel/cpu/mtrr/if.c
+++ b/arch/i386/kernel/cpu/mtrr/if.c
@@ -11,10 +11,6 @@
#include
#include "mtrr.h"
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
#define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
static const char *const mtrr_strings[MTRR_NUM_TYPES] =
@@ -396,7 +392,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
for (i = 0; i < max; i++) {
mtrr_if->get(i, , , );
if (size == 0)
- usage_table[i] = 0;
+ mtrr_usage_table[i] = 0;
else {
if (size < (0x10 >> PAGE_SHIFT)) {
/* less than 1MB */
@@ -410,7 +406,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
len += seq_printf(seq,
"reg%02i: base=0x%05lx000 (%4luMB), size=%4lu%cB:
%s, count=%d\n",
i, base, base >> (20 - PAGE_SHIFT), size, factor,
-mtrr_attrib_to_str(type), usage_table[i]);
+
[PATCH] trim memory not covered by WB MTRRs
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5d0283c..642db9b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in
the file
See drivers/char/README.epca and
Documentation/digiepca.txt.
+ disable_mtrr_trim [X86-64, Intel only]
+ By default the kernel will trim any uncacheable
+ memory out of your available memory pool based on
+ MTRR settings. This parameter disables that behavior,
+ possibly causing your machine to run very slowly.
+
dmascc= [HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
support available.
Format: [,[,..]]
diff --git a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
index 6d59378..bf70d2d 100644
--- a/arch/i386/kernel/cpu/mtrr/generic.c
+++ b/arch/i386/kernel/cpu/mtrr/generic.c
@@ -13,7 +13,7 @@
#include "mtrr.h"
struct mtrr_state {
- struct mtrr_var_range *var_ranges;
+ struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
mtrr_type fixed_ranges[NUM_FIXED_RANGES];
unsigned char enabled;
unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
struct mtrr_var_range *vrs;
unsigned lo, dummy;
- if (!mtrr_state.var_ranges) {
- mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct
mtrr_var_range),
- GFP_KERNEL);
- if (!mtrr_state.var_ranges)
- return;
- }
vrs = mtrr_state.var_ranges;
rdmsr(MTRRcap_MSR, lo, dummy);
diff --git a/arch/i386/kernel/cpu/mtrr/if.c b/arch/i386/kernel/cpu/mtrr/if.c
index c7d8f17..1b3a09c 100644
--- a/arch/i386/kernel/cpu/mtrr/if.c
+++ b/arch/i386/kernel/cpu/mtrr/if.c
@@ -11,10 +11,6 @@
#include
#include "mtrr.h"
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
#define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
static const char *const mtrr_strings[MTRR_NUM_TYPES] =
@@ -396,7 +392,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
for (i = 0; i < max; i++) {
mtrr_if->get(i, , , );
if (size == 0)
- usage_table[i] = 0;
+ mtrr_usage_table[i] = 0;
else {
if (size < (0x10 >> PAGE_SHIFT)) {
/* less than 1MB */
@@ -410,7 +406,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
len += seq_printf(seq,
"reg%02i: base=0x%05lx000 (%4luMB),
size=%4lu%cB: %s, count=%d\n",
i, base, base >> (20 - PAGE_SHIFT), size, factor,
-mtrr_attrib_to_str(type), usage_table[i]);
+mtrr_attrib_to_str(type), mtrr_usage_table[i]);
}
}
return 0;
diff --git a/arch/i386/kernel/cpu/mtrr/main.c b/arch/i386/kernel/cpu/mtrr/main.c
index 55b0051..0e4be8b 100644
--- a/arch/i386/kernel/cpu/mtrr/main.c
+++ b/arch/i386/kernel/cpu/mtrr/main.c
@@ -38,8 +38,8 @@
#include
#include
+#include
#include
-
#include
#include
#include
@@ -47,7 +47,7 @@
u32 num_var_ranges = 0;
-unsigned int *usage_table;
+unsigned int mtrr_usage_table[MAX_VAR_RANGES];
static
Re: [PATCH] trim memory not covered by WB MTRRs
Impressive. Jesse, can you touch base with Intel's BIOS department? Also, what are the chances of that patch making it into 2.6.22-rc6/7 if it hasn't already? On Mon, 25 Jun 2007, Pim Zandbergen wrote: Pim Zandbergen wrote I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. It is now, and it is described as "Fix Vista boot lag with 8GB memory issue" ... Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Pim Zandbergen wrote I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. It is now, and it is described as "Fix Vista boot lag with 8GB memory issue" ... Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Pim Zandbergen wrote I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. It is now, and it is described as Fix Vista boot lag with 8GB memory issue ... Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Impressive. Jesse, can you touch base with Intel's BIOS department? Also, what are the chances of that patch making it into 2.6.22-rc6/7 if it hasn't already? On Mon, 25 Jun 2007, Pim Zandbergen wrote: Pim Zandbergen wrote I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. It is now, and it is described as Fix Vista boot lag with 8GB memory issue ... Pim - 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/
[PATCH] trim memory not covered by WB MTRRs
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5d0283c..642db9b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in
the file
See drivers/char/README.epca and
Documentation/digiepca.txt.
+ disable_mtrr_trim [X86-64, Intel only]
+ By default the kernel will trim any uncacheable
+ memory out of your available memory pool based on
+ MTRR settings. This parameter disables that behavior,
+ possibly causing your machine to run very slowly.
+
dmascc= [HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
support available.
Format: io_dev0[,io_dev1[,..io_dev32]]
diff --git a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
index 6d59378..bf70d2d 100644
--- a/arch/i386/kernel/cpu/mtrr/generic.c
+++ b/arch/i386/kernel/cpu/mtrr/generic.c
@@ -13,7 +13,7 @@
#include mtrr.h
struct mtrr_state {
- struct mtrr_var_range *var_ranges;
+ struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
mtrr_type fixed_ranges[NUM_FIXED_RANGES];
unsigned char enabled;
unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
struct mtrr_var_range *vrs;
unsigned lo, dummy;
- if (!mtrr_state.var_ranges) {
- mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct
mtrr_var_range),
- GFP_KERNEL);
- if (!mtrr_state.var_ranges)
- return;
- }
vrs = mtrr_state.var_ranges;
rdmsr(MTRRcap_MSR, lo, dummy);
diff --git a/arch/i386/kernel/cpu/mtrr/if.c b/arch/i386/kernel/cpu/mtrr/if.c
index c7d8f17..1b3a09c 100644
--- a/arch/i386/kernel/cpu/mtrr/if.c
+++ b/arch/i386/kernel/cpu/mtrr/if.c
@@ -11,10 +11,6 @@
#include asm/mtrr.h
#include mtrr.h
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
#define FILE_FCOUNT(f) (((struct seq_file *)((f)-private_data))-private)
static const char *const mtrr_strings[MTRR_NUM_TYPES] =
@@ -396,7 +392,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
for (i = 0; i max; i++) {
mtrr_if-get(i, base, size, type);
if (size == 0)
- usage_table[i] = 0;
+ mtrr_usage_table[i] = 0;
else {
if (size (0x10 PAGE_SHIFT)) {
/* less than 1MB */
@@ -410,7 +406,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
len += seq_printf(seq,
reg%02i: base=0x%05lx000 (%4luMB),
size=%4lu%cB: %s, count=%d\n,
i, base, base (20 - PAGE_SHIFT), size, factor,
-mtrr_attrib_to_str(type), usage_table[i]);
+mtrr_attrib_to_str(type), mtrr_usage_table[i]);
}
}
return 0;
diff --git a/arch/i386/kernel/cpu/mtrr/main.c b/arch/i386/kernel/cpu/mtrr/main.c
index 55b0051..0e4be8b 100644
--- a/arch/i386/kernel/cpu/mtrr/main.c
+++ b/arch/i386/kernel/cpu/mtrr/main.c
@@ -38,8 +38,8 @@
#include linux/cpu.h
#include linux/mutex.h
+#include asm/e820.h
#include asm/mtrr.h
-
#include asm/uaccess.h
#include asm/processor.h
#include asm/msr.h
@@ -47,7 +47,7 @@
u32
Re: [PATCH] trim memory not covered by WB MTRRs
Will try this patch shortly w/ 2.6.22-rc6.
p34:/usr/src/linux-2.6.22-rc6# patch -p1 ../mtrr-v3.patch
patching file Documentation/kernel-parameters.txt
patching file arch/i386/kernel/cpu/mtrr/generic.c
patching file arch/i386/kernel/cpu/mtrr/if.c
patching file arch/i386/kernel/cpu/mtrr/main.c
patching file arch/i386/kernel/cpu/mtrr/mtrr.h
patching file arch/x86_64/kernel/bugs.c
patching file arch/x86_64/kernel/setup.c
patching file include/asm-x86_64/mtrr.h
p34:/usr/src/linux-2.6.22-rc6#
So far so good.
On Mon, 25 Jun 2007, Jesse Barnes wrote:
On some machines, buggy BIOSes don't properly setup WB MTRRs to
cover all available RAM, meaning the last few megs (or even gigs)
of memory will be marked uncached. Since Linux tends to allocate
from high memory addresses first, this causes the machine to be
unusably slow as soon as the kernel starts really using memory
(i.e. right around init time).
This patch works around the problem by scanning the MTRRs at
boot and figuring out whether the current end_pfn value (setup
by early e820 code) goes beyond the highest WB MTRR range, and
if so, trimming it to match. A fairly obnoxious KERN_WARNING
is printed too, letting the user know that not all of their
memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot
ordering would be slightly different, since the MTRR code on i386
depends on the boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to
run on non-Intel machines (AMD machines apparently don't need it
and it's untested on other non-Intel machines, so best keep it
off).
akpm -- this one should replace all the mtrr patches currently
in your tree.
Yinghai, maybe you can test this on one of your AMD machines to
make sure I got the CPU code right?
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
Thanks,
Jesse
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5d0283c..642db9b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -553,6 +553,12 @@ and is between 256 and 4096 characters. It is defined in
the file
See drivers/char/README.epca and
Documentation/digiepca.txt.
+ disable_mtrr_trim [X86-64, Intel only]
+ By default the kernel will trim any uncacheable
+ memory out of your available memory pool based on
+ MTRR settings. This parameter disables that behavior,
+ possibly causing your machine to run very slowly.
+
dmascc= [HW,AX25,SERIAL] AX.25 Z80SCC driver with DMA
support available.
Format: io_dev0[,io_dev1[,..io_dev32]]
diff --git a/arch/i386/kernel/cpu/mtrr/generic.c
b/arch/i386/kernel/cpu/mtrr/generic.c
index 6d59378..bf70d2d 100644
--- a/arch/i386/kernel/cpu/mtrr/generic.c
+++ b/arch/i386/kernel/cpu/mtrr/generic.c
@@ -13,7 +13,7 @@
#include mtrr.h
struct mtrr_state {
- struct mtrr_var_range *var_ranges;
+ struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
mtrr_type fixed_ranges[NUM_FIXED_RANGES];
unsigned char enabled;
unsigned char have_fixed;
@@ -84,12 +84,6 @@ void get_mtrr_state(void)
struct mtrr_var_range *vrs;
unsigned lo, dummy;
- if (!mtrr_state.var_ranges) {
- mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct
mtrr_var_range),
- GFP_KERNEL);
- if (!mtrr_state.var_ranges)
- return;
- }
vrs = mtrr_state.var_ranges;
rdmsr(MTRRcap_MSR, lo, dummy);
diff --git a/arch/i386/kernel/cpu/mtrr/if.c b/arch/i386/kernel/cpu/mtrr/if.c
index c7d8f17..1b3a09c 100644
--- a/arch/i386/kernel/cpu/mtrr/if.c
+++ b/arch/i386/kernel/cpu/mtrr/if.c
@@ -11,10 +11,6 @@
#include asm/mtrr.h
#include mtrr.h
-/* RED-PEN: this is accessed without any locking */
-extern unsigned int *usage_table;
-
-
#define FILE_FCOUNT(f) (((struct seq_file *)((f)-private_data))-private)
static const char *const mtrr_strings[MTRR_NUM_TYPES] =
@@ -396,7 +392,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
for (i = 0; i max; i++) {
mtrr_if-get(i, base, size, type);
if (size == 0)
- usage_table[i] = 0;
+ mtrr_usage_table[i] = 0;
else {
if (size (0x10 PAGE_SHIFT)) {
/* less than 1MB */
@@ -410,7 +406,7 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
len += seq_printf(seq,
reg%02i: base=0x%05lx000 (%4luMB), size=%4lu%cB:
%s, count=%d\n,
i, base, base (20 - PAGE_SHIFT), size, factor,
-
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, 25 Jun 2007 14:34:42 -0700 Jesse Barnes [EMAIL PROTECTED] wrote: akpm -- this one should replace all the mtrr patches currently in your tree. fear, uncertainty, doubt. box:/usr/src/25 grep mtrr series x86_64-mm-bug-in-i386-mtrr-initialization.patch x86-fix-section-mismatch-warnings-in-mtrr.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix-2.patch i386-mtrr-clean-up-usage_table.patch Not all of those, I'm sure. I think you're referring to the final four. I guess if it doesn't compile (again) I'll find out ;) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 3:01:27 Andrew Morton wrote: On Mon, 25 Jun 2007 14:34:42 -0700 Jesse Barnes [EMAIL PROTECTED] wrote: akpm -- this one should replace all the mtrr patches currently in your tree. fear, uncertainty, doubt. box:/usr/src/25 grep mtrr series x86_64-mm-bug-in-i386-mtrr-initialization.patch x86-fix-section-mismatch-warnings-in-mtrr.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix-2.patch i386-mtrr-clean-up-usage_table.patch Not all of those, I'm sure. I think you're referring to the final four. I guess if it doesn't compile (again) I'll find out ;) Oops, correct. I forgot you were carrying some MTRR patches not authored by me. :) Yeah, the last four are the ones I meant. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Mon, 25 Jun 2007, Jesse Barnes wrote: On Monday, June 25, 2007 3:01:27 Andrew Morton wrote: On Mon, 25 Jun 2007 14:34:42 -0700 Jesse Barnes [EMAIL PROTECTED] wrote: akpm -- this one should replace all the mtrr patches currently in your tree. fear, uncertainty, doubt. box:/usr/src/25 grep mtrr series x86_64-mm-bug-in-i386-mtrr-initialization.patch x86-fix-section-mismatch-warnings-in-mtrr.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix.patch i386-x86_64-trim-memory-not-covered-by-wb-mtrrs-fix-2.patch i386-mtrr-clean-up-usage_table.patch Not all of those, I'm sure. I think you're referring to the final four. I guess if it doesn't compile (again) I'll find out ;) Oops, correct. I forgot you were carrying some MTRR patches not authored by me. :) Yeah, the last four are the ones I meant. Thanks, Jesse Hi Jesse, Tested your patch against 2.6.22-rc6, working good so far! $ uname -r 2.6.22-rc6 Mem: 8039576k total, 1056500k used, 6983076k free, 2420k buffers Swap: 16787768k total,0k used, 16787768k free, 127128k cached Justin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. I should have been more specific in the changelog. My understanding is that AMD systems don't need it for memory above 4G, and since the code doesn't handle holes (no test systems, nor any real reports that I've seen), it's not that useful for finding problems below 4G. We can always change that later if needed though. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes [EMAIL PROTECTED] writes: On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. I should have been more specific in the changelog. My understanding is that AMD systems don't need it for memory above 4G, and since the code doesn't handle holes (no test systems, nor any real reports that I've seen), it's not that useful for finding problems below 4G. We can always change that later if needed though. For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there is an additional mechanism that makes everything above 4G write-back cacheable without using any MTRRs. So only on the very latest AMD cpus would this code not be applicable. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 5:54:49 pm Eric W. Biederman wrote: Jesse Barnes [EMAIL PROTECTED] writes: On Monday, June 25, 2007 4:34:33 Andi Kleen wrote: This patch fixes a bug in the last patch that caused the code to run on non-Intel machines (AMD machines apparently don't need it Actually the problem can happen on AMD too, but the symptoms can be different and there can be more wrong than just the MTRRs. I should have been more specific in the changelog. My understanding is that AMD systems don't need it for memory above 4G, and since the code doesn't handle holes (no test systems, nor any real reports that I've seen), it's not that useful for finding problems below 4G. We can always change that later if needed though. For the K7 and K8 cores AMD systems are exactly like Intel systems with respect to MTRRs (although AMD systems also have additional registers) For the K9 core (i.e. AMD socket F or the K8 with DDR2 support) there is an additional mechanism that makes everything above 4G write-back cacheable without using any MTRRs. So only on the very latest AMD cpus would this code not be applicable. Is there an is_cpu() check to differentiate between those? Anyway I'd rather not enable it unless we see reports though... So far I've only seen reports of this problem on some recent Intel based systems. Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Monday, June 25, 2007 8:29:35 pm Jesse Barnes wrote: Is there an is_cpu() check to differentiate between those? Anyway I'd rather not enable it unless we see reports though... So far I've only seen reports of this problem on some recent Intel based systems. Oh, and FYI I've seen new systems with a default mapping type of WB, with a few uncached holes for MMIO. That means PAT will be absolutely required on those systems if we want to use WC for the framebuffer or other memory. I hope it's ready for mainline soon... Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thursday, June 21, 2007 12:40:58 Yinghai Lu wrote: > On 6/7/07, Jesse Barnes <[EMAIL PROTECTED]> wrote: > > On some machines, buggy BIOSes don't properly setup WB MTRRs to > > cover all available RAM, meaning the last few megs (or even gigs) > > of memory will be marked uncached. Since Linux tends to allocate > > from high memory addresses first, this causes the machine to be > > unusably slow as soon as the kernel starts really using memory > > (i.e. right around init time). > > > > This patch works around the problem by scanning the MTRRs at > > boot and figuring out whether the current end_pfn value (setup > > by early e820 code) goes beyond the highest WB MTRR range, and > > if so, trimming it to match. A fairly obnoxious KERN_WARNING > > is printed too, letting the user know that not all of their > > memory is available due to a likely BIOS bug. > > > > Something similar could be done on i386 if needed, but the boot > > ordering would be slightly different, since the MTRR code on i386 > > depends on the boot_cpu_data structure being setup. > > > > This patch incorporates the feedback from Eric and Andi: > > - use MAX_VAR_RANGES instead of NUM_VAR_RANGES > > - move array declaration to header file as an extern > > - add command line disable option "disable_mtrr_trim" > > - don't run the trim code if the MTRR default type is cacheable > > - don't run the trim code on non-Intel machines > > > > Justin, feel free to test again if you have time and add your > > "Tested-by" signoff. > > > > Andi, as for large pages, do you think this is ok as is, or should > > I trim a larger granularity? If so, what granularity? > > > > Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]> > > > > Thanks, > > Jesse > > NAK. > > for AMD Rev F Opteron later CPU, BIOS will not set WB in MTRR for 4G > above mem. > > This patch will get rid of those RAM. Yeah, Eric already mentioned that. I'll rework it to only run on Intel CPUs per Eric's last mail. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/7/07, Jesse Barnes <[EMAIL PROTECTED]> wrote: On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time). This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug. Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup. This patch incorporates the feedback from Eric and Andi: - use MAX_VAR_RANGES instead of NUM_VAR_RANGES - move array declaration to header file as an extern - add command line disable option "disable_mtrr_trim" - don't run the trim code if the MTRR default type is cacheable - don't run the trim code on non-Intel machines Justin, feel free to test again if you have time and add your "Tested-by" signoff. Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity? Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]> Thanks, Jesse NAK. for AMD Rev F Opteron later CPU, BIOS will not set WB in MTRR for 4G above mem. This patch will get rid of those RAM. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thu, 21 Jun 2007, Pim Zandbergen wrote: Jesse Barnes wrote: What, are you going to report this to GigaByte? No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though... I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. Wow, totally the opposite from Intel. Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: What, are you going to report this to GigaByte? No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though... I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: What, are you going to report this to GigaByte? No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though... I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thu, 21 Jun 2007, Pim Zandbergen wrote: Jesse Barnes wrote: What, are you going to report this to GigaByte? No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though... I reported this to GigaByte, and lo and behold, they sent me a fixed BIOS within 48 hours. Kudos to Taipeh! They sent the BIOS image in a private message, so it might take a while before it's available on their website. Wow, totally the opposite from Intel. Justin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On 6/7/07, Jesse Barnes [EMAIL PROTECTED] wrote: On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time). This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug. Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup. This patch incorporates the feedback from Eric and Andi: - use MAX_VAR_RANGES instead of NUM_VAR_RANGES - move array declaration to header file as an extern - add command line disable option disable_mtrr_trim - don't run the trim code if the MTRR default type is cacheable - don't run the trim code on non-Intel machines Justin, feel free to test again if you have time and add your Tested-by signoff. Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity? Signed-off-by: Jesse Barnes [EMAIL PROTECTED] Thanks, Jesse NAK. for AMD Rev F Opteron later CPU, BIOS will not set WB in MTRR for 4G above mem. This patch will get rid of those RAM. YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thursday, June 21, 2007 12:40:58 Yinghai Lu wrote: On 6/7/07, Jesse Barnes [EMAIL PROTECTED] wrote: On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time). This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug. Something similar could be done on i386 if needed, but the boot ordering would be slightly different, since the MTRR code on i386 depends on the boot_cpu_data structure being setup. This patch incorporates the feedback from Eric and Andi: - use MAX_VAR_RANGES instead of NUM_VAR_RANGES - move array declaration to header file as an extern - add command line disable option disable_mtrr_trim - don't run the trim code if the MTRR default type is cacheable - don't run the trim code on non-Intel machines Justin, feel free to test again if you have time and add your Tested-by signoff. Andi, as for large pages, do you think this is ok as is, or should I trim a larger granularity? If so, what granularity? Signed-off-by: Jesse Barnes [EMAIL PROTECTED] Thanks, Jesse NAK. for AMD Rev F Opteron later CPU, BIOS will not set WB in MTRR for 4G above mem. This patch will get rid of those RAM. Yeah, Eric already mentioned that. I'll rework it to only run on Intel CPUs per Eric's last mail. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
> I assume this cannot be fixed by the simple approach > of echoing some useful numbers into /proc/mtrr like > we used to do for video memory? (Before X did this > automatically?) > > An extra bootscript seems better than loosing memory. In some cases it probably can, in other cases not because the memory controller is misconfigured or not the right bits are set in the PCI bridges to enable DAC IO or ... or ... There are also definite limits on how much quirks can do to fix this -- Linux is a generic kernel, not a BIOS replacement, and can never be as intimate with the current setup as the BIOS is. It's definitely far safer to not use the memory. You're running in a situation never tested or considered by the motherboard vendor and everything is possible. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: On Friday, June 15, 2007 3:17:11 Pim Zandbergen wrote: Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. I *think* the latest trees support that chip. If you're feeling brave, checkout the latest version of the xf86-video-intel driver from freedesktop.org and give it a try As it happens, the Fedora guys just released a new Intel xorg driver RPM that supports the G33. It works. (to get 3d you'll also need newer DRM and AGP bits). No 3D indeed. The newer DRM and AGP bits probably go into the kernel. But hey, it's a server. I've got another machine with the exact same hardware running Windows 2003. No video driver support there at all. Thanks, Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time). This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug. I assume this cannot be fixed by the simple approach of echoing some useful numbers into /proc/mtrr like we used to do for video memory? (Before X did this automatically?) An extra bootscript seems better than loosing memory. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all available RAM, meaning the last few megs (or even gigs) of memory will be marked uncached. Since Linux tends to allocate from high memory addresses first, this causes the machine to be unusably slow as soon as the kernel starts really using memory (i.e. right around init time). This patch works around the problem by scanning the MTRRs at boot and figuring out whether the current end_pfn value (setup by early e820 code) goes beyond the highest WB MTRR range, and if so, trimming it to match. A fairly obnoxious KERN_WARNING is printed too, letting the user know that not all of their memory is available due to a likely BIOS bug. I assume this cannot be fixed by the simple approach of echoing some useful numbers into /proc/mtrr like we used to do for video memory? (Before X did this automatically?) An extra bootscript seems better than loosing memory. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: On Friday, June 15, 2007 3:17:11 Pim Zandbergen wrote: Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. I *think* the latest trees support that chip. If you're feeling brave, checkout the latest version of the xf86-video-intel driver from freedesktop.org and give it a try As it happens, the Fedora guys just released a new Intel xorg driver RPM that supports the G33. It works. (to get 3d you'll also need newer DRM and AGP bits). No 3D indeed. The newer DRM and AGP bits probably go into the kernel. But hey, it's a server. I've got another machine with the exact same hardware running Windows 2003. No video driver support there at all. Thanks, Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
I assume this cannot be fixed by the simple approach of echoing some useful numbers into /proc/mtrr like we used to do for video memory? (Before X did this automatically?) An extra bootscript seems better than loosing memory. In some cases it probably can, in other cases not because the memory controller is misconfigured or not the right bits are set in the PCI bridges to enable DAC IO or ... or ... There are also definite limits on how much quirks can do to fix this -- Linux is a generic kernel, not a BIOS replacement, and can never be as intimate with the current setup as the BIOS is. It's definitely far safer to not use the memory. You're running in a situation never tested or considered by the motherboard vendor and everything is possible. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Friday, June 15, 2007 3:17:11 Pim Zandbergen wrote: > Not that it matters much, as the current i810/intel xorg driver does > not yet support the GMA3100, so I'm using the vesa driver. I *think* the latest trees support that chip. If you're feeling brave, checkout the latest version of the xf86-video-intel driver from freedesktop.org and give it a try (to get 3d you'll also need newer DRM and AGP bits). Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Friday, June 15, 2007 3:21:17 Pim Zandbergen wrote: > Jesse Barnes wrote: > > Thanks for testing, Pim. Glad it works for you. > > The pleasure was all on my side. > > > Keep an eye out for BIOS upgrades, the next version might fix it. > > What, are you going to report this to GigaByte? No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Fri, 15 Jun 2007, Pim Zandbergen wrote: Justin Piszcz wrote: That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top: Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers Me: Mem: 7416672k total, 378988k used, 7037684k free,13592k buffers What type of memory are you using 2x Kingston KVR667D2N5K2/4G and what is your DVT set to? GigaByte's BIOS config options of the onboard graphics controller are very limited compared to those on your Intel motherboard. I can only choose the graphics buffer size, between "1MB+1~2MB for GTT" or "8MB+1~2MB for GTT". I chose the latter. The POST says 9MB are taken for video. Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. Thanks, Pim I use the exact same memory model. So it must be the difference in BIOS MTRR/E820 memory mappings. Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: Thanks for testing, Pim. Glad it works for you. The pleasure was all on my side. Keep an eye out for BIOS upgrades, the next version might fix it. What, are you going to report this to GigaByte? Thanks, Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Justin Piszcz wrote: That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top: Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers Me: Mem: 7416672k total, 378988k used, 7037684k free,13592k buffers What type of memory are you using 2x Kingston KVR667D2N5K2/4G and what is your DVT set to? GigaByte's BIOS config options of the onboard graphics controller are very limited compared to those on your Intel motherboard. I can only choose the graphics buffer size, between "1MB+1~2MB for GTT" or "8MB+1~2MB for GTT". I chose the latter. The POST says 9MB are taken for video. Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. Thanks, Pim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Justin Piszcz wrote: That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top: Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers Me: Mem: 7416672k total, 378988k used, 7037684k free,13592k buffers What type of memory are you using 2x Kingston KVR667D2N5K2/4G and what is your DVT set to? GigaByte's BIOS config options of the onboard graphics controller are very limited compared to those on your Intel motherboard. I can only choose the graphics buffer size, between 1MB+1~2MB for GTT or 8MB+1~2MB for GTT. I chose the latter. The POST says 9MB are taken for video. Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. Thanks, Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
Jesse Barnes wrote: Thanks for testing, Pim. Glad it works for you. The pleasure was all on my side. Keep an eye out for BIOS upgrades, the next version might fix it. What, are you going to report this to GigaByte? Thanks, Pim - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Fri, 15 Jun 2007, Pim Zandbergen wrote: Justin Piszcz wrote: That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top: Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers Me: Mem: 7416672k total, 378988k used, 7037684k free,13592k buffers What type of memory are you using 2x Kingston KVR667D2N5K2/4G and what is your DVT set to? GigaByte's BIOS config options of the onboard graphics controller are very limited compared to those on your Intel motherboard. I can only choose the graphics buffer size, between 1MB+1~2MB for GTT or 8MB+1~2MB for GTT. I chose the latter. The POST says 9MB are taken for video. Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. Thanks, Pim I use the exact same memory model. So it must be the difference in BIOS MTRR/E820 memory mappings. Justin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Friday, June 15, 2007 3:21:17 Pim Zandbergen wrote: Jesse Barnes wrote: Thanks for testing, Pim. Glad it works for you. The pleasure was all on my side. Keep an eye out for BIOS upgrades, the next version might fix it. What, are you going to report this to GigaByte? No, but you should if you haven't already. I think GigaByte probably gets its BIOS from another BIOS vendor (maybe Intel), so when that vendor provides them with an update, they'll probably provide it on their website. And from what I understand, an Intel BIOS update is in the works to address this issue for Intel boards, so a GigaByte version may follow shortly. I don't have an exact timeframe though... Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Friday, June 15, 2007 3:17:11 Pim Zandbergen wrote: Not that it matters much, as the current i810/intel xorg driver does not yet support the GMA3100, so I'm using the vesa driver. I *think* the latest trees support that chip. If you're feeling brave, checkout the latest version of the xf86-video-intel driver from freedesktop.org and give it a try (to get 3d you'll also need newer DRM and AGP bits). Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thursday, June 14, 2007 2:21:16 Justin Piszcz wrote: > To Intel, > > When will HECI be supported via the kernel? When it becomes > supported, would that alter the MTRR map at all? I *think* HECI is related to our IT remote management stuff, but I don't work on it. It *may* affect the MTRR mappings, but I think it's just a PCI device, so I don't think enabling it will change the MTRR layout. Arjan, do you know who's doing our AMT stuff? Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thu, 14 Jun 2007, Jesse Barnes wrote: On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote: On Thu, 14 Jun 2007, Pim Zandbergen wrote: Thanks for this patch. I was having the exact same symptoms as Justin Piszcz, on a different, but similar motherboard: Motherboard: GigaByte GA-G33-DS3R BIOS rev: F2 Chipset: Intel G33 Memory: 8GB Distro: Fedora 7 x86_64 Kernel: kernel-2.6.21-1.3194.fc7 Building vanilla 2.6.22-rc4 with your patch solved the problem. I'm now seeing this in the syslog *** WARNING: likely BIOS bug MTRRs don't cover all of memory, trimmed 196608 pages *** leaving me 7416672 kB of usable memory. If there's any way I can help with more info or testing, then let me know. Thanks, Pim Thanks for testing, Pim. Glad it works for you. Keep an eye out for BIOS upgrades, the next version might fix it. That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top: Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers What type of memory are you using and what is your DVT set to? Different BIOSes will map things differently, so I'd expect differences in the "trimmmed xxx pages" message across machines. But yeah, BIOS config options can also affect things, in particular I've heard that the fan control options change MTRR setup significantly. Jesse To Intel, When will HECI be supported via the kernel? When it becomes supported, would that alter the MTRR map at all? Justin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thursday, June 14, 2007 1:26:07 Justin Piszcz wrote: > On Thu, 14 Jun 2007, Pim Zandbergen wrote: > > Thanks for this patch. I was having the exact same symptoms as > > Justin Piszcz, on a different, but similar motherboard: > > > > Motherboard: GigaByte GA-G33-DS3R > > BIOS rev: F2 > > Chipset: Intel G33 > > Memory: 8GB > > Distro: Fedora 7 x86_64 > > Kernel: kernel-2.6.21-1.3194.fc7 > > > > Building vanilla 2.6.22-rc4 with your patch solved the problem. > > > > I'm now seeing this in the syslog > > > > *** > > WARNING: likely BIOS bug > > MTRRs don't cover all of memory, trimmed 196608 pages > > *** > > > > leaving me 7416672 kB of usable memory. > > > > If there's any way I can help with more info or testing, > > then let me know. > > > > Thanks, > > Pim Thanks for testing, Pim. Glad it works for you. Keep an eye out for BIOS upgrades, the next version might fix it. > That's strange, I guess different chipsets 'chew' up different > amounts of memory OR you have your DVT(?) (video-card > memory/aperature) set to 256MB? I have mine set to 128MB, in top: > > Mem: 8039576k total, 6187304k used, 1852272k free, 696k > buffers > > What type of memory are you using and what is your DVT set to? Different BIOSes will map things differently, so I'd expect differences in the "trimmmed xxx pages" message across machines. But yeah, BIOS config options can also affect things, in particular I've heard that the fan control options change MTRR setup significantly. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trim memory not covered by WB MTRRs
On Thu, 14 Jun 2007, Pim Zandbergen wrote: Thanks for this patch. I was having the exact same symptoms as Justin Piszcz, on a different, but similar motherboard: Motherboard: GigaByte GA-G33-DS3R BIOS rev: F2 Chipset: Intel G33 Memory: 8GB Distro: Fedora 7 x86_64 Kernel: kernel-2.6.21-1.3194.fc7 Building vanilla 2.6.22-rc4 with your patch solved the problem. I'm now seeing this in the syslog *** WARNING: likely BIOS bug MTRRs don't cover all of memory, trimmed 196608 pages *** leaving me 7416672 kB of usable memory. If there's any way I can help with more info or testing, then let me know. Thanks, Pim That's strange, I guess different chipsets 'chew' up different amounts of memory OR you have your DVT(?) (video-card memory/aperature) set to 256MB? I have mine set to 128MB, in top: Mem: 8039576k total, 6187304k used, 1852272k free, 696k buffers What type of memory are you using and what is your DVT set to? Justin. - 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/
