Bug 221328

Description of problem:

qla4xxx/qla3xxx: co-existence issues during load/unload of either interface

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.With qla4xxx and qla3xxx modules loaded,
unloading/loading or bringdown/up one of the qla3xxx interfaces can sometimes
lock up the qla4xxx driver. 
2.With qla4xxx and qla3xxx modules loaded, unloading the qla4xxx module on a
4052 (one with two ports) can lock up the qla4xxx driver.
3.Another simple test is to run traffic on the ISCSI side and simply unload the
qla3xxx module. This would cause the iscsi traffic to stop.
  
Actual results:


Expected results:

One should be able to unload/load either of the modules or bring up/down the
ethernet interfaces with out the other module knowing about it.

Additional info:


The reason is as follows:
qla4xxx supports one Ethernet and one iscsi Interfaces per port.
qla4052 has two physical ports and qla4050 has one port.
qla4052 presents four PCI devices and qla4050 presents two PCI devices.

Irrespective of how many PCI devices are presented, they all share the same
hardware state machine. When one of the interface resets the hardware all other
interface are notified via an interrupt of this event. All interfaces need to
acknowledge the interrupt before the reset actually completes. (please note
there is a timeout mechanism which takes care of the case when one or more of
the interfaces do not acknowledge). To maintain atomicity during
resets/initialization of the hardware a semaphore register is provided. The
individual driver instances corresponding to each interface need to grab this
common semaphore before performing a reset/initialization. As part of the module
unload we leave the chip in a known state buy doing a reset. 

When the ethernet interface is going down or when qla3xxx is unloaded, the
qla4xxx driver is posted an interrupt which results in the initialization
process getting kicked. However the hardware semaphore was not grabbed prior to
it which results in the lock up.

The other case is on a qla4052, when the qla4xxx module is unloaded,
qla4xxx_remove_adapter() gets invoked for the first iSCSI function, the
resulting reset triggers a notification to the second iSCSI function, which
begins its initialization. During this time the qla4xxx_remove_adapter()
completes for the first function and gets called for the second one. This screws
up everything. So I added ql4_mod_unload flag to make sure the second function
does not start initializing when the module is getting unloaded.

This patch has been verified by IBM as well