From owner-freebsd-hackers Fri Apr 11 06:47:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA19527 for hackers-outgoing; Fri, 11 Apr 1997 06:47:20 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA19522 for ; Fri, 11 Apr 1997 06:47:17 -0700 (PDT) Received: from dbws.etinc.com (dbws.etinc.com [204.141.95.130]) by etinc.com (8.8.3/8.6.9) with SMTP id JAA04559; Fri, 11 Apr 1997 09:51:46 -0400 (EDT) Message-Id: <3.0.32.19970411094404.00691d28@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 11 Apr 1997 09:44:07 -0400 To: Michael Smith From: dennis Subject: Re: 2.2.1R NFS and FTP load problem FOUND Cc: msmith@atrad.adelaide.edu.au, andreas@klemm.gtn.com, terry@lambert.org, hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 11:31 AM 4/11/97 +0930, Michael Smith wrote: >dennis stands accused of saying: >> >> >> >> BSDI comes with a RAM tester as add on utiliy on the BSDI CD. >> >> YOu can dd floppy image to floppy, boot from that floppy ... >> > >> >I tested a pile of RAM testers here at one stage while I was having a >> >running brawl with our then-RAM supplier about some memory I knew was >> >faulty. >> > >> >I didn't find a single one that would tell me the memory was busted, >> >but it most certainly was. (They eventually relented, stuck it on >> >their tester, said "oh, well it is actually stuffed" and replaced it. >> >We shop elsewhere now.) >> >> Blaming "bad ram" is like the doctor telling you you "have a virus" when he >> has no clue what else to tell you....... > >... despite the fact that he's right (most people have several viral >infections at any given point in time), and that if you're down it's >the best thing he can tell you anyway. If you want to argue about >this, I can redirect you at my SO (biotech) who will happily talk you >to death on the topic 8) > >> If you have real bad ram (a dead pin or a bad location(s)), you get >> consistent failures that go away when you replace the ram or use >> another machine. If you have "flakey" ram (bad timing, etc) you get >> random failures and crashes. f you get the same failure on 2 >> machines with different ram it ain't the ram..... > >That's lousy logic there Dennis, and you ought to know that. Matter of >fact, the bad RAM I was talking about before was in a group of four >machines, and all four were displaying RAM-like failures. Oddly, >replacing the RAM cured the problems. > >> db > >In your particular case, I don't buy the 'bad RAM' problem though. >Have you considered putting a 'vmstat' binary on the NFS partition >that you are loading from, and running 'vmstat -m' from the >holographic shell while the install is going? Without this sort of >detail, it's impossible to tell what's going on - I can't reproduce >your problems; I did an 'everything' install last night using NFS onto >an 8M 486 (using a locally cut 2.2-STABLE release) and it worked fine. It seems the only one that fails is "kernel developer"...I can do "everything" and bin only loads on both machines with 8 meg....if you could try that it would be cool. Dennis > >-- >]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ >]] Genesis Software genesis@gsoft.com.au [[ >]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ >]] realtime instrument control. (ph) +61-8-8267-3493 [[ >]] Unix hardware collector. "Where are your PEZ?" The Tick [[ > >