From: Andrew Morton <akpm@linux-foundation.org>
To: "Oliver Pinter" <oliver.pntr@gmail.com>
Cc: zsirmo@zsirmo.hu, linux-kernel@vger.kernel.org,
"Ingo Molnar" <mingo@elte.hu>, netdev <netdev@vger.kernel.org>,
Matt Carlson <mcarlson@broadcom.com>,
Michael Chan <mchan@broadcom.com>
Subject: Re: bug report
Date: Fri, 6 Jun 2008 22:56:43 -0700 [thread overview]
Message-ID: <20080606225643.8be222a9.akpm@linux-foundation.org> (raw)
In-Reply-To: <6101e8c40806061844g5b7676d4xb48c5c69ad48391f@mail.gmail.com>
On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr@gmail.com> wrote:
> Add Ingon and netdev to CC
>
>
> On 6/6/08, Zsiros Attila <zsirmo@gmail.com> wrote:
> > Hy!
> >
> > I have a problem.
> >
> > http://www.cyberszeg.hu/log/kern.log
> > http://www.cyberszeg.hu/log/config-2.6.25.4
> > http://www.cyberszeg.hu/log/lspci.txt
> > http://www.cyberszeg.hu/log/ifconfig.txt
> >
: Jun 6 14:03:07 www kernel: [ 5897.660390] NETDEV WATCHDOG: eth0: transmit timed out
: Jun 6 14:03:07 www kernel: [ 5897.660398] tg3: eth0: transmit timed out, resetting
: Jun 6 14:03:07 www kernel: [ 5897.660432] tg3: DEBUG: MAC_TX_STATUS[0000001e] MAC_RX_STATUS[0000000e]
: Jun 6 14:03:07 www kernel: [ 5897.660454] tg3: DEBUG: RDMAC_STATUS[00000000] WDMAC_STATUS[00000000]
: Jun 6 14:03:07 www kernel: [ 5897.762983] tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2
: Jun 6 14:03:07 www kernel: [ 5897.864168] tg3: tg3_stop_block timed out, ofs=c00 enable_bit=2
: Jun 6 14:03:07 www kernel: [ 5897.965619] tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2
That looks like a driver failure.
: Jun 6 14:03:07 www kernel: [ 5898.096689] tg3: eth0: Link is down.
: Jun 6 14:03:11 www kernel: [ 5901.633931] tg3: eth0: Link is up at 1000 Mbps, full duplex.
: Jun 6 14:03:11 www kernel: [ 5901.633937] tg3: eth0: Flow control is on for TX and on for RX.
: Jun 6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation failure. order:3, mode:0x4020
: Jun 6 14:04:11 www kernel: [ 6464.556319] Pid: 24139, comm: clamscan Not tainted 2.6.25.4 #1
: Jun 6 14:04:11 www kernel: [ 6464.556325]
: Jun 6 14:04:11 www kernel: [ 6464.556326] Call Trace:
: Jun 6 14:04:11 www kernel: [ 6464.556329] <IRQ> [__alloc_pages+544/890] __alloc_pages+0x220/0x37a
: Jun 6 14:04:11 www kernel: [ 6464.556353] [tcp_v4_do_rcv+186/504] tcp_v4_do_rcv+0xba/0x1f8
: Jun 6 14:04:11 www kernel: [ 6464.556359] [ktime_get+12/98] ktime_get+0xc/0x62
: Jun 6 14:04:11 www kernel: [ 6464.556364] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556370] [__slab_alloc+330/1403] __slab_alloc+0x14a/0x57b
: Jun 6 14:04:11 www kernel: [ 6464.556374] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556379] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556384] [__kmalloc_track_caller+185/190] __kmalloc_track_caller+0xb9/0xbe
: Jun 6 14:04:11 www kernel: [ 6464.556391] [__alloc_skb+86/305] __alloc_skb+0x56/0x131
: Jun 6 14:04:11 www kernel: [ 6464.556395] [__netdev_alloc_skb+23/49] __netdev_alloc_skb+0x17/0x31
: Jun 6 14:04:11 www kernel: [ 6464.556408] [_end+128472975/2130444940] :tg3:tg3_alloc_rx_skb+0x8f/0x17e
: Jun 6 14:04:11 www kernel: [ 6464.556418] [_end+128493403/2130444940] :tg3:tg3_poll+0x6e8/0x922
: Jun 6 14:04:11 www kernel: [ 6464.556426] [net_rx_action+134/309] net_rx_action+0x86/0x135
: Jun 6 14:04:11 www kernel: [ 6464.556433] [__do_softirq+102/212] __do_softirq+0x66/0xd4
: Jun 6 14:04:11 www kernel: [ 6464.556439] [call_softirq+28/48] call_softirq+0x1c/0x30
: Jun 6 14:04:11 www kernel: [ 6464.556444] [do_softirq+48/107] do_softirq+0x30/0x6b
: Jun 6 14:04:11 www kernel: [ 6464.556448] [do_IRQ+114/212] do_IRQ+0x72/0xd4
: Jun 6 14:04:11 www kernel: [ 6464.556453] [ret_from_intr+0/10] ret_from_intr+0x0/0xa
The driver is trying to do a 32 kbyte GFP_ATOMIC memory allocation.
rofl, good luck with that.
But the netwoking code sould survive this.
<12 billion more page allocation failures>
Are you using jumbo frames or have you manually set the MTU to
something enormous? Because 32k is a pretty crazy amount of memory for
the driver to be trying to allocate - it's going to fail all over the
place, as you have discovered.
next prev parent reply other threads:[~2008-06-07 5:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48499731.1080807@gmail.com>
2008-06-07 1:44 ` bug report Oliver Pinter
2008-06-07 1:45 ` Oliver Pinter
2008-06-07 5:56 ` Andrew Morton [this message]
2008-06-07 8:47 ` Ilpo Järvinen
2008-06-07 12:50 ` Oliver Pinter
2008-06-07 15:09 ` Phil Oester
2008-06-07 18:53 ` Oliver Pinter
2008-06-08 11:56 ` Zsiros Attila
2008-06-09 17:04 ` Oliver Pinter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080606225643.8be222a9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcarlson@broadcom.com \
--cc=mchan@broadcom.com \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=oliver.pntr@gmail.com \
--cc=zsirmo@zsirmo.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).