Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Sep 1997 23:15:09 +0200
From:      Stefan Esser <se@FreeBSD.ORG>
To:        Ollivier Robert <roberto@keltia.freenix.fr>
Cc:        "FreeBSD Current Users' list" <freebsd-current@FreeBSD.ORG>, Stefan Esser <se@FreeBSD.ORG>
Subject:   Re: Assertion failed in ncr driver
Message-ID:  <19970923231509.55420@mi.uni-koeln.de>
In-Reply-To: <19970922230618.13112@keltia.freenix.fr>; from Ollivier Robert on Mon, Sep 22, 1997 at 11:06:18PM %2B0200
References:  <19970922230618.13112@keltia.freenix.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 22, Ollivier Robert <roberto@keltia.freenix.fr> 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: <ncr 53c875 fast20 wide scsi> 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: <IBM DCAS-34330W S65A> 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: <IBM DORS-32160 WA6A> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970923231509.55420>