Return to BSD News archive
Newsgroups: comp.os.linux.hardware,comp.os.ms-windows.win95.misc,comp.os.os2.setup.misc,comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!fu-berlin.de!news.mathworks.com!hunter.premier.net!netnews.worldnet.att.net!ix.netcom.com!netcom.net.uk!netcom.com!stephenk From: stephenk@netcom.com (Stephen Knilans) Subject: Re: HELP: Can I mix memory speeds Message-ID: <stephenkDuxI2x.B5M@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <4s7rae$m3a@symiserver2.symantec.com> <stephenkDutwB2.52D@netcom.com> <4sr0bg$4ae@uriah.heep.sax.de> Date: Mon, 22 Jul 1996 05:04:08 GMT Lines: 38 Sender: stephenk@netcom.netcom.com Xref: euryale.cc.adfa.oz.au comp.os.linux.hardware:45175 comp.os.ms-windows.win95.misc:162107 comp.os.os2.setup.misc:17513 comp.unix.bsd.freebsd.misc:24184 In article <4sr0bg$4ae@uriah.heep.sax.de> joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) writes: >stephenk@netcom.com (Stephen Knilans) wrote: > >> MANY people have had computers WITHOUT parity or tests, and have had NO >> problems. I had several with BOTH, with NO problems! > >The problem is that you can detect memory misconfigurations, SIMM >contact problems etc. easier if you get it announced as a parity >error. Without parity, all you get is (eventually) a segmentation >fault, or a page fault while in kernel mode panic (or however these >things are called in other operating systems). Then you never know >whether it was a software problem or bad hardware. If the parity fault code is good, and you have good documentation, and the memory test isn't very good, you ARE right there. Most people, however, that don't try to push their computer to the limit, make BAD updates often, or use bad hardware, don't often run into these problems though. If I got a segementation problem that couldn't be explained, and saw a consistancy or frequency that would suggest it, I would instantly suspect hardware. The memory would be one of the first things I would check. If I had a problem discerning which SIMM, etc... and COULD, I'd simply write a good check program, and narrow it down. >Btw., panic does even try to flush the disk buffers, so its effect is >not as desastrous as you describe unless the disk subsystem itself is >hosed. But in this case, you lose anyway. Are you saying that Linux intercepts that interrupt, and flushes? That can be WORSE than you could imagine! What if the affected memory confuses it, or is some structural part of the disk? Even the most complicated disk system could probably be destroyed by only 3 bad blocks. SOME can be destroyed by one bad byte. Of course, you COULD scan other sections and rebuild, but that is usually the very LAST resort. Also, what if the disk is compressed? Steve