Booting from or using a Compaq RA4100 Array

Hi,

I have a couple of these arrays I purchased from eBay. Apparently, they don't work with any other controller card, except cpqfc, which is unsupported in the 2.6 kernel. Has anyone gotten these working on a different card? If so, is it possible to boot off of this array? I'm using Emulex LP8000's, but have the 64-bit/66MHz Compaq cards for configuration.

James Bottomley mentioned that it supported the SCC-2 spec, which is
now deprecated, and reading the spec, it seems as though I wouldn't be able to boot directly from the array.

Thanks in advance for any pointers.

Mark

I'm now quoting mkp:

---
But the other reason the cpqfcTS driver is special is the RA4100 array.  The two were sold as a packaged solution.  The RA4100 isn't a "real" fibre channel disk device.  It represents itself as a TYPE_RAID as opposed to TYPE_DISK.  So even if you had my driver in 2.6.5, you wouldn't be able to use it.
---

What he was talking about as his driver is a replacement he writes for cpqfc. cpqfc was deleted from 2.6 because it was horribly written and currently broken. The 2.4 version is the same, but it might work because the 2.4 infrastructure is different from the 2.6 one.

Eike

Eike,

I think I've resigned myself to the fact that it won't boot. I've done a bit of digging by directly sending commands to the unit. I'm not sure why I can't force scsi_scan to do a REPORT_LUN on it through the Black List, but what I know is that it reports luns as 0x40...00 - 0x40...MAX_LUNS - they are reported as flat addressing, according to the SCSI Architecture Manual.

Since TYPE_RAID implements a standard (albeit deprecated), it might actually be worth trying to create a driver for it. The real question I have is whether I could get at the drives simply by masking the LUN's like the cpqfc driver does, or whether something like BLIST_SPARSE_LUNS would do the trick, or maybe even a new blasklist entry like BLIST_FLAT_LUN_ADDRESSING.

Here's a quote from cpqfcTSworker.c:
// e.g., the Compaq RA4x00 f/w Rev 2.54 and above may report // LUNs 4001, 4004, etc., because other LUNs are masked from // this HBA (owned by someone else). We'll make those appear as // LUN 0, 1... to Linux

I'm not sure what the direction of Linux is at this point, but there are a lot of RA4x00's out there for cheap and they (at least initially) seemed like a good entry-level FC RAID system. Also, I'm not sure how strange of a beast the RA4x00 is. If it's a one-off, maybe I could create a specific driver for it that acts as a LUN masker. If there are more, it may make sense to make the changes necessary to deal with flat addressing.

At this point, I'm convinced that it would be a minor change to at least the scsi_scan code to deal with TYPE_RAID. I'm a bit more concerned about how widespread a change like flat addressing would be.

Mark

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I've looked around a bit in the LUN code some month ago as I was trying to get this to a state where it was sort of working. This code is as horrible as the rest of this driver, so I didn't really got the point what of this strange stuff is really needed and what was just caused by code monkeys on drugs.

I now got a card, but a 5121, so I can't test this stuff. And I don't have such an array :)

Now the driver is buried and all the people with such hardware come out of their holes. Fascinating :)) I was thinking about a list related only to these things and/or writing a FAQ for this. What do the other people around think about this? MKP?

I'm not really familiar with the low level SCSI code. James? Christoph?

Eike

Eike,

The RA4100 tries to implement a zoning-style partitioning, called
Selective Storage Presentation (SSP). Basically, you can create LUNs on the RAID and point them to a specific FC cards - although they have to be seen by the 4100 when you're configuring it. That's why the REPORT_LUN command can return non-contiguous LUNs (as the comment indicates).

So, what the cpqfc driver is doing is reporting the 4100 LUNs to the
kernel as 0,1,2,... although on the drive, they may physically be the first, third and seventh logical drives (in addition to the wacky addressing). It then has to create a mapping array that interprets the kernel/drive LUNs.

If I had my pick on SCSI architecture, I'd prefer to standardize the
low-level drivers and put all of the hard-drive/raid specific code in the mid layer drivers, like what has been done with lpfc. There is a lot of garbage code in drivers like cpqfc doing exactly what scsi_scan and other mid-layer drivers are doing.

I'd volunteer one of the units for testing, but I assume shipping
would be more than the unit is worth. :( I'd be happy to test any bits you want to send, though.

Mark

[LUN mangling]

Eike> I've looked around a bit in the LUN code some month ago as I was Eike> trying to get this to a state where it was sort of working. This Eike> code is as horrible as the rest of this driver, so I didn't Eike> really got the point what of this strange stuff is really needed Eike> and what was just caused by code monkeys on drugs.

Yeah, I talked to James about this a while back and he said the only acceptable approach for dealing with deprecated TYPE_RAID devices would be to write an upper level driver. If you'd be interested in working on that, that'd be awesome.

Eike> Now the driver is buried and all the people with such hardware Eike> come out of their holes. Fascinating :)) I was thinking about a Eike> list related only to these things and/or writing a FAQ for Eike> this. What do the other people around think about this? MKP?

