Proposal for CONFIG_SCSI_NO_ISA switch in 2.2.x series kernels
==============================================================
D. Gilbert 990504
Background
----------
Firstly the following only applies to architectures that support
cards like ISA SCSI adapters that have a limited DMA address range
(eg 24 bits or the lower 16MB of RAM). Unfortunately this includes
the most common architecture: i386.
The memory management sub-system attempts to use all the RAM available
in a machine in an optimal way. In the case of a Linux kernel in the
2.2 series with 64MB of RAM, this means that nearly all but the last few
megabytes of RAM are taken by the time the machine is booted, X started
and a desktop like GNOME or KDE is loaded.
For the SCSI sub-system in which most of the memory management is done
by its mid-level this represents a problem that is exacerbated as
more and more RAM becomes the norm. Even if PCI adapters have been seen
at boot time, it is still possible that an ISA adapter (ie a low level
scsi device driver) is loaded as a module later. Hence the SCSI mid
level driver must take the worst case approach and allocate all its
buffers as if and ISA adapter is present.
Hence all SCSI command blocks and the buffer pool are allocated under
the 16MB level. Any time a new high level driver (eg st, sr or sg)
or low level driver (eg aic7xxx) is loaded the mid-level will
attempt to get more command blocks and increase its buffer pool.
This operation is failing to find the appropriate memory more
often in the 2.2 series of kernels. Note that it make no difference
to the mid-level whether an ISA or PCI SCSI adapter is loaded, it
still tries to get more memory below the 16MB level.
Proposal
--------
The proposal is to add a kernel configuration switch:
CONFIG_SCSI_NO_ISA [default initially "N"]
It would have the following effect when "Y":
- Any attempt to load an ISA adapter (or more precisely
"unchecked_isa_dma == 1") at boot time or as a module is rejected
by the SCSI mid-level with an appropriate message to the console,
log and/or insmod.
- the SCSI mid-level does _not_ restrict itself below the 16MB level
when allocating new command blocks or enlarging its buffer pool.
Benefits
--------
The proposal is backward compatible with the existing regime while
the default is "N". If the user decides to make it "Y" then there
is a much lower probability that any of the following will fail:
- loading high level modules (eg sr, st or sg)
- loading low level modules (eg SCSI bus adapters)
- playing with device allocations using "add-single-device" and
"remove-single-device"
Open Issues
-----------
Need to determine if this has an adverse impact on SCSI emulation
drivers like ide-scsi. Also whether low level drivers that handle
both ISA and PCI adapters (eg Advansys) make the same sort of
worst case memory allocation decisions as the SCSI mid level does.
Implementation
--------------
I do not believe that much code needs to be changed in the SCSI
mid level and the high level and low level drivers can be left
untouched (with the above reservation to be resolved). I am also
prepared to make these changes if people agree it is a good idea
or worthy of testing.
Suggestion for Distributions
----------------------------
If you need to make a boot disk with lots of modules on it
(a la Redhat) then the boot parameter "mem=16M" is used
if more than 16MB of memory is available. This mimimizes
the chances of SCSI modules (and sound modules) running
out of space!
Feedback
--------
My email address is [EMAIL PROTECTED] while the natural forum
to discuss this would be on [EMAIL PROTECTED] .
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
