From: Chris Rankin <hidden> Date: 2011-01-10 23:41:49
--- 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
From: Dave, Tushar N <hidden> Date: 2011-01-11 00:37:37
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® Ethernet, visit http://communities.intel.com/community/wired
From: Chris Rankin <hidden> Date: 2011-01-11 08:52:39
--- 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
From: Eric Dumazet <hidden> Date: 2011-01-12 17:35:10
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 <redacted>
Signed-off-by: Eric Dumazet <redacted>
CC: Jeff Kirsher <redacted>
---
@@ -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)-staticinte100_rx_alloc_skb(structnic*nic,structrx*rx)++staticstructsk_buff*e100_alloc_skb(structnet_device*dev,gfp_tflags)+{+structsk_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);+returnskb;+}++staticinte100_rx_alloc_skb(structnic*nic,structrx*rx,gfp_tflags){-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(structrx),GFP_ATOMIC)))+if(!(nic->rxs=kcalloc(count,sizeof(structrx),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® Ethernet, visit http://communities.intel.com/community/wired
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 <redacted>
Signed-off-by: Eric Dumazet <redacted>
CC: Jeff Kirsher <redacted>
Reviewed-by: Jesse Brandeburg <redacted>
quoted hunk
- 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.
From: Eric Dumazet <hidden> Date: 2011-01-12 18:14:17
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 <redacted>
Signed-off-by: Eric Dumazet <redacted>
CC: Jeff Kirsher <redacted>
---
drivers/net/e100.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
@@ -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)-staticinte100_rx_alloc_skb(structnic*nic,structrx*rx)++staticstructsk_buff*e100_alloc_skb(structnet_device*dev,gfp_tflags)+{+structsk_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);+returnskb;+}++staticinte100_rx_alloc_skb(structnic*nic,structrx*rx,gfp_tflags){-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(structrx),GFP_ATOMIC)))+if(!(nic->rxs=kcalloc(count,sizeof(structrx),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;}
From: Chris Rankin <hidden> Date: 2011-01-12 23:27:07
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:
quoted hunk
From: Eric Dumazet <redacted>
Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
To: "Brandeburg, Jesse" <redacted>
Cc: "David Miller" <davem@davemloft.net>, "Chris Rankin" <redacted>, "e1000-devel@lists.sourceforge.net" <redacted>, "Dave, Tushar N" <redacted>, "netdev@vger.kernel.org" <redacted>, "Kirsher, Jeffrey T" <redacted>
Date: Wednesday, 12 January, 2011, 18:14
Le mercredi 12 janvier 2011 à 10:05
-0800, Brandeburg, Jesse a écrit :
quoted
First, I don't think the following comment should hold
up this patch.
quoted
As a policy question when I asked about using
__GFP_NOWARN before in other
quoted
Intel ethernet drivers the consensus seemed to be that
the warning
quoted
messages were useful. All our drivers correctly
handle runtime memory
quoted
failures, but none of them are currently using
__GFP_NOWARN.
quoted
Can I submit patches to change our other drivers to
__GFP_NOWARN? I think
quoted
it will make for quite a few less reports of
non-issues to the list. All
quoted
our drivers that I would be patching already have
ethtool counters that
quoted
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 <redacted>
Signed-off-by: Eric Dumazet <redacted>
CC: Jeff Kirsher <redacted>
---
drivers/net/e100.c | 22
+++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
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;
}
From: Eric Dumazet <hidden> Date: 2011-01-13 04:55:43
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 :
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.
From: Chris Rankin <hidden> Date: 2011-01-13 09:00:37
--- 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
From: Eric Dumazet <hidden> Date: 2011-01-13 09:06:02
Le jeudi 13 janvier 2011 à 01:00 -0800, Chris Rankin a écrit :
quoted hunk
--- On Thu, 13/1/11, Eric Dumazet <eric.dumazet@gmail.com> wrote:
quoted
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.
quoted
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.