All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Jacob Shin <jacob.shin@amd.com>, Tom Rini <trini@ti.com>,
	hpa@zytor.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"stable@kernel.org" <stable@kernel.org>
Subject: Re: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
Date: Mon, 22 Oct 2012 13:26:23 -0700	[thread overview]
Message-ID: <5085ABEF.3060502@linux.intel.com> (raw)
In-Reply-To: <CAE9FiQWZmwa6EwsfZzz_e3A-tz2LUS2+i+zh4zpXpR_Jj_FQ1w@mail.gmail.com>

On 10/22/2012 12:46 PM, Yinghai Lu wrote:
> On Mon, Oct 22, 2012 at 11:38 AM, Jacob Shin <jacob.shin@amd.com> wrote:
>>
>> Does EFI do this on above 4G memory? All the EFI BIOSes we have in house looked
>> to be only touching under 4G.
> 
> I have no idea about it.
> 

I don't think we can rely on what is happening right now anyway.

>>> 2. partial page:
>>>    E820 or user could pass memmap that  is not page aligned.
>>>    old cold will guarded by max_low_pfn and max_pfn. so the end partial
>>>    page will be trimmed down, and memblock can one use it.
>>>    middle partial page will still get covered by directly mapping, and
>>> memblock still can use them.
>>>    Now we will not map middle partial page and memblock still try to use it
>>> we could get panic when accessing those pages.
>>>
>>> So I would suggest to just revert that temporary patch at this time,
>>> and later come out one complete patch for stable kernels.
>>
>> Hm okay, I was hoping not, but if it has to be ..
> 
> It's hpa's call.

So the issue is that two E820 RAM ranges (or ACPI, or kernel-reserved)
are immediately adjacent on a non-page-aligned address?  Or is there a
gap in between and memblock is still expecting to use it?

We should not map a partial page at the end of RAM; it is functionally
lost.  Two immediately adjacent pages could be coalesced, but not a
partial page that abuts I/O space (and yes, such abortions can happen in
the real world.)

However, the issue obviously is that what we can realistically put in
3.7 or stable is limited at this point.

	-hpa




  reply	other threads:[~2012-10-22 20:26 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <903a3ead-98b5-4afa-88a4-3dc723895e82@blur>
     [not found] ` <d556fc0f-da5d-4531-b331-6dc086461f34@blur>
2012-10-21  0:17   ` BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot Tom Rini
2012-10-21  4:01     ` Yinghai Lu
2012-10-21  4:18       ` Jacob Shin
2012-10-21 17:51         ` Tom Rini
2012-10-21 21:06           ` Jacob Shin
2012-10-21 21:23             ` Tom Rini
2012-10-22 14:40               ` Jacob Shin
2012-10-22 18:05                 ` Yinghai Lu
2012-10-22 18:38                   ` Jacob Shin
2012-10-22 19:46                     ` Yinghai Lu
2012-10-22 20:26                       ` H. Peter Anvin [this message]
2012-10-22 20:50                         ` Yinghai Lu
2012-10-22 20:52                           ` H. Peter Anvin
2012-10-22 21:25                             ` Yinghai Lu
2012-10-22 21:27                               ` H. Peter Anvin
2012-10-22 23:35                                 ` Yinghai Lu
2012-10-24 16:48                                   ` Jacob Shin
2012-10-24 18:53                                     ` H. Peter Anvin
2012-10-24 19:53                                       ` Jacob Shin
2012-10-24 21:49                                         ` [tip:x86/urgent] x86, mm: Find_early_table_space based on ranges that are actually being mapped tip-bot for Jacob Shin
2012-10-25  6:42                                           ` Yinghai Lu
2012-10-25  7:55                                             ` Ingo Molnar
2012-10-25 14:33                                               ` Yinghai Lu
2012-10-25 22:23                                                 ` Jacob Shin
2012-10-25 23:31                                                 ` [tip:x86/urgent] x86, mm: Undo incorrect revert in arch/x86/mm/ init.c tip-bot for Yinghai Lu
2012-10-24 19:01                                   ` [tip:x86/urgent] x86, mm: Trim memory in memblock to be page aligned tip-bot for Yinghai Lu
2012-10-24 19:02                                   ` [tip:x86/urgent] x86, mm: Use memblock memory loop instead of e820_RAM tip-bot for Yinghai Lu
2012-10-22 21:00                           ` BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot H. Peter Anvin
2012-10-22 21:06                             ` Yinghai Lu
2012-10-28 20:48                 ` Tom Rini
2012-10-21 17:52       ` Tom Rini
2012-10-21  0:06 Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5085ABEF.3060502@linux.intel.com \
    --to=hpa@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jacob.shin@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=trini@ti.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.