"casler, heather" wrote:
>
> Hi Folks,
> Please let me know if this isn't the correct forum for this question. I
> have an ExpressServer 5800 NEC system with 128MB running v2.2.11 and
> attaching to an external storage device via QLA2202. I'm using the Qlogic
> driver in the kernel as a module. If I rmmod and insmod qlogicfc a few
> times, during an insmod of the driver, the system shows an error like the
> following:
>
> Nov 22 10:55:11 losba183 kernel: Vendor: EMC Model: SYMMETRIX
> Rev: 5265
> Nov 22 10:55:11 losba183 kernel: Type: Direct-Access
> ANSI SCSI revision: 02
> Nov 22 10:55:11 losba183 kernel: Detected scsi disk sdy at scsi5, channel 0,
> id 1, lun 55
> Nov 22 10:55:12 losba183 kernel: scsi::resize_dma_pool: WARNING,
> dma_sectors=2128, wanted=4144, scaling
> Nov 22 10:55:12 losba183 kernel: scsi::resize_dma_pool: WARNING,
> dma_sectors=2128, wanted=3120, scaling
> Nov 22 10:55:12 losba183 kernel: scsi::resize_dma_pool: WARNING,
> dma_sectors=2128, wanted=2352, scaling
> Nov 22 10:55:12 losba183 kernel: WARNING, not enough memory, pool not
> expanded
> Nov 22 10:55:12 losba183 kernel: SCSI device sdb: hdwr sector= 512 bytes.
> Sectors= 8837760 [4315 MB] [4.3 GB]
> Nov 22 10:55:12 losba183 kernel: sdb: sdb1
> Nov 22 10:55:12 losba183 kernel: SCSI device sdc: hdwr sector= 512 bytes.
> Sectors= 8837760 [4315 MB] [4.3 GB]
> Nov 22 10:55:13 losba183 kernel: sdc: sdc1
>
> How do I prevent this error from occurring? Is there something that I
> should modify to prevent it?
> Thanks for your help!
It is not an error, it is a warning: tread carefully. "scsi5" and
"/dev/sdy" indicates you have a lot of SCSI devices there, it would
take a long time to run fsck on all of them ...
The Linux SCSI sub-system has its own kernel memory pool implemented
using the "buddy" system. It pre-allocates kernel memory on the basis
of the devices seen and their maximum queue lengths. Each time a low
level SCSI device (adapter driver) or a "high" level device (sd, st,
sr or sg) is loaded the maximum required pool size is calculated and
if it exceeds the existing pool size then a re-allocation takes place.
If the new pool size is less than the existing size and there are still
host adapters present then nothing occurs otherwise if all host adapters
have been removed then the pool is freed.
Now the SCSI pool makes the worst case assumption that an ISA adapter
may be loaded some time in the future (if one isn't already present)
and makes all its kernel memory allocations under the 16 MByte level.
[This applies to the i386 architecture but not the alpha (which is
limited to 32 MB of pool size).] So on the i386 it doesn't matter
whether you have 1 GB of memory in the machine, what counts is the
amount of free memory under the 16 MB level and its degree of
splintering.
Before about lk 2.2.10 (or thereabouts) scsi::resize_pool() would
panic (by dereferencing 0) if enough suitable memory could not be
found. I added code that attempts to make this logic more resilient.
Now it scales the pool size by 0.75 and tries again (and
again) sending out a warning each time it scales back. It may end
up sticking with the original pool which is what the last warning
showed. The risk is that if every device tries to queue up commands
to maximum length then there won't be enough buffers available.
This is both unlikely and handled reasonably well by the existing
logic if it does occur. Perhaps those warning messages could be
muffled, probably only the first and last are significant.
A kernel boot time parameter (or a scsi_mod module parameter) telling
the SCSI sub-system to reject all ISA SCSI adapters and allocate
the scsi pool without that GFP_DMA flag would remove the problem
for those systems that don't need an ISA adapter. If you have a
1GB machine it is unlikely that you will be putting an ISA SCSI
adapter in it. Comments?
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
