[e100] Page allocation failure warning(?) in 2.6.36.3

[e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

Hi,

I've just booted 2.6.36.3 on my old router box (which contains one single e100 card, and one dual-port e100 card), and have discovered this rather scary message in the dmesg log:

e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:00:0f.0: PME# disabled
e100 0000:00:0f.0: eth0: addr 0xffbeb000, irq 10, MAC addr 00:90:27:76:d0:ec
e100 0000:01:04.0: PME# disabled
e100 0000:01:04.0: eth1: addr 0xff0fe000, irq 11, MAC addr 00:03:47:3b:29:5c
e100 0000:01:05.0: PME# disabled
e100 0000:01:05.0: eth2: addr 0xff0ff000, irq 10, MAC addr 00:03:47:3b:29:5d
...
device eth1 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth1: link is not ready
e100 0000:01:04.0: eth1: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
device eth2 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth2: link is not ready
br0: port 1(eth1) entering learning state
br0: port 1(eth1) entering learning state
ifconfig: page allocation failure. order:6, mode:0x8020
Pid: 3716, comm: ifconfig Not tainted 2.6.36.3 #1
Call Trace:
 [<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
 [<c106177d>] ? __slab_alloc+0x1eb/0x396
 [<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
 [<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
 [<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
 [<c58f97f3>] ? e100_rx_alloc_skb+0x87/0x122 [e100]
 [<c58f9883>] ? e100_rx_alloc_skb+0x117/0x122 [e100]
 [<c58f98dc>] ? e100_alloc_cbs+0x4e/0xfa [e100]
 [<c58fb370>] ? e100_up+0x1b/0xf1 [e100]
 [<c58fb45d>] ? e100_open+0x17/0x3b [e100]
 [<c1121630>] ? __dev_open+0x7c/0xa0
 [<c11217ed>] ? __dev_change_flags+0x8b/0x100
 [<c11218c3>] ? dev_change_flags+0x10/0x3b
 [<c1159880>] ? devinet_ioctl+0x25a/0x532
 [<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
 [<c111452a>] ? sock_ioctl+0x0/0x1ca
 [<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
 [<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
 [<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
 [<c10636f6>] ? sys_faccessat+0x144/0x151
 [<c106e0cc>] ? sys_ioctl+0x2d/0x49
 [<c1177dd5>] ? syscall_call+0x7/0xb
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:    6, btch:   1 usd:   0
active_anon:280 inactive_anon:808 isolated_anon:0
 active_file:1384 inactive_file:9672 isolated_file:0
 unevictable:0 dirty:77 writeback:0 unstable:0
 free:753 slab_reclaimable:499 slab_unreclaimable:1393
 mapped:375 shmem:643 pagetables:59 bounce:0
DMA free:1492kB min:248kB low:308kB high:372kB active_anon:0kB inactive_anon:12kB active_file:288kB inactive_file:12548kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:48kB writeback:0kB mapped:28kB shmem:0kB slab_reclaimable:312kB slab_unreclaimable:884kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 47 47
Normal free:1520kB min:764kB low:952kB high:1144kB active_anon:1120kB inactive_anon:3220kB active_file:5248kB inactive_file:26140kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:260kB writeback:0kB mapped:1472kB shmem:2572kB slab_reclaimable:1684kB slab_unreclaimable:4688kB kernel_stack:176kB pagetables:236kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 51*4kB 23*8kB 3*16kB 3*32kB 7*64kB 4*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1492kB
Normal: 260*4kB 26*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1520kB
11715 total pagecache pages
16 pages in swap cache
Swap cache stats: add 44, delete 28, find 72/72
Free swap  = 2179532kB
Total swap = 2179596kB
16383 pages RAM
826 pages reserved
10736 pages shared
5361 pages non-shared
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100 0000:00:0f.0: eth0: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
br0: port 1(eth1) entering forwarding state

Should I be concerned, please? All three e100 devices still appear to be working, but something nasty seems to have happened anyway.

The lspci output for these devices is:
00:0f.0 0200: 8086:1229 (rev 08)
	Subsystem: 8086:000c
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ffbeb000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at ef00 [size=64]
	Region 2: Memory at fef00000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at 04000000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-
	Kernel driver in use: e100
	Kernel modules: e100

01:04.0 0200: 8086:1229 (rev 05)
	Subsystem: 8086:10f0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ff0fe000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at fcc0 [size=32]
	Region 2: Memory at ff700000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at ff100000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: e100
	Kernel modules: e100

01:05.0 0200: 8086:1229 (rev 05)
	Subsystem: 8086:10f0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ff0ff000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at fce0 [size=32]
	Region 2: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at ff200000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: e100
	Kernel modules: e100

Thanks,
Chris


      

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Dave, Tushar N]

Chris,
Sorry to hear that you have the issue. 
Does the issue appears only when you add a bridge?

Thanks.

-Tushar

-----Original Message-----
From: Chris Rankin [mailto:rankincj@yahoo.com] 
Sent: Saturday, January 08, 2011 4:54 AM
To: e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org
Subject: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

Hi,

I've just booted 2.6.36.3 on my old router box (which contains one single e100 card, and one dual-port e100 card), and have discovered this rather scary message in the dmesg log:

e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:00:0f.0: PME# disabled
e100 0000:00:0f.0: eth0: addr 0xffbeb000, irq 10, MAC addr 00:90:27:76:d0:ec
e100 0000:01:04.0: PME# disabled
e100 0000:01:04.0: eth1: addr 0xff0fe000, irq 11, MAC addr 00:03:47:3b:29:5c
e100 0000:01:05.0: PME# disabled
e100 0000:01:05.0: eth2: addr 0xff0ff000, irq 10, MAC addr 00:03:47:3b:29:5d
...
device eth1 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth1: link is not ready
e100 0000:01:04.0: eth1: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
device eth2 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth2: link is not ready
br0: port 1(eth1) entering learning state
br0: port 1(eth1) entering learning state
ifconfig: page allocation failure. order:6, mode:0x8020
Pid: 3716, comm: ifconfig Not tainted 2.6.36.3 #1
Call Trace:
 [<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
 [<c106177d>] ? __slab_alloc+0x1eb/0x396
 [<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
 [<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
 [<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
 [<c58f97f3>] ? e100_rx_alloc_skb+0x87/0x122 [e100]
 [<c58f9883>] ? e100_rx_alloc_skb+0x117/0x122 [e100]
 [<c58f98dc>] ? e100_alloc_cbs+0x4e/0xfa [e100]
 [<c58fb370>] ? e100_up+0x1b/0xf1 [e100]
 [<c58fb45d>] ? e100_open+0x17/0x3b [e100]
 [<c1121630>] ? __dev_open+0x7c/0xa0
 [<c11217ed>] ? __dev_change_flags+0x8b/0x100
 [<c11218c3>] ? dev_change_flags+0x10/0x3b
 [<c1159880>] ? devinet_ioctl+0x25a/0x532
 [<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
 [<c111452a>] ? sock_ioctl+0x0/0x1ca
 [<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
 [<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
 [<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
 [<c10636f6>] ? sys_faccessat+0x144/0x151
 [<c106e0cc>] ? sys_ioctl+0x2d/0x49
 [<c1177dd5>] ? syscall_call+0x7/0xb
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:    6, btch:   1 usd:   0
active_anon:280 inactive_anon:808 isolated_anon:0
 active_file:1384 inactive_file:9672 isolated_file:0
 unevictable:0 dirty:77 writeback:0 unstable:0
 free:753 slab_reclaimable:499 slab_unreclaimable:1393
 mapped:375 shmem:643 pagetables:59 bounce:0
DMA free:1492kB min:248kB low:308kB high:372kB active_anon:0kB inactive_anon:12kB active_file:288kB inactive_file:12548kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:48kB writeback:0kB mapped:28kB shmem:0kB slab_reclaimable:312kB slab_unreclaimable:884kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 47 47
Normal free:1520kB min:764kB low:952kB high:1144kB active_anon:1120kB inactive_anon:3220kB active_file:5248kB inactive_file:26140kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:260kB writeback:0kB mapped:1472kB shmem:2572kB slab_reclaimable:1684kB slab_unreclaimable:4688kB kernel_stack:176kB pagetables:236kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 51*4kB 23*8kB 3*16kB 3*32kB 7*64kB 4*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1492kB
Normal: 260*4kB 26*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1520kB
11715 total pagecache pages
16 pages in swap cache
Swap cache stats: add 44, delete 28, find 72/72
Free swap  = 2179532kB
Total swap = 2179596kB
16383 pages RAM
826 pages reserved
10736 pages shared
5361 pages non-shared
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100 0000:00:0f.0: eth0: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
br0: port 1(eth1) entering forwarding state

Should I be concerned, please? All three e100 devices still appear to be working, but something nasty seems to have happened anyway.

The lspci output for these devices is:
00:0f.0 0200: 8086:1229 (rev 08)
	Subsystem: 8086:000c
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ffbeb000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at ef00 [size=64]
	Region 2: Memory at fef00000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at 04000000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-
	Kernel driver in use: e100
	Kernel modules: e100

01:04.0 0200: 8086:1229 (rev 05)
	Subsystem: 8086:10f0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ff0fe000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at fcc0 [size=32]
	Region 2: Memory at ff700000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at ff100000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: e100
	Kernel modules: e100

01:05.0 0200: 8086:1229 (rev 05)
	Subsystem: 8086:10f0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ff0ff000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at fce0 [size=32]
	Region 2: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at ff200000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: e100
	Kernel modules: e100

Thanks,
Chris


      

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

--- On Mon, 10/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
> Does the issue appears only when you add a bridge?

Tushar,

I'm not sure what you mean by "add a bridge". I've been using this box ever since the late 1990s, and have had the 3 e100 port since the early 2000s, so I can't say that I "do" anything with it apart from use it. 

The PCI configuration remains as it always has, and the box get rebooted only to receive stable kernel updates. Looking back through old dmesg logs, it looks like this issue also happened in 2.6.33.6 too without me ever realising. Hence I am suspecting that this problem has been happening intermittently for ages...

Is there anything else I can tell you about this ropey old P200 MMX PC before Indiana Jones finds it and tries putting it in his museum ;-)?

Cheers,
Chris


      

Re: [e100] Page allocation failure warning(?) in 2.6.36.3

[Dave, Tushar N]

Chris,
The reason I asked you about bridge is because I have noticed "br0: port 1(eth1) entering learning state" in the dmesg log you sent.
I am trying to figure out exactly what sequence of commands you run that produce this message " br0: port 1(eth1) entering learning state" in log.
Also if you let me know output of 
#cat /etc/network/interface
#ifconfig -a

Thanks.


-Tushar

-----Original Message-----
From: Chris Rankin [mailto:rankincj@yahoo.com] 
Sent: Monday, January 10, 2011 3:42 PM
To: e1000-devel@lists.sourceforge.net; Dave, Tushar N
Cc: netdev@vger.kernel.org
Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

--- On Mon, 10/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
> Does the issue appears only when you add a bridge?

Tushar,

I'm not sure what you mean by "add a bridge". I've been using this box ever since the late 1990s, and have had the 3 e100 port since the early 2000s, so I can't say that I "do" anything with it apart from use it. 

The PCI configuration remains as it always has, and the box get rebooted only to receive stable kernel updates. Looking back through old dmesg logs, it looks like this issue also happened in 2.6.33.6 too without me ever realising. Hence I am suspecting that this problem has been happening intermittently for ages...

Is there anything else I can tell you about this ropey old P200 MMX PC before Indiana Jones finds it and tries putting it in his museum ;-)?

Cheers,
Chris


      
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

--- On Tue, 11/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
The reason I asked you about bridge is because I have
> noticed "br0: port 1(eth1) entering learning state" in the
> dmesg log you sent.
> I am trying to figure out exactly what sequence of commands
> you run that produce this message " br0: port 1(eth1)
> entering learning state" in log.

Tushar,

Ah, sorry. I thought you were referring to a PCI bridge, or something similar.

The br0 interface contains the eth1 and eth2 interfaces, which each connects to a PC on the private LAN. The eth0 interface connects to the ADSL router, and br0 holds the PC's internal LAN IP address. (eth0, eth1 and eth2 are all e100 interfaces, of course.)

It's impossible to state whether the problem *only* happens when I use the bridge because:
a) I've always used the bridge, and need to for the LAN to work, and
b) the problem is both rare and intermittent, even when it does happen. I certainly didn't notice it with the 2.6.36.2 kernel, nor any of the 2.6.34 or 2.6.35 kernels, although the fact that I did with the 2.6.33.6 kernel suggests it was present in all those kernels anyway.

I'll send you the bridge setup and ifconfig information later; I'm not in front of that PC right now.

Thanks,
Chris



      

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

Tushar,

As promised:

$ /sbin/ifconfig -a
br0       Link encap:Ethernet  HWaddr 00:03:47:3b:29:5c  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::203:47ff:fe3b:295c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:372485 errors:0 dropped:0 overruns:0 frame:0
          TX packets:383917 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:37566127 (35.8 MiB)  TX bytes:225458273 (215.0 MiB)

eth0      Link encap:Ethernet  HWaddr 00:90:27:76:d0:ec  
          inet addr:10.0.43.2  Bcast:10.0.43.255  Mask:255.255.255.0
          inet6 addr: fe80::290:27ff:fe76:d0ec/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:432016 errors:0 dropped:0 overruns:0 frame:0
          TX packets:377602 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:229629017 (218.9 MiB)  TX bytes:41958103 (40.0 MiB)

eth1      Link encap:Ethernet  HWaddr 00:03:47:3b:29:5c  
          inet6 addr: fe80::203:47ff:fe3b:295c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:364683 errors:0 dropped:0 overruns:0 frame:0
          TX packets:369235 errors:1 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000 
          RX bytes:42445811 (40.4 MiB)  TX bytes:203414933 (193.9 MiB)

eth2      Link encap:Ethernet  HWaddr 00:03:47:3b:29:5d  
          inet6 addr: fe80::203:47ff:fe3b:295d/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:9059 errors:1 dropped:0 overruns:0 frame:1
          TX packets:15437 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:691449 (675.2 KiB)  TX bytes:22232699 (21.2 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:797 errors:0 dropped:0 overruns:0 frame:0
          TX packets:797 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:81543 (79.6 KiB)  TX bytes:81543 (79.6 KiB)

$ cat /etc/network/interfaces 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
	address 10.0.43.2
	netmask 255.255.255.0
	network 10.0.43.0
	broadcast 10.0.43.255
	gateway 10.0.43.1
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 192.168.0.1
	dns-search underworld

auto br0
iface br0 inet static
	address 192.168.0.1
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255
	bridge-ports eth1 eth2
	bridge_hello 1
	bridge_fd 4
	bridge_maxage 4
	post-up /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev br0

Cheers,
Chris



      

Re: [e100] Page allocation failure warning(?) in 2.6.36.3

[Eric Dumazet]

Le mardi 11 janvier 2011 à 12:59 -0800, Chris Rankin a écrit :
> Tushar,
> 
> As promised:
> 
> $ /sbin/ifconfig -a
> br0       Link encap:Ethernet  HWaddr 00:03:47:3b:29:5c  
>           inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
>           inet6 addr: fe80::203:47ff:fe3b:295c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:372485 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:383917 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:37566127 (35.8 MiB)  TX bytes:225458273 (215.0 MiB)
> 
> eth0      Link encap:Ethernet  HWaddr 00:90:27:76:d0:ec  
>           inet addr:10.0.43.2  Bcast:10.0.43.255  Mask:255.255.255.0
>           inet6 addr: fe80::290:27ff:fe76:d0ec/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:432016 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:377602 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:229629017 (218.9 MiB)  TX bytes:41958103 (40.0 MiB)
> 
> eth1      Link encap:Ethernet  HWaddr 00:03:47:3b:29:5c  
>           inet6 addr: fe80::203:47ff:fe3b:295c/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:364683 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:369235 errors:1 dropped:0 overruns:0 carrier:1
>           collisions:0 txqueuelen:1000 
>           RX bytes:42445811 (40.4 MiB)  TX bytes:203414933 (193.9 MiB)
> 
> eth2      Link encap:Ethernet  HWaddr 00:03:47:3b:29:5d  
>           inet6 addr: fe80::203:47ff:fe3b:295d/64 Scope:Link
>           UP BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:9059 errors:1 dropped:0 overruns:0 frame:1
>           TX packets:15437 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:691449 (675.2 KiB)  TX bytes:22232699 (21.2 MiB)
> 
> lo        Link encap:Local Loopback  
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:797 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:797 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:81543 (79.6 KiB)  TX bytes:81543 (79.6 KiB)
> 
> $ cat /etc/network/interfaces 
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet static
> 	address 10.0.43.2
> 	netmask 255.255.255.0
> 	network 10.0.43.0
> 	broadcast 10.0.43.255
> 	gateway 10.0.43.1
> 	# dns-* options are implemented by the resolvconf package, if installed
> 	dns-nameservers 192.168.0.1
> 	dns-search underworld
> 
> auto br0
> iface br0 inet static
> 	address 192.168.0.1
> 	netmask 255.255.255.0
> 	network 192.168.0.0
> 	broadcast 192.168.0.255
> 	bridge-ports eth1 eth2
> 	bridge_hello 1
> 	bridge_fd 4
> 	bridge_maxage 4
> 	post-up /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev br0
> 
> Cheers,
> Chris
> 

Apparently e100 driver uses GFP_ATOMIC allocations in setup phase, and
your machine doesnt have enough memory.

I would try following patch, allowing the use of GFP_KERNEL at init
time, to let vm games play.

Thanks

[PATCH] e100: use GFP_KERNEL allocations at device init stage

In lowmem conditions, e100 driver can fail its initialization, because
of GFP_ATOMIC abuse.

Switch to GFP_KERNEL were applicable.

Add __GFP_NOWARN flag to GFP_ATOMIC allocations, since driver can cope
with failed allocations (if setup succeeded)

Reported-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index b0aa9e6..e4d8a70 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1880,9 +1880,21 @@ static inline void e100_start_receiver(struct nic *nic, struct rx *rx)
 }
 
 #define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN)
-static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
+
+static struct sk_buff *e100_alloc_skb(struct net_device *dev, gfp_t flags)
+{
+	struct sk_buff *skb;
+
+	skb = __netdev_alloc_skb(dev, RFD_BUF_LEN + NET_IP_ALIGN, flags);
+	if (NET_IP_ALIGN && skb)
+		skb_reserve(skb, NET_IP_ALIGN);
+	return skb;
+}
+
+static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx, gfp_t flags)
 {
-	if (!(rx->skb = netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
+	rx->skb = e100_alloc_skb(nic->netdev, flags);
+	if (!rx->skb)
 		return -ENOMEM;
 
 	/* Init, and map the RFD. */
@@ -2026,7 +2038,8 @@ static void e100_rx_clean(struct nic *nic, unsigned int *work_done,
 
 	/* Alloc new skbs to refill list */
 	for (rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) {
-		if (unlikely(e100_rx_alloc_skb(nic, rx)))
+		if (unlikely(e100_rx_alloc_skb(nic, rx,
+					       GFP_ATOMIC | __GFP_NOWARN)))
 			break; /* Better luck next time (see watchdog) */
 	}
 
@@ -2102,13 +2115,13 @@ static int e100_rx_alloc_list(struct nic *nic)
 	nic->rx_to_use = nic->rx_to_clean = NULL;
 	nic->ru_running = RU_UNINITIALIZED;
 
-	if (!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_ATOMIC)))
+	if (!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_KERNEL)))
 		return -ENOMEM;
 
 	for (rx = nic->rxs, i = 0; i < count; rx++, i++) {
 		rx->next = (i + 1 < count) ? rx + 1 : nic->rxs;
 		rx->prev = (i == 0) ? nic->rxs + count - 1 : rx - 1;
-		if (e100_rx_alloc_skb(nic, rx)) {
+		if (e100_rx_alloc_skb(nic, rx, GFP_KERNEL)) {
 			e100_rx_clean_list(nic);
 			return -ENOMEM;
 		}



------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

--- On Wed, 12/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Apparently e100 driver uses GFP_ATOMIC allocations in setup
> phase, and your machine doesnt have enough memory.

Thanks. You'd think 64 MB of RAM would be enough... ;-).

Cheers,
Chris


      

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Eric Dumazet]

Le mercredi 12 janvier 2011 à 09:42 -0800, Chris Rankin a écrit :
> --- On Wed, 12/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Apparently e100 driver uses GFP_ATOMIC allocations in setup
> > phase, and your machine doesnt have enough memory.
> 
> Thanks. You'd think 64 MB of RAM would be enough... ;-).

I remember using linux on a 8MB machine a loooong time ago, but not a
2.6 kernel :)

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Brandeburg, Jesse]

Hi Eric, thanks for doing this work!

On Wed, 12 Jan 2011, Eric Dumazet wrote:
> Apparently e100 driver uses GFP_ATOMIC allocations in setup phase, and
> your machine doesnt have enough memory.

This part looks great.
 
> I would try following patch, allowing the use of GFP_KERNEL at init
> time, to let vm games play.
> 
> Thanks
> 
> [PATCH] e100: use GFP_KERNEL allocations at device init stage
> 
> In lowmem conditions, e100 driver can fail its initialization, because
> of GFP_ATOMIC abuse.
> 
> Switch to GFP_KERNEL were applicable.
> 
> Add __GFP_NOWARN flag to GFP_ATOMIC allocations, since driver can cope
> with failed allocations (if setup succeeded)
> 
> Reported-by: Chris Rankin <rankincj@yahoo.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>

> -		if (unlikely(e100_rx_alloc_skb(nic, rx)))
> +		if (unlikely(e100_rx_alloc_skb(nic, rx,
> +					       GFP_ATOMIC | __GFP_NOWARN)))

First, I don't think the following comment should hold up this patch.

As a policy question when I asked about using __GFP_NOWARN before in other 
Intel ethernet drivers the consensus seemed to be that the warning 
messages were useful.  All our drivers correctly handle runtime memory 
failures, but none of them are currently using __GFP_NOWARN.

Can I submit patches to change our other drivers to __GFP_NOWARN?  I think 
it will make for quite a few less reports of non-issues to the list.  All 
our drivers that I would be patching already have ethtool counters that 
count failed allocations.

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Eric Dumazet]

Le mercredi 12 janvier 2011 à 10:05 -0800, Brandeburg, Jesse a écrit :

> First, I don't think the following comment should hold up this patch.
> 
> As a policy question when I asked about using __GFP_NOWARN before in other 
> Intel ethernet drivers the consensus seemed to be that the warning 
> messages were useful.  All our drivers correctly handle runtime memory 
> failures, but none of them are currently using __GFP_NOWARN.
> 
> Can I submit patches to change our other drivers to __GFP_NOWARN?  I think 
> it will make for quite a few less reports of non-issues to the list.  All 
> our drivers that I would be patching already have ethtool counters that 
> count failed allocations.
> 

If an allocation failure is really handled, in the sense NIC doesnt
freeze but only lose one incoming frame, then probably yes.

I think the warning message can be useful when driver is known to let
things in a non working state ;)

As you said, this can be done later, here is a respin without this bit.

Thanks !

[PATCH v2] e100: use GFP_KERNEL allocations at device init stage

In lowmem conditions, e100 driver can fail its initialization, because
of GFP_ATOMIC abuse.

Switch to GFP_KERNEL were applicable.

Reported-by: Chris Rankin <rankincj@yahoo.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/e100.c |   22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index b0aa9e6..c9a2126 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1880,9 +1880,21 @@ static inline void e100_start_receiver(struct nic *nic, struct rx *rx)
 }
 
 #define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN)
-static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx)
+
+static struct sk_buff *e100_alloc_skb(struct net_device *dev, gfp_t flags)
+{
+	struct sk_buff *skb;
+
+	skb = __netdev_alloc_skb(dev, RFD_BUF_LEN + NET_IP_ALIGN, flags);
+	if (NET_IP_ALIGN && skb)
+		skb_reserve(skb, NET_IP_ALIGN);
+	return skb;
+}
+
+static int e100_rx_alloc_skb(struct nic *nic, struct rx *rx, gfp_t flags)
 {
-	if (!(rx->skb = netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
+	rx->skb = e100_alloc_skb(nic->netdev, flags);
+	if (!rx->skb)
 		return -ENOMEM;
 
 	/* Init, and map the RFD. */
@@ -2026,7 +2038,7 @@ static void e100_rx_clean(struct nic *nic, unsigned int *work_done,
 
 	/* Alloc new skbs to refill list */
 	for (rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) {
-		if (unlikely(e100_rx_alloc_skb(nic, rx)))
+		if (unlikely(e100_rx_alloc_skb(nic, rx, GFP_ATOMIC)))
 			break; /* Better luck next time (see watchdog) */
 	}
 
@@ -2102,13 +2114,13 @@ static int e100_rx_alloc_list(struct nic *nic)
 	nic->rx_to_use = nic->rx_to_clean = NULL;
 	nic->ru_running = RU_UNINITIALIZED;
 
-	if (!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_ATOMIC)))
+	if (!(nic->rxs = kcalloc(count, sizeof(struct rx), GFP_KERNEL)))
 		return -ENOMEM;
 
 	for (rx = nic->rxs, i = 0; i < count; rx++, i++) {
 		rx->next = (i + 1 < count) ? rx + 1 : nic->rxs;
 		rx->prev = (i == 0) ? nic->rxs + count - 1 : rx - 1;
-		if (e100_rx_alloc_skb(nic, rx)) {
+		if (e100_rx_alloc_skb(nic, rx, GFP_KERNEL)) {
 			e100_rx_clean_list(nic);
 			return -ENOMEM;
 		}

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

Thanks, the problem has not reoccurred since I've rebooted the box with the new e100 module.

However, the problem *did* reoccur when I tried just stopping networking, unloading the old module, loading the new module and restarting networking... (I think there were some residual network packets still taking up memory in the system. Maybe.)

Jan 12 22:27:04 wellhouse kernel: ifconfig: page allocation failure. order:6, mode:0x8020
Jan 12 22:27:04 wellhouse kernel: Pid: 14968, comm: ifconfig Not tainted 2.6.36.3 #1
Jan 12 22:27:04 wellhouse kernel: Call Trace:
Jan 12 22:27:04 wellhouse kernel: [<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
Jan 12 22:27:04 wellhouse kernel: [<c106177d>] ? __slab_alloc+0x1eb/0x396
Jan 12 22:27:04 wellhouse kernel: [<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
Jan 12 22:27:04 wellhouse kernel: [<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
Jan 12 22:27:04 wellhouse kernel: [<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
Jan 12 22:27:04 wellhouse kernel: [<c66f67ee>] ? e100_rx_alloc_skb+0x82/0x11d [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f687e>] ? e100_rx_alloc_skb+0x112/0x11d [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f68d7>] ? e100_alloc_cbs+0x4e/0xfa [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f836e>] ? e100_up+0x1b/0xf1 [e100]
Jan 12 22:27:07 wellhouse kernel: [<c66f845b>] ? e100_open+0x17/0x3b [e100]
Jan 12 22:27:07 wellhouse kernel: [<c1121630>] ? __dev_open+0x7c/0xa0
Jan 12 22:27:07 wellhouse kernel: [<c11217ed>] ? __dev_change_flags+0x8b/0x100
Jan 12 22:27:07 wellhouse kernel: [<c11218c3>] ? dev_change_flags+0x10/0x3b
Jan 12 22:27:07 wellhouse kernel: [<c1159880>] ? devinet_ioctl+0x25a/0x532
Jan 12 22:27:07 wellhouse kernel: [<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
Jan 12 22:27:07 wellhouse kernel: [<c111452a>] ? sock_ioctl+0x0/0x1ca
Jan 12 22:27:07 wellhouse kernel: [<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
Jan 12 22:27:07 wellhouse kernel: [<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
Jan 12 22:27:07 wellhouse kernel: [<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
Jan 12 22:27:07 wellhouse kernel: [<c10636f6>] ? sys_faccessat+0x144/0x151
Jan 12 22:27:07 wellhouse kernel: [<c106e0cc>] ? sys_ioctl+0x2d/0x49
Jan 12 22:27:07 wellhouse kernel: [<c1177dd5>] ? syscall_call+0x7/0xb
Jan 12 22:27:07 wellhouse kernel: Mem-Info:
Jan 12 22:27:07 wellhouse kernel: DMA per-cpu:
Jan 12 22:27:07 wellhouse kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jan 12 22:27:07 wellhouse kernel: Normal per-cpu:
Jan 12 22:27:07 wellhouse kernel: CPU    0: hi:    6, btch:   1 usd:   1
Jan 12 22:27:07 wellhouse kernel: active_anon:2698 inactive_anon:3626 isolated_anon:0
Jan 12 22:27:07 wellhouse kernel: active_file:2305 inactive_file:3574 isolated_file:0
Jan 12 22:27:07 wellhouse kernel: unevictable:0 dirty:17 writeback:0 unstable:0
Jan 12 22:27:07 wellhouse kernel: free:558 slab_reclaimable:484 slab_unreclaimable:1309
Jan 12 22:27:07 wellhouse kernel: mapped:1209 shmem:650 pagetables:129 bounce:0
Jan 12 22:27:07 wellhouse kernel: DMA free:1044kB min:248kB low:308kB high:372kB active_anon:3516kB inactive_anon:4004kB active_file:1784kB inactive_file:4216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:4kB writeback:0kB mapped:988kB shmem:8kB slab_reclaimable:288kB slab_unreclaimable:188kB kernel_stack:56kB pagetables:76kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 12 22:27:07 wellhouse kernel: lowmem_reserve[]: 0 47 47
Jan 12 22:27:07 wellhouse kernel: Normal free:1188kB min:764kB low:952kB high:1144kB active_anon:7276kB inactive_anon:10500kB active_file:7436kB inactive_file:10080kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:64kB writeback:0kB mapped:3848kB shmem:2592kB slab_reclaimable:1648kB slab_unreclaimable:5048kB kernel_stack:240kB pagetables:440kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 12 22:27:07 wellhouse kernel: lowmem_reserve[]: 0 0 0
Jan 12 22:27:07 wellhouse kernel: DMA: 87*4kB 9*8kB 5*16kB 3*32kB 1*64kB 3*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1044kB
Jan 12 22:27:07 wellhouse kernel: Normal: 123*4kB 11*8kB 0*16kB 1*32kB 1*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1188kB
Jan 12 22:27:07 wellhouse kernel: 6766 total pagecache pages
Jan 12 22:27:07 wellhouse kernel: 237 pages in swap cache
Jan 12 22:27:07 wellhouse kernel: Swap cache stats: add 1830, delete 1593, find 1018/1086
Jan 12 22:27:07 wellhouse kernel: Free swap  = 2176336kB
Jan 12 22:27:07 wellhouse kernel: Total swap = 2179596kB
Jan 12 22:27:07 wellhouse kernel: 16383 pages RAM
Jan 12 22:27:07 wellhouse kernel: 826 pages reserved
Jan 12 22:27:07 wellhouse kernel: 5098 pages shared
Jan 12 22:27:07 wellhouse kernel: 12619 pages non-shared

I also noticed that the e100 is still using GFP_ATOMIC in one place. Does this mean that the problem is ultimately only truly fixable by freeing up some memory?

Cheers,
Chris

--- On Wed, 12/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:

> From: Eric Dumazet <eric.dumazet@gmail.com>
> Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
> To: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
> Cc: "David Miller" <davem@davemloft.net>, "Chris Rankin" <rankincj@yahoo.com>, "e1000-devel@lists.sourceforge.net" <e1000-devel@lists.sourceforge.net>, "Dave, Tushar N" <tushar.n.dave@intel.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
> Date: Wednesday, 12 January, 2011, 18:14
> Le mercredi 12 janvier 2011 à 10:05
> -0800, Brandeburg, Jesse a écrit :
> 
> > First, I don't think the following comment should hold
> up this patch.
> > 
> > As a policy question when I asked about using
> __GFP_NOWARN before in other 
> > Intel ethernet drivers the consensus seemed to be that
> the warning 
> > messages were useful.  All our drivers correctly
> handle runtime memory 
> > failures, but none of them are currently using
> __GFP_NOWARN.
> > 
> > Can I submit patches to change our other drivers to
> __GFP_NOWARN?  I think 
> > it will make for quite a few less reports of
> non-issues to the list.  All 
> > our drivers that I would be patching already have
> ethtool counters that 
> > count failed allocations.
> > 
> 
> If an allocation failure is really handled, in the sense
> NIC doesnt
> freeze but only lose one incoming frame, then probably
> yes.
> 
> I think the warning message can be useful when driver is
> known to let
> things in a non working state ;)
> 
> As you said, this can be done later, here is a respin
> without this bit.
> 
> Thanks !
> 
> [PATCH v2] e100: use GFP_KERNEL allocations at device init
> stage
> 
> In lowmem conditions, e100 driver can fail its
> initialization, because
> of GFP_ATOMIC abuse.
> 
> Switch to GFP_KERNEL were applicable.
> 
> Reported-by: Chris Rankin <rankincj@yahoo.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>  drivers/net/e100.c |   22
> +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index b0aa9e6..c9a2126 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -1880,9 +1880,21 @@ static inline void
> e100_start_receiver(struct nic *nic, struct rx *rx)
>  }
>  
>  #define RFD_BUF_LEN (sizeof(struct rfd) +
> VLAN_ETH_FRAME_LEN)
> -static int e100_rx_alloc_skb(struct nic *nic, struct rx
> *rx)
> +
> +static struct sk_buff *e100_alloc_skb(struct net_device
> *dev, gfp_t flags)
> +{
> +    struct sk_buff *skb;
> +
> +    skb = __netdev_alloc_skb(dev,
> RFD_BUF_LEN + NET_IP_ALIGN, flags);
> +    if (NET_IP_ALIGN && skb)
> +        skb_reserve(skb,
> NET_IP_ALIGN);
> +    return skb;
> +}
> +
> +static int e100_rx_alloc_skb(struct nic *nic, struct rx
> *rx, gfp_t flags)
>  {
> -    if (!(rx->skb =
> netdev_alloc_skb_ip_align(nic->netdev, RFD_BUF_LEN)))
> +    rx->skb =
> e100_alloc_skb(nic->netdev, flags);
> +    if (!rx->skb)
>          return -ENOMEM;
>  
>      /* Init, and map the RFD. */
> @@ -2026,7 +2038,7 @@ static void e100_rx_clean(struct nic
> *nic, unsigned int *work_done,
>  
>      /* Alloc new skbs to refill list */
>      for (rx = nic->rx_to_use;
> !rx->skb; rx = nic->rx_to_use = rx->next) {
> -        if
> (unlikely(e100_rx_alloc_skb(nic, rx)))
> +        if
> (unlikely(e100_rx_alloc_skb(nic, rx, GFP_ATOMIC)))
>             
> break; /* Better luck next time (see watchdog) */
>      }
>  
> @@ -2102,13 +2114,13 @@ static int
> e100_rx_alloc_list(struct nic *nic)
>      nic->rx_to_use = nic->rx_to_clean
> = NULL;
>      nic->ru_running = RU_UNINITIALIZED;
>  
> -    if (!(nic->rxs = kcalloc(count,
> sizeof(struct rx), GFP_ATOMIC)))
> +    if (!(nic->rxs = kcalloc(count,
> sizeof(struct rx), GFP_KERNEL)))
>          return -ENOMEM;
>  
>      for (rx = nic->rxs, i = 0; i <
> count; rx++, i++) {
>          rx->next = (i + 1
> < count) ? rx + 1 : nic->rxs;
>          rx->prev = (i ==
> 0) ? nic->rxs + count - 1 : rx - 1;
> -        if
> (e100_rx_alloc_skb(nic, rx)) {
> +        if
> (e100_rx_alloc_skb(nic, rx, GFP_KERNEL)) {
>             
> e100_rx_clean_list(nic);
>             
> return -ENOMEM;
>          }
> 
> 
> 


      

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Eric Dumazet]

Le mercredi 12 janvier 2011 à 15:27 -0800, Chris Rankin a écrit :
> Thanks, the problem has not reoccurred since I've rebooted the box with the new e100 module.
> 
> However, the problem *did* reoccur when I tried just stopping networking, unloading the old module, loading the new module and restarting networking... (I think there were some residual network packets still taking up memory in the system. Maybe.)
> 
> Jan 12 22:27:04 wellhouse kernel: ifconfig: page allocation failure. order:6, mode:0x8020
> Jan 12 22:27:04 wellhouse kernel: Pid: 14968, comm: ifconfig Not tainted 2.6.36.3 #1
> Jan 12 22:27:04 wellhouse kernel: Call Trace:
> Jan 12 22:27:04 wellhouse kernel: [<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
> Jan 12 22:27:04 wellhouse kernel: [<c106177d>] ? __slab_alloc+0x1eb/0x396
> Jan 12 22:27:04 wellhouse kernel: [<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
> Jan 12 22:27:04 wellhouse kernel: [<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
> Jan 12 22:27:04 wellhouse kernel: [<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
> Jan 12 22:27:04 wellhouse kernel: [<c66f67ee>] ? e100_rx_alloc_skb+0x82/0x11d [e100]
> Jan 12 22:27:07 wellhouse kernel: [<c66f687e>] ? e100_rx_alloc_skb+0x112/0x11d [e100]
> Jan 12 22:27:07 wellhouse kernel: [<c66f68d7>] ? e100_alloc_cbs+0x4e/0xfa [e100]
> Jan 12 22:27:07 wellhouse kernel: [<c66f836e>] ? e100_up+0x1b/0xf1 [e100]
> Jan 12 22:27:07 wellhouse kernel: [<c66f845b>] ? e100_open+0x17/0x3b [e100]
> Jan 12 22:27:07 wellhouse kernel: [<c1121630>] ? __dev_open+0x7c/0xa0
> Jan 12 22:27:07 wellhouse kernel: [<c11217ed>] ? __dev_change_flags+0x8b/0x100
> Jan 12 22:27:07 wellhouse kernel: [<c11218c3>] ? dev_change_flags+0x10/0x3b
> Jan 12 22:27:07 wellhouse kernel: [<c1159880>] ? devinet_ioctl+0x25a/0x532
> Jan 12 22:27:07 wellhouse kernel: [<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
> Jan 12 22:27:07 wellhouse kernel: [<c111452a>] ? sock_ioctl+0x0/0x1ca
> Jan 12 22:27:07 wellhouse kernel: [<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
> Jan 12 22:27:07 wellhouse kernel: [<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
> Jan 12 22:27:07 wellhouse kernel: [<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
> Jan 12 22:27:07 wellhouse kernel: [<c10636f6>] ? sys_faccessat+0x144/0x151
> Jan 12 22:27:07 wellhouse kernel: [<c106e0cc>] ? sys_ioctl+0x2d/0x49
> Jan 12 22:27:07 wellhouse kernel: [<c1177dd5>] ? syscall_call+0x7/0xb
> Jan 12 22:27:07 wellhouse kernel: Mem-Info:
> Jan 12 22:27:07 wellhouse kernel: DMA per-cpu:
> Jan 12 22:27:07 wellhouse kernel: CPU    0: hi:    0, btch:   1 usd:   0
> Jan 12 22:27:07 wellhouse kernel: Normal per-cpu:
> Jan 12 22:27:07 wellhouse kernel: CPU    0: hi:    6, btch:   1 usd:   1
> Jan 12 22:27:07 wellhouse kernel: active_anon:2698 inactive_anon:3626 isolated_anon:0
> Jan 12 22:27:07 wellhouse kernel: active_file:2305 inactive_file:3574 isolated_file:0
> Jan 12 22:27:07 wellhouse kernel: unevictable:0 dirty:17 writeback:0 unstable:0
> Jan 12 22:27:07 wellhouse kernel: free:558 slab_reclaimable:484 slab_unreclaimable:1309
> Jan 12 22:27:07 wellhouse kernel: mapped:1209 shmem:650 pagetables:129 bounce:0
> Jan 12 22:27:07 wellhouse kernel: DMA free:1044kB min:248kB low:308kB high:372kB active_anon:3516kB inactive_anon:4004kB active_file:1784kB inactive_file:4216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:4kB writeback:0kB mapped:988kB shmem:8kB slab_reclaimable:288kB slab_unreclaimable:188kB kernel_stack:56kB pagetables:76kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> Jan 12 22:27:07 wellhouse kernel: lowmem_reserve[]: 0 47 47
> Jan 12 22:27:07 wellhouse kernel: Normal free:1188kB min:764kB low:952kB high:1144kB active_anon:7276kB inactive_anon:10500kB active_file:7436kB inactive_file:10080kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:64kB writeback:0kB mapped:3848kB shmem:2592kB slab_reclaimable:1648kB slab_unreclaimable:5048kB kernel_stack:240kB pagetables:440kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> Jan 12 22:27:07 wellhouse kernel: lowmem_reserve[]: 0 0 0
> Jan 12 22:27:07 wellhouse kernel: DMA: 87*4kB 9*8kB 5*16kB 3*32kB 1*64kB 3*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1044kB
> Jan 12 22:27:07 wellhouse kernel: Normal: 123*4kB 11*8kB 0*16kB 1*32kB 1*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1188kB
> Jan 12 22:27:07 wellhouse kernel: 6766 total pagecache pages
> Jan 12 22:27:07 wellhouse kernel: 237 pages in swap cache
> Jan 12 22:27:07 wellhouse kernel: Swap cache stats: add 1830, delete 1593, find 1018/1086
> Jan 12 22:27:07 wellhouse kernel: Free swap  = 2176336kB
> Jan 12 22:27:07 wellhouse kernel: Total swap = 2179596kB
> Jan 12 22:27:07 wellhouse kernel: 16383 pages RAM
> Jan 12 22:27:07 wellhouse kernel: 826 pages reserved
> Jan 12 22:27:07 wellhouse kernel: 5098 pages shared
> Jan 12 22:27:07 wellhouse kernel: 12619 pages non-shared
> 
> I also noticed that the e100 is still using GFP_ATOMIC in one place.
> Does this mean that the problem is ultimately only truly fixable by
> freeing up some memory?


Are you referring to dma_pool_alloc(), using at line 321 :

page = pool_alloc_page(pool, GFP_ATOMIC);

I am not sure it can be changed (we own &pool->lock spinlock), thus
cannot sleep.

We could try :

diff --git a/mm/dmapool.c b/mm/dmapool.c
index 4df2de7..faf254a 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -319,7 +319,7 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,
 		if (page->offset < pool->allocation)
 			goto ready;
 	}
-	page = pool_alloc_page(pool, GFP_ATOMIC);
+	page = pool_alloc_page(pool, GFP_ATOMIC | __GFP_NOWARN);
 	if (!page) {
 		if (mem_flags & __GFP_WAIT) {
 			DECLARE_WAITQUEUE(wait, current);


Problem is e100 allocates an order-6 page in DMA zone
(a 256 KB contigous area of ram)

This contigous area of ram is not available but just after booting...

If you change :

struct param_range cbs  = { .min = 64, .max = 256, .count = 128 };

to

struct param_range cbs  = { .min = 64, .max = 64, .count = 64 };

the need will be reduced to 64 KB of contigous area, it should be OK
then ;)

On such small router, I doubt you need more than 64 slots in TX ring
buffer.

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

--- On Thu, 13/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Problem is e100 allocates an order-6 page in DMA zone
> (a 256 KB contigous area of ram)
> 
> This contigous area of ram is not available but just after
> booting...

I suspected as much. Fortunately, this machine has no function apart from routing and can happily left untouched for extended periods of time.

> On such small router, I doubt you need more than 64 slots
> in TX ring buffer.

But what would the effect of that change be to the interfaces' performance, please?

Cheers,
Chris


      

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Eric Dumazet]

Le jeudi 13 janvier 2011 à 01:00 -0800, Chris Rankin a écrit :
> --- On Thu, 13/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Problem is e100 allocates an order-6 page in DMA zone
> > (a 256 KB contigous area of ram)
> > 
> > This contigous area of ram is not available but just after
> > booting...
> 
> I suspected as much. Fortunately, this machine has no function apart from routing and can happily left untouched for extended periods of time.
> 
> > On such small router, I doubt you need more than 64 slots
> > in TX ring buffer.
> 
> But what would the effect of that change be to the interfaces' performance, please?

If you care of performance, dont unload/reload your driver all the time,
and dont use modules (this matter on old hardware because of TLB misses)

Anyway, the change ( 128 -> 64 ) is not needed, since the kernel message
is a warning only. The allocation is retried and apparently succeeds.

The __GFP_NOWARN should make the failed allocation not noticed at all.

RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

[Chris Rankin]

-- On Thu, 13/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> If you care of performance, dont unload/reload your driver
> all the time, and dont use modules (this matter on old hardware because
> of TLB misses)

As long as I can route the full bandwidth of my ADSLv2 connection then it's fine.

Cheers,
Chris