Hi Vivek! Thanks for your comments!
On 11/14/06, Vivek Goyal <[EMAIL PROTECTED]> wrote:
On Mon, Nov 13, 2006 at 05:01:29PM +0900, Magnus Damm wrote: > Hi again, > > Here are the same tests again, but now using the latest revision of the > kexec-tools-testing git tree, 785f8f7c4e71803cc1ec73f0660e28e14696d1cf. > > http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=commit;h=785f8f7c4e71803cc1ec73f0660e28e14696d1cf > Hi Magnus, Thanks for testing kdump on various configurations and posting the test results.
No problem, I need something working to build my Xen stuff on top of anyway.
> Current status of kexec-testing tree: > > Kexec - working well. > Kdump - 2.6.18 is broken on x86_64. I just tested kdump on 2.6.18.2 with horms's kexec-tools-testing tree and it is working fine. Actually in 2.6.19-rc kernels kdump is broken because of early param changes and your patch fixes it. But early param changes were not even present in 2.6.18 kernels so it should not be broken because of that.
I agree with the early param stuff for 2.6.19-rc, but when you tested 2.6.18,did you just kexec-on-panic or did you also try transfer the vmcore?
At the same time, in your last post you reported 2.6.18 kdump a success with -kdump10 kexec-tools. I think just change of version of kexec-tools should not break it.
No, it _should_ not break it, but I think we have a regression in kexec-tools-testing on x86_64 with older kernels.
Is there some misunderstanding?
The matrix below shows that it is possible to kexec-on-panic into 2.6.18, but that the transfer of vmcore fails. I suspect that the warnings spit out by the kexec tool are related to the vmcore transfer failure.
> > hardware: Shuttle XPC SD36G5, 1 x Pentium D 930, 1 GB RAM > > test kexec kexec kdump transfer > bzImage vmlinux vmlinux vmcore > > primary 2.6.18 2.6.18 2.6.18 > -> -> -> > secondary 2.6.18 2.6.18 2.6.18 2.6.18 > > i386 PASS PASS PASS PASS > i386/PAE PASS PASS PASS PASS > x86_64 PASS PASS PASS* FAIL** > > primary 2.6.19-rc5 2.6.19-rc5 2.6.19-rc5 > -> -> -> > secondary 2.6.19-rc5 2.6.19-rc5 2.6.19-rc5 2.6.19-rc5 > > i386 PASS PASS PASS PASS > i386/PAE PASS PASS PASS PASS > x86_64 PASS PASS PASS FAIL*** > > * kexec complains: > Note name is not null termiated > ELF core (kcore) parse failed > Warning: Hardcoding kernel virtual addr and size > Warning: virtual addr = 0xffffffff80200000 size = 0x2600000 > Ok. This warning message will pop up whenever latest kexec-tools is used with kernel older than 2.6.19-rc kernels. Now we parse /proc/kcore to find out where the kernel is loaded in virt addr space. Previous kernels needed a /proc/kcore fix and that fix is available only in 2.6.19-rc kernels. So above is just a warning message and does not harm. Please suggest if there is a better way to handle the things.
Are you sure that they do no harm? I'm not sure why we want to warn to the user about a missing feature. Isn't it instead possible to just omit the PT_LOAD header that maps the kernel if we cannot determine the virtual address? That may just complicate things though... Also, if we really want to try hard then it should be possible to fallback on information from /proc/kallsyms if present.
> ** cat /proc/vmcore fails: > / # cat /proc/vmcore | ftpput -u ftp -p ftp > 172.17.106.1 /incoming/vmcore - > cat: Read Error: Bad address
The problem above is my main concern. Kexec-on-panic seems to work properly, but that is kind of pointless if we cannot read out data from /proc/vmcore... I've attached the config for my primary 2.6.18-kernel. It is kind of minimalistic because I boot over the network and use initramfs instead of root filesystem. The configuration works with the kexec-tools tree but /proc/vmcore transfer is broken with kexec-tools-testing on x86_64.
> *** kernel problem - fix available at: > > ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/setup-saved_max_pfn-correctly-kdump > Andi, Can you please push above fix upstream so that 2.6.19 kdump on x86_64 is not broken.
Yeah, that would be great! Many thanks, / magnus
config.gz
Description: GNU Zip compressed data
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
