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  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, 04 Dec 2007 20:55:54 -0800
From:	Geoff Levand <geoffrey.levand@...sony.com>
To:	Milton Miller <miltonm@....com>
CC:	Christoph Lameter <clameter@....com>,
	Andy Whitcroft <apw@...dowen.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Yasunori Goto <y-goto@...fujitsu.com>
Subject: Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec

Milton Miller wrote:
> On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote:
> 
>> Hi.
>>
>> I'm finding that recently kexec'ed kernels on PS3 will
>> panic on startup.  It seems the trouble was introduced
>> with the ppc64 SPARSEMEM_VMEMMAP support.  The problem
>> is the same when starting either new or old kernels:
>>
>> 2.6.24 -> 2.6.23 ok
>> 2.6.24 -> 2.6.23 panic
>> 2.6.24 -> 2.6.24 panic
> 
> I'm not sure I completely follow this.  What is the difference between 
> 1 and 2 ?   


Sorry, '2.6.23 -> 2.6.24 ok', but it really doesn't have much meaning,
considering what the actual problem is.


> Also, you are talking about starting with kexec, but I 
> don't see how that fits in the failure you have below.


I think just buy chance the kexec'ed kernel hits because
the 2.6.24 kernel is just at the point of hitting the condition,
and the memory usage of the kexe'ed kernel hits.

If I just reduce the size of the kernel a small amount kexec
works ok, and as Geert pointed out, if you increase the size
of the first stage kernel it will hit it.


>> DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB 
>> present:129280kB pages_scanned:0 all_unreclaimable? no
>> lowmem_reserve[]: 0 0 0
>> DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 
>> 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB
>> Swap cache: add 0, delete 0, find 0/0, race 0+0
>> Free swap  = 0kB
>> Total swap = 0kB
>> Free swap:            0kB
>> 32768 pages of RAM
>> 10403 reserved pages
>> 0 pages shared
>> 0 pages swap cached
> 
> The kernel is using 16MB pages for the linear mapping and, since its in 
> the same region, the sparse virtural memmap.  PS3 uses hotplug for all 
> most all of its memory.   In this case, its trying to allocate an 
> additional page to cover a new region of the memory map.   However, the 
> initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones.


Yes, I see this is the problem.

-Geoff


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