Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch

Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch

[Chuck Ebbert]

Nicj Piggin wrote:

> Does it cause any noticable problems? If not, then stay with
> 2.6.9.
>
> However, it would be nice to get to the bottom of it. It might
> just be happening by chance on 2.6.9 but not 2.6.8.1 though...

  Isn't this the problem fixed by the below patch?  (Sorry I didn't
get sender name when I collected it.)  Some were skeptical this
would fix it but it has worked for those who tried...

  Oh and BTW what is rollup.patch?


# The following patch makes it allocate skb_headlen(skb) - len instead
# of skb->len - len.  When skb is linear there is no difference.  When
# it's non-linear we only ever copy the bytes in the header.
#
===== net/ipv4/tcp_output.c 1.67 vs edited =====
--- 1.67/net/ipv4/tcp_output.c  2004-10-01 13:56:45 +10:00
+++ edited/net/ipv4/tcp_output.c        2004-10-17 18:58:47 +10:00
@@ -455,8 +455,12 @@
 {
        struct tcp_opt *tp = tcp_sk(sk);
        struct sk_buff *buff;
-       int nsize = skb->len - len;
+       int nsize;
        u16 flags;
+
+       nsize = skb_headlen(skb) - len;
+       if (nsize < 0)
+               nsize = 0;
 
        if (skb_cloned(skb) &&
            skb_is_nonlinear(skb) &&

--Chuck Ebbert  25-Oct-04  14:54:36

Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch

[Justin Piszcz]

No, the below patch did not fix the problem.

I am waiting for the error to re-occur then I will sysrq+M and dmesg & 
send the info to the mailing list.

Rollup patch was from Nick Piggin, he stated:

Date: Sat, 23 Oct 2004 19:14:46 +1000
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Page Allocation Failures Return With 2.6.9+TSO patch.
Parts/Attachments:
    1 Shown     32 lines  Text
    2 Shown    356 lines  Text
----------------------------------------

Justin Piszcz wrote:
> Kernel 2.6.9 w/TSO patch.
>
> (most likely do to the e1000/nic/issue)
>
> $ dmesg
> gaim: page allocation failure. order:4, mode:0x21
>  [<c01391a7>] __alloc_pages+0x247/0x3b0
>  [<c0139328>] __get_free_pages+0x18/0x40
>  [<c035c33a>] sound_alloc_dmap+0xaa/0x1b0
>  [<c03648c0>] ad_mute+0x20/0x40
>  [<c035c70f>] open_dmap+0x1f/0x100
>  [<c035cb58>] DMAbuf_open+0x178/0x1d0
>  [<c035a4fa>] audio_open+0xba/0x280
>  [<c015d863>] cdev_get+0x53/0xc0
>  [<c035968c>] sound_open+0xac/0x110
>  [<c035898e>] soundcore_open+0x1ce/0x300
>  [<c03587c0>] soundcore_open+0x0/0x300
>  [<c015d524>] chrdev_open+0x104/0x250
>  [<c015d420>] chrdev_open+0x0/0x250
>  [<c0152d82>] dentry_open+0x1d2/0x270
>  [<c0152b9c>] filp_open+0x5c/0x70
>  [<c01049c8>] common_interrupt+0x18/0x20
>  [<c0152e75>] get_unused_fd+0x55/0xf0
>  [<c0152fd9>] sys_open+0x49/0x90
>  [<c010405b>] syscall_call+0x7/0xb

Ouch, 64K atomic DMA allocation.

The DMA zone barely even keeps that much total memory free.

The caller probably wants fixing, but you could try this patch...

     [ Part 2: "Attached Text" ]


Pine -> 2    356 lines   Text/X-PATCH (Name: "rollup.patch")

That was rollup.patch (patched 3 source files) - but this as well as the 
TSO has not seemed to have fixed the problem.

On Mon, 25 Oct 2004, Chuck Ebbert wrote:

> Nicj Piggin wrote:
>
>> Does it cause any noticable problems? If not, then stay with
>> 2.6.9.
>>
>> However, it would be nice to get to the bottom of it. It might
>> just be happening by chance on 2.6.9 but not 2.6.8.1 though...
>
>  Isn't this the problem fixed by the below patch?  (Sorry I didn't
> get sender name when I collected it.)  Some were skeptical this
> would fix it but it has worked for those who tried...
>
>  Oh and BTW what is rollup.patch?
>
>
> # The following patch makes it allocate skb_headlen(skb) - len instead
> # of skb->len - len.  When skb is linear there is no difference.  When
> # it's non-linear we only ever copy the bytes in the header.
> #
> ===== net/ipv4/tcp_output.c 1.67 vs edited =====
> --- 1.67/net/ipv4/tcp_output.c  2004-10-01 13:56:45 +10:00
> +++ edited/net/ipv4/tcp_output.c        2004-10-17 18:58:47 +10:00
> @@ -455,8 +455,12 @@
> {
>        struct tcp_opt *tp = tcp_sk(sk);
>        struct sk_buff *buff;
> -       int nsize = skb->len - len;
> +       int nsize;
>        u16 flags;
> +
> +       nsize = skb_headlen(skb) - len;
> +       if (nsize < 0)
> +               nsize = 0;
>
>        if (skb_cloned(skb) &&
>            skb_is_nonlinear(skb) &&
>
> --Chuck Ebbert  25-Oct-04  14:54:36
>

Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch

[Justin Piszcz]

It does not cause any noticable problems that I know of, I guess it is 
just a bit disturbing.

> Anyway, how often are you getting the messages? 
It depends what I am doing, sometimes they happen after 20-30 minutes, 
othertimes it takes a day or two.

> How many ethernet cards in the system?

There are 4 ethernet cards in the system.
1) 3c905b (on-board)
2) 3c905b (PCI)
3) 3c900 Combo (PCI)
4) Intel 82541GI/PI (PCI)

