Date: Thu, 22 Oct 1998 15:57:01 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Mike Smith <mike@smith.net.au>, Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Burkard Meyendriesch <bm@malepartus.de>, freebsd-stable@FreeBSD.ORG Subject: Re: ECC memory support Message-ID: <199810222257.PAA17800@salsa.gv.tsc.tdk.com> In-Reply-To: Mike Smith <mike@smith.net.au> "Re: ECC memory support" (Oct 22, 3:37pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810222257.PAA17800>