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

[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

[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

cpqfc gone - all compay RA4X00 Array now useless in linux?

[Ingo Flaschberger]

Hey,

I'm very very sorry that the cpqfc driver is gone because it was the 
_only_ one which supported the now very cheap Compaq FiberChannel Array 
RA4X00.

With all other FC HBA's the logical volumes (LUN's) are not visible.
---snip---
5. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective
Storage Presentation), which maps LUNs to a WWN.  If RA4x00 firmware prior
2.54 (e.g. older controller) is used, or the FC HBA is replaced (another WWN
is used), logical volumes on the RA4x00 will no longer be visible.
---snap---

So... there are 3 possibilities:
1. Repair the cpqfc driver and but it again into linux?
2. Find out, how to get the RA4x00 arrays with othet HBA's running; I
 	searched about 1 week in Google, no way..
3. Aeh.. use... 2.4, use... other OS?

Hope to find a way... and not only kicking a working driver because of not 
as nice code and to much stack memory.

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

Re: cpqfc gone - all compay RA4X00 Array now useless in linux?

[Rolf Eike Beer]

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

Am Montag, 6. Februar 2006 18:46 schrieben Sie:
>Hey,
>
>I'm very very sorry that the cpqfc driver is gone because it was the
>_only_ one which supported the now very cheap Compaq FiberChannel Array
>RA4X00.
>
>With all other FC HBA's the logical volumes (LUN's) are not visible.
>---snip---
>5. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective
>Storage Presentation), which maps LUNs to a WWN.  If RA4x00 firmware prior
>2.54 (e.g. older controller) is used, or the FC HBA is replaced (another WWN
>is used), logical volumes on the RA4x00 will no longer be visible.
>---snap---
>
>So... there are 3 possibilities:
>1. Repair the cpqfc driver and but it again into linux?

The driver is a horrible hack lacking too many of really needed error 
handling.

>2. Find out, how to get the RA4x00 arrays with othet HBA's running; I
> 	searched about 1 week in Google, no way..

We're working on it. The RA4x00 do things normal arrays don't or so. I'm not 
yet familiar enough with this to know exactly what is needed to beat this to 
work again.

>3. Aeh.. use... 2.4, use... other OS?

The 2.4 might work. And I might have some patches for you to make it a bit 
less broken. But don't expect too much from it.

>Hope to find a way... and not only kicking a working driver because of not
>as nice code and to much stack memory.

It was not really working, at least not when I (remotely via IRC) tested it 
last time (some month ago).

Eike

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

Re: cpqfc gone - all compay RA4X00 Array now useless in linux?

[Ingo Flaschberger]

Hello Rolf,

>> _only_ one which supported the now very cheap Compaq FiberChannel Array
>> RA4X00.
>>
>> With all other FC HBA's the logical volumes (LUN's) are not visible.
>> ---snip---
>> 5. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective
>> Storage Presentation), which maps LUNs to a WWN.  If RA4x00 firmware prior
>> 2.54 (e.g. older controller) is used, or the FC HBA is replaced (another WWN
>> is used), logical volumes on the RA4x00 will no longer be visible.
>> ---snap---
>>
>> So... there are 3 possibilities:
>> 1. Repair the cpqfc driver and but it again into linux?
>
> The driver is a horrible hack lacking too many of really needed error
> handling.
>
>> 2. Find out, how to get the RA4x00 arrays with othet HBA's running; I
>> 	searched about 1 week in Google, no way..
>
> We're working on it. The RA4x00 do things normal arrays don't or so.

What means, "We're working on it"?

> I'm not
> yet familiar enough with this to know exactly what is needed to beat this to
> work again.

The only thing I have found, why the RA4X00 arrays are different:
http://mail-index.netbsd.org/tech-kern/2005/01/06/0013.html
---sip---
Its been years time since I checked the T10/T11 drafts, but as best I
recall, there's some SCSI level (SCSI-3? The last ANSI level?)  where
any device claiming that level is required(?) to implement
REPORT_LUNS.

I've also seen devices just below that level which just won't talk
happily to an initiator unless the initiator sends them a REPORT_LUNS.
(The Compaq RA4000 RAID array was infamous for that. IIRC, the Linux
driver for the recommended Compaq/Aglient controller sent a REPORT
LUNs from inside the driver, then remapped the native LUNs to 8-bit
LUNS for upper layers; or something equally distaseful.)
---snap---

and the work around seems to be hardcoded in the cpqfc driver.


