linux-kernel - Re: kdump broken on 2.6.37-rc4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Dec 2010 17:41:36 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Stanislaw Gruszka <sgruszka@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Maxim Uvarov <muvarov@...il.com>, linux-kernel@...r.kernel.org,
	Neil Horman <nhorman@...hat.com>
Subject: Re: kdump broken on 2.6.37-rc4

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/