[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86802c440803211309x501137ccq5eefdeab6423dd4@mail.gmail.com>
Date: Fri, 21 Mar 2008 13:09:06 -0700
From: "Yinghai Lu" <yhlu.kernel@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: "Ingo Molnar" <mingo@...e.hu>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"kernel list" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64: early memtest to find bad ram
On Fri, Mar 21, 2008 at 12:58 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> Yinghai Lu wrote:
> > On Fri, Mar 21, 2008 at 6:08 AM, H. Peter Anvin <hpa@...or.com> wrote:
> >> Ingo Molnar wrote:
> >> >
> >> > very nice patch! I always thought that this was the proper way to do
> >> > memtest - and we could in fact also do something like this after SMP
> >> > bringup, and hit the memory bus via multiple CPUs. [that will need a
> >> > different enumeration though than e820 maps]
> >> >
> >> > one structural observation: please make this unified functionality, so
> >> > that 32-bit kernels can make use of it too.
> >> >
> >>
> >> Indeed. Of course, it would also be nice if distros shipped
> >> bootloader-invoked prekernel test software, like memtest86+, by default.
> >
> > the current memtest86 is running in 32 bit mode, and only support 64G ram.
> >
> > I tried to expand that a bit, to support 1024g, but it only works on
> > some machine.
> > could be stack provide is not big enough?
> >
>
> Wonder how hard it would be to make it run 64 bits...
1. in 32 bit test less than 4g in 32 bit mode
2. switch to 64 bit, set page table under 4g to cover all ram...
YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists