public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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? 

      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