Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755479Ab2IACVp (ORCPT ); Fri, 31 Aug 2012 22:21:45 -0400 Received: from mail-vb0-f46.google.com ([209.85.212.46]:36204 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755430Ab2IACVm (ORCPT ); Fri, 31 Aug 2012 22:21:42 -0400 Date: Fri, 31 Aug 2012 19:21:04 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: David Madore cc: Francois Romieu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c() In-Reply-To: <20120829002548.GA7063@aldebaran.gro-tsen.net> Message-ID: References: <20120829002548.GA7063@aldebaran.gro-tsen.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5416 Lines: 69 [ Cc'ing original mail to netdev as the problem may be recognized there ] On Wed, 29 Aug 2012, David Madore wrote: > Dear all, > > I hope this is the right place to send this sort of backtrace dump. > > I'm getting the following sort of dumps (below) on a 3.2.27 kernel on > an arm/kirkwood (actually DreamPlug) machine that's used as a router. > > I imagine it being somehow related to the fact that it operates a > network bridge (I imagine this because I have another identical > machine with exactly the same kernel and a very similar config but not > running a bridge, and the warning never pops up). > > Is this worth investigating? (I will, of course, provide the config > file and any other relevant data if the answer is "yes".) Is this > potentially serious? (I'm getting hard lockups on this machine which > I suspect are due to hardware and unrelated to this, but if someone > tells me it could be the cause, I'd be more than happy to believe it.) > > [24711.204492] ------------[ cut here ]------------ > [24711.209151] WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c() > [24711.216667] Modules linked in: 8021q ath9k_htc mac80211 ath9k_common ath9k_hw ath cfg80211 bnep rfcomm sit tunnel4 sch_ingress cls_fw cls_u32 sch_sfq sch_htb pppoe pppox ppp_generic slhc bridge stp llc ip6t_REJECT ip6table_filter ip6table_mangle xt_NOTRACK ip6table_raw ip6_tables nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ftp nf_conntrack_ftp ipt_REJECT xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_nat xt_TCPMSS xt_tcpudp xt_mark iptable_mangle ip_tables x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 orion_wdt ipv6 snd_usb_audio snd_pcm snd_page_alloc snd_hwdep snd_usbmidi_lib snd_seq_midi snd_seq_midi_event snd_rawmidi btmrvl_sdio btmrvl snd_seq snd_timer snd_seq_device snd bluetooth soundcore > [24711.280663] [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x50/0x68) > [24711.290124] [] (warn_slowpath_common+0x50/0x68) from [] (warn_slowpath_null+0x1c/0x24) > [24711.299845] [] (warn_slowpath_null+0x1c/0x24) from [] (__alloc_pages_nodemask+0x1d4/0x68c) > [24711.309914] [] (__alloc_pages_nodemask+0x1d4/0x68c) from [] (__get_free_pages+0x10/0x3c) > [24711.319805] [] (__get_free_pages+0x10/0x3c) from [] (kmalloc_order_trace+0x24/0xdc) > [24711.329269] [] (kmalloc_order_trace+0x24/0xdc) from [] (pskb_expand_head+0x68/0x298) > [24711.338901] [] (pskb_expand_head+0x68/0x298) from [] (ip6_forward+0x4d4/0x7bc [ipv6]) > [24711.348638] [] (ip6_forward+0x4d4/0x7bc [ipv6]) from [] (ipv6_rcv+0x2bc/0x3dc [ipv6]) > [24711.358333] [] (ipv6_rcv+0x2bc/0x3dc [ipv6]) from [] (__netif_receive_skb+0x544/0x66c) > [24711.368106] [] (__netif_receive_skb+0x544/0x66c) from [] (br_nf_pre_routing_finish_ipv6+0x10c/0x160 [bridge]) > [24711.379899] [] (br_nf_pre_routing_finish_ipv6+0x10c/0x160 [bridge]) from [] (br_nf_pre_routing+0x59c/0x67c [bridge]) > [24711.392271] [] (br_nf_pre_routing+0x59c/0x67c [bridge]) from [] (nf_iterate+0x8c/0xb4) > [24711.401988] [] (nf_iterate+0x8c/0xb4) from [] (nf_hook_slow+0x5c/0x118) > [24711.410540] [] (nf_hook_slow+0x5c/0x118) from [] (br_handle_frame+0x1b8/0x290 [bridge]) > [24711.420367] [] (br_handle_frame+0x1b8/0x290 [bridge]) from [] (__netif_receive_skb+0x3cc/0x66c) > [24711.430872] [] (__netif_receive_skb+0x3cc/0x66c) from [] (mv643xx_eth_poll+0x540/0x734) > [24711.440680] [] (mv643xx_eth_poll+0x540/0x734) from [] (net_rx_action+0x118/0x314) > [24711.449970] [] (net_rx_action+0x118/0x314) from [] (__do_softirq+0xac/0x234) > [24711.458817] [] (__do_softirq+0xac/0x234) from [] (irq_exit+0x94/0x9c) > [24711.467046] [] (irq_exit+0x94/0x9c) from [] (handle_IRQ+0x34/0x84) > [24711.475007] [] (handle_IRQ+0x34/0x84) from [] (__irq_svc+0x34/0x98) > [24711.483068] [] (__irq_svc+0x34/0x98) from [] (kirkwood_enter_idle+0x4c/0x94) > [24711.491908] [] (kirkwood_enter_idle+0x4c/0x94) from [] (cpuidle_idle_call+0xc8/0x35c) > [24711.501532] [] (cpuidle_idle_call+0xc8/0x35c) from [] (cpu_idle+0x88/0xdc) > [24711.510201] [] (cpu_idle+0x88/0xdc) from [] (start_kernel+0x2a0/0x2f0) > [24711.518512] ---[ end trace e1776fbe32468909 ]--- Francois is right that a GFP_ATOMIC allocation from pskb_expand_head() is failing, which can easily happen, and cause your "failed to reallocate TX buffer" errors; but it's well worth looking up what's actually on lines 2108 and 2109 of mm/page_alloc.c in 3.2.27: if (order >= MAX_ORDER) { WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); That was probably not a sane allocation request, it has gone out of range: maybe the skb header is even corrupted. If you're lucky, it might be something that netdev will recognize as already fixed. Hugh -- 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/