[949] in linux-scsi channel archive
Re: MD + NCR 53c7,8xx driver = death
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Sat Nov 16 18:20:31 1996
Date: Sun, 17 Nov 1996 01:18:46 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Dan Hollis <goemon@sasami.anime.net>
cc: linux-scsi@vger.rutgers.edu, linux-raid@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95.961116132226.16731A-100000@sasami.anime.net>
Dan,
Finally, I am not surprised too much, but I think that the 53c7,8xx
driver is not the only cause of the problem.
My guess, now:
The 53c7,8xx driver allocates all its internal command control blocks very
early and 4 per device.
After all scsi devices has been scanned, the scsi middle driver call
low-level drivers in order to select the queue depth for detected devices
and then tries to resize its dma pool.
In my opinion, it tried to increase it, but some allocations failed because
the 53c7,8xx driver just allocated too much reserved pages for GFP_ATOMIC
priority and remaining is not enough.
If you donnot enable tagged command queueing, the ncr53c8xx driver
allocates only 1 control block per device.
Can you give a try with tagged command queuing enabled in Linux config.
In this case, the ncr53c8xx driver will allocate 4 control block per
device that supports tagged commands and in my opinion your drives do
support this feature.
(It allocates 1 control block at a time on command completion, so 4 scsi
command completions will be necessary in order to allocate 4 control blocks)
Gerard.
On Sat, 16 Nov 1996, Dan Hollis wrote:
> On Sat, 16 Nov 1996, Gerard Roudier wrote:
> > On Sat, 16 Nov 1996, Dan Hollis wrote:
> > > Using the NCR 53c7,8xx driver with MD is certain death at the moment.
> > >
> > > mkfs -t ext2 /dev/md0 starts up, gets to about block 39 then the kernel
> > > starts spewing hundreds of:
> > >
> > > Warning - running *really* short on DMA buffers
> > > Warning - running *really* short on DMA buffers
> > > Warning - running *really* short on DMA buffers
> > > [ad infinitum]
> > >
> > > The ported freeBSD ncr53c8xx works fine.
> > Obviously, my opinion is that the ncr53c8xx driver is better.
> > However, I would be surprised if the 53c7,8xx driver is the real cause of
> > the problem you report.
> >
> > Can you send the linux version, kernel config and scsi hardware description
> > you are using?
>
> Linux 2.0.25, P90, 64mb ram, PCI
> MD Support, RAID0 as module
> SCSI support as module
> SCSI disk support as module
> NCR53c7,8xx SCSI as module, with defaults
> NCR53C8XX as module, with defaults
>
> news:~$ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: SEAGATE Model: ST43400N Rev: 1027
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 02 Lun: 00
> Vendor: SEAGATE Model: ST43400N Rev: 1022
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 03 Lun: 00
> Vendor: SEAGATE Model: ST43400N Rev: 1027
> Type: Direct-Access ANSI SCSI revision: 02
>
> news:~# cat /proc/mdstat
> Personalities : [2 raid0]
> read_ahead 120 sectors
> md0 : active raid0 sda1 sdb1 sdc1 8528928 blocks 32k chunks
> md1 : inactive
> md2 : inactive
> md3 : inactive
>
> With NCR53c7,8xx the system has problems.
> With NCR53C8XX the system has no problems.
