From: Andi Kleen <ak@suse.de>
To: davidm@hpl.hp.com
Cc: davidm@napali.hpl.hp.com, iod00d@hp.com,
ishii.hironobu@jp.fujitsu.com, linux-kernel@vger.kernel.org,
linux-ia64@vger.kernel.org
Subject: Re: [RFC/PATCH, 1/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 20:39:15 +0100 [thread overview]
Message-ID: <20040128203915.22d84e8d.ak@suse.de> (raw)
In-Reply-To: <16408.3157.336306.812481@napali.hpl.hp.com>
On Wed, 28 Jan 2004 11:24:05 -0800
David Mosberger <davidm@napali.hpl.hp.com> wrote:
> >>>>> On Wed, 28 Jan 2004 19:52:46 +0100, Andi Kleen <ak@suse.de> said:
>
> >> I find this comment interesting. Can you elaborate what you mean by
> >> "slightly buggy systems"?
>
> Andi> e.g. one bit ECC errors in memory are quite common. And with
> Andi> ECC memory they are not really fatal.
>
> Yet they are a good indicator that something is wrong (not performing
> properly) or may be failing soon. I don't think putting on blinders
> for such problems is a good idea. Though I agree that the question of
Most server class hardware should log it somewhere and allow
to read the event log in the firmware. This even works for unhandleable
errors unlike what the OS could do.
But when printed in Linux they will report it to the linux maintainer or their
distribution vendor. "My Linux is buggy and giving these weird messages" And they
are both in no position at all to do something about it.
I toyed with the idea of printking a disclaimer of
"This is likely not a software bug. Report it to your hardware vendor."
But I doubt this would help much. Even when you say clearly in the message
that the hardware failed the user sees a weird message and thinks
it is Linux's fault.
You could enable it with CONFIG_I_HAVE_A_HARDWARE_SUPPORT_CONTRACT_OR_I_WRITE_DRIVERS
Or just make it a kernel command line option with off by default.
-Andi
next prev parent reply other threads:[~2004-01-28 19:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-28 1:54 [RFC/PATCH, 1/4] readX_check() performance evaluation Hironobu Ishii
2004-01-28 17:20 ` Grant Grundler
2004-01-28 17:41 ` Andi Kleen
2004-01-28 18:31 ` David Mosberger
2004-01-28 18:52 ` Andi Kleen
2004-01-28 19:24 ` David Mosberger
2004-01-28 19:39 ` Andi Kleen [this message]
2004-01-28 19:48 ` David Mosberger
2004-01-28 20:01 ` Andi Kleen
2004-01-28 23:35 ` David Mosberger
2004-02-16 10:19 ` Pavel Machek
2004-01-29 8:23 ` Matthias Fouquet-Lapar
2004-01-29 19:28 ` David Mosberger
2004-01-29 20:16 ` Matthias Fouquet-Lapar
2004-01-29 21:09 ` David Mosberger
2004-01-29 22:20 ` Matthias Fouquet-Lapar
2004-01-28 19:09 ` Grant Grundler
2004-01-28 19:17 ` Andi Kleen
2004-01-28 21:14 ` Grant Grundler
2004-01-28 21:39 ` Andi Kleen
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=20040128203915.22d84e8d.ak@suse.de \
--to=ak@suse.de \
--cc=davidm@hpl.hp.com \
--cc=davidm@napali.hpl.hp.com \
--cc=iod00d@hp.com \
--cc=ishii.hironobu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox