From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: I am unable to add fiber channel devices to a running RHEL4 machine through a qlogic qla2xxx HBA. Under RHEL3, using the qla2xxx driver under 2.4 kernels, you could do a "scsi-qlascan" to get the card to rediscover the fabric and recognize new devices. Under RHEL4, you CAN do a scsi bus scan using the /sys filesystem, but the qla2xxx driver functionality to recognize new fibre channel devices is missing. A work-around is to load/unload the qla2xxxx drivers, but that is impossible to do with systems that boot using the qla2xxx drivers. Here is more info from Tom Sightler's post to the RHEL4 mailing list: OK, responding to my own post I have discovered a few things about this issue: 1. The echo "- - -" > /sys/class/scsi_host/host1/scan does preform a SCSI bus scan but this does not force a fabric rediscovery. 2. Support for the "scsi-qlascan" via /proc was added to the 2.6 version of the Qlogic driver in version 8.00.00b18. 3. Redhat is shipping version 8.00.00.b21-k which appears to be later than the b18 version that Qlogic claims is the version that includes the "scsi-qlascan" feature, however, looking at the source code I cannot find the code that implements this. 4. The 8.00.01 version (for SLES9) on the Qlogic website does support "scsi-qlascan" via /proc. It also compiles and seems to work fine on RHEL 4. My guess as to the reason for the discrepancy? I assume that the -k on the end of the Redhat version is for "kernel" version which means that it's the version targeted for the official kernel. I think that in 2.6 the are pushing everyone to use the sysfs interface rather than /proc to interface with the driver and thus the /proc interface was removed in the "kernel" version of the driver. I do not know this, this is only conjecture. You can download and install version the 8.00.01 version of the driver from Qlogic and get this feature back for the time being. After installing this version adding a new device is a simple as the following example: echo "scsi-qlascan" > /proc/scsi/qla2xxx/2 echo "- - -" > /sys/class/scsi_host/host2/scan I tested this with my EMC Clariion CX400 and it worked as expected. Version-Release number of selected component (if applicable): kernel-2.6.9-5.0.3.EL How reproducible: Always Steps to Reproduce: 1. zone FC device to running RHEL4 FC HBA 2. attempt fabric rediscovery 3. --try again--, --still nothing-- Additional info:
Here is further information from a discussion with Andrew Vasquez, one of the maintainers of the qlogic 8.X qla2xxx drivers: --- "The speculation mentioned in the RH bugzilla entry is essentially correct -- all new device drivers will be striped of their legacy proc_info() functions in favor of more generic mechanisms via sysfs. I have some patches that I plan on forwarding to linux-scsi which add 'issue-lip' and 'rescan' callbacks to the FC host transport template." --- "RH policy (as well as future distro) will be to only include upstream device drivers (the driver present in the vanilla kernel-sources available from ftp.kernel.org.) As such this 'qla-rescan' functionality will not be available via the 'default' RHEL drivers. Another alternative to consider would be to issue a bus-reset request (which indirectly causes a rescan) to the host via the sg_reset command -- the only downside is that it must be done via an /dev/sg device (so a device must already be present):" # sg_reset -b /dev/sgX --- "Redhat currently and SuSE in the near future will only distribute the upstream driver in their respective distributions. QLogic will continue to maintain a 'standard' driver (which includes /proc, failover and ioctl support)." --- Abe
When the patches that Andrew mentions are accepted upstream, we will consider including them in the next RHEL 4 quarterly update.
Any news on this issue? We are being affected by this and it makes migrating from RHEL3 a little bit uncomfortable.
We are working on a fix for this in U3.
Please submit test results with the 2.6.9-27.EL beta kernel (or later.) Thanks!
I can find no indication that this feature was added to the 2.6.9-27.EL kernel. Perhaps I'm looking in the wrong place. I was expecting to see a "issue-lip" or "rescan" option in sysfs for the host adapter but these don't appear to exist. I'll keep looking, but a hint to point me in the right direction would be great.
Whoops, looking at the source code I see that the code was indeed added. I found the "issue-lip" option under /sys/class/fc_host. It's a little confusing to have different options for the same host listed in different places, but I guess I understand the logic in that. Anyway, doing the following seemed to work: 1. Added a new LUN and made it visible to the system 2. echo "1" > /sys/class/fc_host/host3/issue_lip 3. echo "- - -" > /sys/class/scsi_host/host3/scan Don't know if this is right, but it seemed to work. After the "issue_lip" command the LUNs appeared in the discovered list from the adapter but were not registered with the OS. The "scan" option allowed the OS to allocate the devices and create a device mapper entry for it. That basically what I was looking for and is the equivalent of the capabilities that existed in RHEL3.
(In reply to comment #27) > Whoops, looking at the source code I see that the code was indeed added. I > found the "issue-lip" option under /sys/class/fc_host. It's a little confusing > to have different options for the same host listed in different places, but I > guess I understand the logic in that. Anyway, doing the following seemed to work: > > 1. Added a new LUN and made it visible to the system > 2. echo "1" > /sys/class/fc_host/host3/issue_lip > 3. echo "- - -" > /sys/class/scsi_host/host3/scan > > Don't know if this is right, but it seemed to work. After the "issue_lip" That is correct. I will get something in KnowledgeBase to describe this.
*** Bug 169518 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0132.html