From owner-freebsd-hackers  Tue Aug 27 07:00:16 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id HAA06527
          for hackers-outgoing; Tue, 27 Aug 1996 07:00:16 -0700 (PDT)
Received: from heathers.stdio.com (risner@heathers.stdio.com [204.152.114.65])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA06501;
          Tue, 27 Aug 1996 07:00:07 -0700 (PDT)
Received: (from risner@localhost) by heathers.stdio.com (8.6.12/8.6.13) id JAA02300; Tue, 27 Aug 1996 09:59:07 -0400
Date: Tue, 27 Aug 1996 09:59:07 -0400
From: James Risner <risner@heathers.stdio.com>
Message-Id: <199608271359.JAA02300@heathers.stdio.com>
To: freebsd-hackers@freebsd.org
Subject: SCSI ncr.c assertion fail due to S_QUEUE_FULL error.
Cc: freebsd-scsi@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I have a 3.5 GIG drive:
ncrcontrol -u 1
T:L  Vendor   Device           Rev  Speed   Max Wide Tags
1:0  DEC      RZ74     (C) DEC 427H  10.0  10.0   8    4

on heavy disk seeking I get:
sd1(ncr1:1:0): COMMAND FAILED (4 28) @f09fb000.
assertion "cp" failed: file "../../pci/ncr.c", line 5563

I looked up the COMMAND.FAILED code and found that 4 28 means:
COND_MET or HS_COMPLETE and QUEUE_FULL

I looked up the code about QUEUE_FULL which it does not run and it sets
tags to 0 to fix.

I set tags to 1 with
ncrcontrol -u 1 -t 1 -w -stags=1

The problem went away.
Now it is:
ncrcontrol -u 1
T:L  Vendor   Device           Rev  Speed   Max Wide Tags
1:0  DEC      RZ74     (C) DEC 427H  10.0  10.0   8    1

Who's problem was present?
SCSI system for not probing the drive and setting the tags lower somehow?
ncr.c for not properly reseting after a QUEUE_FULL from a disk?

Or both?

Risner