Red Hat Bugzilla – Bug 59894
Pensacola qlogic drivers not seeing 660F luns
Last modified: 2007-11-30 17:06:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019
Description of problem:
On a slimmerlot with pensacola beta 1 installed, 660F luns not being detected by
qla2200 or qla2300 drivers. Both drivers load successfully, but no luns show
up. As stated, I have tried both the 2200 and 2310 qlogic cards. The cards,
cables, and SAN switch have all been successfully connected to a 7150 with RH
7.2 IA64 installed to see the luns, so this is known good hardware with
detectable configured luns
I have unloaded and reloaded both drivers several times with no success.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install pensacola beta 1
2. Use a 2200 or 2310 qlogic card with 660F direct-attached
3. After loading appropriate driver, no luns are seen and no additional scsi
drives are added.
Actual Results: No luns detected
Expected Results: Luns detected
Interesting. The fact that the ia64 release works means that one of the cleanups
broke it. After the move I'm hoping our 660VF works again.....
Duplicated on Pensacola beta 2.
Just as another piece of information, cannot see LUNs on an EMC FC700 either.
This problem was fixed in Hampton with kernel 2.4.18-0.10, for the bigmem, smp,
Hummm 2.4.18 vs pensacola ???????
Here is another data point, hopefully of some use:
I am running Pensacola 2.4.9-26beta.53 on an Intel system with QLA2200 HBAs.
When I run with the qla2200 driver (FW 2.01.35 driver 5.31.RH1), no logical
units are configured.
When I switch to the qla2x00 driver (FW 2.01.34 driver 4.31.7b), then the
logical units are configured.
The RAID box is a Winchester:
Vendor: WINSYS Model: FLASHDISK G6 Rev: 0315.
I suppose my next step will be to try the Hampton version of the qla2200 driver,
then look at the diffs between the Hampton and the Pensacola qla2200, on the
assumption that there aren't too many. Is that a reasonable plan?
It's not THAT simple. Have you configured the system to scan more luns ?
I don't think this device is on the whitelist yet
The problem of scanning for LUNs > 0 is not relavant to this problem.
With qla2200 I don't see any LUNs, including LUN 0.
With qla2x00 I see LUN 0. If I enable scanning for LUNs > 0 with this driver,
then I see them also.
John, you indicated that the problem was solved by Hampton. Can you cofirm that
you were using the qla2200 driver? (Look for "RH" in the driver rev. string of
the dmesg output).
I installed Hampton 2.4.18-0.13 and I still have the problem: the qla2200 driver
does not see any LUNs. The 2.4.18-0.13 kernel appears not have a qla2x00 driver
built in, so I have not tried that.
The problem I am having may be different than the one that John Hull had, and
reported was fixed by Hampton. The symptom is the same, though.
Used qla2200 in Hampton beta 3. Will check again in beta 4.
I saw luns on beta4 (using qla2200).
I just finished testing with the local PV660 and I see the exact same set
of LUNs (4 in this case) available as SCSI disks when using the
2.4.9-0.12 kernel and when using the 2.4.9-26beta.58 kernel.
Just bringing this report up-to-date:
Subject:Re: Bugzilla Bug - 59894 "Pensacola qlogic drivers not seeing 660F luns"
Date:Wed, 10 Apr 2002 17:24:15 -0400
From:Tom Coughlan <email@example.com>
CC:firstname.lastname@example.org, Clay_Cooper@Dell.com, email@example.com
I have been trying to determine why I am the only one who is
seeing this problem now. One thing that is unusual about my
configuration is that it uses point-to-point FC. There is no hub
or switch in the link. In fact, /var/log/messages shows the
kernel: scsi(0): LOOP UP detected
kernel: scsi0: Topology - (N_Port-to-N_Port), Host Loop address
Clay's original bug report said the 660F was using "direct
connect". Is it possible that you have changed from
point-to-point FC to something else, and that is why it is
working now? Can you look take a look at /var/log/messages on a
working system, and if it is not
"Topology - (N_Port-to-N_Port)", and maybe it used to be, then
try it the old way again?
If you can try this with Pensacola, and with EMC, that would be
helpful as well.
> I didn't test with EMC box. I saw the luns on 660F by using Hampton beta4.
> Since we didn't have a new drop of Pensacola, so I couldn't say, but the "no
> luns" problem existed in Pensacola beta 2.
> Danny Trinh
> Senior Analyst @ DELL
> CNE, MCSE, LPIC, A+
> -----Original Message-----
> From: Tom Coughlan [mailto:firstname.lastname@example.org]
> Sent: Wednesday, April 10, 2002 8:45 AM
> To: Danny_Trinh@exchange.dell.com
> Cc: email@example.com; firstname.lastname@example.org
> Subject: Bugzilla Bug - 59894 "Pensacola qlogic drivers not seeing 660F
> On 2002-04-05 you reported that you "saw luns on beta4 (using
> Was that with the 660F or the EMC, or both?
> Are either you or Clay experiencing the "no LUNs" problem with a
> current baselevel of either Pensacola or Hampton?
> I am seeing the problem here, on a Winchester storage box. Am I
> the only one?
> Tom Coughlan
> Red Hat
> 978-692-3113 ext. 23209
This is beginning to look like a firmware issue -- the card firmware can't
negotiate its own ID during LIP, but setting it to, say, 254 works fine.
Doug, please expand on this...
What we saw here was that the failing test setup would work as soon as we hard
coded the LIP address of the controller card to something that wasn't already in
use on the loop. I suspect that the firmware version 2.01.35, which is the part
responsible for loop ID arbitration if I'm correct, fails to arbitrate properly
in the absence of a controlling device such as a fiber switch (aka, in
point-to-point fiber connection setup arbitration between the controller and the
PV660 is busted, but if you interject a switch in the situation, then I think
the switch is doing the proper arbitration so that the controller doesn't have
to and that's why things work in a setup with a switch involved). Of course, I
don't have the ability to do anything with the FW itself, so it would seem to
boil down to an issue of whether or not the new firmware versions solves more
problems than this one problem it creates (especially since this problem has a
fairly easy workaround, just set the loop ID of the card manually).
I'm quite sure that this firmware had critical fixes. Arjan, do you remember
off the top of your head what some of those critical issues were?
Since there's a simple workaround, this isn't a showstopper. It is something
we should talk to qlogic about.
I'll play dumb and ask a dumb question: with "almost" the same driver, why does
the same firmware work with 7.2 IA-64 and Hampton?? What is different about
Pensacola that makes this problem show up?
It must be something specific to your test hardware; we can reproduce
with Hampton and Pensacola equally.
Connecting through Dell PowerVault 51F switch, we can see LUNs on EMC FC4700
and PV 650F using Qlogic 2310F card (qla2300.o). Checking now with Qlogic 2200
cards through switch and direct-attach.
With pensacola rc1 and a qlogic 2200 copper card, I can see all Luns on a pv650
via a switch and direct-attached. Before checking, I reset to defaults inside
the qlogic option-rom. If I need to test this with another option-rom setting
please let me know.
Closing. Can see LUNs through switch for qla2300 and qla2x00 modules. Direct-
attach works if LIP address hard-coded on HBA's. Dell hard-codes the LIP
address for 2200 cards, but it doesn't for 2310's. We will document this for