From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: [PATCH 0/2] Generic hardware error reporting support Date: Sat, 20 Nov 2010 08:39:33 -0500 Message-ID: <4CE7CF95.2040608@teksavvy.com> References: <1290154233-28695-1-git-send-email-ying.huang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58999 "EHLO ironport2-out.pppoe.ca" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753768Ab0KTNjh (ORCPT ); Sat, 20 Nov 2010 08:39:37 -0500 In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: huang ying Cc: Linus Torvalds , Huang Ying , Len Brown , linux-kernel@vger.kernel.org, Andi Kleen , linux-acpi@vger.kernel.org, Peter Zijlstra , Andrew Morton , Ingo Molnar , Mauro Carvalho Chehab , Borislav Petkov , Thomas Gleixner 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