From owner-freebsd-current  Tue Sep 23 15:32:39 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA09550
          for current-outgoing; Tue, 23 Sep 1997 15:32:39 -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 PAA09517;
          Tue, 23 Sep 1997 15:32:25 -0700 (PDT)
Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA18845
  (5.67b/IDA-1.5); Wed, 24 Sep 1997 00:32:15 +0200
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id AAA04387; Wed, 24 Sep 1997 00:24:58 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
 yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
 EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-Id: <19970924002457.23769@mi.uni-koeln.de>
Date: Wed, 24 Sep 1997 00:24:57 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Stephen McKay <syssgm@dtir.qld.gov.au>
Cc: freebsd-current@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG>
Subject: Re: Assertion failed in ncr driver
References: <19970922230618.13112@keltia.freenix.fr> <19970923053330.QX53740@uriah.heep.sax.de> <199709230513.PAA18083@ogre.dtir.qld.gov.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <199709230513.PAA18083@ogre.dtir.qld.gov.au>; from Stephen McKay on Tue, Sep 23, 1997 at 03:13:29PM +1000
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sep 23, Stephen McKay <syssgm@dtir.qld.gov.au> wrote:
> >> sd0: COMMAND FAILED (4 28) @f0765800.

> I occasionally see these errors with my Diamond FirePort 40 (53c875j based)
> and IBM DCAS-34330W.  I have exchanged a bit of mail with Stefan already,
> but no promising leads developed.  I have no way of reliably reproducing
> the problem, but I do know it has been there a long time because it was
> happening when I ran 2.2.2 (slightly modified to recognise the 875j).
> 
> Could the disk be a rogue after all the praise we've heaped on it?

No, not a rogue, but a little picky
about tagged commands, at times. 

This should become a non-issue when
the new CAM SCSI code is commited by
Justin Gibbs, since he offers support
for tagged commands and that code will
understand the QUEUE_FULL status from
a drive that does not want to accept 
another tagged command ...

Regards, STefan