[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CE7CF95.2040608@teksavvy.com>
Date: Sat, 20 Nov 2010 08:39:33 -0500
From: Mark Lord <kernel@...savvy.com>
To: huang ying <huang.ying.caritas@...il.com>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Huang Ying <ying.huang@...el.com>, Len Brown <lenb@...nel.org>,
linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>,
linux-acpi@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/2] Generic hardware error reporting support
On 10-11-20 02:11 AM, huang ying wrote:
>
> I think the BIOS error should be reported to hardware vendor instead
> of software vendor. Do you think so?
If you (and the code) are absolutely certain that a particular error instance
is totally due to the BIOS, then stick the words "BIOS ERROR" into the printk().
Problem solved.
And in the even that the diagnosis is wrong, the rest of us will still
have the complete picture of what happened from dmesg, rather than seeing
random kernel errors (from other code) happen later without knowing there
was some kind of BIOS or hardware fault that triggered it.
Having them all in one place is rather useful.
And you can still configure rsyslogd to _also_ send the BIOS/hardware
errors to a separate destination, if that turns out to be useful.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists