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
| ||
|
Date: Tue, 4 Sep 2012 16:17:37 -0300 From: Flavio Leitner <fbl@...hat.com> To: Yinghai Lu <yinghai@...nel.org> Cc: lkml <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>, WANG Cong <xiyou.wangcong@...il.com>, Tejun Heo <tj@...nel.org>, ianfang.cn@...il.com, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: kexec/kdump kernel fails to start On Tue, 4 Sep 2012 12:02:00 -0700 Yinghai Lu <yinghai@...nel.org> wrote: > On Tue, Sep 4, 2012 at 10:32 AM, Flavio Leitner <fbl@...hat.com> wrote: > > Hi folks, > > > > I have system that no longer boots kdump kernel. Basically, > > > > # echo c > /proc/sysrq-trigger > > > > to dump a vmcore doesn't work. It just hangs after showing the usual > > panic messages. I've bisected the problem and the commit introducing > > the issue is the one below. > > > > Any idea? > > > > commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 > > Author: WANG Cong <xiyou.wangcong@...il.com> 2012-03-05 20:05:13 > > Committer: Ingo Molnar <mingo@...e.hu> 2012-03-06 05:38:26 > > Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 'mmc-fixes-for-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) > > Child: a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in leave_mm() only when needed) > > Branches: master, remotes/origin/master > > Follows: v3.3-rc6 > > Precedes: v3.5-rc1 > > > > x86/mm: Fix the size calculation of mapping tables > > > > For machines that enable PSE, the first 2/4M memory region still uses > > 4K pages, so needs more PTEs in this case, but > > find_early_table_space() doesn't count this. > > > > This patch fixes it. > > > > The bug was found via code review, no misbehavior of the kernel > > was observed. > > maybe just revert the offending commit? I don't know where the 4K pages were noticed. Here is the dmesg output passing 'debug': [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] last_pfn = 0xbf800 max_arch_pfn = 0x400000000 [ 0.000000] initial memory mapped : 0 - 20000000 [ 0.000000] Base memory trampoline at [ffff880000098000] 98000 size 20480 [ 0.000000] init_memory_mapping: 0000000000000000-00000000bf800000 [ 0.000000] 0000000000 - 00bf800000 page 2M [ 0.000000] kernel direct mapping tables up to bf800000 @ 1fa00000-20000000 [ 0.000000] init_memory_mapping: 0000000100000000-0000000440000000 [ 0.000000] 0100000000 - 0440000000 page 2M [ 0.000000] kernel direct mapping tables up to 440000000 @ bdaab000-bf4bd000 [ 0.000000] RAMDISK: 352c8000 - 3695c000 so, it appears that on my system, the pages are 2M. I will try moving the extra accounting to be inside of CONFIG_X86_32. fbl -- 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/
Powered by blists - more mailing lists