From owner-freebsd-current  Wed Sep 24 07:15:33 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA00612
          for current-outgoing; Wed, 24 Sep 1997 07:15:33 -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 HAA00599
          for <freebsd-current@freebsd.org>; Wed, 24 Sep 1997 07:15:30 -0700 (PDT)
Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16905
  (5.67b/IDA-1.5 for <freebsd-current@FreeBSD.ORG>); Wed, 24 Sep 1997 16:13:06 +0200
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id NAA00850; Wed, 24 Sep 1997 13:27:08 +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: <19970924132707.59208@mi.uni-koeln.de>
Date: Wed, 24 Sep 1997 13:27:07 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: Ollivier Robert <roberto@keltia.freenix.fr>
Cc: freebsd-current@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> <19970924022224.06262@keltia.freenix.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <19970924022224.06262@keltia.freenix.fr>; from Ollivier Robert on Wed, Sep 24, 1997 at 02:22:24AM +0200
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sep 24, Ollivier Robert <roberto@keltia.freenix.fr> wrote:
> According to Stephen McKay:
> > 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
> 
> As for "reliably reproducing", it is very easy. Run dum(8) on /dev/sd0a and 
> I'll see the messages.

Well, then you may want to try without the
scsi_start_unit() call in the raw device
open function ...

Best if you enable SCSI debugging for that
target in the generic SCSI code. This will
show the command that is responsible for the
QUEUE_FULL status, and will let you verify,
that in fact no START_STOP_UNIT command is
sent anymore, when dump opens the partition
to backup.

Regards, STefan