Original message:
>
> System: Sun Sparc-2 running 4.0.3
> several SCSI devices attached
Correction: The machine is a Sparc-2 (4/75) running 4.1.1.
(Sorry for the error, most respondents pointed out
that you cannot run 4.0.3 on a Sparc-2)
>
> I have been running the above system for months without any problems.
> The SCSI devices in question appear in the listings below. All SCSI
> devices used start synchronously at boot time, but after moving the
> system from one corner of the lab to another, they will only come up
> asynchronously (The complete original message is appended)...
>
The problem was a faulty cable.
Most answers pointed to the sensitivity of SCSI to cable length and
cable positioning. My original message was somewhat unclear as to
whether I kept same peripherals, same cables, etc. I did indeed just
pick up the system and move it from one corner of the lab to another
corner with absolutely no change - same system, peripherals, cables...
I did go and read the SCSI specs to confirm that the maximum bus
length for single-ended SCSI (as opposed to differential SCSI) is 6
meters. My cables measured a total of 5.5 meters.
Taking devices off the bus, one by one, pointed to the last device on
the daisy chain (a Cipher tape drive), with the conclusion that the
problem was either in the drive's SCSI cable (an unshieled
ribbon cable) or the drive's SCSI interface. The cable seemed to
be the least expensive thing to fix, even though it had to be
custom-made (50 pin unshielded connector; "printed circuit
connector"). MAKING THIS NEW CABLE AND REPLACING THE OLD ONE FIXED
THE PROBLEM COMPLETELY.
In addition to learning that a simple connector on one device of the
SCSI chain can mess up the whole bus, I am now accutely aware of
the variety of different SCSI connectors. Four different types are
used in our systems:
- Unshielded Connector ("printed circuit board)
- Shielded Alternative 2 Connector ("Centronics")
- Sun Microsystems Compatible Connector (DB50)
- SCSI 2 connector (Micro SCSI)
There is yet another type, Shielded Alternative 1, which I have never
seen. Needless to say that this variety of connectors makes it
difficult to shift around cables for testing; especially since the
cables are expensive and therefore often not kept in stock.
Here is a summary of responses to my original message:
. My only suggestion would be to check cable lengths. SUN's SCSI is
very sensitive.
. did you make any of the cables longer?
. Perhaps you had the cords coiled "just so" before that it got better
SCSI throughput (i.e., less noise). Try rearranging them, or, better
yet, getting shorter ones.
. There isn't really a way to force it. Sync operation is the result
of a negotiation between the host adaptor and the target. If that
negotiation breaks down, or the error rate is too high, sync goes
right off.
. sync negotiation became the default in SunOS 4.1.1, so if the SCSI
bus and the connected interfaces are operating error-free and at a low
noise level, the SCSI devices will come up synchronously (at least
those that are capable of it)
. by default (unless you've changed the kernel), the sun host will
always ask the scsi devices if they'd like to run sync or not. when
you moved the equipment, you may have damaged cables, increased their
lengths, or somehow made it harder for the disks to negotiate sync
transfers.
Thanks alot to:
Hal Stern <stern@sunne.east.sun.com>
Mark Seiden <mis@seiden.com,>
Mike Raffety <miker@sbcoc.com>
Anthony A. Datri <datri@concave.convex.com>
Brett Chapman <chapmanB@med.ge.com>
Kevin Sheehan <kevins@aus.sun.com>
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Rudolf W. Nottrott |
| Long-term Ecological Research (LTER) |
| Network Office |
| College of Forest Resources AR-10 Phone: (206) 543-8492 |
| University of Washington FAX: (206) 685-0790 |
| Seattle, Washington 98195 |
| |
| Electronic Mail: |
| Internet: rNott@LTERnet.Washington.edu |
| Bitnet: rNott@LTERnet |
| Forest Service: LTERNET:X400 (FORWARD: rNott) |
| Omnet: (site:internet, id:<rNott(a)LTERnet.washington.edu>) |
| UUCP: uw-beaver!LTERnet!rNott |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
COMPLETE ORIGINAL MESSAGE====================================================
Date: Tue, 1 Oct 91 12:27:01 PDT
From: Rudolf Nottrott <rnott@lternet.washington.edu>
To: sun-managers@eecs.nwu.edu
Subject: SCSI Bus device operating synchronously/asynchronously
Organization: US Long-Term Ecological Research Network (LTER)
System: Sun Sparc-2 running 4.0.3
several SCSI devices attached
I have been running the above system for months without any problems.
The SCSI devices in question appear in the listings below. All SCSI
devices used start synchronously at boot time, as per following
excerpt from the /var/adm/messages:
Sep 30 14:35:51 space vmunix: esp0 at SBus slot 0 0x800000 pri 3
Sep 30 14:35:51 space vmunix: esp0: Target 3 now Synchronous at 4.0 mb/s max transmit rate
Sep 30 14:35:51 space vmunix: sd0 at esp0 target 3 lun 0
Sep 30 14:35:51 space vmunix: sd0: <SUN0207 cyl 1254 alt 2 hd 9 sec 36>
Sep 30 14:35:51 space vmunix: esp0: Target 1 now Synchronous at 4.0 mb/s max transmit rate
Sep 30 14:35:51 space vmunix: sd1 at esp0 target 1 lun 0
Sep 30 14:35:51 space vmunix: sd1: <Maxtor Panther cyl 1624/1632 alt 2 h cyl 1624 alt 2 hd 15 sec 81>
Sep 30 14:35:51 space vmunix: reo0 at esp0 target 2 lun 0
Sep 30 14:35:51 space vmunix: esp0: Target 0 now Synchronous at 4.0 mb/s max transmit rate
Sep 30 14:35:51 space vmunix: sd3 at esp0 target 0 lun 0
Sep 30 14:35:51 space vmunix: sd3: <Maxtor Panther 1626/1632 alt 2 cyl 1 cyl 1624 alt 2 hd 15 sec 81>
Sep 30 14:35:51 space vmunix: esp0: Target 4 now Synchronous at 2.0 mb/s max transmit rate
Sep 30 14:35:51 space vmunix: st0 at esp0 target 4 lun 0
Sep 30 14:35:51 space vmunix: st0: <Exabyte 8mm Helical Scan>
Yesterday, I moved the equipment from one table to another, with the
result that three of the four SCSI devices are no longer
coming up synchronously:
Sep 30 16:22:49 space vmunix: esp0 at SBus slot 0 0x800000 pri 3
Sep 30 16:22:49 space vmunix: esp0: Target 3 now Synchronous at 4.0 mb/s max transmit rate
Sep 30 16:22:49 space vmunix: sd0 at esp0 target 3 lun 0
Sep 30 16:22:49 space vmunix: sd0: <SUN0207 cyl 1254 alt 2 hd 9 sec 36>
Sep 30 16:22:49 space vmunix: sd1 at esp0 target 1 lun 0
Sep 30 16:22:49 space vmunix: sd1: <Maxtor Panther cyl 1624/1632 alt 2 h cyl 1624 alt 2 hd 15 sec 81>
Sep 30 16:22:49 space vmunix: reo0 at esp0 target 2 lun 0
Sep 30 16:22:49 space vmunix: sd3 at esp0 target 0 lun 0
Sep 30 16:22:49 space vmunix: sd3: <Maxtor Panther 1626/1632 alt 2 cyl 1 cyl 1624 alt 2 hd 15 sec 81>
Sep 30 16:22:49 space vmunix: st0 at esp0 target 4 lun 0
Sep 30 16:22:49 space vmunix: st0: <Exabyte 8mm Helical Scan>
I have checked all cable connections but everything looks O.K.
Is there any way to 'force' synchronous operation?
Has any of you come across this behaviour, and what were the causes?
Thank you for your help.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:18 CDT