linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch
@ 2004-10-25 10:48 Justin Piszcz
  2004-10-25 11:33 ` Nick Piggin
  0 siblings, 1 reply; 11+ messages in thread
From: Justin Piszcz @ 2004-10-25 10:48 UTC (permalink / raw)
  To: linux-kernel; +Cc: akpm

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch
  2004-10-25 10:48 Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch Justin Piszcz
@ 2004-10-25 11:33 ` Nick Piggin
  2004-10-25 12:03   ` Justin Piszcz
  2004-10-27 21:40   ` Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Justin Piszcz
  0 siblings, 2 replies; 11+ messages in thread
From: Nick Piggin @ 2004-10-25 11:33 UTC (permalink / raw)
  To: Justin Piszcz; +Cc: linux-kernel, akpm

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch
  2004-10-25 11:33 ` Nick Piggin
@ 2004-10-25 12:03   ` Justin Piszcz
  2004-10-27 21:40   ` Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Justin Piszcz
  1 sibling, 0 replies; 11+ messages in thread
From: Justin Piszcz @ 2004-10-25 12:03 UTC (permalink / raw)
  To: Nick Piggin; +Cc: linux-kernel, akpm

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
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch
@ 2004-10-25 18:53 Chuck Ebbert
  2004-10-25 19:03 ` Justin Piszcz
  0 siblings, 1 reply; 11+ messages in thread
From: Chuck Ebbert @ 2004-10-25 18:53 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Justin Piszcz, linux-kernel

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch
  2004-10-25 18:53 Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch Chuck Ebbert
@ 2004-10-25 19:03 ` Justin Piszcz
  0 siblings, 0 replies; 11+ messages in thread
From: Justin Piszcz @ 2004-10-25 19:03 UTC (permalink / raw)
  To: Chuck Ebbert; +Cc: Nick Piggin, linux-kernel

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
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)
  2004-10-25 11:33 ` Nick Piggin
  2004-10-25 12:03   ` Justin Piszcz
@ 2004-10-27 21:40   ` Justin Piszcz
  2004-10-27 21:58     ` Andrew Morton
  2004-10-28  0:33     ` Lee Revell
  1 sibling, 2 replies; 11+ messages in thread
From: Justin Piszcz @ 2004-10-27 21:40 UTC (permalink / raw)
  To: Nick Piggin; +Cc: linux-kernel, akpm

After a couple days the errors have shown up again.

Can anyone help me debug this problem further?

Is there any chance Linus will freeze 2.6 and make the current development 
tree 2.7?  It seems like ever since around 2.6.8 things have been getting 
progressively worse (page allocation failures/nvidia 
breakage/XFS-oops-when-copying-over-nfs-when-the-file-is-being-written-to)?


$ uptime
  17:34:32 up 2 days,  8:53, 29 users,  load average: 0.29, 0.38, 0.36

jpiszcz@p500:/usr/src/linux$ grep -i sysrq .config
CONFIG_MAGIC_SYSRQ=y

I tried various combinations of sysrq+M but it did not seem to do anything 
special?

Also, all of the failures below, could they possibly be causing data 
corruption?

Once again, box = Dell GX1 p3 500mhz / 768MB ram (Intel 440BX/ZX/DX) 
chipset.

$ lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge 
(rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge 
(rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0d.0 Unknown mass storage controller: Promise Technology, Inc. 20269 
(rev 02)
00:0e.0 Unknown mass storage controller: Promise Technology, Inc. 20267 
(rev 02)
00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] 
(rev 24)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 
1X/2X (rev 5c)
02:09.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet 
Controller
02:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] 
(rev 30)
02:0b.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang]

$ cat /proc/interrupts
            CPU0
   0:  204979514          XT-PIC  timer
   1:       2484          XT-PIC  i8042
   2:          0          XT-PIC  cascade
   5:          0          XT-PIC  Crystal audio controller
   8:          1          XT-PIC  rtc
   9:          0          XT-PIC  acpi
  10:    3866403          XT-PIC  ide2, ide3
  11:  129079320          XT-PIC  ide4, ide5, eth0, eth1, eth2, eth3
  12:      16198          XT-PIC  i8042
  15:         50          XT-PIC  ide1