Sure. I'll try to conjure up a web page about cpqfcTS, RA4x00, and the current state of the tachyon nation.

Martin K. Petersen      http://mkp.net/

Martin,

I think I'm the one who would have to sign up for TYPE_RAID driver
writing. I'll probably need some pointers, and it won't be fast, but I've definitely got a carrot. I think the last scsi-howto for programming was dealing with the 2.4 series.

Also, any info on the Tachyon chips would be helpful. I have a TS and
a HPFC-5000C (32-bit old chip).

Thanks,

Mark

I'd suggets copying sd.c and add the command translations the cpqfc driver has been doing to sd_init_command. After that works post the preliminary results to this list ;-)

Later lots of unessecary bits can be removed from the driver and the init_command can be rewritten to directly issue the proper commands instead of crafting SPC command and then translating them.

Mark> Also, any info on the Tachyon chips would be helpful. I have
Mark> a TS and a HPFC-5000C (32-bit old chip).

HPFC-5000 is the original HP Tachyon design which my driver won't support. It doesn't have FCP support in hardware or anything. My driver only does TachLite.

My aim is to support the following boards:

HP A5156A HPFC-5100 /2.0 (TL)
HP A5157A HPFC-5100B/2.2 (TL) dual port
HP A5158A HPFC-5100C/2.3 (TL)
HP A5158A HPFC-5100D/3.0 (TL)
HP A6795A HPFC-5200C/2.2 (XL2)
Compaq FC HBA HPFC-5166A/1.2 (TS)

The Compaq FC HBA is the one that the RA-4x00 people have. I don't have this controller yet but there should be one waiting for me at the post office once the world goes out of suspend mode tomorrow...

Martin K. Petersen      http://mkp.net/

Am Montag, 2. Januar 2006 20:43 schrieben Sie:

Ok, can you collect such a list of the "other" cards that your driver does not support? And a list of PCI ids that match both lists?

These are the devices supported by the original cpqfc driver:

#define PCI_DEVICE_ID_COMPAQ_TACHYON    0xa0fc
#define PCI_DEVICE_ID_HP_TACHYON        0x1028
#define PCI_DEVICE_ID_HP_TACHLITE       0x1029

I now own a Agilent HHBA-5121. What's that for a thing?

Eike

You could make an effort here too.

Plugging "Agilent HHBA-5121" into google gets me a PDF with the following text:

At the heart of the HHBA-5121 is the HPFC-5166 Tachyon TS Fibre Channel Interface Controller IC.

Matthew Wilcox:

But it sounded like Martin already knows :)

Sounds good :)

PCI id is 103c:102a.

Eike

Eike> Ok, can you collect such a list of the "other" cards that your Eike> driver does not support? And a list of PCI ids that match both Eike> lists?

Tachyon chips are all over the place on cards from a multitude of vendors. The list I provided represents the pile of HP cards I have in my lab.

Eike> These are the devices supported by the original cpqfc driver:

Eike> #define PCI_DEVICE_ID_COMPAQ_TACHYON 0xa0fc
Eike> #define PCI_DEVICE_ID_HP_TACHYON 0x1028
Eike> #define PCI_DEVICE_ID_HP_TACHLITE 0x1029

Only the Compaq board is really supported.

The HP TL board happens to work if you don't care about using a valid WWN on your SAN. The XL2 board doesn't actually work at all.

Technically it's not correct to refer to 0x1028 and 0x1029 as TACHYON and TACHLITE. Both of them are TachLite. To my knowledge Tachyon proper doesn't have a PCI interface, so there's probably a glue chip on the HPFC-5000 boards out there.

These are the right identifiers:

#define PCI_DEVICE_ID_HP_TACH_TL 0x1028
#define PCI_DEVICE_ID_HP_TACH_XL2 0x1029
#define PCI_DEVICE_ID_HP_TACH_TS 0x102a
#define PCI_DEVICE_ID_COMPAQ_TACHYON 0xa0fc

pciids.sf.net has them right. It's just the kernel pci_ids.h that's a bit out of whack.

Some day I'll insert my cards one by one and get all the subsystem ids right.

Unlike most cards the subsystem id matters in this case as each vendor may wrap their boards differently in terms of Flash/ROM interface, onboard RAM, SERDES, GBIC interface, etc.

HP TL/XL2 HBA:

I'm currently mucking with extracting WWNs from the HP boards.

Compaq FC HBA:

Supporting this board shouldn't be a problem as the I2C NVRAM interface is documented in cpqfcTS.

InterPhase 55x6:

These boards are documented in the ancient iphase driver.

Agilent:

My hope is that Agilent's own boards are using the reference designs and consequently should be easy to support.

Adaptec:

I think Adaptec's boards were OEM'ed from Agilent. Probably just a different ROM.

These are the board vendors I know off the top of my head. There may well be more.

(I'm going to put all this on a webpage later today)

Martin K. Petersen      http://mkp.net/