From owner-freebsd-current Tue Sep 23 15:32:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA09627 for current-outgoing; Tue, 23 Sep 1997 15:32:56 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA09583; Tue, 23 Sep 1997 15:32:46 -0700 (PDT) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA18872 (5.67b/IDA-1.5); Wed, 24 Sep 1997 00:32:42 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA04127; Tue, 23 Sep 1997 23:15:10 +0200 (CEST) X-Face: " Date: Tue, 23 Sep 1997 23:15:09 +0200 From: Stefan Esser To: Ollivier Robert Cc: "FreeBSD Current Users' list" , Stefan Esser Subject: Re: Assertion failed in ncr driver References: <19970922230618.13112@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970922230618.13112@keltia.freenix.fr>; from Ollivier Robert on Mon, Sep 22, 1997 at 11:06:18PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sep 22, Ollivier Robert wrote: > I get the following errors when I use dump to back up my machine. I thought > it is was the tags and sets the tags for my disks to 0 in the script but it > doesn't seem to make any difference. > > I have a SC-875 for both sd0 and sd2 (DCAS-34330W & DORS-32160). > > 203 [22:55] root@keltia:/build/xemacs-20.2# ncrcontrol -i > T:L Vendor Device Rev Speed Max Wide Tags > 0:0 IBM DCAS-34330W S65A 20.0 20.0 16 8 > 2:0 IBM DORS-32160 WA6A 20.0 20.0 8 8 > 4:0 TANDBERG TDC 3600 =08: ? 20.0 ? - > > ncr0: rev 0x03 int a irq 12 on pci0.11.0 > ncr0: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo > ncr0: single-ended, open drain IRQ driver, using on-chip SRAM > ncr0: restart (scsi reset). > ncr0 scanning for targets 0..6 and 8..15 (V2 pl24 96/12/14) > Choosing drivers for scbus configured at 0 > scbus0 at ncr0 bus 0 > sd is configured at 0 > sd0 at scbus0 target 0 lun 0 > sd0: type 0 fixed SCSI 2 > sd0: Direct-Access > sd0: NCR quirks=0x2 > > sd0: WIDE SCSI (16 bit) enabled > sd0: 40.0 MB/s (50 ns, offset 15) > 4134MB (8467200 512 byte sectors) > sd0: with 8205 cyls, 6 heads, and an average 171 sectors/track > sd is configured at 2 > sd2 at scbus0 target 2 lun 0 > sd2: type 0 fixed SCSI 2 > sd2: Direct-Access > sd2: NCR quirks=0x2 > > sd2: 20.0 MB/s (50 ns, offset 15) > 2063MB (4226725 512 byte sectors) > sd2: with 6703 cyls, 5 heads, and an average 126 sectors/track > > Any idea why I get these ? > > assertion "cp" failed: file "../../pci/ncr.c", line 6227 > sd0: COMMAND FAILED (4 28) @f0765800. > assertion "cp" failed: file "../../pci/ncr.c", line 6227 > sd0: COMMAND FAILED (4 28) @f0765c00. The command fails, since the drive returns a QUEUE_FULL status, which is the correct way to tell the drive can't deal with another tagged command, currently. (And, BTW, I found that drive to be faster without tags in a number of micro benchmarks I performed.) The problem with those IBM drives is, that they usually support a reasonable number of tagged commands, but in certain situations return QUEUE_FULL if less than 4 commands are issued at a time. The current generic SCSI code does not offer much support for this situation. If the driver just let the generic code issue a retry, then the command would fail again, since it will take the drive a few tens of milli-seconds before it is able to accept another command. The IBM drives often had problems with tagged START_STOP_UNIT commands, which are issued at the time a raw partition is opened (which is the case in dump). You may want to try with the call of scsi_start_unit() removed from /sys/scsi/sd.c. Justin Gibbs' new generic CAM SCSI layer will take care of this and other problems. If you are seeing this problem only in certain situations (e.g. while writing a backup), you may want to temporarily disable tagged commands for that drive. Regards, STefan