linux-kernel - Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it

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, 31 Jan 2013 11:35:59 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Shuah Khan <shuahkhan@...il.com>
CC:	Yinghai Lu <yinghai@...nel.org>,
	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>, Jan Kiszka <jan.kiszka@....de>,
	Jason Wessel <jason.wessel@...driver.com>,
	linux-kernel@...r.kernel.org, Joerg Roedel <joro@...tes.org>
Subject: Re: [PATCH v7u1 26/31] x86: Don't enable swiotlb if there is not
 enough ram for it

On 01/31/2013 11:28 AM, Shuah Khan wrote:
> On Mon, Jan 28, 2013 at 8:44 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>> On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan <shuahkhan@...il.com> wrote:
>>> On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>>>
>>> Your for-x86-boot git boots on AMD system I have. However, with
>>> memmap=4095$1M option, it panics very early in boot. I don't have
>>> physical access to the console and I will try to get you the panic
>>> information tomorrow.
>>
>> panic is good, but it is supposed some kind of late..
>>
> 
> It is a very early panic, however it is not specific to your git. It
> happens on 3.4, 3.8-rc4. You can disregard the early panic for your
> git.
> 

Knocking out 4095 bytes is kind of an unusual action, however, assuming
the kernel is running at 16 MiB as normal then it should just work...

memmap=4095M$1M as was shown later is another matter... there the kernel
will be living inside the reserved region, and yes, at that point it is
panic time since there is nothing the kernel can do about it.

	-hpa


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