Messages in this thread | | | Date | Wed, 15 Dec 2010 11:39:54 +0100 | From | Stanislaw Gruszka <> | Subject | Re: kdump broken on 2.6.37-rc4 |
| |
On Tue, Dec 14, 2010 at 05:41:36PM -0500, Vivek Goyal wrote: > On Mon, Dec 13, 2010 at 11:47:08AM -0800, H. Peter Anvin wrote: > > On 12/13/2010 10:20 AM, Yinghai Lu wrote: > > > > > > it seems 32bit kdump need crashkernel much low than we expect... > > > > > > Maybe we have to find_in_range_low() to make 32bit kdump happy. > > > > > > > Not this garbage again... sigh. Once again, I will want to know what > > the actual constraint is... not just "oh, this seems to work on this one > > system." > > > > I realize that the kdump interfaces are probably beyond saving -- we > > have had this discussion enough times -- but I'm not happy about it and > > I will really want to know what the heck the real issue is. > > Same here Yinghai. We need to debug that what is that upper limit for > loading x86 32bit kernel and if we know/understand that, we can fail > the loading of kdump kernel citing the appropriate reason. Last time > our understanding was that as long as we allocate memory below 896MB > things should be fine. > > Stanislaw, how much memory you are reserving at what address with -rc4 > kernel?
crashkernel=128M, system has 1G mem.
> Can you please look at /proc/iomem? And try to reserve same > amount of memory at roughly same address at 2.6.36 kernel, and see if > kdump works. > > So how I used to debug problems in kdump path. > > - Try earlyprintk for second kernel. > - Try --debug, --console-serial options with kexec while loading second > kernel. Important thing to know here is control reached to purgatory > or not. > - If that gives me nothing then it boils down to putting some outb() > statements in first kernel and second kernel boot path to know where > things went wrong. > > Because the issue was resolved by reserving memory in low memory > area, it sounds like second kernel failed to boot early. So early > printk might help otherwise outb() and serial console is the friend.
I could debug this problem, but I do not suffer from free time right now :-) Would be better someone bootmem/kdump experienced debug this. I just check other laptop (T500, 2.6.37-rc5, x86_64, RHEL6 user space, crashkernel=256M, 1.6G mem), kdump does not work there too. So I do think problem is hard to reproduce.
Stanislaw
| |