cpqfcTSworker.c
---snip---
     // 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
     {
       int j;
       int AppendLunList = 0;
       // Walk through the LUN list.  The 'j' array number is
       // Linux's lun #, while the value of .lun[j] is the target's
       // lun #.
       // Once we build a LUN list, it's possible for a known device
       // to go offline while volumes (LUNs) are added.  Later,
       // the device will do another PLOGI ... Report Luns command,
       // and we must not alter the existing Linux Lun map.
       // (This will be very rare).
---snap---

perhaps its that part of code....

when my server boots with 2.4.20:
dmesg:
---snip---
   HBA Tachyon RevId 3.0
Allocating 119808 for 576 Exchanges @ 057e0000
Allocating 112904 for LinkQ @ 057c0000 (576 elements)
Allocating 104456 for TachSEST for 512 Exchanges
   cpqfcTS: writing IMQ BASE 37B0000h    PI 37B4000h
   cpqfcTS: SEST 05780000(virt): Wrote base 3780000h @ c2a02140
cpqfcTS: NVRAM read failed
  WARNING! HBA NVRAM WWN read failed - make alias
cpqfcTS: New FC port 000001h WWN: 500508B100092C20 SCSI Chan/Trgt 0/0
scsi1 : Compaq FibreChannel HBA Tachyon Chip/Board Ver??: WWN 
5000061144556677
  on PCI bus 3 device 0x1028 irq 24 IObaseL 0x2000, MEMBASE 0xfe7f0000
PCI bus width 64 bits, bus speed 66 MHz
FCP-SCSI Driver v2.1.1
GBIC detected: NONE!  LPSM 0h Monitor
   Vendor: COMPAQ    Model: LOGICAL VOLUME    Rev: 2.40
   Type:   Direct-Access                      ANSI SCSI revision: 02
   Vendor: COMPAQ    Model: LOGICAL VOLUME    Rev: 2.40
   Type:   Direct-Access                      ANSI SCSI revision: 02
libata version 1.10 loaded.
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi disk sdc at scsi1, channel 0, id 0, lun 1
---snap---

>> 3. Aeh.. use... 2.4, use... other OS?
>
> The 2.4 might work. And I might have some patches for you to make it a bit
> less broken. But don't expect too much from it.
>
>> Hope to find a way... and not only kicking a working driver because of not
>> as nice code and to much stack memory.
>
> It was not really working, at least not when I (remotely via IRC) tested it
> last time (some month ago).

I would like to give it a try.
What have been the latest parts of code?

Kind regards,
 	Ingo Flaschberger

Re: cpqfc gone - all compay RA4X00 Array now useless in linux?

[Rolf Eike Beer]

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

Am Montag, 6. Februar 2006 19:38 schrieben Sie:
>Hello Rolf,
>
>>> _only_ one which supported the now very cheap Compaq FiberChannel Array
>>> RA4X00.
>>>
>>> With all other FC HBA's the logical volumes (LUN's) are not visible.
>>> ---snip---
>>> 5. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective
>>> Storage Presentation), which maps LUNs to a WWN.  If RA4x00 firmware
>>> prior 2.54 (e.g. older controller) is used, or the FC HBA is replaced
>>> (another WWN is used), logical volumes on the RA4x00 will no longer be
>>> visible. ---snap---
>>>
>>> So... there are 3 possibilities:
>>> 1. Repair the cpqfc driver and but it again into linux?
>>
>> The driver is a horrible hack lacking too many of really needed error
>> handling.
>>
>>> 2. Find out, how to get the RA4x00 arrays with othet HBA's running; I
>>> 	searched about 1 week in Google, no way..
>>
>> We're working on it. The RA4x00 do things normal arrays don't or so.
>
>What means, "We're working on it"?

Martin K. Petersen is working on a new driver for the Controller that also 
supports additional cards. I'm playing a bit around with a completely new 
driver for myself (as I still don't have seen MKP's one) but I have no access 
to any FC equipment beyond my HBA.

>> I'm not
>> yet familiar enough with this to know exactly what is needed to beat this
>> to work again.
>
>The only thing I have found, why the RA4X00 arrays are different:
>http://mail-index.netbsd.org/tech-kern/2005/01/06/0013.html
>---sip---
>Its been years time since I checked the T10/T11 drafts, but as best I
>recall, there's some SCSI level (SCSI-3? The last ANSI level?)  where
>any device claiming that level is required(?) to implement
>REPORT_LUNS.
>
>I've also seen devices just below that level which just won't talk
>happily to an initiator unless the initiator sends them a REPORT_LUNS.
>(The Compaq RA4000 RAID array was infamous for that. IIRC, the Linux
>driver for the recommended Compaq/Aglient controller sent a REPORT
>LUNs from inside the driver, then remapped the native LUNs to 8-bit
>LUNS for upper layers; or something equally distaseful.)
>---snap---
>
>and the work around seems to be hardcoded in the cpqfc driver.
>perhaps its that part of code....

Yes, but that's not the whole story. It also uses other type of disc 
representation or sort of stuff.

You may find some additional information in thread "Booting from or using a 
Compaq RA4100 Array" beginning on 2005-12-28.

>>> 3. Aeh.. use... 2.4, use... other OS?
>>
>> The 2.4 might work. And I might have some patches for you to make it a bit
>> less broken. But don't expect too much from it.
>>
>>> Hope to find a way... and not only kicking a working driver because of
>>> not as nice code and to much stack memory.
>>
>> It was not really working, at least not when I (remotely via IRC) tested
>> it last time (some month ago).
>
>I would like to give it a try.
>What have been the latest parts of code?

Subversion repository can be found on

http://opensource.sf-tec.de/repos/cpqfc

I need to make a branch for the 2.6 code. Patches can be found at 
http://opensource.sf-tec.de/kernel/

Eike

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

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