> > scsi0: scanning channel 1 for devices.
> > scsi0: scanning virtual channel for logical drives.
> >   Vendor: MegaRAID  Model: LD0 RAID5 26094R  Rev: 3.00
> >   Type:   Direct-Access                      ANSI SCSI revision: 02
> > Detected scsi disk sda at scsi0, channel 1, id 0, lun 0
> > scsi::resize_dma_pool: WARNING, dma_sectors=0, wanted=13200, scaling
> > scsi::resize_dma_pool: WARNING, dma_sectors=0, wanted=9904, scaling
> > scsi::resize_dma_pool: WARNING, dma_sectors=0, wanted=7440, scaling
> > scsi::resize_dma_pool: WARNING, dma_sectors=0, wanted=5584, scaling
> > SCSI device sda: hdwr sector= 512 bytes. Sectors= 53440512 [26094 MB]
[26.1 GB]
>
> The dma_pool in the scsi mid level still makes the worst case
> assumption and allocates memory with the GFP_DMA flag (line
> 2627 of scsi.c in 2.3.40). On the i386 this implies memory
> must be found in the first 16 MB. The first request was for
> about 6.5 MB and the kernel couldn't find enough pages, so
> those were freed up and it asked for 5 MB and the kernel
> ... etc. This algorithm is an alternative to panicing or
> ignoring a NULL result from kmalloc().
>
> Does the MegaRAID really need 6.5 MBytes of scsi dma buffers?
> Has the zoning allocator been changed making memory under
> 16 MB harder to find?

    This may be a result of the over-allocation of Scsi_Cmnd buffers.  The
DMA pool is sized assuming based upon the number of devices, the queue depth
for each device, and the maximum scatter-gather table size.  The problem is
that I am not looking at the maximum number of commands that the host itself
might be able to queue at one time.  Thus even though you might have 8
devices with a queue depth of 32, if the host can only queue 32 commands at
one time, the DMA pool should be sized accordingly.

    Actually the over-allocation of Scsi_Cmnd buffers isn't really the bug
here - that is just a handful of bytes in the broader scheme of things.  The
real bug is the over-allocation of the DMA pool.   This is actually much
easier to correct, now that I think about it.

-Eric



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to