NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/sgi/13518

Internet Message Format | 1992-09-11 | 4.0 KB

Path: sparky!uunet!sun-barr!olivea!sgigate!odin!atl380.atlanta.sgi.com!georges
From: [e-mail] (George Smith)
Newsgroups: comp.sys.sgi
Subject: Re: SCSI disconnect or lack thereof in kernel/devices
Message-ID: <[e-mail]>
Date: 11 Sep 92 12:08:17 GMT
References: <[e-mail]>
Sender: [e-mail] (Net News)
Organization: Silicon Graphics, Inc.
Lines: 73
Nntp-Posting-Host: atl380.atlanta.sgi.com


 I'll take a stab at this one.. Dave can straighten out in incorrect info.

In article <[e-mail]>, [e-mail] (Jeff Carey) writes:
|>
|> We have a SCSI device attached to a SGI PI25 running IRIX 4.0.5A that I know
|> does not support SCSI disconnect.
|> The kernel, in particular /usr/sysgen/master.d/scsi, has not been changed.
|> There is a line in there that currently reads:
|> int scsi_enable_disconnect[SC_MAXADAP] = {1,1,1,1};
|>
|> The device seems to work, and just as importantly, the whole system seems
|> to work just fine while using the non-disconnecting device.  Obviously,
|> the SCSI bus is locked down when said device is being accessed.
|>

  By default we allow SCSI devices to disconnect from the bus. A device is not
required to do so however. The problem comes from the fact that our SCSI
devices, disks, tapes, etc do disconnect and your device doesn't. The disconnected
devices are expected  to reconnect to their initiator with in a timeout period which is
around 30 seconds for the disk drives. If they cannot the SCSI bus will be reset.
Hence your message on the console and SYSLOG that a timeout has occurred and the
SCSI bus has been reset.
  Since SCSI device activity is outside of a user's control ( to some extent anyway)
one can never be sure how long is too long to hold the bus. Hence with non-disconnecting
devices you may run in to trouble even if the device only holds the bus for short periods
of time. For devices which require many seconds of bus time you will almost allways
run into problems.

|> My questions are:
|> 1.  Is it necessary for some as-yet unrecognized reason to disable disconnect
|>     on the host adapter with said device?

  Yes. (see above)

|> 2.  Is it beneficial (integrity, speed, dependability-wise) to disable
|>     disconnect on the host adapter?

 Generally system performance will suffer when not allowing disconnects. In particular
if you are using a tape device with a high SCSI id (often SCSI id 7 on SGI machines).
The higher the SCSI id the higher the arbitration priority for the SCSI bus. With
tape devices taking the bus often and for long periods of time system performance
goes down the tubes.

|> 3.  Should I expect similar success(/failure) rates on other machines, such
|>     as PI35s, Indigos, Crimsons (with their two host adapters), etc?  (I can
|>     not imagine graphics options 8-bit, Elan, etc. would have any affect.)
|>
  Any SCSI bus will in general have the same problems with non-disconnecting devices.
On the ASD machines ( Crimsons, etc) with a IO3 there are two SCSI buses. If one
is used for you device and the other for you disks then system performance should not
be impacted to the same extent as a single SCSI bus. Also I believe on the IO3 you
could allow disconects on one bus while disallowing disconnects on the other so impact
might be eliminated. ( Dave can confirm/deny this..)

|> Could someone (Dave) expound on the usage and potential advantages of the
|> scsi_enable_disconnect variable beyond what the comments in the
|> /usr/sysgen/master.d/scsi file and the last note in the dks(7M) man page
|> say when using non-disconnecting devices.
|>
|> Thanks for all your help,
|>
|> -jeff
|>
|> --
|> Jeff Carey
|> [e-mail]       (or: contex![e-mail])

--
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|  George Smith  (Systems Engineer) | ph.[phone]              |
   Silicon Graphics Inc.              Email: [e-mail]
|  Atlanta,Ga.                      | Vaya con Dios            |