Booting from or using a Compaq RA4100 Array

Booting from or using a Compaq RA4100 Array

[Mark Schaefer]

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

Re: Booting from or using a Compaq RA4100 Array

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

Mark Schaefer wrote:
>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.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Booting from or using a Compaq RA4100 Array

[mark]

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

>
> 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
>


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

Re: Booting from or using a Compaq RA4100 Array

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

Mark Schaefer wrote:
>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'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 :)

>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.

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?

>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.

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

Eike

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Booting from or using a Compaq RA4100 Array

[mark]

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

Re: Booting from or using a Compaq RA4100 Array

[mark]

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

Re: Booting from or using a Compaq RA4100 Array

[Martin K. Petersen]

>>>>> "Eike" == Rolf Eike Beer <eike-kernel@sf-tec.de> writes:

[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/

Re: Booting from or using a Compaq RA4100 Array

[Mark Schaefer]

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

On Fri, 2005-12-30 at 17:18 -0500, Martin K. Petersen wrote:

> 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.
> 

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

Re: Booting from or using a Compaq RA4100 Array

[Christoph Hellwig]

On Sun, Jan 01, 2006 at 09:22:43PM -0500, Mark Schaefer wrote:
> 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.

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.

Re: Booting from or using a Compaq RA4100 Array

[Martin K. Petersen]

>>>>> "Mark" == Mark Schaefer <mark@markschaefer.org> writes:

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/

Re: Booting from or using a Compaq RA4100 Array

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]

Am Montag, 2. Januar 2006 20:43 schrieben Sie:
>>>>>> "Mark" == Mark Schaefer <mark@markschaefer.org> writes:
>
>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...

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Booting from or using a Compaq RA4100 Array

[Matthew Wilcox]

On Tue, Jan 03, 2006 at 08:51:30AM +0100, Rolf Eike Beer wrote:
> >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)
> 
> 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?

You could make an effort here too.

> 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?

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.

Re: Booting from or using a Compaq RA4100 Array

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Matthew Wilcox:
>On Tue, Jan 03, 2006 at 08:51:30AM +0100, Rolf Eike Beer wrote:
>> >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)
>>
>> 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?
>
>You could make an effort here too.

But it sounded like Martin already knows :)

>> 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?
>
>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.

Sounds good :)

PCI id is 103c:102a.

Eike

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Booting from or using a Compaq RA4100 Array

[Martin K. Petersen]

>>>>> "Eike" == Rolf Eike Beer <eike-kernel@sf-tec.de> writes:

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/

Re: Booting from or using a Compaq RA4100 Array

[Ingo Flaschberger]

Hello,

first: I would really appreciate the creation of a own devel list for 
that.

second: I would like to help with coding and testing and could provide 
test hardware and remote hands at my location:
 	1x HHBA-5101C Tachyon Fibre Channel Host Bus Adapater, Chipset HPFC-5100
 		with fiber gbic
 	1x HHBA-5101C Tachyon Fibre Channel Host Bus Adapater, Chipset HPFC-5100
 		with copper gbic
 	1x qlogic ISP2200A with copper gbic (wit 2.4 RA4000 does not work with
 		this card)
 	1x Compaq RA4000 with fiber or copper gbic
 	1x test-server, 256mb ram, ~500mhz cp with inet connectivity

Kind regards,
 	ingo flaschberger

geschaeftsleitung
crossip communications gmbH
------------------------------
sebastian kneipp gasse 1
a-1020 wien
fix: +43-1-726 15 22-217
fax: +43-1-726 15 22-111
mob: +43-699-105 86 719
www.xip.at
------------------------------