Red Hat Bugzilla – Bug 165850
Disable FAN processing in Emulex lpfc driver
Last modified: 2007-11-30 17:07:08 EST
From my rhkernel-list posting on 05 Aug 2005:
Emulex requests the following fix for U6, if possible.
The current driver does not process a particular FC link event properly.
This can cause devices on the FC to become inaccessible.
The details: when an FC initialization event occurs a node can
optionally wait for a Fabric Address Notification (FAN) to arrive from
another node that it was in communication with. If the address
information in the FAN exactly match the values prior to the
initialization, then any existing exchanges can be resumed. If the FAN
does not arrive, or it is ignored, or the address values do not match,
then communication with the the remote node is restarted from scratch
(FLOGI - Fabric Login).
The patch simply ignores the FAN and goes straight to FLOGI. This is
done to keep the fix as simple as possible. The FLOGI path should be
very safe because it is already the default approach used in most other
FC link events.
I built the patched driver and did some regression testing. Emulex has
tested it and has already given it to their big OEMs for qualification.
Taking this patch is the best way for us to keep U6 synchronized with
the rest of the world.
Broadly speaking, this may come under the "addressing committed hardware
support" post-beta critera:
Without this patch, the lpfc driver does not work reliably on Fibre Channel
public loops. Public loops are not common for hba's - they are usually fabric,
point to point, or private loop. However, a large (3-letter acryonym) blade
vendor has embedded a switch, which runs loop for all the hbas on the blade and
uplinks to an external switch. Thus the configuration is now much more prevalent.
The rest of the justification is that the patch is low risk, and it keeps is
synchronized with the driver version that is being certified at the big OEMs
(this is a high priority for EMC, because of their support martix, in particular).
Adding to U6 proposed list and adding devel_ack.
*** Bug 165848 has been marked as a duplicate of this bug. ***
*** Bug 165849 has been marked as a duplicate of this bug. ***
This is a low risk, high return change. Quality Emulex support is vital.
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-35.EL).
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.