Date: Tue, 09 Jan 2001 20:26:23 -0600 From: David Kelly <dkelly@hiwaay.net> To: Chris Dillon <cdillon@wolves.k12.mo.us> Cc: FreeBSD Chat List <freebsd-chat@FreeBSD.org> Subject: Re: ECC worth the extra cost for SOHO server? Message-ID: <200101100226.f0A2QNR65771@grumpy.dyndns.org> In-Reply-To: Message from Chris Dillon <cdillon@wolves.k12.mo.us> of "Tue, 09 Jan 2001 12:18:14 CST." <Pine.BSF.4.21.0101091210590.15567-100000@mail.wolves.k12.mo.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Dillon writes: > It LOOKS simple enough, but looks are always deceiving. I'll take a > shot at it if someone can point me at some documentation for the Intel > 440BX and the RCC ServerWorks chipsets (hopefully NOT under NDA), > which are the two chipsets I use in most of my FreeBSD boxen. I'll > nose around on Intel's developer site and on the ServerWorks site to > see if they have any info. > > I can already forsee one problem, though... How would I TEST it? I > don't have any flaky ECC memory lying around. :-) The only way I've found to "test" to see if a MB which says it does parity and/or ECC is to put narrow memory in it while enabling ECC or parity. If it bombs then its telling at least some of the truth. In the Bad Old Days when PC's were expensive cheap junk (rather than inexpensive) there were many MB's with a parity switch in the BIOS config yet made no difference what memory was installed. Anyway, if you have a trap in the FreeBSD kernel for handling ECC errors, if it can get past the boot phases without the BIOS enabling the feature, then FreeBSD could blow up and demonstrate the ECC report handler. Don't think that will work because the system would bomb the instant BIOS enabled ECC if you didn't have wide enough memory. Another way to test is if you knew how to enable the ECC feature on the chipset, enable it after FreeBSD is up and running with non-ECC or parity memory. A kernel switch maybe? Then disable it in the test ECC handler after a certain number of instances. Nope, that won't work because it will double fault for failing to repair an 8 bit fault when its only able to repair a 1 bit fault. Otherwise it would take a little hardware grafted onto a DIMM. Thinking of a flip flop that might collide with a data bit for one cycle only. And a switch for causing this single event on demand. Get really fancy and one could put an address decoder on the board to fault on one address only. A task for an FPGA guy. Roughly half the time it wouldn't work as a 1 would collide with a 1, or a 0 with a 0. Would want to be able to move the fault bit as some tests should be done on the data bits, and some should be done on the ECC/parity bits. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101100226.f0A2QNR65771>