RE: [PATCH]send slave cpus to SAL slave loop on crash (IA64)

From: Zou, Nanhai <nanhai.zou_at_intel.com>
Date: 2006-11-14 12:25:00
> -----Original Message-----
> From: Jay Lan [mailto:jlan@sgi.com]
> Sent: 20061111 3:23
> To: Zou, Nanhai
> Cc: fastboot; Linux-IA64; Jack Steiner; Luck, Tony
> Subject: Re: [PATCH]send slave cpus to SAL slave loop on crash (IA64)
> 
> 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?


  During kdump_cpu_freeze, putting everybody except cpu0 to rendez state looks like a hack... However fix_b0_for_bsp is another hack.... 
  Since I think the first one looks less hacky, I will include your patch in my kdump patch. 
  
Thanks
Zou Nan hai
  
> 
> 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, start=3018000000, end=3028000000
> memory_range: Boot, idx=7, start=307a280010, end=307a280061
> memory_range: MemoryMap, idx=9, start=307a3f0010, end=307a3f0611
> build_mem_shdrs: ei_class=2, e_shnum=46, e_shoff=54506776
> build_mem_shdrs: sizeof(e_shdr)=72, e_shdr=0x6000000000014120
> ready to load. type=0,
> build_mem_shdrs: ei_class=2, e_shnum=46, e_shoff=54506776
> build_mem_shdrs: sizeof(e_shdr)=72, e_shdr=0x6000000000014f30
> elf_exec_load
> Invalid memory segment 0x4000000 - 0x4997fff
> Segmentation fault
> [root@pogo1 boot]#
> 
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Nov 14 12:25:36 2006

This archive was generated by hypermail 2.1.8 : 2006-11-14 12:25:50 EST