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.