Bug 68957 - scsi_merge.c : short on DMA buffers
scsi_merge.c : short on DMA buffers
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-07-16 11:06 EDT by paulm
Modified: 2007-04-18 12:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-23 10:19:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description paulm 2002-07-16 11:06:57 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 

Description of problem:
When I updated my RH 7.3 ibm/intel servers to 2.4.18-5, I noticed an error 
that wasnt happening before:
"Warning - running *really* short on DMA buffers"
This happened on several machines, but only one type of model and configuration
(1Ghz ibmx220 512M ram single scsi disk -aic7xxxx) . The message appears 1-10 
times during heavy i/o , specifically during long rcopy (rsh) operations 
between servers. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. do heavy i/o (ie rsh 5 Gigs of data @ 100 mips)

Actual Results:  The error message appeared as indicated above 
(on /dev/console)
No other ill-effects appear to occur

Expected Results:  No messages.

Additional info:
Comment 1 Daniel Davidson 2002-07-18 16:03:27 EDT
I can confirm I am getting the same error messages using an adaptec 29160 card
hooked up to an 8 disk promise raid when moving large files to the raid from the
IDE disk or by formatting the raid.

Athlon 1.66 GHz
1.5 MB ram
promise ultratrack sx8000
Asus A7v 333 motherboard
Comment 2 Arjan van de Ven 2002-07-18 18:37:56 EDT
The message, while sounding serious, USUALLY isn't. Basically it's a "uh oh,
we're getting in the neighborhood of trouble", without actually getting into
real trouble. However if the system actually dies it's an indication about WHY
it died; just about always it doesn't die though. (you need to do some serious
effort to get to that point, I managed that once with a VERY broken VM in a
2.4.6 kernel ;( ). If the VM does it's job the "oh shit" case can't actually happen.
Comment 3 Drew Bertola 2002-08-16 18:55:44 EDT
I'm getting a similar result on two identical servers based on Tyan 2510 w/
on-board sym53c8xx.  I get these when doing large file (100+ MB) ops like
gunzip, unzip, scp (to the box), etc.  This would give me a bunch of the "really
short on DMA buffer" messages, followed by a kernel panic.  This happened only
after updating the kernel to 2.4.18-5-smp, but goes away when reverting to
2.4.18-smp-3.  This 100% reproducible on these systems, but not on my Tyan
workstation (w/ off-board aic7xxx).

These systems have:
- ServerWorks OSB4 IDE Controller.
- 53c1010 Ultra3 SCSI Adapter (x2).

The boxes are running 2 x 1GHz PIII, 1 GB PC-133, 2 x FUJITSU MAN3184MP 18GB 10K
U160 in software RAID0, CD-ROM on IDE secondary.  RH 7.3 + all relevant updates
(less kernel update as noted above).
Comment 4 paulm 2002-08-23 09:48:28 EDT
More info:
I can only make this happen on a disk setup ext3 with journal=full. If I set 
journal to default, it takes all the i/o pounding plus much more- no DMA 
messages. I don't suppose this is actually a tweakable buffer? 
PS- there was a ext3 major change from 2.4.18-3 to 2.4.18-5, I wonder if that 
is related..or it is indeed just a noisy kernel
Comment 5 Stephen Tweedie 2002-08-23 10:19:17 EDT
There is no such ext3 option as "journal=full" --- what options exactly are you
using there?

The ext3 change between -3 and -5 is quite minor.
Comment 6 Stephen Tweedie 2002-08-23 10:22:06 EDT
The "short on dma buffers" message is not a bug: it is simply a message that the
driver was getting short on resources at one point, but that it survived, so
I'll close this as NOTABUG.

However, the update from drew@drewb.com indicates that the message was followed
by a panic, and that is much more likely to be a real bug.  Drew, please open
that as a separate bug report, and include the full kernel panic (either in the
text or as an attachment) so that we can start to look at that.
Comment 7 paulm 2002-08-23 11:30:10 EDT
The actual journal option is data=journal (referred to as "full journal").  
This is the only journaling mode that can produce this message.
NOTABUG? So Bugzilla policy is messages w/o symptoms are not bugs?
(I humbly ask). Any hints on how to make this go away or tweak buffers so this 
buffer "danger zone" is not breached will be appreciated.
PS- I tune actual the journal size maximum size (instead of default) for 
maximum performace (I read that somewhere), but not sure what else I can tweak 
or experiment with...  I'm 1/2 tempted to hack the driver and take the message 
out... Thanks 

Comment 8 Drew Bertola 2002-08-30 01:04:30 EDT
I've opened a new bug report (#73048) as suggested.

Note You need to log in before you can comment on or make changes to this bug.