RE: Attaching IBM 3590 to Ultra 60 - LATE SUMMARY

From: Riddoch, John E SITI-ITDSEP3 <John.E.Riddoch_at_is.shell.com>
Date: Mon Sep 30 2002 - 08:35:28 EDT
Somewhat belatedly (this job has sat on the back burner for a couple of
months) I think I've managed to get the 3590 working.

Anand Chouthai pointed me towards setting SCSI options in
/kernel/drv/glm.conf.  After reading the man page and cross referencing to
/usr/include/sys/scsi/conf/autoconf.h, I set about putting the config in.
What I eventually put in was:

name="glm" parent="/pci@1f,2000"
    unit-address="1,1"
    scsi-options=0x7f8;

This references the specific port, setting the SCSI options to 0x7f8.  With
that in, the system boots and recognizes the tape drive without any errors.
What is confusing is that the system will work even if we set the same SCSI
options as it had before setting glm.conf (i.e. using the SCSI options
reported in prtconf -v).  Simply the act of setting any SCSI options lets it
work.  Very strange.

However, there is one slight gotcha in that the first time we use the drive
(e.g. mt -f /dev/rmt/1 stat) we get the following errors:

Sep 24 11:26:05 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:05 abew176         SCSI bus DATA IN phase parity error
Sep 24 11:26:05 abew176 glm: [ID 663555 kern.warning] WARNING:
ID[SUNWpd.glm.parity_check.6010]
Sep 24 11:26:05 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:05 abew176         SCSI bus DATA IN phase parity error
Sep 24 11:26:05 abew176 glm: [ID 663555 kern.warning] WARNING:
ID[SUNWpd.glm.parity_check.6010]
Sep 24 11:26:05 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:05 abew176         Target 0 reducing sync. transfer rate
Sep 24 11:26:05 abew176 glm: [ID 923092 kern.warning] WARNING:
ID[SUNWpd.glm.sync_wide_backoff.6014]
Sep 24 11:26:08 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:08 abew176         SCSI bus DATA IN phase parity error
Sep 24 11:26:08 abew176 glm: [ID 663555 kern.warning] WARNING:
ID[SUNWpd.glm.parity_check.6010]
Sep 24 11:26:08 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:08 abew176         SCSI bus DATA IN phase parity error
Sep 24 11:26:08 abew176 glm: [ID 663555 kern.warning] WARNING:
ID[SUNWpd.glm.parity_check.6010]
Sep 24 11:26:08 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:08 abew176         SCSI bus DATA IN phase parity error
Sep 24 11:26:08 abew176 glm: [ID 663555 kern.warning] WARNING:
ID[SUNWpd.glm.parity_check.6010]
Sep 24 11:26:08 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:08 abew176         Target 0 disabled wide SCSI mode
Sep 24 11:26:08 abew176 glm: [ID 681974 kern.warning] WARNING:
ID[SUNWpd.glm.sync_wide_backoff.6012]
Sep 24 11:26:08 abew176 scsi: [ID 107833 kern.warning] WARNING:
/pci@1f,2000/scsi@1,1 (glm3):
Sep 24 11:26:08 abew176         Target 0 reverting to async. mode
Sep 24 11:26:08 abew176 glm: [ID 802533 kern.warning] WARNING:
ID[SUNWpd.glm.sync_wide_backoff.6013]

Net result is that sync speed (as reported by prtconf -v) drops down to
500KB/sec(!!) and scsiinfo reports it as:
glm3: st0,0 tgt 0 lun 0:
        Asynchronous Noisy NoTaggedQueuing Narrow

However, the users have done a couple of transfers and haven't complained
(yet, anyway...), so I'm inclined to leave it as working satisfactorily
until I hear otherwise.




-----Original Message-----
From: Riddoch, John E SITI-ITDSEP3 
Sent: 13 August 2002 15:45
To: 'sunmanagers@sunmanagers.org'
Subject: Attaching IBM 3590 to Ultra 60


Sorry for the delay in replying, but I haven't had a chance to try some of
the fixes.

I had a total of four responses, which gave the following hints:
1. Make sure it's terminated (the most common reply)
2. Make sure it's differential SCSI
3. Try a different SCSI ID

WRT termination, it worked fine on the Ultra 1, but that may or may not be
entirely relevant as the Sbus SCSI card it has may be more forgiving.
However, Baranyai Pal gave me a link to the 3590 installation guide which
said I should terminate the second port on the drive which I hadn't done.
However, that made no difference (yes, it was a diff. SCSI terminator).

It'd definately differential SCSI, and this has been confirmed as it's not
seen by either a SE SCSI card or the onboard SCSI of the Ultra 60.

I did try a different SCSI ID, but it didn't help.

Finally, I also tried using the second port on the 3590, but that didn't
help either.

I also tried booting up the Ultra 60 as boot -rs and got the following
error:
WARNING: /pci@1f,2000/scsi@1,1 (glm3):
         Disconnected command timeout for Target 3.0
This came up a few times, presumably when the U60 was trying to initialise
the tape drive.

As an aside, we have a similar tape drive attached to an E250 with a similar
setup which worked without any special tweaking.

So, does anyone have any other ideas?


-----Original Message-----
From: Riddoch, John E SITI-ITDSEP3 
Sent: 26 July 2002 16:09
To: 'sunmanagers@sunmanagers.org'
Subject: Attaching IBM 3590 to Ultra 60


We're trying to move a system from it's existing Ultra 1 (Solaris 2.6) to an
Ultra 60 (Solaris 8).  Attached to the system are an Exabyte tape drive, an
IBM 3590 tape drive and a D1000.

While the D1000 and Exabyte work perfectly, the 3590 isn't recognized;
running probe-scsi-all at the PROM returns:

Fatal SCSI error at script address 10 Unexpected disconnect.

This line appears twice under the path name of the SCSI card.  Booting up
Solaris doesn't help, and the device doesn't appear under /dev/rmt (even
after boot -r).

We're trying to attach this with a PCI dual differential SCSI card.  We've
tried it in both ports on the card with the same results.  The D1000 works
fine, reporting back all its disks under probe-scsi-all.

As far as cabling goes, we've tried a VHDCI-HD68 connector (direct to the
system) and a VHDCI-HD68 adapter to attach to the existing HD68-HD68 cable.
Neither option works, giving the error above.

The Ultra 1 sees the drive fine if we reconnect.

In case it's relevant the Ultra 60's OBP is at 3.23.

Anyone have any ideas?  Google shows a few things related to that error, but
nothing which seems appropriate.

Summary as usual...
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu Oct 3 17:20:37 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:56 EST