Red Hat Bugzilla – Bug 68957
scsi_merge.c : short on DMA buffers
Last modified: 2007-04-18 12:44:12 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
Version-Release number of selected component (if applicable):
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
No other ill-effects appear to occur
Expected Results: No messages.
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
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.
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).
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
There is no such ext3 option as "journal=full" --- what options exactly are you
The ext3 change between -3 and -5 is quite minor.
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 firstname.lastname@example.org 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.
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
I've opened a new bug report (#73048) as suggested.