[ On , October 22, 2002 at 18:19:01 (-0400), Nathan J. Williams wrote: ]
> Subject: Re: Offtopic, Mainboard recommandation
>
> Given the history of PCs, I'd be rather surprised if anything
> defaulted to having this enabled, as opposed to depending on the OS to
> set it up.

Hmmm... something's causing this PPro thing to NMI too often...  :-)

On the other hand many IBM PC 325 servers (P-II's) I've run have never
even squawked in the slightest though I've more than once suspected one
of them of having memory problems.

> If you let me know what the chipset on that board is, I'll have a look
> at supporting when I do the work for the AMD MPX+.

Will this help?  I believe it's a just plain Intel 440FX PCIset.

NetBSD 1.5W (STARTING-OUT) #0: Mon Apr 15 17:11:15 EDT 2002
    woods@proven:/work/woods/NetBSD-src/sys/arch/i386/compile/STARTING-OUT
cpu0: Intel Pentium Pro (686-class), 199.35 MHz
cpu0: I-cache 8 KB 32b/line 4-way, D-cache 8 KB 32b/line 2-way
cpu0: L2 cache 256 KB 32b/line 4-way
cpu0: features f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR>
cpu0: features f9ff<PGE,MCA,CMOV>
[[ .... ]]
BIOS32 rev. 0 found at 0xfb3a0
mainbus0 (root)
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled
pchb0 at pci0 dev 0 function 0
pchb0: Intel 82441FX PCI and Memory Controller (PMC) (rev. 0x02)
pcib0 at pci0 dev 7 function 0
pcib0: Intel 82371SB PCI-to-ISA Bridge (PIIX3) (rev. 0x01)


I think I can also test on at least one model of the IBM PC 325 which
has the same PMC (though I'm not sure yet if I have access to a sample
DIMM with a bad or failing chip....):

NetBSD 1.5W (PROVEN) #1: Sat Aug 25 21:25:26 EDT 2001
    woods@proven:/work/woods/NetBSD-src/sys/arch/i386/compile/PROVEN
cpu0: Intel Pentium II (Klamath) (686-class), 299.22 MHz
cpu0: I-cache 16 KB 32b/line 4-way, D-cache 16 KB 32b/line 2-way
cpu0: L2 cache 512 KB 32b/line 4-way
cpu0: features 80fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
cpu0: features 80fbff<PGE,MCA,CMOV,MMX>
[[ .... ]]
BIOS32 rev. 0 found at 0xf0851
mainbus0 (root)
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled
pchb0 at pci0 dev 0 function 0
pchb0: Intel 82441FX PCI and Memory Controller (PMC) (rev. 0x02)
vga1 at pci0 dev 7 function 0: S3 Trio32/64 (rev. 0x54)
wsdisplay0 at vga1
ppb0 at pci0 dev 11 function 0: IBM 82351 PCI-PCI Bridge (rev. 0x01)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
[[ .... ]]
pcib0 at pci0 dev 19 function 0
pcib0: Intel 82371SB PCI-to-ISA Bridge (PIIX3) (rev. 0x01)


The 440FX PCIset specification says that bit#0 of the ERRCMD register
(0x90) controls whether the PMC asserts SERR# when it detects a
single-bit ECC error, and bit#1 controls SERR# assertion when a
multiple-bit ECC/Pairty error is encountered.  (and bit#3 controls SERR#
on PCI Parity errors).  There are also registers to read the row number
of where single-bit and multi-bit errors came from, and some indication
of how to translate the row number into a SIMM/DIMM slot number.


Sadly, but perhaps not unexpectedly, I read in the 440FX specification
update that:

	"When an Intel 440FX PCIset platform is configured for ECC
	support, if a multi-bit uncorrectable memory error is detected
	during a memory read by a ssytem device, and SERR, SCI, or SMI
	will be generated.  This typically results in an NMI.  However
	bad data may still reach the intended target before NMI can be
	generated or before NMI interrupt handler can service the
	problem.  This chipset was not architected or designed to ensure
	that taregets are protected from corrupted data in this
	situation."

I'm guessing that means if, for example, you're doing DMA to a disk
controller then it's probably too late to prevent corrupted data (or
maybe worse a corrupted command?) from being written to disk.....

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>