On Wed, Mar 14, 2007 at 11:48:15AM -0700, Jay Lan wrote: > Jay Lan wrote: > > Jay Lan wrote: > >> Magnus Damm wrote: > >> [snip] > >>>> I tested on 2.6.21-rc3 with DEBUG_VM turned on. The vanilla 2.6.21-rc3 > >>>> without Nan-hai's patch, panicked on bugcheck on free_initmem->free_page > >>>> as predicted. We still need this patch. > >>> Ok, thanks for testing. =) > >>> > >>>> However, the zero-size vmcore problem is back on SN. But that is a > >>>> dfiffernet problem. > >>> Argh, more problems... > >> I found the problem. It was the "elfcorehdr" introduced in 2.6.21-rc1. > >> Without specifying it, the elfcorehdr_addr is initialized to > >> ELFCORE_ADDR_MAX. Later, a check in reserve_elfcorehdr will fail: > >> if (elfcorehdr_addr >= ELFCORE_ADDR_MAX) > >> return -EINVAL; > >> > >> Is it supposed to be a physical address to store elf core header? > >> If so, it is not possible for SN to provide a physical address at > >> boot time, just like in the case of crashkernel=X@Y where Y is not used. > > > > Sorry, the elfcorehdr parameter is provided to the kdump kernel by > > kexec. The problem is in the reserve_elfcorehdr logic introduced in > > 2.6.21-rc1. > > > > When booting up the kdump kernel, i observed a failure in > > reserve_elfcorehdr. The below are my debugging messages: > > > > elfcorehdr_addr=3027fe4000, ELFCORE_ADDR_MAX=ffffffffffffffff > > Cannot locate EFI vmcore descriptor > > reserve_elfcorehdr: vmcore descriptor size = 0 > > reserve_memory: FAIL to reserve reserve_elfcorehdr > > Hi Tony, > > The kernel code 2.6.21-rc3+ is fine wrt zero-size-vmcore issue. > > I have been testing on a rhel5 environment. The /sbin/kexec worked > for me up to 2.6.20. > > I then built a new kexec from tot kexec-tools-testing git tree and > i no longer see the zero-size-vmcore problem. I take it that elfcorehdr is also correct in this environment? The latest (ia64) kernels need a fairly recent kexec-tools-testing because of the change "kexec: Use EFI_LOADER_DATA for ELF core header". A recent kexec-tools-testing is probably needed for other reasons, though I can't think of them off-hand. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|