Red Hat Bugzilla – Bug 149294
qlogic fabric rediscovery functionality missing
Last modified: 2012-06-29 02:19:24 EDT
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
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
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
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
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):
Steps to Reproduce:
1. zone FC device to running RHEL4 FC HBA
2. attempt fabric rediscovery
3. --try again--, --still nothing--
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)."
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.