<div class="gmail_quote">On Fri, Apr 24, 2009 at 12:49 AM, John Hearns <span dir="ltr"><<a href="mailto:hearnsj@googlemail.com">hearnsj@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/4/23 Nifty Tom Mitchell <<a href="mailto:niftyompi@niftyegg.com">niftyompi@niftyegg.com</a>>:<br>
<div class="im">> On Thu, Apr 23, 2009 at 04:45:08PM +0100, Huw Lynes wrote:<br>
><br>
</div><div class="im">> IMO Running on a large cluster without multiple bit detection and a minimum of one bit<br>
> correction ECC is silly.<br>
><br>
> Further running without watching the ECC logs is also silly.  Watching the<br>
> logs can be hard to do.<br>
<br>
</div>Yes indeed.<br>
At the risk of being an SGI fanboy again, obviously SGI Altix systems<br>
keep excellent logs of hardware errors in /var/log/salinfo - indeed we<br>
had a DIMM fail the day before yesterday, I sent off the traces, and<br></blockquote></div><br clear="all">The EDAC drivers for Linux are able to do this for all x86_64 platforms up to but not including Nehalem (a driver hasn't been released yet). With EDAC, a whole slew of statistics are made available in /sys which can be used for reporting, tracking and tracing the failing DIMM down to physical socket. In fact, just a few weeks ago, AMD released 29 patches for Barcelona and Shanghai. (Unfortunately, these new patches only build on 2.6.30-rc*.)<br>
<br>At Advanced Clustering, we use this reporting facility in our Breakin software--we run BLAS-optimized linpack from a RAM filesystem and watch for EDAC messages.<br><br>-- <br> Jason D. Clinton, 913-643-0306<br>