From owner-freebsd-scsi Sun Jan 7 11:45:58 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by hub.freebsd.org (Postfix) with ESMTP id 5874D37B400 for ; Sun, 7 Jan 2001 11:45:40 -0800 (PST) Received: from nas1-162.mea.club-internet.fr (nas1-162.mea.club-internet.fr [195.36.139.162]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA12413; Sun, 7 Jan 2001 20:45:33 +0100 (MET) Date: Sun, 7 Jan 2001 19:45:06 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Justin T. Gibbs" Cc: Darren Joy , freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: <200101071628.f07GSHs61375@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 7 Jan 2001, Justin T. Gibbs wrote: > >> If I try to install the ports distibution, I get the following errors = : > >>=20 > >> ncr0: queue empty > >> ncr0: queue empty > >> ncr0: queue empty > >> ncr0: queue empty > >> > > > >Looks like the device is returning QUEUE FULL status and the NCR does no= t > >see any command currently pending at device side (i.e. SCSI I/O having > >been disconnected). >=20 > You still pass this code up to CAM, right? =20 It is what the NCR code is doing. It completes the command with QUEUE FULL status. The above message looks to me informational only. The SYM does the same but silently (+ returns to XPT for requeuing all commands for this device not yet started, in order to preserve initial ordering of IOs). > The XPT should be treating > it as a BUSY status and deferring I/O for a bit. Perhaps some recent > change in CAM has broken this behavior. We should check. If CAM does not delay the retry, a storm of QUEUE FULL statuses may occur, but this should not harm in theory (just load uselessly the machine). Practice could be pretty different. The SYM reported bad reselections on this system under 4.2 (device selecting for tasks that didn't exist in driver context). In the same situation the NCR also aborts the IO using appropriate messages, but silently. The same system was reported by Darren to works flawlessly with the NCR in FreeBSD-3.2. Darren should check if tagged command queuing was enabled for his Conner hard disk in the configuration that worked. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message