Bug 149294

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