Help: SCSI controller sees disk at end of SCSI chain, not at beginning

Help: SCSI controller sees disk at end of SCSI chain, not at beginning

Post by Charles Rot » Tue, 04 Jun 1996 04:00:00

I have an ancient Sun 386i which is used to booting off SCSI target 2,
partition a (/dev/sd2a).  Up until recently, a similarly ancient 91 Mb
Wren III half-height SCSI hard disk performed this function.  I hang
my auxiliary (non-system) disk off /dev/sd0c.  The OS is SunOS 4.0.2.  
Yeah .. I know .. bleeech.  But that was the last OS Sun got out the door
for the 386i before they closed the line down.  

The 386i is prone to accumulate internal dust, due to an engineering
screwup relating to the fans.  _Especially_ in my apartment, full of dust
and cat hairs as it is.  So every once in a while, I take apart the system
box and "peripheral expansion box" (marketriodish for "Sun official
shoebox") and clean as much crud out as possible.  I did this on Friday
of last week, May 30.  

When I put things back together, the system failed to boot.  After about 10
hours of swapping parts and praying, I got the system to boot with a
_borrowed_ system disk /dev/sd2.  I had tar tapes of the divergences of my
own (non-booting) system disk from its newly-installed state (i.e., links
to the non-system disk, customized initialization files, etc.), so I put my
old boot disk at the _end_ of the SCSI chain (rather than at its beginning,
where /dev/sd2 traditionally is in the 386i), and reloaded the OS there
from the original boot tape after rejumpering the old boot disk to /dev/sd0
(so SunOS would not confuse it with the _borrowed_ /dev/sd2 I was booting

On booting from the install tape, it was clear that the SCSI controller on
the motherboard _WAS_ finding the old, rejumpered boot disk.  I formatted
it again (finding 8 new defects not in the original defect list), and
successfully reinstalled the 4.0.1 version of the OS (4.0.2 needs a later
set of patches, but 4.0.1 should boot OK).  

Several things then became obvious.  The system would boot from the
_borrowed_ boot disk, in the traditional location at the start of the SCSI
chain, just downstream of the controller on the motherboard.  During boot,
the OS and SCSI controller _did_ see the rejumpered old boot disk, and
correctly reported its label during bootup.  Once booted, partitions of
the old disk _could_ be mounted on empty directories of the borrowed boot
disk, which was now at the front of the SCSI chain, with the old boot disk
(reformatted and with 4.0.1 reinstalled) at its end, with the tape drive
in the middle.  

Next experiment .. rejumper the old disk again, from /dev/sd0 to /dev/sd2,
put it back in the traditional boot-disk position at the beginning of the
SCSI chain, put a disk jumpered to /dev/sd0 at the end (where the old boot
disk resided while being reformatted), and try to boot.  

No soap.  Not only did the SCSI controller fail to find /dev/sd2, but the
LEDs on the tape drive downstream from /dev/sd2 failed to light.  
Apparently, _everything_ past /dev/sd2 was unavailable to the SCSI
controller.  Tried to boot from the boot tape _explicitly_ ("b st(0,4,0)")
.. no soap.  

Here's the paradox:  The old disk is _perfectly_ accessable to the SCSI
controller (booting aside) at the _end_ of the SCSI chain.  Its label, disk
type, and target are correctly identified as /dev/sd0.  But rejumpered to
/dev/sd2 and placed at the _beginning_ of the SCSI chain, the SCSI controller
finds neither it nor anything downsteam of it.  Is that wierd or what ??  

I know what you're thinking .. "what if this guy jumpered the disk to
/dev/sd2 wrong?".  Well, not only was I working from a copy of the original
Sun tech sheet about this specific drive, but I also had dead specimens of
the same exact drive to examine .. all used as boot drives, and all jumpered
_EXACTLY_ as my disk was when the controller failed to find it.  

In addition, I _checked_ the fit of the internal SCSI cable _carefully_ each
time I swapped drives.  It fit into the 50-pin male connector of the drive's
imbedded SCSI adapter _tightly_, both with the working borrowed boot drive
and with my own.  I made the same checks with the power supply fitting.  
Same result.  

Can some kind soul tell me what the _HELL_ is going on here ?!?!?  If the
disk or adapter were simply toast, either the controller would _never_
find it, or format would fail, or both.  I've seen this before, on
verifiably dead drives.  It seems to me I have a potentially workable boot
disk here, if I could only figure out _WHAT_ has gone wrong.  

Thanks, Charles.  


1. SCSI disk targets 4 & 6 NOT seen by SUN OS 4.1.4, help!

I bought disks to consolidate the user data on ten legacy Sparc (2 or 10)

The disks on the Sparc with the new drives are set up with
these SCSI target mappings (target 5 unused) :

  four identical *new* drives on:  targets 0,2,4,6

  424 MB (/ /usr /home) disk on: target 3

  1.05GB user data disk on:      target 1

When I run "probe-scsi" at the monitor level (SUN OS *not* running),
all six drives (including targets 4 & 6) are recognized just fine.

After booting SUN OS, *only* *two* of the four drives
are accessible!  I have tried moving the drives to another
SUN box, but the same thing occurs.

What do I need to do to get all the drives available?

The new drives are all "SEAGATE ST12400N SUN2.1G"
(narrow single ended SCSI 2) drives in a single SUN external
drive enclosure.  See below for more details..

thanks much in advance,

Tom Rodman

esp0: sd3 tgt 0 lun 0:
        Synchronous(4.000MB/sec) Clean CanReconnect
        Non-removable Disk:     SEAGATE  ST12400N SUN2.1G 8720          [ST]
esp0: sd2 tgt 2 lun 0:
        Synchronous(4.000MB/sec) Clean CanReconnect
        Non-removable Disk:     SEAGATE  ST12400N SUN2.1G 8720          [ST]
esp0: sd1 tgt 1 lun 0:
        Synchronous(4.000MB/sec) Clean CanReconnect
        Non-removable Disk:     SEAGATE  ST11200N SUN1.05 9500          [ST]
esp0: sd0 tgt 3 lun 0:
        Synchronous(4.000MB/sec) Clean CanReconnect
        Non-removable Disk:     SEAGATE  ST1480   SUN0424 8628          [ASL]
SunOS wtn104 4.1.4 3 sun4c
sd0 at esp0 target 3 lun 0
sd0: <SUN0424 cyl 1151 alt 2 hd 9 sec 80>
sd1 at esp0 target 1 lun 0
sd1: <SUN1.05 cyl 2036 alt 2 hd 14 sec 72>
sd2 at esp0 target 2 lun 0
sd2: <SUN2.1G cyl 2733 alt 2 hd 19 sec 80>
sd3 at esp0 target 0 lun 0
sd3: <SUN2.1G cyl 2733 alt 2 hd 19 sec 80>

2. Scanners

3. Please help. scsi controller not supported

4. Listing devices

5. format not seeing SCSI drives/Quantum PD1800S

6. fs: tandy1000sx

7. QLGC,isp0 is a "Sun DWIS/S" SCSI controller disk controller

8. ntp4.0.72c and "Lost Sync" Messages?

9. Story continues: Sun's F/W single-ended SCSI controller

10. Sun's single-ended F/W SCSI controller on SS20

11. SCSI-3 20/Mbs device on a SCSI-2 10/Mbs chain?

12. Solaris on Ultra 10 sees a single SCSI disk multiple times.

13. Differential SCSI HD (single-ended SCSI) on a Sparc ?