Alan Cox wrote:
>
> 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?
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
