From owner-freebsd-scsi Sat Nov 30 10:12:28 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA28662 for freebsd-scsi-outgoing; Sat, 30 Nov 1996 10:12:28 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA28649 for ; Sat, 30 Nov 1996 10:12:19 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA00323 (5.67b/IDA-1.5 for ); Sat, 30 Nov 1996 19:12:10 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.3/8.6.9) id QAA01069; Sat, 30 Nov 1996 16:57:28 +0100 (CET) Message-Id: Date: Sat, 30 Nov 1996 16:56:07 +0100 From: se@freebsd.org (Stefan Esser) To: roberte@mep.ruhr-uni-bochum.de (Robert Eckardt) Cc: scsi@freebsd.org Subject: Re: CACHE TEST FAILED: script execution failed. References: <199611292217.XAA01440@ghost.mep.ruhr-uni-bochum.de> X-Mailer: Mutt 0.52 Mime-Version: 1.0 In-Reply-To: <199611292217.XAA01440@ghost.mep.ruhr-uni-bochum.de>; from Robert Eckardt on Nov 29, 1996 23:17:41 +0100 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 29, roberte@mep.ruhr-uni-bochum.de (Robert Eckardt) wrote: > Hi All, > > after experimenting around for a while I'm clue-less how to solve > the following problem. > > The machine is a Pentium-133, 32MB RAM, ASUS-Board (don't know the model-id > right now) with 2 NCR controllers, 2GB IBM disk, hp DAT, 7 Teac CDROMs > running 2.1.5-RELEASE. > I generated a kernel with firewall enabled, superfluous devices disabled > and some params tuned (I can send the config file on request). > After the problem occurred I tried different combinations but to no avail. > > When I boot it finds the 1st NCR, all the devices, the 2nd NCR, the > error message and goes on with the ISA devices. > > Nov 27 19:26:07 bug /kernel1: > Probing for devices on PCI bus 0: > ncr0 rev 1 int a irq 9 on pci0:11 > ncr1 rev 2 int a irq 12 on pci0:12 > CACHE TEST FAILED: script execution failed. The code for this is at the end of the NCR driver (/sys/pci/ncr.c). Look for the function ncr_snooptest() ... It tries to make the NCR execute a very simple program, which in fact only reads and writes some variables in the host systems memory space. The code waits a few hundred microseconds for the NCR chip to reach an INT instruction. If there is no interrupt in time, then the NCR appears to not be able to execute any instructions at all ... If the NCR fails to complete this simple test program within a few tens of microseconds, then there is no chance it will later be able to execute the "microcode" that makes it perform SCSI transactions. > The GENERIC kernel correctly continues: > Nov 18 17:09:21 bug /kernel.GENERIC: > ncr1 rev 2 int a irq 12 on pci0:12 > ncr1 waiting for scsi devices to settle > (ncr1:2:0): "TEAC CD-ROM CD-56S 1.0B" type 5 removable SCSI 2 > cd2(ncr1:2:0): CD-ROM > [....] > > > In the beginning I found that the CACHE TEST FAILED appeared when > SCSI_DELAY=15 was NOT in. After putting this option in it detected > all devices on the second SCSI bus, however it panicked after > `changing root device to sd0a'. Hmmm, that's really strange ... Did you try swapping controller cards ??? > I further reduced the configuration and now I get CACHE TEST FAILED > with SCSI_DELAY=15 included! > (What cache, what script ???) See above. I can send you my phone number, if you want to discuss further details and ways to test this ... > Since I know for sure that the provided information is not what is needed > and the important information is missing, any response that helps me to > find out what goes wrong is appreciated. I actually don't understand what is failing. But we might get it narrowed down with some tests. For example, I'd need to know, whether the second NCR chip does execute any instructions at all, or whether it can't be activated. The GENERIC kernel should have been built with FAILSAVE #defined. But I do not see how that might make a difference for the early probe phase that is causing you problems. You may try a custom kernel with "options FAILSAFE" anyway ... Regards, STefan