linux-kernel - Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid crash on armada-xp

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:	Thu, 12 Mar 2015 13:47:56 +0100
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org,
	Gregory Clément 
	<gregory.clement@...e-electrons.com>,
	Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH] n_tty: use kmalloc() instead of vmalloc() to avoid
 crash on armada-xp

Dear Stas Sergeev,

On Thu, 12 Mar 2015 15:44:44 +0300, Stas Sergeev wrote:

> Hello Thomas, I haven't got to look into that register:
> uboot is updated to v2011.12-2014_T2.0 and everything
> is working! So thanks once again.

Well if everything is working now, and seeing your boot log, the
register 0xf1020254 will contain 0xf0000000.

> The only problem I now have is the lack of 256Mb of
> ram.
> 
> [    0.000000] MEMBLOCK
> configuration:                                         
> [    0.000000]  memory size = 0x1f0000000 reserved size =
> 0x70d6e3             
> [    0.000000]  memory.cnt  =
> 0x2                                              
> [    0.000000]  memory[0x0]     [0x00000000000000-0x000000efffffff],
> 0xf0000000
> bytes flags:
> 0x0                                                               
> [    0.000000]  memory[0x1]     [0x00000100000000-0x000001ffffffff],
> 0x100000000
>  bytes flags: 0x0 
> 
> There is a 8Gb in a single dimm.
> Do you have any idea why 0xf0000000-0xffffffff range is missing?
> I suspect this is something with uboot too.

No, this is expected. Your physical address space is shared between RAM
and I/O devices. So the space 0xf0000000 -> 0xffffffff in the physical
address space is where all the registers for your SoC and PCIe devices
will be located. You are therefore indeed losing 256 MB of RAM, but
there's nothing that can be done about this.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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/