On 11/15/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > 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.
Are you using the kexec-tools-testing tree, or Eric's kexec-tools git tree? > > >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. Indeed. > [..] > > > > > >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. Well, my config has CONFIG_PHYSICAL_START=0x100000, but I changed it to 2 MB and it does not seem to help - still not able to read out /proc/vmcore correctly. While at it, was there any specific reason to not support 1MB physical start address? It does seem to be a separate issue to my original problem, but I think supporting any kind of sane CONFIG_PHYS_START value sounds like a good thing to do IMO. > > 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. Cool. I'd like to try out your patches, but right now I can't kexec x86_64 using kexec-tools-testing and 2.6.18, and I feel like tracking it down. So I will spend some time on this. If you find a working x86_64 config for 2.6.18 please send it to me. > 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? Correct.Using 2 MB instead of 1 MB does not seem to work either. I'm using two 2.6.18 kernels - one primary and one secondary. Using these two kernels I can successfully kexec-on-panic and transfer the vmcore using code from the kexec-tools git repository. The latest kexec-tools-testing git version does not work: PASS: kexec-tools 529ad18980e297efc6ac2839c82afc24eccdcd1f FAIL: kexec-tools-testing 785f8f7c4e71803cc1ec73f0660e28e14696d1cf Thanks, / magnus _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
