On Thu, Dec 16, 2010 at 08:16:41AM -0800, H. Peter Anvin wrote:
quoted text
> On 12/16/2010 02:00 AM, Stanislaw Gruszka wrote:
> > On Wed, Dec 15, 2010 at 08:29:01PM -0800, Yinghai Lu wrote:
> >> please check
> >>
> >> [PATCH] x86, crashkernel, 32bit: only try to get range under 512M
> >>
> >> Steanishlaw report kdump is 32bit is broken.
> > LOL
> > 
> >> in misc.c for decompresser, it will do sanity checking to make sure heap
> >> heap under 512M.
> >>
> >> So limit it in first kernel under 512M for 32bit system.
> >>
> >> Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
> >> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> > 
> > Patch fix problem on my T-60 laptop.
> > 
> > As expected patch does not help on my other T-500 x86_64 system,
> > kdump not work there, but perhaps this is a different problem,
> > I'm going to check it.
> > 
> 
> I think limiting kdump below 512 MiB on 32 bits may make sense; perhaps
> even on 64 bits.  It's pretty conservative, after all...
> 
> Opinions?

Actually it will be good to know why 512MB. I know in the past we have
been talking of reserving memory in higher memory regions and Neil Horman
had been trying to boot bzImage in 64 bit mode so that it can be run
from higher addresses. 

So right now limiting it is easy but it is desirable to be able to run
bzImage from as high a address as possible and knowing why to limit it
to 512MB can help see if there is a way to get rid of that limitation.

I probably would not worry about 32bit systems but for 64 bit, I
cerntainly want to make it boot from higher addresses (if it is possible
technically).

Thanks
Vivek
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/