Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760399AbYF3PDS (ORCPT ); Mon, 30 Jun 2008 11:03:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751771AbYF3PDG (ORCPT ); Mon, 30 Jun 2008 11:03:06 -0400 Received: from smtp1.riverbed.com ([206.169.144.12]:1426 "EHLO smtp1.riverbed.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbYF3PDF (ORCPT ); Mon, 30 Jun 2008 11:03:05 -0400 Date: Mon, 30 Jun 2008 08:03:46 -0700 From: Arthur Jones To: Doug Thompson CC: Andi Kleen , "dougthompson@xmission.com" , "akpm@linux-foundation.org" , "bluesmoke-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/13] EDAC i5100 new intel chipset driver Message-ID: <20080630150346.GF10571@ajones-laptop.nbttech.com> References: <87r6aip2pi.fsf@basil.nowhere.org> <77374.55758.qm@web50103.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <77374.55758.qm@web50103.mail.re2.yahoo.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2483 Lines: 69 Hi Doug, ... On Fri, Jun 27, 2008 at 11:15:06PM -0700, Doug Thompson wrote: > > --- Andi Kleen wrote: > > > dougthompson@xmission.com writes: > > > > > > 2) I have not yet tackled the de-interleaving of the > > > rank/controller address space into the physical address > > > space of the CPU. There is nothing fundamentally missing, > > > it is just ending up to be a lot of code, and I'd rather > > > keep it separate for now, esp since it doesn't work yet... > > > > > > 3) The code depends on a particular i5100 chip select > > > to DIMM mainboard chip select mapping. This mapping > > > seems obvious to me in order to support dual and single > > > ranked memory, but it is not unique and DIMM labels > > > could be wrong on other mainboards. There is no way > > > to query this mapping that I know of. > > > > Since there's a non negligible probability that the output > > of this driver is completely misleading because of (2) and (3) > > and probably (4) too [reporting the wrong DIMMs etc.] > > would it be possible to add some flag to EDAC that > > warns the user that the output is not fully reliable?\ > > good idea. > > Arthur, could you add some more text to the driver's output, before the call to the > core's output function, doing exactly that? Explaining just what you DO know, and what you don't > know? Everything should be good except the DIMM label. There are all kinds of ways this could be wrong (mainboard labelling, mainboard routing, ...). I think it might be better just to leave this blank. Are there any EDAC drivers that properly report the DIMM label? How do they get around these issues? Thanks... Arthur > > > > -Andi (who can just see people replacing the wrong DIMMs and > > then blaming Linux) > > > > > > > W1DUG > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > bluesmoke-devel mailing list > bluesmoke-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bluesmoke-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/