From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-kernel@vger.kernel.org, akpm@osdl.org, andrea@novell.com
Subject: Re: Non-e1000, 2.6.9 page allocation failures with OSS/audio.
Date: Fri, 12 Nov 2004 08:41:58 -0200 [thread overview]
Message-ID: <20041112104158.GJ22133@logos.cnet> (raw)
In-Reply-To: <4194A9F9.7060901@yahoo.com.au>
On Fri, Nov 12, 2004 at 11:18:01PM +1100, Nick Piggin wrote:
> Justin Piszcz wrote:
> >The other page allocation failures were due to the e1000+TSO
> >segmentation offload issue.
> >
> >I use OSS sound drivers with 2.6.9.
> >
> >Here are the options I use and have been using for quite some time
> >without error:
> >
> >1] <*> Open Sound System (DEPRECATED)
> >2] <*> OSS sound modules
> >3] [*] Verbose initialisation
> >4] [*] Persistent DMA buffers
> >5] <*> Crystal CS4232 based (PnP) cards
> >
> >My LILO append line as is follows:
> >append="cs4232=0x530,5,1,0,388,5 mce video=atyfb:1600x1200-16@60"
> >
> >What happened to the page allocation / memory subsystem in 2.6.9?
> >I do not recall getting these with 2.6.4, 2.6.5, 2.6.6, 2.6.7, 2.6.8 or
> >2.6.8.1.
> >
>
> These failures are actually harmless and not entirely unexpected.
> That path should tell the allocator not to produce warnings on
> failure.
>
> The issue is being actively worked on in the -mm kernels, and the
> important stuff should get into 2.6.10.
>
> However, earlier kernels had a bug that prevented a large amount
> of ZONE_DMA memory from being allocated by GFP_KERNEL allocations
> which is probably why this particular path hasn't been a problem
> before. This actually won't be completely reverted in 2.6.10, however
> the correct way to get this behaviour is with "lower zone protection"
> which Andrea had been working on... so things may happen soon.
Well, the zone->protection code is in the tree but disable by default
(Andrea's lowmem_reserve effectively enables/adjusts it, apart from changing
"protection" to "lowmem_reserve", etc).
The zone protection setup code doesnt configure any protection
for DMA zone with reference to GFP_KERNEL allocations.
It only sets up protection with reference to HIGH zone, I think.
There must be some reasoning to explain why its disable now?
Who wrote the zone->protection code, Andrew?
prev parent reply other threads:[~2004-11-12 14:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-12 12:03 Non-e1000, 2.6.9 page allocation failures with OSS/audio Justin Piszcz
2004-11-12 12:18 ` Nick Piggin
2004-11-12 10:41 ` Marcelo Tosatti [this message]
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=20041112104158.GJ22133@logos.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=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