lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6101e8c40806070550h62866816s1d8f8c1ba31f59f@mail.gmail.com>
Date:	Sat, 7 Jun 2008 14:50:06 +0200
From:	"Oliver Pinter" <oliver.pntr@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>, zsirmo@...rmo.hu,
	LKML <linux-kernel@...r.kernel.org>,
	"Ingo Molnar" <mingo@...e.hu>, netdev <netdev@...r.kernel.org>,
	"Matt Carlson" <mcarlson@...adcom.com>,
	"Michael Chan" <mchan@...adcom.com>,
	"Brian Vowell" <brian.vowell@...il.com>
Subject: Re: bug report

[snip]
Jun  6 14:04:11 www kernel: [ 6464.556309] clamscan: page allocation
failure. order:3, mode:0x4020 <------------- this
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
[snip]

...

[snip]
Jun  6 14:04:11 www kernel: [ 6464.558231] Pid: 24139, comm: clamscan
Not tainted 2.6.25.4 #1
Jun  6 14:04:11 www kernel: [ 6464.558234]
Jun  6 14:04:11 www kernel: [ 6464.558235] Call Trace:
Jun  6 14:04:11 www kernel: [ 6464.558239]  <IRQ>
[__alloc_pages+544/890] __alloc_pages+0x220/0x37a
Jun  6 14:04:11 www kernel: [ 6464.558257]  [tcp_v4_do_rcv+186/504]
tcp_v4_do_rcv+0xba/0x1f8
Jun  6 14:04:11 www kernel: [ 6464.558263]
[apic_timer_interrupt+102/112] apic_timer_interrupt+0x6
[snip]

On 6/7/08, Ilpo Järvinen <ilpo.jarvinen@...sinki.fi> wrote:
> ...Added Brian Vowell.
>
> On Fri, 6 Jun 2008, Andrew Morton wrote:
>
>> On Sat, 7 Jun 2008 03:44:32 +0200 "Oliver Pinter" <oliver.pntr@...il.com>
>> wrote:
>>
>> > Add Ingon and netdev to CC
>> >
>> >
>> > On 6/6/08, Zsiros Attila <zsirmo@...il.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.
>
> Same allocation failed problem (among an TCP issue that is nowadays
> fixed) was also reported by Brian Vowell:
>   http://bugzilla.kernel.org/show_bug.cgi?id=10767
>
>
> --
>  i.
>


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