Bug#611622: linux-image-2.6.32-bpo.5-686: VM problems
Ben Hutchings wrote:
> On Mon, 2011-01-31 at 11:16 +0000, Anton Ivanov wrote:
>
>> Package: linux-2.6
>> Version: 2.6.32-30~bpo50+1
>> Severity: normal
>>
>>
>> I keep getting VM failure messages. I suspect the machine
>> is simply a bit too slow for the network card which is in
>> it. It is a via Nehemia at 1.7GHz with an extra Intel
>> GigE server adapter. The backtraces look like showing
>> problems in the network receive/xmit routines.
>>
>
> This is an allocation failure for a *huge* allocation (order 5 = 128 KB
> chunk) in atomic (non-sleeping) context. I think this may be related to
> (1) use of GRO on the receive path to coalesce packets (2) a
> netfilter/iptables rule that requires the packet to be duplicated, or
> requires the contents to be made contiguous.
>
1. Do you mean gso? I do not see gro as an option on ethtool.
2. I think I know the culprit. I have recently made the machine to
double up as a X-term. Some pixmap updates can easily pass around chunks
that size. I have a couple of other systems with similar hardware so I
will see if I can reproduce it with them.
3. While the machine has a few netfilter rules they are all on another
interface (towards a wifi AP) and it does not do any NAT so no need to
reconstruct packets.
>
>> The machine is swapless and is used mostly as an NFS
>> server. It was not showing this behaviour under 2.6.26
>>
> [...]
>
> Probably because e1000 did not use LRO or GRO there. You can test this
> by turning off GRO with 'ethtool -K eth0 gro off'.
>
> However I would also recommend configuring the machine with some swap
> space. The kernel has trouble defragmenting memory without swapping.
>
It is my always-on server with everything raid-ed. If I configure swap
the reliability is out of the window. I did that mistake once a while
back (7 years or so) and it ended up with some serious damage. The only
to get swap for it is hardware RAID.
> Ben.
>
>
--
Understanding is a three-edged sword:
your side, their side, and the truth. --Kosh Naranek
A. R. Ivanov
E-mail: aivanov@sigsegv.cx
WWW: http://www.sigsegv.cx/
pub 1024D/DDE5E715 2002-03-03 Anton R. Ivanov <ai1-n@sigsegv.cx>
Fingerprint: C824 CBD7 EE4B D7F8 5331 89D5 FCDA 572E DDE5 E715
Reply to: