allocation failure in b43/ssb - Kernel

This is a discussion on allocation failure in b43/ssb - Kernel ; We just had a report from a user who spotted a bunch of messages of the form below in his logs.. swapper: page allocation failure. order:1, mode:0x4020 Pid: 0, comm: swapper Not tainted 2.6.26.6-79.fc9.i686.debug #1 [ ] ? printk+0xf/0x17 [ ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: allocation failure in b43/ssb

  1. allocation failure in b43/ssb

    We just had a report from a user who spotted a bunch of messages
    of the form below in his logs..

    swapper: page allocation failure. order:1, mode:0x4020
    Pid: 0, comm: swapper Not tainted 2.6.26.6-79.fc9.i686.debug #1
    [] ? printk+0xf/0x17
    [] __alloc_pages_internal+0x3c0/0x3db
    [] __alloc_pages+0xa/0xc
    [] __slab_alloc+0x1aa/0x4ea
    [] __kmalloc_track_caller+0x98/0xf9
    [] ? setup_rx_descbuffer+0x3d/0x1cf [b43]
    [] ? setup_rx_descbuffer+0x3d/0x1cf [b43]
    [] __alloc_skb+0x49/0xf8
    [] setup_rx_descbuffer+0x3d/0x1cf [b43]
    [] ? ssb_pci_read32+0x29/0x31 [ssb]
    [] b43_dma_rx+0x28b/0x3f1 [b43]
    [] b43_interrupt_tasklet+0x58f/0x6e4 [b43]
    [] ? tasklet_action+0x40/0xec
    [] tasklet_action+0x7f/0xec
    [] __do_softirq+0x84/0x10a
    [] do_softirq+0x79/0xda
    [] ? handle_fasteoi_irq+0x0/0xb6
    [] irq_exit+0x44/0x77
    [] do_IRQ+0xe4/0xfd
    [] common_interrupt+0x2e/0x34
    [] ? pm_qos_add_requirement+0x39/0x93
    [] ? acpi_idle_enter_simple+0x19e/0x20e
    [] acpi_idle_enter_bm+0xbc/0x345
    [] ? pm_qos_requirement+0x26/0x2b
    [] ? menu_select+0x38/0x86
    [] cpuidle_idle_call+0x67/0x97
    [] ? cpuidle_idle_call+0x0/0x97
    [] cpu_idle+0xb8/0xd8
    [] rest_init+0x4e/0x50
    =======================
    Mem-info:
    DMA per-cpu:
    CPU 0: hi: 0, btch: 1 usd: 0
    Normal per-cpu:
    CPU 0: hi: 186, btch: 31 usd: 125
    Active:127308 inactive:26735 dirty:8411 writeback:340 unstable:0
    free:1213 slab:15322 mapped:13069 pagetables:1563 bounce:0
    DMA free:2864kB min:72kB low:88kB high:108kB active:2784kB inactive:1552kB present:16160kB pages_scanned:0 all_unreclaimable? no
    lowmem_reserve[]: 0 709 709 709
    Normal free:1988kB min:3368kB low:4208kB high:5052kB active:506448kB inactive:105388kB present:726060kB pages_scanned:1460 all_unreclaimable? no
    lowmem_reserve[]: 0 0 0 0
    DMA: 34*4kB 1*8kB 8*16kB 11*32kB 9*64kB 3*128kB 1*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 2864kB
    Normal: 341*4kB 2*8kB 20*16kB 1*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1988kB
    78549 total pagecache pages
    Swap cache: add 352198, delete 308691, find 91428/128877
    Free swap = 1065960kB
    Total swap = 1502068kB
    188128 pages of RAM
    0 pages of HIGHMEM
    4850 reserved pages
    100808 pages shared
    43507 pages swap cached
    8411 pages dirty
    340 pages writeback
    13069 pages mapped
    15322 pages slab
    1563 pages pagetables


    The kernel is a little old (2.6.26).

    Looking at it though, I'm puzzled..

    It seems we failed to allocate an order-1 allocation, even though
    we had memory available in the DMA and normal zones.

    What am I missing?

    Full logs at https://bugzilla.redhat.com/attachment.cgi?id=322882

    Dave

    --
    http://www.codemonkey.org.uk
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: allocation failure in b43/ssb

    On Fri, Nov 07, 2008 at 02:09:44PM -0500, Dave Jones wrote:
    > We just had a report from a user who spotted a bunch of messages
    > of the form below in his logs..




    > The kernel is a little old (2.6.26).
    >
    > Looking at it though, I'm puzzled..
    >
    > It seems we failed to allocate an order-1 allocation, even though
    > we had memory available in the DMA and normal zones.
    >
    > What am I missing?
    >
    > Full logs at https://bugzilla.redhat.com/attachment.cgi?id=322882


    Most of those traces look a little scrambled, but as best as I can
    tell that call to setup_rx_descbuffer comes from dma_rx. That means
    that the call to __dev_alloc_skb is done with GFP_ATOMIC. I don't
    know if that factors into the answer to what is happening or not.

    John
    --
    John W. Linville Linux should be at the core
    linville@tuxdriver.com of your literate lifestyle.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: allocation failure in b43/ssb

    On Fri, 7 Nov 2008 14:54:03 -0500 "John W. Linville" wrote:

    > On Fri, Nov 07, 2008 at 02:09:44PM -0500, Dave Jones wrote:
    > > We just had a report from a user who spotted a bunch of messages
    > > of the form below in his logs..

    >
    >
    >
    > > The kernel is a little old (2.6.26).
    > >
    > > Looking at it though, I'm puzzled..
    > >
    > > It seems we failed to allocate an order-1 allocation, even though
    > > we had memory available in the DMA and normal zones.
    > >
    > > What am I missing?
    > >
    > > Full logs at https://bugzilla.redhat.com/attachment.cgi?id=322882

    >
    > Most of those traces look a little scrambled, but as best as I can
    > tell that call to setup_rx_descbuffer comes from dma_rx. That means
    > that the call to __dev_alloc_skb is done with GFP_ATOMIC. I don't
    > know if that factors into the answer to what is happening or not.
    >


    It does. If there were not any two physically-contiguous free pages in
    the page allocator reserves, __alloc_pages() will not be able to
    satisfy that order-1 allocation request.

    You can have plenty of free memory, but if it's all fragmented,
    non-order-0 atomic allocations can still fail.

    GFP_KERNEL allocations can run page reclaim to _make_ the allocation
    request succeed in this situation.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread