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

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

cpqfc

[Ingo Flaschberger]

Hello again,

I have not received any answer regarding implementation of a new driver 
for the cpqfc adapter.

In one week I will start to port the old 2.4 driver to 2.6; with all its 
"not nice" code, because it works!

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
------------------------------
On Tue, 7 Feb 2006, Ingo Flaschberger wrote:

Re: cpqfc

[Christoph Hellwig]

On Fri, Feb 10, 2006 at 12:26:27PM +0100, Ingo Flaschberger wrote:
> Hello again,
> 
> I have not received any answer regarding implementation of a new driver 
> for the cpqfc adapter.
> 
> In one week I will start to port the old 2.4 driver to 2.6; with all its 
> "not nice" code, because it works!

The driver was in 2.6.x until a while ago, so that might be an easier
starting point.  Either variant is very broken so we're not going to put
it in again, though.

Re: cpqfc

[Martin K. Petersen]

>>>>> "Ingo" == Ingo Flaschberger <if@xip.at> writes:

Ingo> I have not received any answer regarding implementation of a new
Ingo> driver for the cpqfc adapter.

I've been away for a couple of days and I'm still catching up on mail.

It is correct that I've been working on a generic tachyon driver for a
while.  It is, however, still at the "poke this register and see what
happens" stage.  As soon as I get the driver to a point where it makes
sense to have other people pick at it I'll submit it here.


Ingo> In one week I will start to port the old 2.4 driver to 2.6; with
Ingo> all its "not nice" code, because it works!

No it doesn't.  It has data corruption issues.

If you really want to help there's still the issue of RA4100 and other
(if there are any?) TYPE_RAID devices not working.  That should be a
really quick hack and would make a lot of people happy.

Check the archives for info...

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

Re: cpqfc

[Rolf Eike Beer]

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

Am Freitag, 10. Februar 2006 12:26 schrieben Sie:
>Hello again,
>
>I have not received any answer regarding implementation of a new driver
>for the cpqfc adapter.
>
>In one week I will start to port the old 2.4 driver to 2.6; with all its
>"not nice" code, because it works!

It will not (really). cpqfc uses many functions not longer available in 2.6 so 
you will not even get it compile for a long time.

If you still want to do something like that you might want to have a look on 
http://opensource.sf-tec.de/repos/cpqfc/ where I put my changes to this 
driver online. The 2.6-branch will not compile by now but it is much cleaner 
than the code that was in 2.6.

Eike

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