Re: APEI: ERST table in ACPI NVS not supported

[Chen Gong <gong.chen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Mon, Feb 04, 2013 at 09:06:24AM -0800, Max Asbock wrote:
> Date:	Mon, 04 Feb 2013 09:06:24 -0800
> From: Max Asbock <masbock@linux.vnet.ibm.com>
> To: gong.chen@intel.com, linux-acpi@vger.kernel.org, ying.huang@intel.com,
>  naveen.n.rao@in.ibm.com
> Subject: Re: APEI: ERST table in ACPI NVS not supported
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130108
>  Thunderbird/10.0.12
> 
> On 02/04/2013 01:20 AM, Chen Gong wrote:
> >On Tue, Jan 29, 2013 at 10:08:11AM -0800, Max Asbock wrote:
> >
> >
> >we have systems that declare the memory range for ERST in ACPI NVS.
> >Because ACPI NVS is marked 'busy' by e820_reserve_resources() the
> >call to request_mem_region(erst_erange.base, erst_erange.size, "APEI
> >ERST") made from erst_init() fails and we get:
> >ERST: Can not request iomem region<0x        7e91f000-0x
> >7e920c00>  for ERST.
> >
> >I did notice that quite some effort was made to add code to avoid
> >resource conflicts between APEI and ACPI NVS. But ERST still goes
> >straight to request_mem_region() which is bound to fail. I am
> >assuming this should go through apei_resources_request() instead or
> >I am missing something?
> >
> >If my understanding is right, after ERST resource is requested via
> >apei_resources_request and when requesting error log address range,
> >you meet an NVS conflict, right?
> >
> >If so, NVS must be excluded. But I'm afraid if error range is
> >separated into two parts thus some errors will be lost. Would you
> >please paste errage address range and conflicted NVS range?
> ACPI NVS is:
> 
> [    0.000000] BIOS-e820: [mem
> 0x000000007e6a5000-0x000000007ebc5fff] ACPI NVS
> 
> ERST erange is:
> 
> 0x7e91f000-0x7e920c00
> 
> which is a single range entirely within ACPI NVS.
> 
> thanks,
> Max
> 
If so, ERST erange can't be allocated. It looks like a BIOS bug.
I think your concern is meaningful but as I said, erange means
the whole ERST table entries, which means any overlap will cause
part of error records are lost. So the safest way is to refuse
the allocation for such type of range.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]