linux-kernel - Re: [RFC v2 0/2] Early use of boot service memory

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]

Message-ID: <528ED04E.4060606@jp.fujitsu.com>
Date:	Fri, 22 Nov 2013 12:32:30 +0900
From:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Vivek Goyal <vgoyal@...hat.com>, jerry.hoemann@...com,
	"H. Peter Anvin" <hpa@...or.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Borislav Petkov <bp@...e.de>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-efi@...r.kernel.org, Pekka Enberg <penberg@...nel.org>,
	Ingo Molnar <mingo.kernel.org@...il.com>,
	Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>
Subject: Re: [RFC v2 0/2] Early use of boot service memory

(2013/11/22 11:29), Vivek Goyal wrote:
> [..]
>>> makedumpfile going to cyclic buffer has helped out greatly, but on
>>> our new systems we're still looking at 512 MB crash kernels.
>>
>> I tried 6TiB system/16 PCIE cards, kdump on RHEL 6.5 beta still does not work.
>> still get OOM.
>
> What crashkernel= option you are using?
>
> Interesting. So something is consuming lot of memory. How about setting
> "debug_mem_level 1" in /etc/kdump.conf and regenerate initrd and retry.
> This time it should output some memory usage info at various points
> during boot and that can give us some idea who is consuming how much
> memory.
>
> If some module are consuming lot of memory, then you can try "blacklist"
> option in /etc/kdump.conf to disable those.
>
> If it is not modules, then it will concern me because then either
> kernel is consuming too much memory (which it should not) or for
> some reason makedumpfile cyclic mode did not work for you properly.
>
> While you are re-testing, how about also increasing debug message
> level of makedumpfile. makedumpfile developers should be able to
> have a look at that. In /etc/kdump.conf, specify.
>
> core_collector makedumpfile -c --message-level 31 -d 31
>
> If message level 31 turns out to be too verbose, reduce it as per
> makedumpfile man page.
>

The following configuration is more flexible:

core_collector false
default shell

Then crash dump collection fails and emergency shell shows up,
where you can type a variety of commands.

If 2nd kernel keeps failing even on this configuration, it's likely
that kernel side already causes the OOM you're facing before reaching
invocation of the command specified by core_collector directive.

-- 
Thanks.
HATAYAMA, Daisuke

--
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/