NMI:          0
LOC:          0
ERR:       1022
MIS:          0

$ cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
0184-0187 : MPU-401 UART
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vga+
03f8-03ff : serial
0530-0533 : Crystal audio controller
0800-083f : 0000:00:07.3
   0800-0803 : PM1a_EVT_BLK
   0804-0805 : PM1a_CNT_BLK
   0808-080b : PM_TMR
   080c-080f : GPE0_BLK
0840-085f : 0000:00:07.3
   0850-0857 : piix4-smbus
0cf8-0cff : PCI conf1
c880-c8ff : 0000:00:11.0
   c880-c8ff : 0000:00:11.0
cc40-cc7f : 0000:00:0e.0
   cc40-cc47 : ide4
   cc48-cc4f : ide5
   cc50-cc7f : PDC20267
cca0-ccaf : 0000:00:0d.0
   cca0-cca7 : ide2
   cca8-ccaf : ide3
ccb0-ccb7 : 0000:00:0e.0
   ccb0-ccb7 : ide5
ccb8-ccbb : 0000:00:0d.0
   ccba-ccba : ide3
ccbc-ccbf : 0000:00:0e.0
   ccbe-ccbe : ide5
ccc0-ccc7 : 0000:00:0d.0
   ccc0-ccc7 : ide3
ccc8-cccf : 0000:00:0e.0
   ccc8-cccf : ide4
ccd0-ccd3 : 0000:00:0d.0
   ccd2-ccd2 : ide2
ccd4-ccd7 : 0000:00:0e.0
   ccd6-ccd6 : ide4
ccd8-ccdf : 0000:00:0d.0
   ccd8-ccdf : ide2
cce0-ccff : 0000:00:07.2
d000-dfff : PCI Bus #02
   dc00-dc7f : 0000:02:0a.0
     dc00-dc7f : 0000:02:0a.0
   dc80-dcbf : 0000:02:0b.0
     dc80-dcbf : 0000:02:0b.0
   dcc0-dcff : 0000:02:09.0
     dcc0-dcff : e1000
e000-efff : PCI Bus #01
   ec00-ecff : 0000:01:00.0
ffa0-ffaf : 0000:00:07.1
   ffa8-ffaf : ide1

  [<c01ca635>] nfsd_open+0x45/0x190
  [<c01cae1e>] nfsd_write+0x4e/0x390
  [<c0375f7a>] net_rx_action+0x6a/0xf0
  [<c036f9e2>] skb_drop_fraglist+0x42/0x50
  [<c036faa6>] skb_release_data+0x96/0xc0
  [<c01d335b>] nfsd3_proc_write+0xbb/0x120
  [<c01c6663>] nfsd_dispatch+0xa3/0x250
  [<c041f841>] svc_process+0x6e1/0x7f0
  [<c01c6403>] nfsd+0x203/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
