Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jun 1995 10:41:13 +0200
From:      esser@zpr.uni-koeln.de (Stefan Esser)
To:        Bob Willcox <bob@luke.pmr.com>
Cc:        hackers@freebsd.org
Subject:   Re: NCR SCSI driver emiting: in getcc reselect by t0.
Message-ID:  <199506140841.AA10668@FileServ1.MI.Uni-Koeln.DE>
In-Reply-To: Bob Willcox <bob@luke.pmr.com> "NCR SCSI driver emiting: in getcc reselect by t0." (Jun 13, 17:39)

next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 13, 17:39, Bob Willcox wrote:
} Subject: NCR SCSI driver emiting: in getcc reselect by t0.
} Right after starting a "tar tvf /dev/rst1" to list the contents of
} an 8mm tape I got a number of these messages:
} 
} /kernel: in getcc reselect by t0.
} 
} listed on the console.  I poked around in the source (sys/pci/ncr.c)
} and it seems that I shouldn't worry too much about it (though I've
} had 30 in the last 30 minutes) since the circumstances causing the
} message don't seem to be really an error and the system appears to
} still be running ok.  Can anyone shed some light on this?

The messages appear when doing a "tar tvf" ?
I guess there is other disk activity on target 0 on the same
host adapter as the tape is connected to ?


It is a common situation (depending on the load on the SCSI bus), 
that the SCSI host adapter wants to connect to a device, but 
another device has just succeeded arbitrating for the SCSI bus.
This situation is dealt with in the main loop of the code 
executed by the NCR.

But the GET_CC command is different from any other SCSI command, 
in that it may depend on the state of the drive after the previous 
command. (In a certain sense it may be considered the continuation
of the previous command to understand why it wasn't accepted or
returned an error condition.) 
For this reason, there is a completely independent subroutine to
send this command, and that subroutine prints a message when the
GET_CC could not be sent.

The GET_CC command is required after a drive ready change, but
AFAIK also after soft errors reading or writing the EXABYTE.
Since a soft error every few seconds is normal, there is quite 
a chance that some disk reconnects before the NCR got the EXABYTE
status. 

The warning is just there to give a hint if some device ever
couldn't accept the fact, that the NCR driver insists on first 
having the GET_CC command complete, before it will accept a 
reselect from any other device.
If it couldn't make this other device give up the bus, then the 
system would hang (and in the end a timeout would force a SCSI
bus reset).

} Here's my configuration:
} 
} P100, 256k cache, 32mb RAM, 4 NCR 810 PCI SCSI controllers with
} the following devices:
} 
} 1.   1 disk, 2 CDROM drives, 2 tape drives
} 2.   3 disks
} 3.   3 disks
} 4.   3 disks

Quite impressive !
4 * NCR SCSI (which motherboard is this ???)

Regards, STefan



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