On Tue, Nov 14, 2006 at 12:49:17PM +0900, Magnus Damm wrote: > >> 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? >
I even transferred the vmcore and opened it using gdb and crash. Everything looked fine. We have been using 2.6.18 base kernel in RHEL, and kdump is working fine. > >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. > Strange. [..] > > > >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? > Yes, until and unless somebody is using old kernels where by default kernel was being compiled for address 1MB. There one shall have to use older version of kexec-tools with -kdump10. > 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. > I will test with your config as soon as I am done with more modification required for x86_64 relocatable kernel patches. So the bottom line is that with your config, you can't save vmcore on your system with 2.6.18 kernels and right now nature of problem is not known and no fix is available? Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
