From: Justin Piszcz <jpiszcz@lucidpixels.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Page Allocation Failures Return With 2.6.9+TSO patch.
Date: Sat, 23 Oct 2004 06:02:08 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.61.0410230558060.639@p500> (raw)
In-Reply-To: <417A251A.2040209@yahoo.com.au>
It does not seem like they do, but they cannot be good...
I have applied the following patches
1] TSO patch
2] rollup.patch
Rebooting now and will alert the list if/when I receive more page
allocation failures.
FYI - I started getting these with 2.6.9.
(However, it was always possible on the Dell Optiplex GX1 to create page
allocation failure with: ifconfig eth0 mtu 9000), however, on a higher-end
machine (2.6GHZ, 2GB ram, etc) ifconfig eth0 mtu 9000 worked fine.
Is it something with the architecture of the box bus/box?
Why does it tend to affect one machine and not the other?
On Sat, 23 Oct 2004, Nick Piggin wrote:
> Justin Piszcz wrote:
>> Applying this patch now and I will let everyone know what happens, thanks.
>>
>> On Sat, 23 Oct 2004, Nick Piggin wrote:
>>
>>> Justin Piszcz wrote:
>>>
>>>> Kernel 2.6.9 w/TSO patch.
>>>>
>>>> (most likely do to the e1000/nic/issue)
>>>>
>>>> $ dmesg
>>>> gaim: page allocation failure. order:4, mode:0x21
>>>> [<c01391a7>] __alloc_pages+0x247/0x3b0
>>>> [<c0139328>] __get_free_pages+0x18/0x40
>>>> [<c035c33a>] sound_alloc_dmap+0xaa/0x1b0
>>>> [<c03648c0>] ad_mute+0x20/0x40
>>>> [<c035c70f>] open_dmap+0x1f/0x100
>>>> [<c035cb58>] DMAbuf_open+0x178/0x1d0
>>>> [<c035a4fa>] audio_open+0xba/0x280
>>>> [<c015d863>] cdev_get+0x53/0xc0
>>>> [<c035968c>] sound_open+0xac/0x110
>>>> [<c035898e>] soundcore_open+0x1ce/0x300
>>>> [<c03587c0>] soundcore_open+0x0/0x300
>>>> [<c015d524>] chrdev_open+0x104/0x250
>>>> [<c015d420>] chrdev_open+0x0/0x250
>>>> [<c0152d82>] dentry_open+0x1d2/0x270
>>>> [<c0152b9c>] filp_open+0x5c/0x70
>>>> [<c01049c8>] common_interrupt+0x18/0x20
>>>> [<c0152e75>] get_unused_fd+0x55/0xf0
>>>> [<c0152fd9>] sys_open+0x49/0x90
>>>> [<c010405b>] syscall_call+0x7/0xb
>>>
>>>
>>> Ouch, 64K atomic DMA allocation.
>>>
>>> The DMA zone barely even keeps that much total memory free.
>>>
>>> The caller probably wants fixing, but you could try this patch...
>>>
>>
>
> Oh... these allocation failure don't actually hurt anything, do they?
> sound_alloc_dmap would have just reverted to using a 32K buffer instead
> of a 64K one.
>
> Probably the easiest thing to do is stick a __GFP_NOWARN on that
> allocation.
>
next prev parent reply other threads:[~2004-10-23 10:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-23 8:35 Justin Piszcz
2004-10-23 9:14 ` Nick Piggin
2004-10-23 9:22 ` Justin Piszcz
2004-10-23 9:32 ` Nick Piggin
2004-10-23 10:02 ` Justin Piszcz [this message]
2004-10-23 10:29 ` Nick Piggin
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=Pine.LNX.4.61.0410230558060.639@p500 \
--to=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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
all inboxes | Powered by JetHome®