From owner-freebsd-hardware@FreeBSD.ORG Fri Aug 28 19:34:31 2009 Return-Path: Delivered-To: hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBCB106564A for ; Fri, 28 Aug 2009 19:34:31 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 59BBE8FC1A for ; Fri, 28 Aug 2009 19:34:31 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id BDA6A153435 for ; Fri, 28 Aug 2009 21:34:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52R2fjxM8HHM; Fri, 28 Aug 2009 21:34:27 +0200 (CEST) Received: from [192.168.10.242] (unknown [192.168.10.242]) by mail.digiware.nl (Postfix) with ESMTP id A4EA2153434 for ; Fri, 28 Aug 2009 21:34:27 +0200 (CEST) Message-ID: <4A983147.8080906@withagen.nl> Date: Fri, 28 Aug 2009 21:34:31 +0200 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: hardware@freebsd.org References: <200908262253.n7QMrauP063683@wattres.watt.com> <200908271130.18073.erich@apsara.com.sg> <20090827112229.GB14987@britannica.bec.de> <864ort1lw0.fsf@ds4.des.no> In-Reply-To: <864ort1lw0.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: enable ECC in OS code? X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:34:31 -0000 Dag-Erling Smørgrav wrote: > Joerg Sonnenberger writes: >> Erich Dollansky writes: >>> how should it be done at OS level at all when the OS is loaded >>> into RAM? >> Copy the kernel to the video RAM, jump to it, enable ECC, copy back. > > Not just the kernel - you have to copy all the memory that is currently > in use, including interrupt tables, the BIOS configuration space, shadow > copies of various ROMs... The CPU will probably not look too kindly on > having interrupt descriptors, segment descriptors, page tables etc. in > memory accessed through the I/O controller instead of the memory > controller. > > The machine might not even have video RAM! > > On systems that support ECC, I suspect that the BIOS enables it at the > same time as it configures the memory controller, which is one of the > very first things it does - literally within a few dozen (or perhaps a > few hundred) instructions from CPU reset - using only CPU registers, ROM > code, and configuration variables loaded from NVRAM. The way we did it when we were building Unix Systems in the 80's is that the output of the EEC checker on the memoryboards was gated to an High Prio Intr of an Open collectorline to the m68k. And that OC had a gate that was only enabled once we were sure that the whole memory had been test written. Remember that usually the memory in extention systems don't have EEC either. This holds for I/O registers, video memory, memory on networkcontrollers etc, unless we build the devices outselves... These memories also connects to the gate to allow access without triggering an EEC error. I have not ever looked into the HW of a current ECC controller but I expect there is a big chance that EEC parity always gets written. Not doing so will require extra gates in an already too long path from the XOR devices to the ECC cells (Thus reducing the writecycle time). ECC errors will only be flagged if EEC is enabled,but very likely EEC is always tested and/or written. So I would expect it to be "relatively simpele" read/write all the physical memory then enable the ECC intr/trap mechanism. --WjW