swapper: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c02d9471>] add_interrupt_randomness+0x31/0x40
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c0101df0>] default_idle+0x0/0x40
  [<c0101e13>] default_idle+0x23/0x40
  [<c0101e9f>] cpu_idle+0x2f/0x50
  [<c04f2967>] start_kernel+0x157/0x180
  [<c04f2540>] unknown_bootoption+0x0/0x180
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c038abd0>] ip_rcv_finish+0x0/0x2d0
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c038abd0>] ip_rcv_finish+0x0/0x2d0
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c032c184>] boomerang_rx+0x254/0x490
  [<c032b869>] boomerang_interrupt+0xb9/0x430
  [<c0339798>] ide_intr+0x188/0x1e0
  [<c01069fd>] handle_IRQ_event+0x3d/0x80
  [<c0106e3f>] do_IRQ+0x8f/0x130
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c013de66>] __kmalloc+0x56/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
eth2: memory shortage
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c032c184>] boomerang_rx+0x254/0x490
  [<c032b869>] boomerang_interrupt+0xb9/0x430
  [<c0339798>] ide_intr+0x188/0x1e0
  [<c01069fd>] handle_IRQ_event+0x3d/0x80
  [<c0106e3f>] do_IRQ+0x8f/0x130
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c013de66>] __kmalloc+0x56/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c032c184>] boomerang_rx+0x254/0x490
  [<c032b869>] boomerang_interrupt+0xb9/0x430
  [<c0339798>] ide_intr+0x188/0x1e0
  [<c01069fd>] handle_IRQ_event+0x3d/0x80
  [<c0106e3f>] do_IRQ+0x8f/0x130
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c013de66>] __kmalloc+0x56/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
nfsd: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c011007b>] setup_pit_timer+0x2b/0x60
  [<c0124d23>] sigprocmask+0x3/0xe0
  [<c01c63f3>] nfsd+0x1f3/0x3c0
  [<c01c6200>] nfsd+0x0/0x3c0
  [<c010207d>] kernel_thread_helper+0x5/0x18
lftp: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
kswapd0: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c038abd0>] ip_rcv_finish+0x0/0x2d0
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c030941a>] __make_request+0x4ea/0x560
  [<c0309563>] generic_make_request+0xd3/0x190
  [<c0137b85>] mempool_alloc+0x85/0x190
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c0309671>] submit_bio+0x51/0xf0
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c015915b>] bio_alloc+0x17b/0x1f0
  [<c0155ab0>] end_buffer_async_write+0x0/0x110
  [<c0158925>] submit_bh+0xe5/0x140
  [<c0289fa5>] xfs_submit_page+0xb5/0x100
  [<c028a16a>] xfs_convert_page+0x17a/0x2b0
  [<c01345b7>] find_trylock_page+0x27/0x60
  [<c0289aef>] xfs_probe_delalloc_page+0x1f/0xa0
  [<c028a30f>] xfs_cluster_write+0x6f/0x90
  [<c028a633>] xfs_page_state_convert+0x303/0x6e0
  [<c028b0f4>] linvfs_writepage+0x74/0x130
  [<c013fe89>] pageout+0xb9/0x100
  [<c0134290>] wake_up_page+0x10/0x30
  [<c0140165>] shrink_list+0x295/0x4b0
  [<c01404e3>] shrink_cache+0x163/0x380
  [<c01150cd>] wake_up_process+0x1d/0x20
  [<c028d1f5>] pagebuf_daemon_wakeup+0x15/0x20
  [<c013fbc8>] shrink_slab+0x98/0x1a0
  [<c0140c82>] shrink_zone+0xa2/0xd0
  [<c01410c0>] balance_pgdat+0x1e0/0x2c0
  [<c014125f>] kswapd+0xbf/0xe0
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c0103f32>] ret_from_fork+0x6/0x14
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c01411a0>] kswapd+0x0/0xe0
  [<c010207d>] kernel_thread_helper+0x5/0x18
