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
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
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
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
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
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) {
>
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");
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
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
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
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
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
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
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
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
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:
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:
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
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
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
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
[...]
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
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
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
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
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
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) {
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
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
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
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
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 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
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
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.
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
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.
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 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,
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?
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
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
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
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
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
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.
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
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
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
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
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
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
> 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
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.
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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,
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
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
> 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
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
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
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
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
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
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
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,
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,
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
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:
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:
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
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,
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
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
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
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
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
> >
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:
1 - 100 of 232 matches
Mail list logo
