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] [day] [month] [year] [list]
Date:	Thu, 26 May 2016 08:14:29 -0400
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	"pankaj.dubey" <pankaj.dubey@...sung.com>,
	linux-kernel@...r.kernel.org
Cc:	Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	linux-samsung-soc@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Kukjin Kim <kgene@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org,
	Sjoerd Simons <sjoerd.simons@...labora.co.uk>,
	Kevin Hilman <khilman@...libre.com>
Subject: Re: ARM: dts: exynos: Add MFC memory banks for Peach boards

Hello Pankaj,

On 05/26/2016 05:10 AM, pankaj.dubey wrote:

[snip]

>>> [    0.000000] Kernel command line: cros_legacy console=ttySAC3,115200
>>> debug earlyprintk cros_debug no_console_suspend root=/dev/ram0 rw
>>> ramdisk=32768 initrd=0x42000000,3
>>> 2M
>>
>> I see that you are loading an initrd at 0x42000000 with size of 32 MiB.
>>
>> [...]
>>
>>> [    1.121421] Trying to unpack rootfs image as initramfs...
>>> [    1.126940] rootfs image is not initramfs (junk in compressed
>>> archive); looks like an initrd
>>> [    1.160139] Unable to handle kernel paging request at virtual address
>>> e3000000
>>
>> So I wonder if the problem is that the memblock_remove() is called very
>> early and so the kernel is not able to copy the initrd from 0x42000000
>> to 0x44000000 since overlaps with the mfc-r mem (0x43000000-0x43800000).
>>
>> Specially since the NULL pointer dereference below happens in the
>> populate_rootfs() function when calling xwrite() to do the copy.
>>
>> Could you please try to change the load address for your initrd, or
>> change the mfc-r start address to see if that prevents the issue?
>>
> 
> Yes, you are correct. This was the case.
> I changed initrd location from 0x42000000 to 0x44000000, and it is able
> to boot without any crash.
>

Great, good to confirm that this was causing your boot failure.
 
> Thanks,
> Pankaj Dubey
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