linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: doug thompson <dthompson@linuxnetworx.com>
To: Dave Peterson <dsp@llnl.gov>
Cc: Doug Thompson <norsk5@yahoo.com>, Dave Jones <davej@redhat.com>,
	Alan Cox <alan@redhat.com>,
	"bluesmoke-devel@lists.sourceforge.net" 
	<bluesmoke-devel@lists.sourceforge.net>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: noisy edac
Date: Mon, 30 Jan 2006 14:04:21 -0700	[thread overview]
Message-ID: <1138655061.8251.74.camel@logos.linuxnetworx.com> (raw)
In-Reply-To: <200601301158.09438.dsp@llnl.gov>

On Mon, 2006-01-30 at 11:58 -0800, Dave Peterson wrote:
> On Monday 30 January 2006 10:59, Doug Thompson wrote:
> > that driver should be refactored to only output NON-FATALs with debug
> > turned on.
> 
> I would prefer a sysfs option or something similar that allows the user
> to determine what action to take on these errors.  I think the debug
> option should only pertain to messages whose purpose is for debugging
> the EDAC code itself, as opposed to hardware errors detected by EDAC.

Something like an ERROR report verbose level?  0 to 7 like?

0 being quiet, 7 being very verbose? or the reverse. 

/sys/drivers/system/edac/mc/error_report_verbosity   ????

This tackles the immediate issue, but there is a systemic issue we have
to face sometime.

One problem that this e752x_edac module exhibits, which is manifest on
all of the drivers to one degree, is the output of driver specific error
messages directly, since there is not an abstracted error interface
(yet) in the EDAC core.  The messages are or can be very specific to the
MC being driven.  In time, we can (should) add a better MC error
interface to the core and then map errors from specific MC errors to the
new CORE error interface. Similiar to how SCSI and SATA have higher
level abstract errors which the transport drivers map errors to.

This e752x_edac module just plainly outputs to printk() with
KERN_WARNING w/o any other output control.

Looks like the old "how do we report errors" pattern, with its first
implementation now looking old.

doug t



> 
> > Copying to edac/bluesmoke mailing list
> >
> > doug t
> >
> > --- Dave Jones <davej@redhat.com> wrote:
> > > On Sun, Jan 29, 2006 at 04:52:06PM -0500, Alan Cox wrote:
> > >  > On Thu, Jan 26, 2006 at 08:41:05PM -0500, Dave Jones wrote:
> > >  > > e752x_edac is very noisy on my PCIE system..
> > >  > > my dmesg is filled with these...
> > >  > >
> > >  > > [91671.488379] Non-Fatal Error PCI Express B
> > >  > > [91671.492468] Non-Fatal Error PCI Express B
> > >  > > [91901.100576] Non-Fatal Error PCI Express B
> > >  > > [91901.104675] Non-Fatal Error PCI Express B
> > >  >
> > >  > Pre-production system or final release ?
> > >
> > > Currently shipping Dell Precision 470.
> > >
> > > 		Dave
> 



  reply	other threads:[~2006-01-30 21:04 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 [this message]
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
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=1138655061.8251.74.camel@logos.linuxnetworx.com \
    --to=dthompson@linuxnetworx.com \
    --cc=alan@redhat.com \
    --cc=bluesmoke-devel@lists.sourceforge.net \
    --cc=davej@redhat.com \
    --cc=dsp@llnl.gov \
    --cc=linux-kernel@vger.kernel.org \
    --cc=norsk5@yahoo.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;
as well as URLs for NNTP newsgroup(s).