Messages in this thread | | | Date | Mon, 30 Jun 2008 12:58:59 -0700 (PDT) | From | Doug Thompson <> | Subject | Re: [PATCH 1/13] EDAC i5100 new intel chipset driver |
| |
--- Arthur Jones <ajones@riverbed.com> wrote:
> > 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?
The drivers don't print the information just because of these issues. The labeling action is left to user space via edac-utils. The label attributes in sysfs are initialized via a bootup daemon. Thereby EDAC (and the driver) provides a mechanism of storing the DIMM Label. (The driver is free to populate label if it so chooses, but that too could be overridden by userspace).
One driver I did for the Sicortex MIPS cluster only had TWO DIMMS, "East" and "West" on a 6 core processor card. The driver labeled those inside itself.
> > How do they get around these issues?
Late binding. Allow the setting of the label by userspace. edac-utils utilizes a file database of motherboards, which must be maintained yes, but it is flexible. An additional userspace program could source the labels via another mechanism.
Lawrence Livermore National Labs has tens of thousands of nodes, with 2, 4 or 8 CPUs per node, and they are the ones who developed the edac-utils userspace daemon and scripts.
http://sourceforge.net/projects/edac-utils/
The model for EDAC modules IS to leave the DIMM label blank for late binding of that information.
> > Thanks... > > Arthur
W1DUG
| |