From owner-freebsd-stable Thu Oct 22 16:17:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20131 for freebsd-stable-outgoing; Thu, 22 Oct 1998 16:17:58 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA20119 for ; Thu, 22 Oct 1998 16:17:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA01737; Thu, 22 Oct 1998 16:19:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810222319.QAA01737@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: Mike Smith , Burkard Meyendriesch , freebsd-stable@FreeBSD.ORG Subject: Re: ECC memory support In-reply-to: Your message of "Thu, 22 Oct 1998 15:57:01 PDT." <199810222257.PAA17800@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Oct 1998 16:19:20 -0700 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Oct 22, 3:37pm, Mike Smith wrote: > } Subject: Re: ECC memory support > > } > The last time this subject came up, some folks wanted to use the BIOS > } > (which should understand the chipset on that motherboard) to retrieve > } > this information rather than build knowledge of specific chipsets into > } > the kernel. > } > } That would be the "nice" way to do it. I haven't made much progress > } pursuing things related to DMI lately, and it does look as though the > } way Microsoft want to do it you need to have motherboard-specific > } drivers installed. Some systems will preserve it in the BIOS event > } log, which theoretically can be retrieved - there's no guarantee that > } you will be able to arrange a trap on soft ECC, so you may have to live > } with this sort of deferred notification. > > In this case, who gets first crack at the NMI, the kernel or the BIOS? > If the kernel sees the NMI first and it calls the BIOS, it would know > if the BIOS handled the NMI and could then query the event log. If the > BIOS sees the NMI, then the kernel shouldn't even see it and at least > the machine won't silently reboot. Firstly, there's no guarantee that you're going to *get* an NMI on a soft ECC error. If the design integrates error detection into the BIOS, you're going to get an SMI and the BIOS will run regardless. If you did, there would be no point in calling the BIOS, as you already know what's going on. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message