cpqfc

cpqfc

[lance dillon]

I have an old compaq proliant server (dual 733) with the Compaq
FibreChannel HBA Tachyon Chip/Board Ver??: WWN 5002CE4E44556677 (that is
what the kernel messages say).  This is for my church, which has a very
limited budget, so they really can't just buy a new machine with regular
ide drives (this machine was donated to them).  It also has a fibre
channel array attached to it.

kernel 2.6.14.3

Of course the driver is broken, so I'm trying to fix it.

I changed cpqfcTSworker.c so that it allocates space with kmalloc()
instead of on the stack (as per the messages seen by google: cpqfc too
much stack).

I modified a few lines that reference struct scsi_cmd member timeout,
which doesn't seem to exist anymore.  I replaced it with
timeout_per_command, but I'm not sure if that is correct.  Does anybody
have any more information on this for me?

I also had to modify the driver so it sees a0ec, rather than a0fc.

But, I'm getting the problem at all the resources seem to be already
allocated:

cat /proc/pci:

Bus  3, device   5, function 00:
  Class 0280: PCI device 0e11:a0ec (rev 3).
    IRQ 201.
    Master Capable.  Latency=64
    I/O at 0x4000 [0x40ff].
    I/O at 0x4400 [0x44ff].
    Non-prefetchable 32 bit memory at 0xc6fffe00 [0xc6ffffff].

in cpqfcTSinit.c, function Cpqfc_initHBAdata(), it sets IOBaseL and
IOBaseU from PciDev->resource[1].start and PciDev->resource[2].start.
It almost appears that it should be 0 and 1 instead.


I enable DEBUG_PCI in the source...

The kernel messages say that:
HostAdapter->PciDev->irq = 201
PciDev->baseaddress[0]= 4000
PciDev->baseaddress[1]= 4400
PciDev->baseaddress[2]= c6fffe00
PciDev->baseaddress[3]= 0
PciDev->baseaddress[4]= 0
PciDev->baseaddress[5]= 0

So it appears that Cpqfc_initHBAdata() should call request_region() on
4000 and 4400 (IOBaseL and IOBaseU), but since IOBaseL gets set to 4400
and IOBaseU gets set to c6fffe00.

I tried changing the code to set IOBaseL to PciDev->resource[0].start
and IOBaseU to PciDev->resource[1].start, and MemBase to
PciDev->resource[2].start, but the entire system froze when I did
modprobe cpqfc.

This is the error message I get when it is unmodified:

cpqfcHBAdata->fcChip.Registers.:
  IOBaseL = 4400
  IOBaseU = c6fffe00
  SFQconsumerIndex.address = f887e058
  ERQproducerIndex.address = f887e008
  TYconfig.address = f887e184
  FMconfig.address = f887e1c0
  FMcontrol.address = f887e1c4
cpqfc: address in use: c6fffe00
ACPI: PCI interrupt for device 000:03:05.0 disabled

This is when it tries to request_region() IOBaseU, which seems to be
incorrectly set to c6fffe00

However, when I change it so it request 4400 and 4000, it still says the
address is in use.

Would anybody have any ideas, or perhaps be able to point me in the
right direction?

Thanks...

Re: cpqfc

[Rolf Eike Beer]

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

Lance Dillon wrote:
>I have an old compaq proliant server (dual 733) with the Compaq
>FibreChannel HBA Tachyon Chip/Board Ver??: WWN 5002CE4E44556677 (that is
>what the kernel messages say).  This is for my church, which has a very
>limited budget, so they really can't just buy a new machine with regular
>ide drives (this machine was donated to them).  It also has a fibre
>channel array attached to it.

The driver has been removed now. It was broken at many more places. I've 
hacked a bit on this beast, you can find several of my patches on 
http://opensource.sf-tec.de/kernel/ . After all these it was still not 
usable.

Martin K. Petersen (mkp) is writing a replacement driver for this, but I don't 
know the state of this work. We've tried many things on this beast, but some 
changed got recursive. This is because many of the functions just return void 
and now have to check about the return codes because of kmalloc() an such 
stuff.

I wonder where all the users of this thing come from as it went clear that the 
driver will die :))

Eike

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

cpqfc

[lance dillon]

So, I got the code to successfully compile and load, but when I
rebooted, the modprobe.conf shows:

alias eth1 cpqfc


I'm just wondering why it should look like an ethernet card, unless I'm
missing something...  I thought it would look like scsi drives..

Does anybody have any ideas?

Thanks...

l

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