LPFC Driver Release Notes¶

The following information is provided for additional background on thehistory of the driver as we push for upstream acceptance.

Cable pull and temporary device Loss:

In older revisions of the lpfc driver, the driver internally queued i/oreceived from the midlayer. In the cases where a cable was pulled, linkjitter, or a device temporarily loses connectivity (due to its cablebeing removed, a switch rebooting, or a device reboot), the driver couldhide the disappearance of the device from the midlayer. I/O’s issued tothe LLDD would simply be queued for a short duration, allowing the deviceto reappear or link come back alive, with no inadvertent side effectsto the system. If the driver did not hide these conditions, i/o would beerrored by the driver, the mid-layer would exhaust its retries, and thedevice would be taken offline. Manual intervention would be required tore-enable the device.

The community supporting kernel.org has driven an effort to removeinternal queuing from all LLDDs. The philosophy is that internalqueuing is unnecessary as the block layer already performs thequeuing. Removing the queues from the LLDD makes a more predictableand more simple LLDD.

As a potential new addition to kernel.org, the 8.x driver was asked tohave all internal queuing removed. Emulex complied with this request.In explaining the impacts of this change, Emulex has worked with thecommunity in modifying the behavior of the SCSI midlayer so that SCSIdevices can be temporarily suspended while transport events (such asthose described) can occur.

The proposed patch was posted to the linux-scsi mailing list. The patchis contained in the 2.6.10-rc2 (and later) patch kits. As such, thispatch is part of the standard 2.6.10 kernel.

By default, the driver expects the patches for block/unblock interfacesto be present in the kernel. No #define needs to be set to enable support.