kswapd0: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c032c184>] boomerang_rx+0x254/0x490
  [<c032b869>] boomerang_interrupt+0xb9/0x430
  [<c0339798>] ide_intr+0x188/0x1e0
  [<c01069fd>] handle_IRQ_event+0x3d/0x80
  [<c0106e3f>] do_IRQ+0x8f/0x130
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c013de66>] __kmalloc+0x56/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c038abd0>] ip_rcv_finish+0x0/0x2d0
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c030941a>] __make_request+0x4ea/0x560
  [<c0309563>] generic_make_request+0xd3/0x190
  [<c0137b85>] mempool_alloc+0x85/0x190
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c0309671>] submit_bio+0x51/0xf0
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c015915b>] bio_alloc+0x17b/0x1f0
  [<c0155ab0>] end_buffer_async_write+0x0/0x110
  [<c0158925>] submit_bh+0xe5/0x140
  [<c0289fa5>] xfs_submit_page+0xb5/0x100
  [<c028a16a>] xfs_convert_page+0x17a/0x2b0
  [<c01345b7>] find_trylock_page+0x27/0x60
  [<c0289aef>] xfs_probe_delalloc_page+0x1f/0xa0
  [<c028a30f>] xfs_cluster_write+0x6f/0x90
  [<c028a633>] xfs_page_state_convert+0x303/0x6e0
  [<c028b0f4>] linvfs_writepage+0x74/0x130
  [<c013fe89>] pageout+0xb9/0x100
  [<c0134290>] wake_up_page+0x10/0x30
  [<c0140165>] shrink_list+0x295/0x4b0
  [<c01404e3>] shrink_cache+0x163/0x380
  [<c01150cd>] wake_up_process+0x1d/0x20
  [<c028d1f5>] pagebuf_daemon_wakeup+0x15/0x20
  [<c013fbc8>] shrink_slab+0x98/0x1a0
  [<c0140c82>] shrink_zone+0xa2/0xd0
  [<c01410c0>] balance_pgdat+0x1e0/0x2c0
  [<c014125f>] kswapd+0xbf/0xe0
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c0103f32>] ret_from_fork+0x6/0x14
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c01411a0>] kswapd+0x0/0xe0
  [<c010207d>] kernel_thread_helper+0x5/0x18
eth2: memory shortage
kswapd0: page allocation failure. order:0, mode:0x20
  [<c0139227>] __alloc_pages+0x247/0x3b0
  [<c01393a8>] __get_free_pages+0x18/0x40
  [<c013ca2f>] kmem_getpages+0x1f/0xc0
  [<c013d770>] cache_grow+0xc0/0x1a0
  [<c013da1b>] cache_alloc_refill+0x1cb/0x210
  [<c013de81>] __kmalloc+0x71/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c032c184>] boomerang_rx+0x254/0x490
  [<c032b869>] boomerang_interrupt+0xb9/0x430
  [<c0339798>] ide_intr+0x188/0x1e0
  [<c01069fd>] handle_IRQ_event+0x3d/0x80
  [<c0106e3f>] do_IRQ+0x8f/0x130
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c013de66>] __kmalloc+0x56/0x80
  [<c036f8f3>] alloc_skb+0x53/0x100
  [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
  [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
  [<c038abd0>] ip_rcv_finish+0x0/0x2d0
  [<c031f76b>] e1000_clean+0x5b/0x100
  [<c0375f7a>] 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
  [<c030941a>] __make_request+0x4ea/0x560
  [<c0309563>] generic_make_request+0xd3/0x190
  [<c0137b85>] mempool_alloc+0x85/0x190
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c0309671>] submit_bio+0x51/0xf0
  [<c01049c8>] common_interrupt+0x18/0x20
  [<c015915b>] bio_alloc+0x17b/0x1f0
  [<c0155ab0>] end_buffer_async_write+0x0/0x110
  [<c0158925>] submit_bh+0xe5/0x140
  [<c0289fa5>] xfs_submit_page+0xb5/0x100
  [<c028a16a>] xfs_convert_page+0x17a/0x2b0
  [<c01345b7>] find_trylock_page+0x27/0x60
  [<c0289aef>] xfs_probe_delalloc_page+0x1f/0xa0
  [<c028a30f>] xfs_cluster_write+0x6f/0x90
  [<c028a633>] xfs_page_state_convert+0x303/0x6e0
  [<c028b0f4>] linvfs_writepage+0x74/0x130
  [<c013fe89>] pageout+0xb9/0x100
  [<c0134290>] wake_up_page+0x10/0x30
  [<c0140165>] shrink_list+0x295/0x4b0
  [<c01404e3>] shrink_cache+0x163/0x380
  [<c01150cd>] wake_up_process+0x1d/0x20
  [<c028d1f5>] pagebuf_daemon_wakeup+0x15/0x20
  [<c013fbc8>] shrink_slab+0x98/0x1a0
  [<c0140c82>] shrink_zone+0xa2/0xd0
  [<c01410c0>] balance_pgdat+0x1e0/0x2c0
  [<c014125f>] kswapd+0xbf/0xe0
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c0103f32>] ret_from_fork+0x6/0x14
  [<c0116c60>] autoremove_wake_function+0x0/0x60
  [<c01411a0>] kswapd+0x0/0xe0
  [<c010207d>] kernel_thread_helper+0x5/0x18

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
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)
  2004-10-27 21:58     ` Andrew Morton
@ 2004-10-27 21:55       ` Justin Piszcz
  2004-10-27 22:19         ` Francois Romieu
  0 siblings, 1 reply; 11+ messages in thread
From: Justin Piszcz @ 2004-10-27 21:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: nickpiggin, linux-kernel

Ok, thanks, one last question,

I do not explicitly set ethtool* tso, however I use dhcpcd on this 
interface, does that set TSO on the interface? I have never used TSO (that 
I am aware of) and I am wondering if it is something else?

On Wed, 27 Oct 2004, Andrew Morton wrote:

> Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>>
>> swapper: page allocation failure. order:0, mode:0x20
>>   [<c0139227>] __alloc_pages+0x247/0x3b0
>>   [<c02d9471>] add_interrupt_randomness+0x31/0x40
>>   [<c01393a8>] __get_free_pages+0x18/0x40
>>   [<c013ca2f>] kmem_getpages+0x1f/0xc0
>>   [<c013d770>] cache_grow+0xc0/0x1a0
>>   [<c013da1b>] cache_alloc_refill+0x1cb/0x210
>>   [<c013de81>] __kmalloc+0x71/0x80
>>   [<c036f8f3>] alloc_skb+0x53/0x100
>>   [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
>>   [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
>>   [<c031f76b>] e1000_clean+0x5b/0x100
>>   [<c0375f7a>] net_rx_action+0x6a/0xf0
>>   [<c011daa1>] __do_softirq+0x41/0x90
>>   [<c011db17>] do_softirq+0x27/0x30
>>   [<c0106ebc>] do_IRQ+0x10c/0x130
>
> This should be harmless - networking will recover.  The TSO fix was
> merged a week or so ago.
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)
  2004-10-27 21:40   ` Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Justin Piszcz
