Re: page allocation failure

[Hugo Vanwoerkom <hvw59601@care2.com>]

Eric Gaumer wrote:
> On Mon, 2004-10-25 at 07:35 -0500, Hugo Vanwoerkom wrote:
>
> > Eric Gaumer wrote:
> >
> > > On Sun, 2004-10-24 at 15:20 -0500, Hugo Vanwoerkom wrote:
> > >
> > >
> > > > Hi Debian!
> > > >
> > > > In 2.6.9 I am seeing for the first time:
> > > >
> > > > debian kernel: realplay.bin: page allocation failure. order:4, mode:0x21
> > > >
> > > > Followed by more messages mentioning modules.
> > > >
> > > > It does not seem to cause any noticable problem: realplay plays as usual.
> > > >
> > > > What is it? Anybody knows some details?
> > >
> > >
> > > Yikes... a 64K atomic allocation request. This message is basically the
> > > kernel saying "sorry but I don't have the resources to complete your
> > > request". 
> > >
> > > The problem is that the request is atomic (0x21) meaning the process
> > > cannot sleep so that the swapper can run and free up enough _contiguous_
> > > pages. There is no real harm done and the process most likely falls back
> > > to a smaller request.
> > >
> > > You should repost this problem on the kernel mailing list and be sure to
> > > include the stack dump that followed the allocation failure. 
> > >
> > > This problem was brought yesterday on the LKML and Nick submitted a
> > > patch fixing some TSO stuff dealing with large order allocations in
> > > interrupt context. Are you using TSO?
> >
> > One of the clueless here :-( what's TSO? I used to use T(ime) S(haring) 
> > O(ption) om MVS but I am sure that's not it.
>
>
> Sorry. TSO is TCP Segmentation Offloading. It basically means the OS
> does not break network data up into the default MTU size but instead
> sends the huge chunk a data to the network driver who in turn does the
> segmentation.
>
> It reduces CPU usage because the work is handled by the hardware (NIC)
> and we do less DMA but it means we need to make large allocations in
> interrupt context.

But I notice TSO is mostly related to NIC stuff, which I don't have.
Anyway I am going to try the patch that was given in LKML.
Thanks.

Hugo

> > > Does the stack trace have a call to sound_alloc_dmap in it?
> >
> > Yup:
> > debian kernel:  [sound_alloc_dmap+157/400] sound_alloc_dmap+0x9d/0x190
>
>
> Yea there were a few more posts this morning (LKML) so definitely check
> out those archives.
>
>
> > > It's relatively safe to say that there is no real harm here. Check
> > > yesterdays LKML archives for the full details and/or to post your
> > > problem on the correct list.
> >
> > That's what I was after! Thanks!
> >
> > Hugo