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. Message-ID: <Mutt.19961130165607.se@x14.mi.uni-koeln.de> In-Reply-To: <199611292217.XAA01440@ghost.mep.ruhr-uni-bochum.de>; from Robert Eckardt on Nov 29, 1996 23:17:41 %2B0100 References: <199611292217.XAA01440@ghost.mep.ruhr-uni-bochum.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ncr 53c810 scsi> rev 1 int a irq 9 on pci0:11 > ncr1 <ncr 53c810 scsi> 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 <ncr 53c810 scsi> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Mutt.19961130165607.se>