All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Lan <jlan@sgi.com>
To: Simon Horman <horms@verge.net.au>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Bernhard Walle <bwalle@suse.de>,
	"Luck, Tony" <tony.luck@intel.com>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>
Subject: Re: kdump broken on Altix 350
Date: Thu, 02 Oct 2008 10:04:24 -0700	[thread overview]
Message-ID: <48E4FF18.10405@sgi.com> (raw)
In-Reply-To: <20081002051348.GA1027@verge.net.au>

Simon Horman wrote:
> On Mon, Sep 29, 2008 at 04:42:52PM -0700, Luck, Tony wrote:
>> Does this make kexec/kdump happier?  Bare minimum testing so far
>> (builds and boots on tiger ... didn't try kexec yet).
> 
> Hi Tony,
> 
> your analysis (in your previous email) was more or less the same
> conclusion that I had come too, though I was puzzling over
> why you had put the reserved area for cpu0 where you had - I assumed
> I was misunderstanding things.
> 
> This patch looks good to me.
> 
> Jay,
> 
> With this patch I assume that we still need an order of operations fix for
> kexec-tools but no section merging changes. Is that correct?

I think the code should still be simplified.

The 'break' of the if-statement has never been executed due to
the mistake in operation precedence. Thus, the code have been
doing segment merging by calculating p_memsz of each segment
without having to deal with 'gap' between PT_LOAD headers.

As demonstrated by this incidence, when there is a gap happened,
the kernel boot fail. So, if we assume the PT_LOAD headers will
be generated correctly, then the segment merging logic should be
simplified. It does not make sense to pick up p_memsz of each
segment and do all those calculation. It caused confusion.

Regards,
jay

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Jay Lan <jlan@sgi.com>
To: Simon Horman <horms@verge.net.au>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Bernhard Walle <bwalle@suse.de>,
	"Luck, Tony" <tony.luck@intel.com>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>
Subject: Re: kdump broken on Altix 350
Date: Thu, 02 Oct 2008 17:04:24 +0000	[thread overview]
Message-ID: <48E4FF18.10405@sgi.com> (raw)
In-Reply-To: <20081002051348.GA1027@verge.net.au>

Simon Horman wrote:
> On Mon, Sep 29, 2008 at 04:42:52PM -0700, Luck, Tony wrote:
>> Does this make kexec/kdump happier?  Bare minimum testing so far
>> (builds and boots on tiger ... didn't try kexec yet).
> 
> Hi Tony,
> 
> your analysis (in your previous email) was more or less the same
> conclusion that I had come too, though I was puzzling over
> why you had put the reserved area for cpu0 where you had - I assumed
> I was misunderstanding things.
> 
> This patch looks good to me.
> 
> Jay,
> 
> With this patch I assume that we still need an order of operations fix for
> kexec-tools but no section merging changes. Is that correct?

I think the code should still be simplified.

The 'break' of the if-statement has never been executed due to
the mistake in operation precedence. Thus, the code have been
doing segment merging by calculating p_memsz of each segment
without having to deal with 'gap' between PT_LOAD headers.

As demonstrated by this incidence, when there is a gap happened,
the kernel boot fail. So, if we assume the PT_LOAD headers will
be generated correctly, then the segment merging logic should be
simplified. It does not make sense to pick up p_memsz of each
segment and do all those calculation. It caused confusion.

Regards,
jay

  reply	other threads:[~2008-10-02 17:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-29 16:03 kdump broken on Altix 350 Bernhard Walle
2008-08-29 16:03 ` Bernhard Walle
2008-08-29 16:05 ` Bernhard Walle
2008-08-29 16:05   ` Bernhard Walle
2008-08-29 20:42   ` Luck, Tony
2008-08-29 20:42     ` Luck, Tony
2008-08-29 20:48     ` Bernhard Walle
2008-08-29 20:48       ` Bernhard Walle
2008-09-10 11:48     ` Bernhard Walle
2008-09-10 11:48       ` Bernhard Walle
2008-09-10 20:21       ` Jay Lan
2008-09-10 20:21         ` Jay Lan
2008-09-27  1:00         ` Jay Lan
2008-09-27  1:00           ` Jay Lan
2008-09-29 20:55           ` Luck, Tony
2008-09-29 20:55             ` Luck, Tony
2008-09-29 23:42             ` Luck, Tony
2008-09-29 23:42               ` Luck, Tony
2008-09-30  0:30               ` Jay Lan
2008-09-30  0:30                 ` Jay Lan
2008-10-02  5:13               ` Simon Horman
2008-10-02  5:13                 ` Simon Horman
2008-10-02 17:04                 ` Jay Lan [this message]
2008-10-02 17:04                   ` Jay Lan
2008-09-10 12:19 ` Bernhard Walle
2008-09-10 12:19   ` Bernhard Walle

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=48E4FF18.10405@sgi.com \
    --to=jlan@sgi.com \
    --cc=bwalle@suse.de \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=tony.luck@intel.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.