hyper_ch,
please test the very latest kernel from raring-updates (3.8.0-31.46), which contains the following patch:
commit bc421a035e6cc8420866754af35b355c165c6ed2 Author: Eric Dumazet <email address hidden> Date: Mon Jul 29 10:24:04 2013 -0700
atl1c: use custom skb allocator
BugLink: http://bugs.launchpad.net/bugs/1221794
[ Upstream commit 7b70176421993866e616f1cbc4d0dd4054f1bf78 ]
We had reports ( https://bugzilla.kernel.org/show_bug.cgi?id=54021 ) that using high order pages for skb allocations is problematic for atl1c
We do not know exactly what the problem is, but we suspect that crossing 4K pages is not well supported by this hardware.
Use a custom allocator, using page allocator and 2K fragments for optimal stack behavior. We might make this allocator generic in future kernels.
hyper_ch,
please test the very latest kernel from raring-updates (3.8.0-31.46), which contains the following patch:
commit bc421a035e6cc84 20866754af35b35 5c165c6ed2
Author: Eric Dumazet <email address hidden>
Date: Mon Jul 29 10:24:04 2013 -0700
atl1c: use custom skb allocator
BugLink: http:// bugs.launchpad. net/bugs/ 1221794
[ Upstream commit 7b7017642199386 6e616f1cbc4d0dd 4054f1bf78 ]
We had reports ( https:/ /bugzilla. kernel. org/show_ bug.cgi? id=54021 )
that using high order pages for skb allocations is problematic for atl1c
We do not know exactly what the problem is, but we suspect that crossing
4K pages is not well supported by this hardware.
Use a custom allocator, using page allocator and 2K fragments for
optimal stack behavior. We might make this allocator generic
in future kernels.