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 ma
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
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 unsubscr
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");
printk(KERN_WARNI
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 18446744073709486
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 18446744073709486
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 12:22:
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
w
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 a
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 uns
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:
Je
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 sock
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 appa
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. T
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
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 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
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 sys
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
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 sympto
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 wron
> 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 lis
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
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
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-warnin
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
pa
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 sta
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 fi
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
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 te
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, the
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.
> 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 t
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 t
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
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 xf8
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
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, 185
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 "unsubscri
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: 74166
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 ma
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-DS3
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:
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
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 pat
Jesse Barnes <[EMAIL PROTECTED]> writes:
> On Tuesday, June 12, 2007 6:11:21 Eric W. Biederman wrote:
>> Jesse Barnes <[EMAIL PROTECTED]> writes:
>> > 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 memo
On Wed, Jun 13, 2007 at 08:52:23AM +0200, Bodo Eggert wrote:
> 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 Linu
Hi!
> >> Panicking when it's not necessary is anti-social. If the kernel can
> >> continue, then it should, unless it's a correctness issue that may
> >> cause data corruption. Given that the kernel can even work around the
> >> problem now, throwing a panic is even less warranted.
> >
> >Printk("
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 mach
On Tuesday, June 12, 2007 6:11:21 Eric W. Biederman wrote:
> Jesse Barnes <[EMAIL PROTECTED]> writes:
> > 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 t
Jesse Barnes <[EMAIL PROTECTED]> writes:
> 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 mac
On 6/12/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
On Tue 2007-06-12 14:38:28, Ray Lee wrote:
> Panicking when it's not necessary is anti-social. If the kernel can
> continue, then it should, unless it's a correctness issue that may
> cause data corruption. Given that the kernel can even work ar
On Tue 2007-06-12 14:38:28, Ray Lee wrote:
> On 6/12/07, Pavel Machek <[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 Lin
On 6/12/07, Pavel Machek <[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 addresse
On Tue, 12 Jun 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 m
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
> > > unus
> > Missing 4K of memory is not worth 4K of junk in syslog per boot. Can
> > you drop the stars and stop shouting?
>
> How missing about 1G of memory? We already discussed this, and Andi and
> Venki felt that either a panic or a really obnoxious message was the
> way to go...
Perhaps you could
On Friday, June 8, 2007 4:13:22 Eric W. Biederman wrote:
> Jesse Barnes <[EMAIL PROTECTED]> writes:
> >> - Overlapping MTRRs.
> >
> > Overlapping should be ok, since that's usually intentional (e.g.
> > one big wb range with a portion of uc space due to another mtrr).
>
> I'm not say overlapping wa
On Tuesday, June 12, 2007 7:50:08 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 addresse
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
Jesse Barnes <[EMAIL PROTECTED]> writes:
>> - Overlapping MTRRs.
>
> Overlapping should be ok, since that's usually intentional (e.g. one big
> wb range with a portion of uc space due to another mtrr).
I'm not say overlapping was a bug. I was saying that you don't handle
overlapping mtrrs in f
On Friday, June 8, 2007 2:15:00 Andrew Morton wrote:
> > 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.
>
> i386 allmodconfig:
>
> arch/i386/kernel/cpu/mtrr
On Wed, 6 Jun 2007 12:29:23 -0700
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 add
Hi!
> 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 kn
On Thu, 7 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
Justin Piszcz wrote:
Note that your boot also mentions this:
[ 106.449661] mtrr: no more MTRRs available
which indicates that things like X may not be able to map the
framebuffer with the 'write-combine' attribute, which will hurt
performance. I've heard reports that turning of 'Intel QST fan
On Thursday, June 7, 2007 5:20:50 Andrew Morton wrote:
> > -unsigned int *usage_table;
> > +unsigned int usage_table[NUM_VAR_RANGES];
> > static DEFINE_MUTEX(mtrr_mutex);
>
> didn't it feel all dirty when you had to do that?
Hey, this was already there... I didn't want to rewrite the whole thing
On Wed, 6 Jun 2007 12:29:23 -0700
Jesse Barnes <[EMAIL PROTECTED]> wrote:
> --- a/arch/i386/kernel/cpu/mtrr/if.c
> +++ b/arch/i386/kernel/cpu/mtrr/if.c
> @@ -12,7 +12,7 @@
> #include "mtrr.h"
>
> /* RED-PEN: this is accessed without any locking */
> -extern unsigned int *usage_table;
> +extern
p34:/usr/src/linux# patch -p1 < ../mtrr-v2.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 f
Will see if it still patches against -rc4.
On Thu, 7 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
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 sta
On Thu, 7 Jun 2007, Jesse Barnes wrote:
On Thursday, June 7, 2007 1:16 am Andi Kleen wrote:
On Wed, Jun 06, 2007 at 12:29:23PM -0700, 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 memor
On Thursday, June 7, 2007 1:16 am Andi Kleen wrote:
> On Wed, Jun 06, 2007 at 12:29:23PM -0700, 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
On Thursday, June 7, 2007 1:51 am Andi Kleen wrote:
> On Wed, Jun 06, 2007 at 04:27:46PM -0700, Jesse Barnes wrote:
> > On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
> > > > The mem= approach though looks slightly off, but I haven't
> > > > looked at x86_64's mem= handling to see why. Fr
On Thursday, June 7, 2007 12:45 am Eric W. Biederman wrote:
> Ok. Overall this feels good but a few nits below.
> Would it make sense to split this into two patches.
> The first to just do the cleanup that removes the allocations
> for holding the mttr ranges?
I suppose we could split it, but it'
On 6/7/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Wed, Jun 06, 2007 at 04:27:46PM -0700, Jesse Barnes wrote:
> [...]
> I'm not sure it's appropriate for -rc5 since it mucks around with some
> early boot ordering, but I'll leave that to Andi, since it does address
> some real bugs people have be
On Thu, 7 Jun 2007, Andi Kleen wrote:
On Wed, Jun 06, 2007 at 04:27:46PM -0700, Jesse Barnes wrote:
On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
The mem= approach though looks slightly off, but I haven't looked
at x86_64's mem= handling to see why. From a high level though,
adjus
On Wed, Jun 06, 2007 at 04:27:46PM -0700, Jesse Barnes wrote:
> On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
> > > The mem= approach though looks slightly off, but I haven't looked
> > > at x86_64's mem= handling to see why. From a high level though,
> > > adjusting end_pfn is the right
On Wed, Jun 06, 2007 at 12:29:23PM -0700, 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,
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 4:15 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
Hm, not sure if it was from the patch or what but I ran this:
1. swapoff -a
2. ./eatmem
You
Jesse Barnes <[EMAIL PROTECTED]> writes:
> 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 mac
On Wednesday, June 6, 2007 4:15 pm Justin Piszcz wrote:
> On Wed, 6 Jun 2007, Randy Dunlap wrote:
> > On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
> >> Hm, not sure if it was from the patch or what but I ran this:
> >>
> >> 1. swapoff -a
> >> 2. ./eatmem
> >
> > You usually have to
On Wednesday, June 6, 2007 4:24 pm Justin Piszcz wrote:
> > The mem= approach though looks slightly off, but I haven't looked
> > at x86_64's mem= handling to see why. From a high level though,
> > adjusting end_pfn is the right thing to do, since theoretically
> > mem= could choose to make holes
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:57 pm Justin Piszcz wrote:
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW
in the box and I guess the buffer
On Wednesday, June 6, 2007 3:57 pm Justin Piszcz wrote:
> On Wed, 6 Jun 2007, Jesse Barnes wrote:
> > On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
> >> Nope, I booted with only netconsole= options. I have a lot of HW
> >> in the box and I guess the buffer is too small. Not sure where t
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
Hm, not sure if it was from the patch or what but I ran this:
1. swapoff -a
2. ./eatmem
You usually have to access the allocated memory, like:
*d = 1.0;
for it to actually be al
On Wed, 6 Jun 2007 18:54:37 -0400 (EDT) Justin Piszcz wrote:
> Hm, not sure if it was from the patch or what but I ran this:
>
> 1. swapoff -a
> 2. ./eatmem
>
> The machine responded to ping and alt-sysrq-b but the box remain
> unresponsive, I guess the kernel did not kill the process? :(
>
>
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called "kernel log bu
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change i
On Wed, 6 Jun 2007, Randy Dunlap wrote:
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change i
On Wed, 6 Jun 2007 15:28:43 -0700 Jesse Barnes wrote:
> On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
> > Nope, I booted with only netconsole= options. I have a lot of HW in
> > the box and I guess the buffer is too small. Not sure where to
> > change it in the kernel. Looking..
>
>
On Wed, 6 Jun 2007, Jesse Barnes wrote:
On Wednesday, June 6, 2007 3:26 pm Justin Piszcz wrote:
Nope, I booted with only netconsole= options. I have a lot of HW in
the box and I guess the buffer is too small. Not sure where to
change it in the kernel. Looking..
It's called "kernel log bu
1 - 100 of 116 matches
Mail list logo
