From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 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): How reproducible: Always 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 Additional info:
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, and up.
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). Thanks.
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 <coughlan> To:Danny_Trinh CC:arjanv, Clay_Cooper, stevens 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 following: kernel: scsi(0): LOOP UP detected kernel: scsi0: Topology - (N_Port-to-N_Port), Host Loop address 0x1 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. Thanks. Tom Danny_Trinh wrote: > > 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 [coughlan] > Sent: Wednesday, April 10, 2002 8:45 AM > To: Danny_Trinh.com > Cc: arjanv; clay_cooper.com > Subject: Bugzilla Bug - 59894 "Pensacola qlogic drivers not seeing 660F > luns" > > Danny, > > On 2002-04-05 you reported that you "saw luns on beta4 (using > qla2200)". > > 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). Arjan?
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 the customers.