-
Andrew Vasquez authored
During internal testing, we've seen issues (hangs) with the 'deferred' vport tear-down-processing typically accompanied with the fc_remove_host() call. This is due to the current implementation's back-end vport handling being performed by the physical-HA's DPC thread where premature shutdown could lead to latent vport requests without a processor. This should also address a problem reported by Gal Rosen (http://marc.info/?l=linux-scsi&m=121731664417358&w=2) where the driver would attempt to awaken a previously torn-down DPC thread from interrupt context by implicitly calling wake_up_process() rather than the driver's qla2xxx_wake_dpc() helper. Rather, than reshuffle the remove_one() device-removal code, during unload, depend on the driver's timer to wake-up the DPC process, by limiting wake-ups based on an 'unloading' flag. Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
c795c1e4