Bug 203505

don't do that ;)

My situation is that I have some machines with an excessive number of modules 
in the initrd.  To reduce the size of the initrd I want to remove some.  So I 
try running rmmod on the modules with a 0 use count to make sure that they are 
actually not needed, the module that causes the machine to die when it is 
removed is the one that stays in the initrd.  :(

Andrew, 

Would you modify the qla2xxx drivers so they update the module use count? This
will prevent them from being unloaded while in use.

If you can provide this with whatever other changes you submit to us for RHEL
4.5 that would be ideal.

Tom

Patches to 'fix' this quirk with the reference counts not trailing the firmware-loader
modules of qla2xxx have been floating around for some time.  For a variety of reasons
(some I'll list below), we've been trying to educate users to 'not do that' (as was noted in
an earlier comment -- bottom line is you need to be root to modify (load/remove)
modules, at least understand what the implications are).

I'll attach a 'reference patch' which passes the proper module reference down to the
mid-layer sure host-registration.  There are some caveats/quirks though:

1) each firmware-loader needs it own static scsi_host_template
2) duplicate /proc/scsi/qla2xxx entries are created per loader module

(2) could be handled by not overloading proc_name with 'qla2xxx' for each 
firmware-loader and assigning the value based on firmware-loader name, e.g.
qla2300.ko assigns proc_name == 'qla2300'.  Unfortunatelely, there are large
installations which depend on /proc/scsi/qla2xxx/ data for configuration.
A name change at this stage in time is not advisable.

Also, going forward, these module-reference quirks are becoming a non-issue
given the firmware-loader modules have been removed in favor of more flexible
initramfs loading via request_firwmare().

Created attachment 137089 [details]
RFC: module-reference counting in qla2xxx

Understood. Thanks Andrew. 

We're not likely to see request_firwmare() in RHEL 4.5 :)

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

QE ack for 4.5.

committed in stream U5 build 42.38. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

*** Bug 160064 has been marked as a duplicate of this bug. ***

Note to QLOGIC: could you please test this? Thanks!

This may be the cause of IT 116776 (two instances of /proc/scsi/qla2xxx/ in 
RHEL4U5).

It has been determined that this patch can cause a system crash. See BZ 234260.
At this point in the 4.5 schedule we have no choice but to remove this patch. 

The following release note is needed for 4.5. We will consider addressing this
in 4.6. 

The QLogic driver in RHEL 4 has two parts, the main driver
(qla2xxx), and a hardware-specific firmware loader (qla2100, qla2200,
qla2300, qla2322, qla2400, qla6312). Both must be loaded for the driver
to work. Currently, the module use count for the qla2xxx module is incremented
when the attached storage is in use. The use count is not incremented for the
firmware loader modules. This means that you must use caution to never rmmod the
firmware module when it is in use. The system will not automatically prevent
this, and I/O errors will result.

adding the following note to 4.5 Release Notes Updates:

<quote>
The QLogic driver in Red Hat Enterprise Linux 4 has two components: the main
driver and a hardware-specific firmware loader. Both components must be loaded
for the driver to work. Currently, the module use count for the main driver is
incremented when the attached storage device is in use. The use count for
firmware loader modules is not incremented.

As a result, the system does not automatically prevent you from performing an
rmmod on the firmware module even when it is in use. Doing so will result in I/O
errors.

As such, you should never remove the firmware module while it is still in use. 
</quote>

please confirm if this note is sufficient. if so, we'll have it posted on the
Release Notes Updates within 24 hours.

thanks!

Only correction I can suggest is modifying the following:

  As such, you should never remove the firmware module while it is still in use.

to read as:

  As such, you should never remove the firmware module while
  the main driver module is still in use.

corrected accordingly. thanks!

release notes updates should be... updated within 24 hours or so.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Red Hat is assuming this bugzilla is only for the release note, and will revisit
this for a fix in the future.

This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.