Date: Mon, 29 Jun 1998 12:36:11 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-stable@FreeBSD.ORG Subject: Re: determining ecc errors on freebsd-stable Message-ID: <199806291636.MAA20240@brain.zeus.leitch.com> In-Reply-To: Mike Smith's message of "Sun, June 28, 1998 22:51:00 -0700" regarding "Re: determining ecc errors on freebsd-stable " id <199806290551.WAA22882@antipodes.cdrom.com> References: <3.0.5.32.19980628220904.008411f0@mail.sstar.com> <199806290551.WAA22882@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Sun, June 28, 1998 at 22:51:00 (-0700), Mike Smith wrote: ] > Subject: Re: determining ecc errors on freebsd-stable > > Jim King <jim.king@mail.sstar.com> > > > > At 05:04 PM 6/28/98 -0700, Tom <tom@uniserve.com> wrote: > > > > > > There is no way to log ECC corrections are they are done > > > transparently in the hardware, and currently there is no mechanism > > > for the hardware to make available that kind of info. > > > > My very newest PC (a Gateway 400 MHz Pentium II, just unboxed Friday) has > > an option in the BIOS configuration to log ECC corrections via DMI. I know > > almost nothing about DMI, but I would assume there's some way to get at > > this information besides the BIOS config utility. I've also been trying to find out how to log ECC errors on an ASUS P2L97 motherboard (using the Intel 440LX chipset). > Yes; you have to use the PnP BIOS. Unfortunately, we won't be able to > support this in the 2.2 family (it requires 3.x features). That sucks. But then why use the PnP BIOS anyway? (more on this below) > Typically, the system hardware will generate an SMI event during which > the SMI handler (part of the BIOS) will examine the ECC event(s) and log > them. I'd actually expect an NMI, at least on boards using Intel chipsets such as the 440LX. I don't think an SMI would make much sense. When I cause an SMI via the LM78 on my ASUS P2L97 motherboard the system seems to go into suspend mode. That's asssuming, of course, that the LM78's SMI pin is hooked up to the same SMI as the i82371 ASIC, which is a fair assumption given the apparent behaviour. > For Intel hardware, you should study the Intel datasheets, however it > should be noted that we cannot play on the BIOS side of the SMI fence - > we have to talk to it according to the rules, ie. you should be > focussing on using the PnP BIOS to obtain event log information, not > poking the hardware. I've always been very wary of anything claiming to be "PnP", even with the "(tm)" [suggesting it's some industry "standard"], and I've also been very wary of ever trying to access a system BIOS that wasn't designed with Unix firmly in mind. Poking at the hardware is often far simpler and avoids needless confusion and complication introduced by foreign interfaces. Unfortunately motherboard manufacturers make it really hard to know how to poke at the hardware (Intel's manuals are the best I've seen in PC-land recently, and they're far below good). One potentially positive potential seems is that the SMBIOS v2.1 spec. provides a pointer to the (packed) SMBIOS data structures residing somewhere in 32-bit physical address space so that the data can be accesssed from a 32-bit protected mode operating system. The only problem is that I don't see how an OS such as Unix is to allow the SMBIOS code to handle NMIs as it would need to in order to record things like ECC events. Yet another reason why it's probably better to just support the hardware directly. There's already ample direct hardware support in FreeBSD, and most of it is not going to go away no matter how fancy the BIOS gets (even the OpenFirmware guys are going direct to the hardware when they can for performance reasons), so a wee bit more hardware knowledge shouldn't hurt much. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com> 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?199806291636.MAA20240>