public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gunther Mayer <gunther.mayer@gmx.net>
To: Dave Peterson <dsp@llnl.gov>
Cc: "bluesmoke-devel@lists.sourceforge.net" 
	<bluesmoke-devel@lists.sourceforge.net>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: noisy edac
Date: Tue, 31 Jan 2006 01:02:42 +0100	[thread overview]
Message-ID: <43DEA922.3030602@gmx.net> (raw)
In-Reply-To: <200601301552.09955.dsp@llnl.gov>

Dave Peterson wrote:

>On Monday 30 January 2006 15:44, Gunther Mayer wrote:
>  
>
>>>For each individual type of error that is specific to a particular
>>>low-level chipset driver (e752x, amd76x, etc.) there could be an entry
>>>in the appropriate part of the sysfs hierarchy under the given chipset
>>>driver.  This entry could have several settings that the user may choose
>>>      
>>>
>>>from such as { ignore, syslog, panic }.  For the implementation, there
>>    
>>
>>>could be a generic piece of code in the core EDAC module that a chipset
>>>driver calls into.  The generic code would do the dirty work of creating
>>>the sysfs entries (and destroying them when the chipset module is
>>>unloading).  How does this sound?
>>>      
>>>
>>Over-Engineered.
>>    
>>
>
>Do you have an alternate suggestion?
>  
>
Just printk() the exact driver specific low-level error, even if non-fatal.

Single non-fatal errors just show your system recovers correctly.

Multiple (e.g. noisy) non-fatal are either an indication of a serious 
problem
  (e.g. after how many corrected ECC errors on the same address in which
    time interval will you replace your dimm? How many S-ATA CRC-errors
     will indicate marginal bad cabling? )
or it shows the problem needs to be root analyzed. But don't disable the
messages as this will only hide the real problem.

Concerning Non-Fatal PCI Express errors, the error cause registers need
to be printed in case of error, too (see Intel Chipset Specifications)

-
Gunther



  reply	other threads:[~2006-01-31  0:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-27  1:41 noisy edac Dave Jones
2006-01-29 21:52 ` Alan Cox
2006-01-29 23:42   ` Dave Jones
2006-01-30 18:59     ` Doug Thompson
2006-01-30 19:58       ` Dave Peterson
2006-01-30 21:04         ` doug thompson
2006-01-30 22:24           ` Dave Peterson
2006-01-30 23:44             ` Gunther Mayer
2006-01-30 23:52               ` Dave Peterson
2006-01-31  0:02                 ` Gunther Mayer [this message]
2006-01-31  0:32                   ` doug thompson
2006-01-31  4:09                     ` Dave Peterson
2006-01-31  0:53                   ` Dave Peterson
2006-01-31  3:22                     ` Eric W. Biederman
2006-01-31  4:15                       ` Dave Peterson
2006-01-31 16:34                         ` doug thompson
2006-02-02  3:16                       ` [PATCH] EDAC printk() cleanup Dave Peterson
2006-02-02 16:16                         ` doug thompson
2006-01-31  3:28       ` noisy edac Eric W. Biederman

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=43DEA922.3030602@gmx.net \
    --to=gunther.mayer@gmx.net \
    --cc=bluesmoke-devel@lists.sourceforge.net \
    --cc=dsp@llnl.gov \
    --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