netdev - Re: [NET][TG3] Fwd: page allocation failure with linux 3.1.1

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]

Date:	Mon, 28 Nov 2011 09:16:26 +0200
From:	Пламен Петров 
	<plamen.sisi@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [NET][TG3] Fwd: page allocation failure with linux 3.1.1

2011/11/28 Eric Dumazet <eric.dumazet@...il.com>:
> Le dimanche 27 novembre 2011 à 22:34 +0200, Пламен Петров a écrit :
>> Hello, David, Jarek and Eric!
>>
>> In September 2010 I had trouble with the Broadcom Tygon 3 network driver:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=64289c8e6851bca0e589e064c9a5c9fbd6ae5dd4
>>
>> Please, see below my most recent findings, where again tg3 is present.
>>
>> I sent this earlier today to linux-kernel list. Sorry if this is not
>> related to the above, thus to the tg3 kernel driver.
>>
>> ---------- Forwarded message ----------
>> From: Пламен Петров <plamen.sisi@...il.com>
>> Date: 2011/11/27
>> Subject: page allocation failure with linux 3.1.1
>> To: linux-kernel@...r.kernel.org
>>
>>
>> Hello, folks!
>>
>> Please, cc me, as I'm not subsribed to the list.
>>
>> With Linux 3.1.1 I'm hitting a page allocation failure on a machine
>> with 512 MB RAM and 2 GB swap, which looks like this:
>>
>> [388632.749423] swapper: page allocation failure: order:4, mode:0x4020
>> [388632.749431] Pid: 0, comm: swapper Not tainted 3.1.1-FS #1
>> [388632.749434] Call Trace:
>> [388632.749447]  [<c106cd03>] ? warn_alloc_failed+0xab/0xd5
>> [388632.749454]  [<c106f5f5>] ? __alloc_pages_nodemask+0x4ea/0x6aa
>> [388632.749460]  [<c106f822>] ? __get_free_pages+0x14/0x32
>> [388632.749467]  [<c12aecc7>] ? __alloc_skb+0x4c/0xe9
>> [388632.749472]  [<c12b02cc>] ? skb_copy+0x2e/0x7a
>> [388632.749478]  [<c122de36>] ? tg3_start_xmit+0x82f/0xa37
>> [388632.749484]  [<c12b778b>] ? dev_hard_start_xmit+0x27e/0x4f8
>> [388632.749495]  [<c130e851>] ? ip_fragment+0x7dd/0x7dd
>> [388632.749500]  [<c12e8b88>] ? nf_iterate+0x66/0x87
...
>
> You hit a known tg3 hardware bug, and the workaround needs to copy skb
> to a new one.
>
> Since TCP layer can build big skbs if TSO is on, and you can hit an
> allocation error because your memory gets fragmented after a while, a
> way to avoid this is to switch off TSO :
>
> ethtool -K eth0 tso off
> ip route flush cache
>
>

Well, Eric, thanks for the explanation! I will disable TSO and will
see how is that working out for me - if I recall correctly, I had no
problems when TSO was off.

Sorry to bother you, if the above explanation was somewhere readily
available, but I didn't manage to find it.

Thanks,
Plamen
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html