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: Fri, 10 Nov 2006 19:23:28 +0000 [thread overview]
Message-ID: <4554D1B0.9090306@sgi.com> (raw)
In-Reply-To: <4546623D.5000105@engr.sgi.com>
Zou, Nanhai wrote:
>>> But this will rely on machine crash on CPU 0?
>> 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.
Hi Nanhai,
Where do we stand as to this patch's concern? Did you include this yet?
As to Scenario 3 and 4, 'kexec -l' failed on "Inivalid memory segment"
on SN Altix systems, and i have not had time to dig into it. This patch
is pretty much doing what you suggested "calling ia64_jump_to_sal"
to send the cpus to slave loop.
We can include cpu 0 also by calling fix_b0_for)bsp() to set up b0
for cpu 0 in ia64_mca_init(), if so desired. What do you think?
Regards,
- jay
[root@pogo1 boot]# /home/jlan/kexec-noio -l /boot/vmlinuz-2.6.18-kdump
--noio -
-initrd=/boot/initrd-2.6.18-kdump --append="root=/dev/sdb6 irqpoll ro
console=t
tySG0"
Done with process_options
kernel: 0x2000000000328010 kernel_size: 3502601
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_shoffT506776
build_mem_shdrs: sizeof(e_shdr)r, e_shdr=0x6000000000014120
ready to load. type=0,
build_mem_shdrs: ei_class=2, e_shnumF, e_shoffT506776
build_mem_shdrs: sizeof(e_shdr)r, e_shdr=0x6000000000014f30
elf_exec_load
Invalid memory segment 0x4000000 - 0x4997fff
Segmentation fault
[root@pogo1 boot]#
>
next prev parent reply other threads:[~2006-11-10 19:23 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
2006-11-03 17:42 ` Jay Lan
2006-11-08 2:01 ` Zou, Nanhai
2006-11-10 19:23 ` Jay Lan [this message]
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=4554D1B0.9090306@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 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.