Bug 641457
| Summary: | FCoE: Do not fall back to non-FIP FLOGI [rhel-6.0.z] | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Benjamin Kahn <bkahn> |
| Component: | kernel | Assignee: | Frantisek Hrbata <fhrbata> |
| Status: | CLOSED ERRATA | QA Contact: | Storage QE <storage-qe> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.1 | CC: | bdonahue, borgan, coughlan, cward, dhoward, fge, jack.morgan, jane.lv, john.ronciak, jpirko, jvillalo, kzhang, luyu, mchristi, pm-eus, qcai, robert.w.love, rpacheco, syeghiay, yi.zou |
| Target Milestone: | rc | Keywords: | OtherQA, ZStream |
| Target Release: | 6.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-2.6.32-71.4.1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, timing issues could cause the FIP (FCoE Initialization Protocol) FLOGIs to timeout even if there were no problems. This caused the kernel to go into a non-FIP mode even though it should have been in the FIP mode. With this update, the timing issues no longer occur and the kernel no longer switches to the non-FIP mode when logging to the Fibre Channel Switch/Forwarder.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-10 19:11:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 636233 | ||
| Bug Blocks: | |||
|
Description
Benjamin Kahn
2010-10-08 18:56:40 UTC
in kernel-2.6.32-71.4.1.el6 Cannot reproduce this issue with "Emulex LPe12002-M8". It's firmware version is : 1.11A5 (U3D1.11A5), sli-3 Kernel version: 2.6.32-71.el6.x86_64 Reboot 5 times, no lpfc kernel panic came out. As comment #1 spot out: >Emulex believes there is exposure to this issue in large SAN environment where >the device discovery process could see delayed responses which result in iocbs >being queued. Do we need a large SAN environment to reproduce this issue? Please kindly ignore previous update Verified fixed by Intel 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 therefore 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-2010-0842.html
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Previously, timing issues could cause the FIP (FCoE Initialization Protocol) FLOGIs to timeout even if there were no problems. This caused the kernel to go into a non-FIP mode even though it should have been in the FIP mode. With this update, the timing issues no longer occur and the kernel no longer switches to the non-FIP mode when logging to the Fibre Channel Switch/Forwarder.
|