Date: Fri, 11 Jun 2010 11:37:17 -0300
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Brian Gordon <legerde@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Aerospace and linux
Message-ID: <20100611143717.GF28084@khazad-dum.debian.net>
References: <AANLkTimrZvKyh6zYnUg2xzDVBVr5NxqtJhxZ42AVhkVI@mail.gmail.com>
 <4C112E7B.1040101@nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C112E7B.1040101@nortel.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1247
Lines: 28

On Thu, 10 Jun 2010, Chris Friesen wrote:
> On 06/10/2010 11:29 AM, Brian Gordon wrote:
> >     When these SEU can be detected some action may be taken to improve
> > the behaviour of the system  (log a fault and reset in order to
> > refresh things from scratch?).   So the first question becomes how to
> > detect an SEU.
> 
> I do work in telco stuff.  We use ECC RAM, turn on ECC/parity on the
> various buses, enable error-checking in the hardware, etc.

Let's not forget that the hardware better have unassisted scrubbing
(rewrite cells where an CE is detected), because we don't scrub when
we are notified of a CE.

Background scrubbing might also be something to look for (run over all
RAM over a large period of time, to catch dormant CEs and fix them
before they become UEs).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/