From: Alexander Graf <hidden> Date: 2011-12-23 16:54:23
Hi guys,
While trying to test my latest patch queue for ppc kvm, I realized that =
even though the device trees got updated, the p1020 box still is =
unstable. The trace below is the one I've seen the most. It only occurs =
during network I/O which happens a lot on that box, since I'm running it =
using NFS root.
As for configuration, I use kumar's "merge" branch from today and the =
p1020rdb.dts device tree provided in that tree.
The last known good configuration I'm aware of is 3.0.
Any ideas what's going wrong here?
Alex
---
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xc00eb38c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=3D2 P1020 RDB
Modules linked in:
NIP: c00eb38c LR: c00eb278 CTR: c0340e48
REGS: effedc70 TRAP: 0300 Not tainted =
(3.2.0-rc3-00013-gaca3173-dirty)
MSR: 00021000 <ME,CE> CR: 28842422 XER: 00000000
DEAR: 00000004, ESR: 00800000
TASK =3D ef4bd900[4816] 'cc1' THREAD: ee4c4000 CPU: 0
GPR00: 00004080 effedd20 ef4bd900 ef001180 c15e5700 ffffffff c03e7448 =
00100021=20
GPR08: 00100020 00010001 00000000 00000000 28842442 10a3e610 00210d00 =
00200200=20
GPR16: 00100100 00000001 c06d6748 ef002670 00000000 c03e7448 ffffffff =
00000020=20
GPR24: effec000 ffffffec 00029000 ef001188 00000000 ef002600 c18079e0 =
ef001180=20
NIP [c00eb38c] __slab_alloc+0x3d4/0x4f8
LR [c00eb278] __slab_alloc+0x2c0/0x4f8
Call Trace:
[effedd20] [c06d6b78] hashrnd+0x0/0x4 (unreliable)
[effeddc0] [c00eb680] __kmalloc_track_caller+0x1d0/0x200
[effedde0] [c03e6064] __alloc_skb+0x74/0x150
[effede00] [c03e7448] __netdev_alloc_skb+0x28/0x60
[effede10] [c03408f0] gfar_new_skb+0x50/0x7c
[effede20] [c0340acc] gfar_clean_rx_ring+0x1b0/0x52c
[effede90] [c03412d0] gfar_poll+0x488/0x624
[effedf60] [c03f062c] net_rx_action+0x140/0x1e8
[effedfa0] [c0061aa0] __do_softirq+0x124/0x210
[effedff0] [c000e0fc] call_do_softirq+0x14/0x24
[ee4c5c40] [c000564c] do_softirq+0xb4/0xe0
[ee4c5c60] [c006170c] irq_exit+0x94/0xb4
[ee4c5c70] [c000591c] do_IRQ+0xb0/0x1ac
[ee4c5ca0] [c000fc5c] ret_from_except+0x0/0x18
--- Exception: 501 at do_lookup+0x118/0x3cc
LR =3D do_lookup+0xec/0x3cc
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-12-24 06:54:08
On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote:
Hi guys,
While trying to test my latest patch queue for ppc kvm, I realized
that even though the device trees got updated, the p1020 box still is
unstable. The trace below is the one I've seen the most. It only
occurs during network I/O which happens a lot on that box, since I'm
running it using NFS root.
As for configuration, I use kumar's "merge" branch from today and the
p1020rdb.dts device tree provided in that tree.
The last known good configuration I'm aware of is 3.0.
Any ideas what's going wrong here?
Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB
that should be fixed upstream now but I think did hit 3.2
Cheers,
Ben.
From: Alexander Graf <hidden> Date: 2011-12-25 10:48:35
On 24.12.2011, at 07:53, Benjamin Herrenschmidt wrote:
On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote:
quoted
Hi guys,
While trying to test my latest patch queue for ppc kvm, I realized
that even though the device trees got updated, the p1020 box still is
unstable. The trace below is the one I've seen the most. It only
occurs during network I/O which happens a lot on that box, since I'm
running it using NFS root.
As for configuration, I use kumar's "merge" branch from today and the
p1020rdb.dts device tree provided in that tree.
The last known good configuration I'm aware of is 3.0.
Any ideas what's going wrong here?
Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB
that should be fixed upstream now but I think did hit 3.2
Yup, things seem a lot more stable with SLAB now :).
Alex
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2011-12-28 05:01:34
On Sun, 2011-12-25 at 11:48 +0100, Alexander Graf wrote:
On 24.12.2011, at 07:53, Benjamin Herrenschmidt wrote:
quoted
On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote:
quoted
Hi guys,
While trying to test my latest patch queue for ppc kvm, I realized
that even though the device trees got updated, the p1020 box still is
unstable. The trace below is the one I've seen the most. It only
occurs during network I/O which happens a lot on that box, since I'm
running it using NFS root.
As for configuration, I use kumar's "merge" branch from today and the
p1020rdb.dts device tree provided in that tree.
The last known good configuration I'm aware of is 3.0.
Any ideas what's going wrong here?
Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB
that should be fixed upstream now but I think did hit 3.2
Yup, things seem a lot more stable with SLAB now :).
BTW. Fix for slub should be upstream:
42d623a8cd08eb93ab221d22cee5a62618895bbf
Cheers,
Ben.
From: Alexander Graf <hidden> Date: 2012-01-02 15:20:38
On 28.12.2011, at 06:01, Benjamin Herrenschmidt wrote:
On Sun, 2011-12-25 at 11:48 +0100, Alexander Graf wrote:
quoted
On 24.12.2011, at 07:53, Benjamin Herrenschmidt wrote:
quoted
On Fri, 2011-12-23 at 17:54 +0100, Alexander Graf wrote:
quoted
Hi guys,
While trying to test my latest patch queue for ppc kvm, I realized
that even though the device trees got updated, the p1020 box still is
unstable. The trace below is the one I've seen the most. It only
occurs during network I/O which happens a lot on that box, since I'm
running it using NFS root.
As for configuration, I use kumar's "merge" branch from today and the
p1020rdb.dts device tree provided in that tree.
The last known good configuration I'm aware of is 3.0.
Any ideas what's going wrong here?
Try SLAB instead of SLUB and let me know. It -could- be a bogon in SLUB
that should be fixed upstream now but I think did hit 3.2
Yup, things seem a lot more stable with SLAB now :).
BTW. Fix for slub should be upstream:
42d623a8cd08eb93ab221d22cee5a62618895bbf
Yup, works like a charm now again. Thanks a lot!
Alex