From: Andrew Morton <akpm@osdl.org>
To: Calin Szonyi <caszonyi@rdslink.ro>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Memory management problem with 2.6.0
Date: Fri, 2 Jan 2004 17:23:40 -0800 [thread overview]
Message-ID: <20040102172340.130f75ba.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.53.0401030252510.5448@grinch.ro>
caszonyi@rdslink.ro wrote:
>
> see atached file
> mplayer: page allocation failure. order:1, mode:0x21
> Call Trace:
> [<c013a3fc>] __alloc_pages+0x30c/0x350
> [<c013a45f>] __get_free_pages+0x1f/0x50
> [<c036fd5d>] sound_alloc_dmap+0x9d/0x1a0
> [<c0377ec0>] ad_mute+0x20/0x40
> [<c0370116>] open_dmap+0x26/0x100
> [<c0370554>] DMAbuf_open+0x174/0x1a0
> [<c036e0c2>] audio_open+0xc2/0x250
> [<c036d2e4>] sound_open+0xf4/0x120
> [<c036c5b5>] soundcore_open+0x1e5/0x330
> [<c036c3d0>] soundcore_open+0x0/0x330
> [<c015c3e8>] chrdev_open+0xe8/0x210
> [<c0161fdc>] open_namei+0xac/0x3f0
> [<c015c300>] chrdev_open+0x0/0x210
> [<c0152425>] dentry_open+0x145/0x210
> [<c01522d8>] filp_open+0x68/0x70
> [<c015276b>] sys_open+0x5b/0x90
> [<c0109367>] syscall_call+0x7/0xb
>
> Sound error: Couldn't allocate DMA buffer
> esd: page allocation failure. order:4, mode:0x21
> Call Trace:
> [<c013a3fc>] __alloc_pages+0x30c/0x350
> [<c013a45f>] __get_free_pages+0x1f/0x50
> [<c036fd5d>] sound_alloc_dmap+0x9d/0x1a0
> [<c0377ec0>] ad_mute+0x20/0x40
> [<c0370116>] open_dmap+0x26/0x100
> [<c0370554>] DMAbuf_open+0x174/0x1a0
> [<c036e0c2>] audio_open+0xc2/0x250
> [<c036d2e4>] sound_open+0xf4/0x120
> [<c036c5b5>] soundcore_open+0x1e5/0x330
> [<c036c3d0>] soundcore_open+0x0/0x330
> [<c015c3e8>] chrdev_open+0xe8/0x210
> [<c0161fdc>] open_namei+0xac/0x3f0
> [<c015c300>] chrdev_open+0x0/0x210
> [<c0152425>] dentry_open+0x145/0x210
> [<c01522d8>] filp_open+0x68/0x70
> [<c015276b>] sys_open+0x5b/0x90
> [<c0109367>] syscall_call+0x7/0xb
sound_alloc_dmap() is trying to perform a 4-order GFP_ATOMIC allocation.
There is just nothing the MM system can do about that - it is a basic
design problem in that part of the OSS sound system.
I'm not sure what to suggest - development and maintenance of OSS seems to
have come to a stop.
Can you use ALSA instead? If not, increasing /proc/sys/vm/min_free_kbytes
by quite a lot will probably decrease the frequency at which this occurs.
next prev parent reply other threads:[~2004-01-03 1:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-27 17:34 Memory management problem with 2.6.0 caszonyi
2003-12-28 3:41 ` Andrew Morton
2004-01-01 4:05 ` caszonyi
2004-01-01 10:04 ` Andrew Morton
2004-01-03 1:01 ` caszonyi
2004-01-03 1:23 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-12-27 23:07 caszonyi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040102172340.130f75ba.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=caszonyi@rdslink.ro \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox