Re: latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)
From: Vegard Nossum
Date: Fri Jul 18 2008 - 04:44:01 EST
On Fri, Jul 18, 2008 at 10:29 AM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote:
> BUG: unable to handle kernel paging request at c08845af
> IP: [<c02f9122>] release_metapage+0x32/0x1c0
Hi,
I am still unable to see the "already zero" message. I'll post this as
well because it looks completely different:
------------[ cut here ]------------
WARNING: at kernel/mutex.c:134 mutex_lock_nested+0x2d4/0x320()
Pid: 5335, comm: cp Not tainted 2.6.26-03415-gdf3030b #45
[<c0135b6f>] warn_on_slowpath+0x4f/0xa0
[<c015b6e9>] ? __lock_acquire+0x2c9/0x1110
[<c015906b>] ? trace_hardirqs_off+0xb/0x10
[<c015ab70>] ? mark_held_locks+0x40/0x80
[<c015addb>] ? trace_hardirqs_on+0xb/0x10
[<c015ad76>] ? trace_hardirqs_on_caller+0x116/0x170
[<c0748da4>] mutex_lock_nested+0x2d4/0x320
[<c02eb38b>] ? diAlloc+0x28b/0x680
[<c02eb38b>] diAlloc+0x28b/0x680
[<c074a6d7>] ? _spin_unlock+0x27/0x50
[<c02f7bc9>] ialloc+0x49/0x320
[<c02dffa7>] jfs_mkdir+0x77/0x3c0
[<c015906b>] ? trace_hardirqs_off+0xb/0x10
[<c015addb>] ? trace_hardirqs_on+0xb/0x10
[<c015906b>] ? trace_hardirqs_off+0xb/0x10
[<c03030b0>] ? jfs_permission+0x0/0x10
[<c02dff30>] ? jfs_mkdir+0x0/0x3c0
[<c01acb27>] vfs_mkdir+0xb7/0x130
[<c074a6d7>] ? _spin_unlock+0x27/0x50
[<c01af4b8>] sys_mkdirat+0xe8/0x100
[<c0430948>] ? trace_hardirqs_on_thunk+0xc/0x10
[<c0120140>] ? do_page_fault+0x0/0x880
[<c01af4f0>] sys_mkdir+0x20/0x30
[<c010407f>] sysenter_past_esp+0x78/0xc5
=======================
---[ end trace 010115e08457f5d6 ]---
BUG: unable to handle kernel paging request at fff7f7f7
IP: [<c04401b0>] __list_add+0x10/0x70
*pde = 00007067 *pte = 00000000
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Pid: 5335, comm: cp Tainted: G W (2.6.26-03415-gdf3030b #45)
EIP: 0060:[<c04401b0>] EFLAGS: 00210046 CPU: 1
EIP is at __list_add+0x10/0x70
EAX: fff7f7f7 EBX: e5b77d88 ECX: e5f68a70 EDX: fff7f7f7
ESI: e5f68a50 EDI: 00200246 EBP: e5b77d60 ESP: e5b77d4c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process cp (pid: 5335, ti=e5b76000 task=f69acfb0 task.ti=e5b76000)
Stack: c02eb38b e5f68a84 e5f68a4c e5f68a50 e5f68a4c e5b77da8 c0748baa 00000000
00000002 c02eb38b c02eb38b 00000000 f69acfb0 e5f68a70 e5f68a84 e5b77d88
e5b77d88 11111111 e5f68a4c e5b77d88 de0a9d8c de0a82d4 de0a9d8c e5b77e0c
Call Trace:
[<c02eb38b>] ? diAlloc+0x28b/0x680
[<c0748baa>] ? mutex_lock_nested+0xda/0x320
[<c02eb38b>] ? diAlloc+0x28b/0x680
[<c02eb38b>] ? diAlloc+0x28b/0x680
[<c02eb38b>] ? diAlloc+0x28b/0x680
[<c074a6d7>] ? _spin_unlock+0x27/0x50
[<c02f7bc9>] ? ialloc+0x49/0x320
[<c02dffa7>] ? jfs_mkdir+0x77/0x3c0
[<c015906b>] ? trace_hardirqs_off+0xb/0x10
[<c015addb>] ? trace_hardirqs_on+0xb/0x10
[<c015906b>] ? trace_hardirqs_off+0xb/0x10
[<c03030b0>] ? jfs_permission+0x0/0x10
[<c02dff30>] ? jfs_mkdir+0x0/0x3c0
[<c01acb27>] ? vfs_mkdir+0xb7/0x130
[<c074a6d7>] ? _spin_unlock+0x27/0x50
[<c01af4b8>] ? sys_mkdirat+0xe8/0x100
[<c0430948>] ? trace_hardirqs_on_thunk+0xc/0x10
[<c0120140>] ? do_page_fault+0x0/0x880
[<c01af4f0>] ? sys_mkdir+0x20/0x30
[<c010407f>] ? sysenter_past_esp+0x78/0xc5
=======================
Code: 54 24 04 c7 04 24 80 59 88 c0 e8 20 bf 30 00 0f 0b eb fe 90 8d
b4 26 00 00 00 00 55 89 e5 53 89 c3 83 ec 10 8b 41 04 39 d0 75 16 <8b>
10 39 ca 75 32 89 5a 04 89 13 89 43 04 89 18 83 c4 10 5b 5d
EIP: [<c04401b0>] __list_add+0x10/0x70 SS:ESP 0068:e5b77d4c
Kernel panic - not syncing: Fatal exception
(Followed by similar smp_call_function warnings as before.)
But I think I'll stop testing now until we have another patch.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/