905 2011-03-18 00:14:05 +0000 crownbay: networking problem blocking switchover to linux-yocto 2011-04-27 07:14:48 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-configuration 1.0 TunnelCreek x86 RESOLVED FIXED Medium normal 1.1 1 tom.zanussi tom.zanussi richard.purdie yp.bsp.watcher yp.watcher --- --- --- oldest_to_newest 12809 0 tom.zanussi 2011-03-18 00:14:05 +0000 The 2.6.37 linux-yocto crownbay upgrade has been 'almost ready' for awhile - all the basic platform capabilities work, except for a network problem that has been blocking me from switching the crownbay BSP over to it. So I'm submitting a bug for it so I can get some time dedicated to figuring it out. The problem: For some reason, rather than getting the expected DHCP address from my local network, something like 192.168.1.8, I get some other completely unrelated and unknown address: eth0 Link encap:Ethernet HWaddr 00:13:20:F9:0C:D9 inet addr:169.254.71.179 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::213:20ff:fef9:cd9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3 errors:0 dropped:3 overruns:0 frame:0 TX packets:34 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:528 (528.0 B) TX bytes:9679 (9.4 KiB) 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:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:980 (980.0 B) TX bytes:980 (980.0 B) 12880 1 bruce.ashfield 2011-03-21 13:21:52 +0000 sending the bug to you Tom. If you want me or someone else to grab it .. just shout. 13045 2 tom.zanussi 2011-03-29 19:52:33 +0000 The commit that immediately causes the problem is this from 2.6.35: commit 5933dd2f028cdcbb4b3169dca594324704ba10ae Author: Eric Dumazet <eric.dumazet@gmail.com> Date: Tue Jun 15 18:16:43 2010 -0700 net: NET_SKB_PAD should depend on L1_CACHE_BYTES In old kernels, NET_SKB_PAD was defined to 16. Then commit d6301d3dd1c2 (net: Increase default NET_SKB_PAD to 32), and commit 18e8c134f4e9 (net: Increase NET_SKB_PAD to 64 bytes) increased it to 64. While first patch was governed by network stack needs, second was more driven by performance issues on current hardware. Real intent was to align data on a cache line boundary. So use max(32, L1_CACHE_BYTES) instead of 64, to be more generic. Remove microblaze and powerpc own NET_SKB_PAD definitions. Thanks to Alexander Duyck and David Miller for their comments. Suggested-by: David Miller <davem@davemloft.net> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> This wreaks havoc with the pch_gbe driver because Atom processors should have L1_CACHE_BYTES = 64 rather than the 32 that the kernel gets compiled with, and NET_SKB_PAD gets a value of 32 which should actually be 64 as before. The cpu type defaults to M686 with the X86_32 config option, which defines L1_CACHE_SHIFT = 5, where it should be L1_CACHE_SHIFT = 6. Adding the MATOM=y cpu option gives the correct L1_CACHE_SHIFT and therefore NET_SKB_PAD, and allows the pch_gbe driver to work correctly. That said, it shouldn't be necessary to define MATOM in order to get basic functionality; the different cpu type should allow for better optimization, but the unoptimized version should still work, not be completely nonfunctional as in this case. So while defining MATOM fixes the problem, and we should be defining it anyway on atom boxes, I still need to dig a little further and see if I can come up with a patch for upstream. The pch_gbe code doesn't use NET_SKB_PAD directly, so it will take a little debugging or closer code inspection to find it. 13441 3 tom.zanussi 2011-04-27 07:14:48 +0000 fixed by commit 1a60e04bbac334023f0ffde050cc2d3da9fd03d9