public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Andi Kleen <ak@muc.de>
Cc: Doug Thompson <norsk5@yahoo.com>,
	akpm@osdl.org, mm-commits@vger.kernel.org, norsk5@xmission.com,
	linux-kernel@vger.kernel.org
Subject: Re: + edac-new-opteron-athlon64-memory-controller-driver.patch added to -mm tree
Date: Tue, 04 Jul 2006 11:09:47 +0100	[thread overview]
Message-ID: <1152007787.28597.20.camel@localhost.localdomain> (raw)
In-Reply-To: <20060704092358.GA13805@muc.de>

Ar Maw, 2006-07-04 am 11:23 +0200, ysgrifennodd Andi Kleen:
> Regarding your buzzwords: I don't think mcelog is in any way
> less "manageable" or "consistent" than EDAC.

Its chip specific rather than generalised so you need awareness of it.

> > > Hmm, i haven't checked, but my understanding was that the newer
> > > Intel chipsets all forwarded the memory errors as machine 
> > > check anyways.
> > 
> > Quite a few still in use do not. We also have no idea where the future
> 
> New ones?  Would surprise me.

All the world is not x86. 

> Yes the machine check architecture doesn't try to handle all old systems,
> but then in practice error reporting on old x86 systems doesn't tend
> to work particularly well either.

Its pretty solid on the AMD 32bit chipsets and some of the older Intel
ones. 

> mce code also uses a consistent interface - it's even the same
> code in kernel space for all systems.

For the subset of cases it supports.

> We don't have a generic interface for logging some of the other errors
> (like PCI-E errors), but I don't see EDAC solving that. In some ways
> it's understandable because there is no generic PCI-E error handling
> code at all yet.

EDAC solves that for the PCI bus side. It's only solving the logging
side not the "ok it exploded, now what" question - although there are
some unrelated IBM patches in that area.

> > The ecc code predates the MCE bits by years. The re-doing occurred
> > rather earlier. Rather more useful would be to get the common interface
> 
> Earlier than the x86-64 machine check code?

Linux 1.2 I believe, certainly by 2.0

> Giving a consistent sysfs interface is a bit harder, but I suppose one 
> could change the code to provide pseudo banks for enable/disable too.
> However that would be system specific again, so a default "all on/all off" 
> policy might be quite ok.

I think we need the basic consistent sysfs case. Whether that is
provided by the mcelog code in the AMD64 case, or by an exported hook
from the MCE interfaces for AMD64 or duplicating the code in EDAC isn't
so important (avoiding duplication aside of course).


Alan


  reply	other threads:[~2006-07-04  9:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060701150430.GA38488@muc.de>
     [not found] ` <20060703172633.50366.qmail@web50109.mail.yahoo.com>
     [not found]   ` <20060703184836.GA46236@muc.de>
     [not found]     ` <1151962114.16528.18.camel@localhost.localdomain>
2006-07-04  9:23       ` + edac-new-opteron-athlon64-memory-controller-driver.patch added to -mm tree Andi Kleen
2006-07-04 10:09         ` Alan Cox [this message]
2006-07-04 11:34           ` Andi Kleen
2006-07-05 22:08             ` Alan Cox
2006-07-05 22:04               ` Andi Kleen
2006-07-06  6:12                 ` Eric W. Biederman
2006-07-06 13:01                   ` Andi Kleen
2006-07-06 15:31                     ` Eric W. Biederman
2006-07-06 16:51                       ` Andi Kleen
2006-07-06 17:46                         ` Eric W. Biederman
2006-07-06 18:08                           ` Andi Kleen
2006-07-06 18:34                             ` Alan Cox
2006-07-06 18:27                               ` Andi Kleen
2006-07-06 19:09                                 ` Eric W. Biederman
2006-07-06 19:18                                   ` Andi Kleen
2006-07-06 19:43                                     ` Eric W. Biederman
2006-07-06 18:43                             ` Eric W. Biederman
2006-07-05 17:39         ` Doug Thompson
2006-07-05 19:39           ` Andi Kleen

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=1152007787.28597.20.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mm-commits@vger.kernel.org \
    --cc=norsk5@xmission.com \
    --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