linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Peterson <dsp@llnl.gov>
To: doug thompson <dthompson@linuxnetworx.com>
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:24:16 -0800	[thread overview]
Message-ID: <200601301424.16884.dsp@llnl.gov> (raw)
In-Reply-To: <1138655061.8251.74.camel@logos.linuxnetworx.com>

On Monday 30 January 2006 13:04, doug thompson wrote:
> 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.

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?

  reply	other threads:[~2006-01-30 22:24 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 [this message]
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=200601301424.16884.dsp@llnl.gov \
    --to=dsp@llnl.gov \
    --cc=alan@redhat.com \
    --cc=bluesmoke-devel@lists.sourceforge.net \
    --cc=davej@redhat.com \
    --cc=dthompson@linuxnetworx.com \
    --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).