From owner-freebsd-hackers Wed Jun 14 01:43:34 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id BAA22752 for hackers-outgoing; Wed, 14 Jun 1995 01:43:34 -0700 Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id BAA22715 for ; Wed, 14 Jun 1995 01:43:08 -0700 Received: by FileServ1.MI.Uni-Koeln.DE id AA10668 (5.67b/IDA-1.5 for hackers@freebsd.org); Wed, 14 Jun 1995 10:41:15 +0200 Message-Id: <199506140841.AA10668@FileServ1.MI.Uni-Koeln.DE> From: esser@zpr.uni-koeln.de (Stefan Esser) Date: Wed, 14 Jun 1995 10:41:13 +0200 In-Reply-To: Bob Willcox "NCR SCSI driver emiting: in getcc reselect by t0." (Jun 13, 17:39) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Bob Willcox Subject: Re: NCR SCSI driver emiting: in getcc reselect by t0. Cc: hackers@freebsd.org Sender: hackers-owner@freebsd.org Precedence: bulk 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