@ 2004-10-27 21:58     ` Andrew Morton
  2004-10-27 21:55       ` Justin Piszcz
  2004-10-28  0:33     ` Lee Revell
  1 sibling, 1 reply; 11+ messages in thread
From: Andrew Morton @ 2004-10-27 21:58 UTC (permalink / raw)
  To: Justin Piszcz; +Cc: nickpiggin, linux-kernel

Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>
> swapper: page allocation failure. order:0, mode:0x20
>   [<c0139227>] __alloc_pages+0x247/0x3b0
>   [<c02d9471>] add_interrupt_randomness+0x31/0x40
>   [<c01393a8>] __get_free_pages+0x18/0x40
>   [<c013ca2f>] kmem_getpages+0x1f/0xc0
>   [<c013d770>] cache_grow+0xc0/0x1a0
>   [<c013da1b>] cache_alloc_refill+0x1cb/0x210
>   [<c013de81>] __kmalloc+0x71/0x80
>   [<c036f8f3>] alloc_skb+0x53/0x100
>   [<c031fe88>] e1000_alloc_rx_buffers+0x48/0xf0
>   [<c031fb8e>] e1000_clean_rx_irq+0x18e/0x440
>   [<c031f76b>] e1000_clean+0x5b/0x100
>   [<c0375f7a>] net_rx_action+0x6a/0xf0
>   [<c011daa1>] __do_softirq+0x41/0x90
>   [<c011db17>] do_softirq+0x27/0x30
>   [<c0106ebc>] do_IRQ+0x10c/0x130

This should be harmless - networking will recover.  The TSO fix was
merged a week or so ago.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)
  2004-10-27 21:55       ` Justin Piszcz
