Re: kdump broken on 2.6.37-rc4

[Vivek Goyal <vgoyal@redhat.com>]

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? 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.

Thanks
Vivek