From owner-freebsd-bugs Wed Oct 9 12:12:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA22658 for bugs-outgoing; Wed, 9 Oct 1996 12:12:04 -0700 (PDT) Received: from Octopussy (Octopussy.MI.Uni-Koeln.DE [134.95.212.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA22573 for ; Wed, 9 Oct 1996 12:11:19 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-43.slip.Uni-Koeln.DE) by Octopussy with SMTP id AA24825 (5.67b/IDA-1.5 for ); Wed, 9 Oct 1996 21:10:37 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.6/8.6.9) id VAA03662; Wed, 9 Oct 1996 21:09:12 +0200 (MET DST) Date: Wed, 9 Oct 1996 21:09:12 +0200 (MET DST) Message-Id: <199610091909.VAA03662@x14.mi.uni-koeln.de> From: Stefan Esser To: batie@aahz.jf.intel.com (Alan Batie) Cc: freebsd-bugs@freebsd.org Subject: Re: ncr error In-Reply-To: References: Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alan Batie writes: > One of our techs was trying to install FreeBSD 2.1.5 RELEASE this morning. > He'd gotten into sysinstall (unfortunately, I'm not sure just *where* in > sysinstall), and the debug screen showed the following: > > ncr0: aborting job ... > ncr0:1 ERROR (90:0) (8-0-0) (0/13) @ (c8c:50000000) > script cmd = 740a8700 > reg: de 00 00 13 47 00 06 0f 35 08 81 00 90 00 0f 02. > ncr0: restart (fatal error). > sd0(ncr0:1:0): COMMAND FAILED (9 ff) @f0b1e800 > sd0(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. > > I disabled the 2nd IDE controller (both onboard), for two reasons: 1. > he complained about a blank screen for about a minute or so during boot > up (I assume it was BIOS timing out on devices on 2nd ctrlr), and 2. > potential conflict with NCR on pci bus. > > This seems to have fixed the problem. Could you please send a verbose boot log for your system ? (Enter "-v" at the "Boot: " prompt.) This could have been caused by IRQ mapping problems, this is the only thing which might conflict between the NCR and an EIDE controller ... > I know it's not really a bug, per se, but perhaps it will help improve > handling of the condition, or maybe the 2nd ctrlr didn't really help, > just coincidence? I don't know what the error codes mean... Well, they are not too meaningful in this particular case. A command was aborted with no data left to transfer. Then there is the exact position in the NCR SCRIPTS code, where this happened (in the WIDE SCSI negotiation code: Do you really have a WIDE SCSI drive connected ???) Please send some more information for me to understand what actually went wrong ... Regards, STefan