@ 2004-10-27 22:19         ` Francois Romieu
  2004-10-27 22:23           ` Justin Piszcz
  0 siblings, 1 reply; 11+ messages in thread
From: Francois Romieu @ 2004-10-27 22:19 UTC (permalink / raw)
  To: Justin Piszcz; +Cc: Andrew Morton, nickpiggin, linux-kernel

Justin Piszcz <jpiszcz@lucidpixels.com> :
[...]
> I do not explicitly set ethtool* tso, however I use dhcpcd on this 
> interface, does that set TSO on the interface? I have never used TSO (that 

Hint: ethtool -k ethX

--
Ueimor

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)
  2004-10-27 22:19         ` Francois Romieu
@ 2004-10-27 22:23           ` Justin Piszcz
  0 siblings, 0 replies; 11+ messages in thread
From: Justin Piszcz @ 2004-10-27 22:23 UTC (permalink / raw)
  To: Francois Romieu; +Cc: Andrew Morton, nickpiggin, linux-kernel

Ah, you are correct:

root@p500:~# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
root@p500:~# ethtool -k eth1
Offload parameters for eth1:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not supported
Cannot get device tcp segmentation offload settings: Operation not 
supported
no offload info available
root@p500:~# ethtool -k eth2
Offload parameters for eth2:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not supported
Cannot get device tcp segmentation offload settings: Operation not 
supported
no offload info available
root@p500:~# ethtool -k eth3
Offload parameters for eth3:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not supported
Cannot get device tcp segmentation offload settings: Operation not 
supported
no offload info available
root@p500:~#


On Thu, 28 Oct 2004, Francois Romieu wrote:

> Justin Piszcz <jpiszcz@lucidpixels.com> :
> [...]
>> I do not explicitly set ethtool* tso, however I use dhcpcd on this
>> interface, does that set TSO on the interface? I have never used TSO (that
>
> Hint: ethtool -k ethX
>
> --
> Ueimor
>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Kernel 2.6.9 Multiple Page Allocation Failures (Part 2)
  2004-10-27 21:40   ` Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Justin Piszcz
  2004-10-27 21:58     ` Andrew Morton
@ 2004-10-28  0:33     ` Lee Revell
  1 sibling, 0 replies; 11+ messages in thread
From: Lee Revell @ 2004-10-28  0:33 UTC (permalink / raw)
  To: Justin Piszcz; +Cc: Nick Piggin, linux-kernel, akpm

On Wed, 2004-10-27 at 17:40 -0400, Justin Piszcz wrote:
> Is there any chance Linus will freeze 2.6 and make the current development 
> tree 2.7?  It seems like ever since around 2.6.8 things have been getting 
> progressively worse (page allocation failures/nvidia 
> breakage/XFS-oops-when-copying-over-nfs-when-the-file-is-being-written-to)?

This not the kernel's problem when nvidia breaks.  The kernel developers
make NO EFFORT to support binary only modules!  Please, talk to nvidia
if this is a problem for you.

Lee


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2004-10-28  0:37 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-25 10:48 Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch Justin Piszcz
2004-10-25 11:33 ` Nick Piggin
2004-10-25 12:03   ` Justin Piszcz
2004-10-27 21:40   ` Kernel 2.6.9 Multiple Page Allocation Failures (Part 2) Justin Piszcz
2004-10-27 21:58     ` Andrew Morton
2004-10-27 21:55       ` Justin Piszcz
2004-10-27 22:19         ` Francois Romieu
2004-10-27 22:23           ` Justin Piszcz
2004-10-28  0:33     ` Lee Revell
  -- strict thread matches above, loose matches on Subject: below --
2004-10-25 18:53 Kernel 2.6.9 Page Allocation Failures w/TSO+rollup.patch Chuck Ebbert
2004-10-25 19:03 ` Justin Piszcz

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).