From owner-freebsd-hackers Thu Jul 10 21:06:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA14018 for hackers-outgoing; Thu, 10 Jul 1997 21:06:01 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA14012 for ; Thu, 10 Jul 1997 21:05:55 -0700 (PDT) Received: (qmail 10138 invoked by uid 1000); 11 Jul 1997 04:06:07 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 10 Jul 1997 21:06:07 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tom Samplonius Subject: Re: Make World Explodes Cc: FreeBSD-Hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom Samplonius; On 11-Jul-97 you wrote: > > On Thu, 10 Jul 1997, Simon Shapiro wrote: > > > I did. That is not it. > > Hmm, I just did a "make world" a couple of days ago, and that's all I > had to do. > > Is there is any chance your source tree is damaged. Try removing the > files in /usr/sup, and re-running cvsup. cvsup will then check every > file, rather than rely on the database in /usr/sup. DON'T TELL ME THAT :-( I do not mind re-creating the checked out version but re-doing cvsup is a long, painful process. > Also, how is the DPT driver coming? You can track the gory details in the SCSI mailing list; It runs now on every motherboard that the DPT can live on. It appears to be sensitive to some timing problems on the PCI bus. As long as good hardware is used andthe networking code is not interacting (appears unrelated), it is very stable. We use it routinely on about a dozen machines, build releases, backup to two tapes simultaneouly (three angered the SCSI layer in earlier version), and run up to 1048 instances of dd reading and writing to disk. Performance with RAID-5 is a constant 8.9MB/Sec writing/reading mix. RAID-0 is closer to 18-20MB/Sec. The only other problem is that if you use reboot instead of shutdown (or maybe shutdown itself), the kernel does not wait for the ``ALLOW MEDIA REMOVAL'' to complete before resetting the CPU. DPT uses this SCSI command to flush and invalidate the caches. Not waiting for it to finish can leave ``few'' buffers unwritten. ``Few'' can equal 64MB, which is unpeasant. It takes about 21-28.5 seconds to flush the caches written by newfs on a 4096MB file system. Simon