Rules of the Road for Fibre Channel Interop

Being relatively new to fibre channel, I need to gain more awareness of what
works and what to expect. Maybe some gurus here on usenet can help. I
discovered that my Sun X6730A (FC100/S) card will not correctly communicate
with a Clariion FC5700 DPER. I don't understand why. Doesn't everyone follow
the ANSI standard for Fibre Channel? Is the standard kinda "loose" or what?
I've seen a number of shops with large systems that had Fibre Channel cards
from 2 or 3 different vendors talking to arrays from different vendors. I
never really considered why. I think I'm beginning to get a clue about
this.
In my configuration I can see one device out on the Fibre Channel. It is
identified as a DGC (Data General, creator of Clariion). This device has 3
LUN's available (yes, I already did the sd.conf). But any further
communication beyond the format command to see available drives results in
"SCSI transport failed: reason 'timeout': retrying command."
It seems like connecting an FC100/S to a Clariion is like breaking the
main law of Fibre Channel: Never expect interoperability between any two
given devices. Is that true or am I just making some kind of configuration
mistake with the drivers or the OS? Any help is appreciated.

Charles McCane
Dallas, TX.

 

Some cards were released before the standards were formalized, but
should be able to work with some tweaking. What does your
topology look like? Do you have the latest drivers?

Do you have a switch between the host and the Clarion? What happens
when you run a read/analyze on the LUN through format? Did you
label the LUN through format? We have used Emulex cards w/ the
Clarion line and have had great luck.

 

Thanks for the response. Topology is FC-AL, very simple at this point - one
initiator (Sun) and one target (Clariion). As for latest drivers, I'm using
Solaris 8 with the latest jumbo patch. I haven't researched the possibility
of doing something with the firmware for the FC100/S. That HBA has been
working flawlessly with a 3rd party JBOD enclosure consisting of 8 IBM
DDYF-18350 10K rpm drives. Never had any issues with that configuration -
all the drives show up under format and provide decent performance as
configured under Veritas 3.2 with striping. I'm using a different boot disk
with a simple Solaris 8 install for testing - no Veritas on the test boot
disk.
When I remvoe the JBOD, connect the Clariion, and boot from the test
boot disk, I can see the DGC-RAID10-0511 target on the loop. With a
reconfigure the OS manages to create /dev/dsk/c1t0d0s0-7 device files.
Format shows the DGC device and I can go into partition and see the
partition table. It shows an 82G device. The problem comes when I do any
kind of write, which as you pointed out would first be a label command.
Thats when I get the "SCSI transport failed: reason 'timeout': retrying
command." response showing up in var/messages. I've never been any further
than that.

 

I've had essentially the same exact problem as you're describing.
Over here, I have a CLARiiON FC5500 array, and tried connecting it to the
SOC+ ports on my E4000 (which is basically the on-board version of the
FC100/S). The machine saw the RAID LUNs, but when I went to write the
label in format, it just hung forever. (and eventually timed out with an
error) Further testing (banging on the raw device with "dd") revealed that
I could read from the array, but not write reliably.
If you'll refer to my response to your last post, I mentioned that I
have now purchased a JNI FC64-1063 SBus HBA, and it works perfectly. While
I have no idea what the problem is, I suspect that the SOC+ (Sun's 100MB/s
FC-AL controller) is only truely compatible with the StorEdge A5000, and
maybe a few other Sun arrays.
For the heck of it, I'll mention that I also tested the array on a
PC with both an LSI FC909 HBA, and a QLogic QLA2100 HBA. Both also worked
perfectly, albeit with substandard performance when compared with the
FC64-1063 (though I could blame this on any number of factors, though not
the OS (as I tried a few with similar results), given that I was sticking
fancy 64-bit PCI cards in a vanilla 32-bit PCI desktop).

-Derek Konigsberg <>

 

What OS version? Solaris 9? I've had endless problems with Suns
FC100/S Sbus adapters under Solaris 9 trying to communicate
with Sun A5000 FC boxes. A setup you'd think would be stable...

I think it might be something in Solaris 9 since I've got a lot
of reports from other users of the FC100/S that it works - but those
users have all been using Solaris 8 or earlier releases...

Alas, we now use HBAs from JNI instead. Works like a charm.

- Peter

 

Just barely - as I wrote in another posting we've had a lot of problems
getting the FC100/S working with A5000 units under Solaris 9.

The JNI adapters solved most of our problems.

(It didn't solve the problem with Seagate 36GB Cheetah's in
A5000 boxes - but that I think is a physical/environmental
issue with the A5000 box. Perhaps the power supplies on the A5K
can't handle the 36GB Cheetahs or something. The A5K works
perfectly with 9 and 18GB Barracudas though (which is what
Sun supported once upon a time).

Now if we (actually, the local computer club at the University) could
find some JBOD or RAID units that can take full-height 36GB Cheetahs
(and someone willing to donate them to the club). We have some 30
disks to install in such a box in that case

- Peter Eriksson <>

 

Using Solaris 8 here. And now I've ordered another JNI adapter because so
many people say that it works. Thanks to everyone for the replies. Obviously
I have a single bad adapter but the FC64-1063 in general is a good choice
for the job. As soon as I get this working with JNI on FC-AL, I'll be
switching over to FC-SW with a Brocade switch. I'm confident that I'll be
back with more issues then.

Thanks,
Charles

 

some of the FC HBA manufacturers have special EMC drives that you
can download from their site
while some of the others make "oem" versions specially for EMC
enviornments


_____ . .
' \\ . . |>>
O// . . |
\_\ . . |
| | . . . |
/ | . www.EvenEnterprises.com . . . |
/ .| . . . |
/ . | 310-544-9439 / 310-544-9309 fax . . . o