[3330] in linux-scsi channel archive
Re: Warning low DMA Buffers
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Sat Feb 14 17:16:26 1998
Date: Sat, 14 Feb 1998 17:37:51 -0500 (EST)
From: Eric Youngdale <eric@andante.jic.com>
To: flavio santos <flavio@dtpdf.gov.br>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <34E45DB4.602F@dtpdf.gov.br>
On Fri, 13 Feb 1998, flavio santos wrote:
> Using AHA 1542CF with a SCSI-CD Sony and having the Warning message
> "Running low on DMA buffers". The message is just a warninng, the CD is
> working. The computaer has 32 Mb RAM. The free command show tha buffers
> going almost to ZERO.
> Mr. Eric Youngdale (eric@andante.jic.com) gave me a helpful orientation
> telling to check out the source code in sd.c and sr.c and locate the
> line of code that matches the message. I have still some questions ...
> I have examined the sd.c and sr.c files. I've examined the amount of
> free buffers while running the scsi CD. For sure I can manage the
The DMA buffers used by the scsi subsystem are not the buffers
that are displayed by 'free' or any other user space utility. It is
possible to get at the number by hacking the kernel or through a kernel
debugger, however.
> source code to avoid that message (at least it gives me a braek :/ ),
> but the resources are still slow. I'm using the AHA1542 criver (not
> 1542CF) as a module, and I've compiled it using kernell 3.0.33 (3.0.30
> or 32 makes no difference in this case).
It won't. That code hasn't been touched in ages.
> An interesting point: after a fresh install of RedHat or Slackware, the
> SCSI works well without that warning message. Probably fresh
> installation uses another drive such as standard SCSI.
This has more to do with the way memory is used. Remember that
only physical memory < 16Mb can be used for I/O to the 1542, and you are
evidently hitting some pathological case where you are getting lots and
lots of buffers > 16Mb for some reason.
> Shouldn't the AHA1542 driver manage to negotiate the traffic betwen the
> AHA board and the buffers?
Yes, it does negotiate the traffic in an indirect way. The point
is that each low-level driver tells sr.c whether it needs bounce buffers
or not. If the driver does need the bounce buffers, then it starts using
memory from the pool. By the time the request reaches the 1542, the
buffers that are listed in the request should all be <16Mb.
The reason I pointed you at the differences between sd.c and sr.c
is that apparently someone in the past put a fix in so that if a similar
situation came up with disk drives, that a different recovery strategy
would be used (that doesn't involve printing a message). The code is
virtually identical between sd.c and sr.c, so all I am suggesting is that
you transplant the handling code from sd.c into sr.c.
-Eric
