Bug 165850 - Disable FAN processing in Emulex lpfc driver
Disable FAN processing in Emulex lpfc driver
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Coughlan
Brian Brock
:
: 165848 165849 (view as bug list)
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2005-08-12 16:39 EDT by Tom Coughlan
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 11:32:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Coughlan 2005-08-12 16:39:19 EDT
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.
Comment 1 Tom Coughlan 2005-08-12 16:49:23 EDT
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.
Comment 2 Ernie Petrides 2005-08-12 17:09:15 EDT
*** Bug 165848 has been marked as a duplicate of this bug. ***
Comment 3 Ernie Petrides 2005-08-12 17:10:41 EDT
*** Bug 165849 has been marked as a duplicate of this bug. ***
Comment 4 Rob Kenna 2005-08-13 09:17:02 EDT
This is a low risk, high return change.  Quality Emulex support is vital.
Comment 5 Ernie Petrides 2005-08-19 17:58:49 EDT
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).
Comment 8 Red Hat Bugzilla 2005-09-28 11:32:35 EDT
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-2005-663.html

Note You need to log in before you can comment on or make changes to this bug.