From owner-freebsd-current Fri Mar 22 22:27:46 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA02843 for current-outgoing; Fri, 22 Mar 1996 22:27:46 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA02837 Fri, 22 Mar 1996 22:27:43 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id WAA26014; Fri, 22 Mar 1996 22:23:23 -0800 From: "Rodney W. Grimes" Message-Id: <199603230623.WAA26014@GndRsh.aac.dev.com> Subject: Re: Crash advice needed APPENDIX B To: uhclem@nemesis.lonestar.org (Frank Durda IV) Date: Fri, 22 Mar 1996 22:23:23 -0800 (PST) Cc: hackers@freebsd.org, current@freebsd.org, uhclem@nemesis.lonestar.org In-Reply-To: from "Frank Durda IV" at Mar 22, 96 11:21:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ... > 6. Someone asked about the settings on the Barracuda, which is a > ST12550N (not a NW or ND). The jumpers are: > J4-9-10 Delay motor start (10 sec * ID) > J01- 2-4 Terminator power from pin 26 on the SCSI bus. > The resistor packs are installed (never removed). > The drive selected as controller 0. > > If someone thinks drive power for termination would be better, > I'll try it. Termination power from the drive is far far far far better... > In answer to another question, the above settings prevent the > Barracuda from supplying terminating power to the bus. That is fine and also desireable, it also happens to keep scsi bus induced noise from getting into the termination on the drive. ... > > 7. It has been suggested that I remove the cache. I'll just > mention that the cache and the board it is plugged-into were > both replaced earlier and there was no change in failure rate. > Further, this board/cache has no trouble with SCO UNIX, > Windows '95 and Windows NT which have all run on it previously > (for weeks at a time under heavy stress-loads using a program > called "evildisk" which is used to qualify hard disk drives). > The CPU also ran 1.1.5.1 and 2.0.5 which some crashes, but not > nearly the volume. Why would the cache "detect" 2.1.0 and fail > on cue? Because SCO Unix, Windows 95 and Windows NT are all gross in the way they handled bus master DMA disk controllers, they use a dedicated buffer area that is marked uncacheable just so they can run on the broken cache coherency motherboards. Can you say totally defeat the purpose of bus master DMA buy having the processor bcopy data around... > Granted, FreeBSD 2.0.5 did not like the cache when booting > a compressed kernel. It would always fail during uncompression. > This was fixed in 2.1.0 and I have seen no other solid > errors of that type. Big indication your board does infact have a cache coherency problem. > 8. By Pentium-class system from Rod. Ah, yes. Well that > might happen once the Triton IIs are stable, but it can't > happen today. I like this option for some strange reason :-) :-) :-) I tried again today to get PCI/I-P55T2P4 status from ASUS, but they had no new news for me :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD