public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>,
	"Chen, Gong" <gong.chen@linux.intel.com>,
	"arozansk@redhat.com" <arozansk@redhat.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 2/2] trace, RAS: Add eMCA trace event interface
Date: Tue, 11 Mar 2014 15:27:11 +0100	[thread overview]
Message-ID: <20140311142711.GB4773@pd.tnic> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F31DE8ADA@ORSMSX106.amr.corp.intel.com>

On Mon, Mar 10, 2014 at 05:37:19PM +0000, Luck, Tony wrote:
> Since we have separate trace points for EDCA and extlog - we can use
> different conventions for "invalid". If you think that changing the
> ABI in EDAC would be a problem - then you can keep running the almost
> infinitesimal chance that you have a real error at 0x00000000000000
> that you treat as unknown address.

I hardly believe changing that would be noticed by anyone.

> Does X86 actually allocate that page for use? - I know on Itanium
> it got thrown out when rounding usable blocks of memory to 16MB
> boundaries for cache coherency reasons.

Yeah, it turns out we reserve at least the first page - 64K by default
though - because BIOS likes to make love to that range. Detailed
explanation from Kconfig text below.

Still, for correctness sake at least, I think we should use a value
which denotes an invalid memory address, i.e. ~0x0, for example, and not
a valid one.

config X86_RESERVE_LOW
	int "Amount of low memory, in kilobytes, to reserve for the BIOS"
	default 64
	range 4 640
	---help---
	  Specify the amount of low memory to reserve for the BIOS.

	  The first page contains BIOS data structures that the kernel
	  must not use, so that page must always be reserved.

	  By default we reserve the first 64K of physical RAM, as a
	  number of BIOSes are known to corrupt that memory range
	  during events such as suspend/resume or monitor cable
	  insertion, so it must not be used by the kernel.

	  You can set this to 4 if you are absolutely sure that you
	  trust the BIOS to get all its memory reservations and usages
	  right.  If you know your BIOS have problems beyond the
	  default 64K area, you can set this to 640 to avoid using the
	  entire low memory range.

	  If you have doubts about the BIOS (e.g. suspend/resume does
	  not work or there's kernel crashes after certain hardware
	  hotplug events) then you might want to enable
	  X86_CHECK_BIOS_CORRUPTION=y to allow the kernel to check
	  typical corruption patterns.

	  Leave this to the default value of 64 if you are unsure.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-03-11 14:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-04  9:23 trace, RAS: New eMCA trace event interface Chen, Gong
2014-03-04  9:23 ` [PATCH 1/2] trace, RAS: Add basic RAS trace event Chen, Gong
2014-03-06 11:18   ` Borislav Petkov
2014-03-06 11:43     ` Mauro Carvalho Chehab
2014-03-06 12:17       ` Borislav Petkov
2014-03-06 13:06         ` Mauro Carvalho Chehab
2014-03-06 15:26           ` Borislav Petkov
2014-03-06 15:39             ` Mauro Carvalho Chehab
2014-03-07  6:21               ` Chen, Gong
2014-03-07  9:08                 ` Mauro Carvalho Chehab
2014-03-04  9:23 ` [PATCH 2/2] trace, RAS: Add eMCA trace event interface Chen, Gong
2014-03-07 11:44   ` Borislav Petkov
2014-03-10  8:22     ` Chen, Gong
2014-03-10 10:04       ` Mauro Carvalho Chehab
2014-03-10 10:31         ` Borislav Petkov
2014-03-10 11:41           ` Mauro Carvalho Chehab
2014-03-10 13:29             ` Borislav Petkov
2014-03-10 17:37               ` Luck, Tony
2014-03-11 14:27                 ` Borislav Petkov [this message]
2014-03-10 10:33       ` Borislav Petkov
2014-03-10 17:42       ` Luck, Tony
2014-03-11  7:03         ` Chen, Gong
2014-03-04 17:54 ` trace, RAS: New " Luck, Tony
2014-03-07  9:10   ` Mauro Carvalho Chehab
2014-03-10 18:55     ` Tony Luck
2014-03-10 19:41       ` Mauro Carvalho Chehab

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=20140311142711.GB4773@pd.tnic \
    --to=bp@alien8.de \
    --cc=arozansk@redhat.com \
    --cc=gong.chen@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=tony.luck@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox