RE: Qlogic Fiber Channel

RE: Qlogic Fiber Channel

[conway, heather]

Hi Mike,
Looks like QLogic up-rev'd the driver versions on their website.  They have
the source code for both v4.25 and v4.27 posted now and rpm's for v4.25.
Hope that helps.
Heather  

> -----Original Message-----
> From: Mike Black [mailto:mblack@csihq.com]
> Sent: Friday, June 29, 2001 6:53 AM
> To: linux-kernel@vger.kernel.or
> Subject: Qlogic Fiber Channel
> 
> 
> I have been running successfully with qla2x00src-4.15Beta.tgz 
> for several
> months now over several kernel versions up to 2.4.5.
> When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD
> MISTAKE!!!
> 
> #1 - My system had crashed (for a different reason) and when 
> the raid5 was
> resyncing and e2fsck happening at the same time the kernel locked with
> messages from qlogicfc.o:
> qlogicfc0: no handle slots, this should not happen.
> hostdata->queue  is 2a, inptr: 74
> I was able to repeat this several times so it's a consistent error.
> Waiting for the raid resync to finish did allow this complete 
> -- but now
> when I come in the next morning the console is locked up and 
> no network
> access either.  So I reset it.  Checked the logs and here it is again:
> Jun 29 03:39:21 yeti kernel: qlogicfc0 : no handle slots, 
> this should not
> happen.
> Jun 29 03:39:21 yeti kernel: hostdata->queued is 36, in_ptr: 13
> This was during a tape backup.
> 
> So I'm switching back to qla2x00src-4.15Beta.tgz -- which 
> does the resync
> and e2fsck just fine together BTW.
> Jun 29 06:22:47 yeti kernel: qla2x00: detect() found an HBA
> Jun 29 06:22:47 yeti kernel: qla2x00: VID=1077 DID=2100 
> SSVID=0 SSDID=0
> 
> Only problem is I don't see this package on qlogic's website 
> anymore and
> their "beta" directory is empty now.  I'm waiting to see what 
> their tech
> support says.
> 
> ________________________________________
> Michael D. Black   Principal Engineer
> mblack@csihq.com  321-676-2923,x203
> http://www.csihq.com  Computer Science Innovations
> http://www.csihq.com/~mike  My home page
> FAX 321-676-2355
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Qlogic Fiber Channel

[Mike Black]

I have been running successfully with qla2x00src-4.15Beta.tgz for several
months now over several kernel versions up to 2.4.5.
When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD
MISTAKE!!!

#1 - My system had crashed (for a different reason) and when the raid5 was
resyncing and e2fsck happening at the same time the kernel locked with
messages from qlogicfc.o:
qlogicfc0: no handle slots, this should not happen.
hostdata->queue  is 2a, inptr: 74
I was able to repeat this several times so it's a consistent error.
Waiting for the raid resync to finish did allow this complete -- but now
when I come in the next morning the console is locked up and no network
access either.  So I reset it.  Checked the logs and here it is again:
Jun 29 03:39:21 yeti kernel: qlogicfc0 : no handle slots, this should not
happen.
Jun 29 03:39:21 yeti kernel: hostdata->queued is 36, in_ptr: 13
This was during a tape backup.

So I'm switching back to qla2x00src-4.15Beta.tgz -- which does the resync
and e2fsck just fine together BTW.
Jun 29 06:22:47 yeti kernel: qla2x00: detect() found an HBA
Jun 29 06:22:47 yeti kernel: qla2x00: VID=1077 DID=2100 SSVID=0 SSDID=0

Only problem is I don't see this package on qlogic's website anymore and
their "beta" directory is empty now.  I'm waiting to see what their tech
support says.

________________________________________
Michael D. Black   Principal Engineer
mblack@csihq.com  321-676-2923,x203
http://www.csihq.com  Computer Science Innovations
http://www.csihq.com/~mike  My home page
FAX 321-676-2355

Re: Qlogic Fiber Channel

[christophe barbé]

The qlogicfc driver is based on the chris loveland work.
You can find outdated information here :
	http://www.iol.unh.edu/consortiums/fc/linux/qlogic.html

>From my point of view, this driver is sadly broken. The fun part is that
the qlogic driver is certainly based on this one too (look at the code, the
drivers differs not so much). 
If you don't need IP support then keep using the qlogic driver which is far
better. I'm pretty sure that they have a working IP enhanced version but
for an unknow reason this one is not released. And without the IP-enhanced
firmware we can do nothing.

I've unsuccessfully tried to get information from qlogic and others a few
weeks ago. 
IMHO the qlogicfc driver should be removed from the kernel tree and perhaps
replaced by the last qlogic one. We then lost the IP support but this is a
broken support.

The qlogicfc driver blocks the kernel each time a FC event occured and is
know to failed under heavy load (not so heavy, under load IMHO).

Christophe

On Fri, 29 Jun 2001 12:52:53 Mike Black wrote:
> I have been running successfully with qla2x00src-4.15Beta.tgz for several
> months now over several kernel versions up to 2.4.5.
> When I tested 2.4.6-pre6 I decided to use the qlogicfc driver -- BAD
> MISTAKE!!!
> 
> #1 - My system had crashed (for a different reason) and when the raid5
> was
> resyncing and e2fsck happening at the same time the kernel locked with
> messages from qlogicfc.o:
> qlogicfc0: no handle slots, this should not happen.
> hostdata->queue  is 2a, inptr: 74
> I was able to repeat this several times so it's a consistent error.
> Waiting for the raid resync to finish did allow this complete -- but now
> when I come in the next morning the console is locked up and no network
> access either.  So I reset it.  Checked the logs and here it is again:
> Jun 29 03:39:21 yeti kernel: qlogicfc0 : no handle slots, this should not
> happen.
> Jun 29 03:39:21 yeti kernel: hostdata->queued is 36, in_ptr: 13
> This was during a tape backup.
> 
> So I'm switching back to qla2x00src-4.15Beta.tgz -- which does the resync
> and e2fsck just fine together BTW.
> Jun 29 06:22:47 yeti kernel: qla2x00: detect() found an HBA
> Jun 29 06:22:47 yeti kernel: qla2x00: VID=1077 DID=2100 SSVID=0 SSDID=0
> 
> Only problem is I don't see this package on qlogic's website anymore and
> their "beta" directory is empty now.  I'm waiting to see what their tech
> support says.
> 
> ________________________________________
> Michael D. Black   Principal Engineer
> mblack@csihq.com  321-676-2923,x203
> http://www.csihq.com  Computer Science Innovations
> http://www.csihq.com/~mike  My home page
> FAX 321-676-2355
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: Qlogic Fiber Channel

[Alan Cox]

> =46rom my point of view, this driver is sadly broken. The fun part is t=
> hat
> the qlogic driver is certainly based on this one too (look at the code,=
>  the
> drivers differs not so much).=20

And if the other one is stable someone should spend the time merging the
two.

> IMHO the qlogicfc driver should be removed from the kernel tree and per=
> haps
> replaced by the last qlogic one. We then lost the IP support but this i=
> s a
> broken support.

For 2.5 that may wellk make sense. Personally I'd prefer someone worked out
why the qlogicfc driver behaves as it does. It sounds like two small bugs
nothing more

1.	That the FC event code wasnt updated from 2.2 so now runs
	with IRQ's off when it didnt expect it

2.	That someone has a slight glitch in the queue handling.
> 

Re: Qlogic Fiber Channel

[christophe barbé]

Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit :
> > From my point of view, this driver is sadly broken. The fun part is
that
> > the qlogic driver is certainly based on this one too (look at the code,
> > the drivers differs not so much).
> 
> And if the other one is stable someone should spend the time merging the
> two.

That what I would like to try but It seems impossible without an
IP-enhanced firmware. I could try with the old firmware but I believe that
the new code from QLogic use some features that are only in recent
firmware.

> 
> > IMHO the qlogicfc driver should be removed from the kernel tree and
> > perhaps replaced by the last qlogic one. We then lost the IP support
> > but this is a broken support.
> 
> For 2.5 that may wellk make sense. Personally I'd prefer someone worked
> out
> why the qlogicfc driver behaves as it does. It sounds like two small bugs
> nothing more
> 
> 1.	That the FC event code wasnt updated from 2.2 so now runs
> 	with IRQ's off when it didnt expect it
> 
> 2.	That someone has a slight glitch in the queue handling.

This driver is already buggy under kernel 2.2. This driver is a well known
source of problems in the GFS mailing lists.

I believe that the better thing to do is to use the qlogic driver. If we
manage to get a recent IP-enhanced firmware we could rewrite the missing IP
code. Half of the job is already done in the source of this driver.

I didn't manage to reach the good person from qlogic. Perhaps someone would
have better results.

Christophe

-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: Qlogic Fiber Channel

[Alan Cox]

> manage to get a recent IP-enhanced firmware we could rewrite the missing =
> IP
> code. Half of the job is already done in the source of this driver.
> 
> I didn't manage to reach the good person from qlogic. Perhaps someone wou=
> ld
> have better results.

Well lets wait and see what qlogic have to say, but removing IP support in
the middle of a stable release is bad. And I still do not believe the
driver will be hard to fix, its relatively clean

Re: Qlogic Fiber Channel

[Matthew Jacob]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2757 bytes --]


You know, this is probably slightly OTm, but I've been getting closer
and closer to what I consider 'happy' for my QLogic megadriver under
Linux- I have just a tad more to deal with in local loop failures (I
spent far too much time working on fabric only)- but I've been happier
with it and need to close it up and move on.

I *do* plan to finish IP support eventually.

I certainly would like to get more feedback about it.

Feel free to pick up-

bk://blade.feral.com:9002
ftp://ftp.feral.com/pub/isp/isp_dist.tgz

It's certainly got the latest f/w in it which you can try and use with
qlogicfc.

-matt


On Fri, 29 Jun 2001, [ISO-8859-1] christophe barbé wrote:

>
> Le ven, 29 jun 2001 17:09:56, Alan Cox a écrit :
> > > From my point of view, this driver is sadly broken. The fun part is
> that
> > > the qlogic driver is certainly based on this one too (look at the code,
> > > the drivers differs not so much).
> >
> > And if the other one is stable someone should spend the time merging the
> > two.
>
> That what I would like to try but It seems impossible without an
> IP-enhanced firmware. I could try with the old firmware but I believe that
> the new code from QLogic use some features that are only in recent
> firmware.
>
> >
> > > IMHO the qlogicfc driver should be removed from the kernel tree and
> > > perhaps replaced by the last qlogic one. We then lost the IP support
> > > but this is a broken support.
> >
> > For 2.5 that may wellk make sense. Personally I'd prefer someone worked
> > out
> > why the qlogicfc driver behaves as it does. It sounds like two small bugs
> > nothing more
> >
> > 1.	That the FC event code wasnt updated from 2.2 so now runs
> > 	with IRQ's off when it didnt expect it
> >
> > 2.	That someone has a slight glitch in the queue handling.
>
> This driver is already buggy under kernel 2.2. This driver is a well known
> source of problems in the GFS mailing lists.
>
> I believe that the better thing to do is to use the qlogic driver. If we
> manage to get a recent IP-enhanced firmware we could rewrite the missing IP
> code. Half of the job is already done in the source of this driver.
>
> I didn't manage to reach the good person from qlogic. Perhaps someone would
> have better results.
>
> Christophe
>
> --
> Christophe Barbé
> Software Engineer - christophe.barbe@lineo.fr
> Lineo France - Lineo High Availability Group
> 42-46, rue Médéric - 92110 Clichy - France
> phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
> http://www.lineo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Qlogic Fiber Channel

[David S. Miller]

Alan Cox writes:
 > > =46rom my point of view, this driver is sadly broken. The fun part is t=
 > > hat
 > > the qlogic driver is certainly based on this one too (look at the code,=
 > >  the
 > > drivers differs not so much).=20
 > 
 > And if the other one is stable someone should spend the time merging the
 > two.

Actually, I think "sadly broken" depends upon your situation.
I've been using the driver just fine on my systems here, even
during cerberus stress testing.  So it is working perfectly fine
for some people.

Later,
David S. Miller
davem@redhat.com

Re: Qlogic Fiber Channel

[Matthew Jacob]

On Fri, 29 Jun 2001, David S. Miller wrote:

>
> Alan Cox writes:
>  > > =46rom my point of view, this driver is sadly broken. The fun part is t=
>  > > hat
>  > > the qlogic driver is certainly based on this one too (look at the code,=
>  > >  the
>  > > drivers differs not so much).=20
>  >
>  > And if the other one is stable someone should spend the time merging the
>  > two.
>
> Actually, I think "sadly broken" depends upon your situation.
> I've been using the driver just fine on my systems here, even
> during cerberus stress testing.  So it is working perfectly fine
> for some people.

That's actually the story of Fibre Channel.

What is cerberus testing?

Try the following: try issuing a LIP every 180 seconds for 24 hours
during load with auditted pattern checkers (whether local loop or fabric
topologies). If you (and, haha, your fabric switches) survive that
without losing data or disks, then we'll begin to talk about 'fine'.

-matt

Re: Qlogic Fiber Channel

[David S. Miller]

Matthew Jacob writes:
 > That's actually the story of Fibre Channel.
 > 
 > What is cerberus testing?

VA Linux's stress tester suite.

Later,
David S. Miller
davem@redhat.com