All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Hansen <haveblue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, "Martin J. Bligh" <mbligh@aracnet.com>
Subject: Re: kexec reboot code buffer
Date: 28 Jan 2003 00:04:19 -0700	[thread overview]
Message-ID: <m1r8ax69ho.fsf@frodo.biederman.org> (raw)
In-Reply-To: <3E35AAE4.10204@us.ibm.com>

Dave Hansen <haveblue@us.ibm.com> writes:

> Eric W. Biederman wrote:
> > Dave Hansen <haveblue@us.ibm.com> writes:
> >>On my system, it appears to lock up in:
> >>kimage_alloc_reboot_code_pages()
> >>after the kexec -l.
> > 
> > 
> > O.k. It should come out of it eventually from what I have
> > seen described, the current algorithm is definitely inefficient on
> > your machine.
> 
> It does appear to completely hang in the free loop.  Something funny is
> happening there.  I'll try to provide more details later.  BTW, do you
> mind updating your patches for 2.5.59?  

I will give it a shot shortly I have been intensely busy just
lately so find the free second is a bit difficult.  At the same

> I'm having some other problems
> and I want to make sure it isn't my bad merging that's at fault :)

I don't recall any merging issues at all with the stock kernel, just
a some slight line changes.
> 
> > And being able to allocate from 3GB instead of just 1GB is
> > much more polite.  The question then is how do I specify the zones
> > properly.
> 
> Actually, I think that using lowmem is OK.  The machine is going away
> soon anyway, and the necessary memory is a very small portion,
> especially on a machine with this much RAM.

I agree that lowmem for the common case is fine.  For kexec on panic,
and a some weird cases using high mem is beneficial.  I don't have
a problem with changing it back to just lowmem for the time being.
 
Eric

  parent reply	other threads:[~2003-01-28  6:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E31AC58.2020802@us.ibm.com>
2003-01-25 14:16 ` kexec reboot code buffer Eric W. Biederman
2003-01-27 21:55   ` Dave Hansen
2003-01-27 22:03     ` Martin J. Bligh
2003-01-28  0:10       ` William Lee Irwin III
2003-01-28  7:24       ` Eric W. Biederman
2003-01-28 16:15         ` Martin J. Bligh
2003-01-29 15:41           ` Eric W. Biederman
2003-01-29 16:17             ` Martin J. Bligh
2003-01-28  7:04     ` Eric W. Biederman [this message]
2003-01-28  7:18       ` William Lee Irwin III
2003-01-28  7:28         ` Eric W. Biederman
2003-01-28  7:31           ` William Lee Irwin III
2003-01-28 15:21             ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1r8ax69ho.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.