Date: Mon, 29 Jun 1998 10:07:39 -0700 From: Mike Smith <mike@smith.net.au> To: freebsd-stable@FreeBSD.ORG Subject: Re: determining ecc errors on freebsd-stable Message-ID: <199806291707.KAA00714@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 29 Jun 1998 12:36:11 EDT." <199806291636.MAA20240@brain.zeus.leitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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). Log them or retrieve them from the log? Use the DMI interface to retrieve them from the log. > > 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) Because the BIOS is the only component that knows how the hardware is configured. > > 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. That depends on how the board implementor wants to do it. Using SMI means that you don't run the risk of the OS stealing the vector from you. > 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. Not necessarily. > > 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. Given that current BIOS standards are being developed and implemented with NT in mind, and given that NT is as anally 32-bit as most Unix systems are, I think you may need to reassess your position. > 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). The whole point is that you should *not* be poking at the hardware, but rather talking to the BIOS. This is just the same as eg. under OpenFirmware. (Performance isn't an issue for this sort of information, but abstraction and portability is.) > 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. Unfortunately, what you generally get with this is a minimal table in ROM (it varies between vendors) only describing the static hardware in the system. I have a tool for dumping this (via /dev/mem), I haven't found too many systems where there's much interesting there (as opposed to what can be retrieved using the LanDesk client, eg.). > 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. This is why board implementers use SMI. It's also used eg. for APM (see the APM mailbox register in the PIIX4). > Yet another reason why it's probably better to just > support the hardware directly. Not at all. Why try to support all the different hardware (an impossible task) when we can move up a level and use the same API that everyone else is using? It's documented and it works. -- \\ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806291707.KAA00714>