> Can you run a kernel with sysrq support, and do `SysRq+M`
> (close to when the allocation failure happens if possible, but
> otherwise on a normally running system after it has been up
> for a while). Then send in the dmesg.
Ok, I will try this.

On Mon, 25 Oct 2004, Nick Piggin wrote:

> Justin Piszcz wrote:
>> I guess people who get this should just stick with 2.6.8.1?
>> 
>
> Does it cause any noticable problems? If not, then stay with
> 2.6.9.
>
> However, it would be nice to get to the bottom of it. It might
> just be happening by chance on 2.6.9 but not 2.6.8.1 though...
>
> Anyway, how often are you getting the messages? How many
> ethernet cards in the system?
>
> Can you run a kernel with sysrq support, and do `SysRq+M`
> (close to when the allocation failure happens if possible, but
> otherwise on a normally running system after it has been up
> for a while). Then send in the dmesg.
>
> Thanks,
> Nick
>

Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch

[Nick Piggin]

Justin Piszcz wrote:
> I guess people who get this should just stick with 2.6.8.1?
> 

Does it cause any noticable problems? If not, then stay with
2.6.9.

However, it would be nice to get to the bottom of it. It might
just be happening by chance on 2.6.9 but not 2.6.8.1 though...

Anyway, how often are you getting the messages? How many
ethernet cards in the system?

Can you run a kernel with sysrq support, and do `SysRq+M`
(close to when the allocation failure happens if possible, but
otherwise on a normally running system after it has been up
for a while). Then send in the dmesg.

Thanks,
Nick

Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch

[Justin Piszcz]

I guess people who get this should just stick with 2.6.8.1?

$ dmesg
nfsd: page allocation failure. order:0, mode:0x20
  [<c013923c>] __alloc_pages+0x21c/0x350
  [<c0139388>] __get_free_pages+0x18/0x40
  [<c013c9ef>] kmem_getpages+0x1f/0xc0
  [<c013d730>] cache_grow+0xc0/0x1a0
  [<c013d9db>] cache_alloc_refill+0x1cb/0x210
  [<c013de41>] __kmalloc+0x71/0x80
  [<c036f583>] alloc_skb+0x53/0x100
  [<c031fb18>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031f81e>] e1000_clean_rx_irq+0x18e/0x440
  [<c0106a2f>] handle_IRQ_event+0x6f/0x80
  [<c031f3fb>] e1000_clean+0x5b/0x100
  [<c0375c0a>] net_rx_action+0x6a/0xf0
  [<c011daa1>] __do_softirq+0x41/0x90
  [<c011db17>] do_softirq+0x27/0x30
  [<c0106ebc>] do_IRQ+0x10c/0x130
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c013007b>] simplify_symbols+0x5b/0x110
  [<c014019a>] shrink_list+0x30a/0x4b0
  [<c01404a3>] shrink_cache+0x163/0x380
  [<c0140c42>] shrink_zone+0xa2/0xd0
  [<c0140cc3>] shrink_caches+0x53/0x70
  [<c0140d8f>] try_to_free_pages+0xaf/0x1b0
  [<c0139287>] __alloc_pages+0x267/0x350
  [<c0136763>] generic_file_buffered_write+0x123/0x660
  [<c013918b>] __alloc_pages+0x16b/0x350
  [<c013d557>] alloc_slabmgmt+0x57/0x70
  [<c027c156>] xfs_trans_unlocked_item+0x56/0x60
  [<c02929cf>] xfs_write+0x78f/0xc00
  [<c028de01>] linvfs_writev+0x101/0x140
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c02a5e52>] copy_from_user+0x42/0x70
  [<c01542fa>] do_readv_writev+0x28a/0x2b0
  [<c028dfe0>] linvfs_open+0x0/0x90
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c0153bc0>] do_sync_write+0x0/0x110
  [<c028e03a>] linvfs_open+0x5a/0x90
  [<c0152da2>] dentry_open+0xd2/0x270
  [<c01543d8>] vfs_writev+0x58/0x60
  [<c01caf26>] nfsd_write+0xf6/0x390
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c01d33bb>] nfsd3_proc_write+0xbb/0x120
  [<c01c66c3>] nfsd_dispatch+0xa3/0x250
  [<c041f4e1>] svc_process+0x6e1/0x7f0
  [<c01c6463>] nfsd+0x203/0x3c0
  [<c01c6260>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18

I am not sure what else to do except stay with 2.6.8.1 as it did not have 
these problems.