From: Huang Ying <ying.huang@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Len Brown <lenb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: RE: [RFC] ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Date: Thu, 16 Dec 2010 08:45:06 +0800 [thread overview]
Message-ID: <1292460306.12648.1207.camel@yhuang-dev> (raw)
In-Reply-To: <987664A83D2D224EAE907B061CE93D530193C9D504@orsmsx505.amr.corp.intel.com>
On Thu, 2010-12-16 at 00:40 +0800, Luck, Tony wrote:
> >Because the memory area used to transfer hardware error information
> >from BIOS to Linux can be determined only in NMI, IRQ or timer
> >handler, but general ioremap can not be used in atomic context, so a
> >special version of atomic ioremap is implemented for that.
> >
> >Known issue:
> >
> >- Error information can not be printed for recoverable errors notified
> > via NMI, because printk is not NMI-safe. Will fix this via delay
> > printing to IRQ context via irq_work or make printk NMI-safe.
>
> Would it be possible to defer the "ioremap" to a work queue too? Then
> we wouldn't need the special versions of ioremap.
For recoverable error, we can defer the "ioremap" to a work queue,
because most recoverable action can take place only there in fact. But
for fatal error, I think it is too late to be processed in a work queue,
we need go panic as soon as possible to prevent data corruption.
Best Regards,
Huang Ying
prev parent reply other threads:[~2010-12-16 0:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 5:34 [RFC] ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support Huang Ying
2010-12-15 16:40 ` Luck, Tony
2010-12-16 0:45 ` Huang Ying [this message]
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=1292460306.12648.1207.camel@yhuang-dev \
--to=ying.huang@intel.com \
--cc=andi@firstfloor.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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