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. > > > > > > 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 > -- Eric Gaumer <gaumerel@ecs.fullerton.edu>
Attachment:
signature.asc
Description: This is a digitally signed message part