public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jay Lan <jlan@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH]send slave cpus to SAL slave loop on crash (IA64)
Date: Tue, 31 Oct 2006 18:08:40 +0000	[thread overview]
Message-ID: <45479128.7050100@sgi.com> (raw)
In-Reply-To: <4546623D.5000105@engr.sgi.com>

Zou, Nanhai wrote:

>> We do not rely on machine crash on CPU 0 any more. If the
>> crashing CPU is not cpu 0 and the cpu 0 not being returned to
>> the slave loop, this case is handled by our PROM now.
>>
>> However, if somebody tries to boot up a production kernel using '-le'
>> option _after_ the kexec'ed kernel is up running, the third kernel
>> would not boot unless we boot up the second kernel with cpu 0. I
>> posted a question on "if running 'kexec -le' on a kexec'ed kdump
>> kernel is legal" earlier and Vivek responded saying the scenario
>> is not guranteed to work. So, i think we are fine here.
> 
>   Ok, so with this patch and the PROM fix, on a SN system,
>   1. Kdump -> 2nd kernel works.
>   2. Kdump -> 2nd kernel -> Kexec to third kernel will not work.
>   3. Kexec -> 2nd Kernel -> Kexec -> 3rd kernel works?
>   4. Kexec -> 2nd Kernel -> Kdump -> 3rd kernel works?
> 
>   I think if scenario 1, 3 and 4 works it will be ok. Scenario 2 is not so useful I guess.
> 

The '-l' option caused a seg fault of kexec:

[root@pogo1 boot]# /home/jlan/kexec -l
/boot/efi/efi/redhat/vmlinuz-2.6.18-kdump
--initrd=/boot/efi/efi/redhat/initrd-2.6.18-kdump
--append="root=/dev/sdb6 rhgb irqpoll ro quite"
Done with process_options
kernel: 0x2000000000328010 kernel_size: 3503fec
memory_range: crashk, idx=5, start018000000, end028000000
memory_range: Boot, idx=7, start07a280010, end07a280061
memory_range: MemoryMap, idx=9, start07a3f0010, end07a3f0611
build_mem_shdrs: ei_class=2, e_shnumF, e_shoffT509848
build_mem_shdrs: sizeof(e_shdr)r, e_shdr=0x6000000000014120
ready to load. type=0,
build_mem_shdrs: ei_class=2, e_shnumF, e_shoffT509848
build_mem_shdrs: sizeof(e_shdr)r, e_shdr=0x6000000000014f30
elf_exec_load
Invalid memory segment 0x4000000 - 0x498bfff
Segmentation fault
[root@pogo1 boot]#

It is on my list but my priority is to make sure kdump work (on
sysrq-c, INIT, MCA) and to ensure /proc/vmcore contains correct
and needed information for SN.


Thanks,
 - jay

  parent reply	other threads:[~2006-10-31 18:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-30 20:36 [PATCH]send slave cpus to SAL slave loop on crash (IA64) Jay Lan
2006-10-31  2:02 ` Zou, Nanhai
2006-10-31  4:33 ` Zou, Nanhai
2006-10-31  8:59 ` Jay Lan
2006-10-31  9:11 ` Zou, Nanhai
2006-10-31 18:08 ` Jay Lan [this message]
2006-11-03 17:42 ` Jay Lan
2006-11-08  2:01 ` Zou, Nanhai
2006-11-10 19:23 ` Jay Lan
2006-11-14  1:25 ` Zou, Nanhai
2006-11-20 23:13 ` Zou Nan hai
2006-11-20 23:33 ` Jay Lan

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=45479128.7050100@sgi.com \
    --to=jlan@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox