* 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 15:22 Alexander Beregalov
[not found] ` <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-04 9:23 ` Dave Chinner
0 siblings, 2 replies; 14+ messages in thread
From: Alexander Beregalov @ 2009-06-01 15:22 UTC (permalink / raw)
To: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
Hi
Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
------------[ cut here ]------------
kernel BUG at fs/xfs/support/debug.c:109!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file: /sys/kernel/uevent_seqnum
CPU 0
Modules linked in:
Pid: 30665, comm: emerge Not tainted 2.6.30-rc6-00144-g5805977 #1 PowerEdge 1950
RIP: 0010:[<ffffffff8043abeb>] [<ffffffff8043abeb>] assfail+0x2b/0x30
RSP: 0018:ffff8800303c1b98 EFLAGS: 00010246
RAX: 0000000000000054 RBX: 0000000000000000 RCX: 0000000000000301
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff8800303c1ba8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000800000000
R13: ffff880078c0ccc0 R14: 0000000000000002 R15: ffff88007eb3f000
FS: 00007f7e92dbc6f0(0000) GS:ffff880005000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001b0a024 CR3: 0000000074cb0000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process emerge (pid: 30665, threadinfo ffff8800303c0000, task ffff88007e335e10)
Stack:
ffff8800051cefa0 00000000780d89a3 ffff8800303c1d88 ffffffff803d6bad
ffffffff804c9ad8 ffffffff814497f8 ffff880045a72000 ffff880045a72aa8
ffffffff81449800 0000000000000000 0000000000000000 00000000780d89a3
Call Trace:
[<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
[<ffffffff804c9ad8>] ? _atomic_dec_and_lock+0x88/0xb0
[<ffffffff8042ef97>] ? xfs_buf_free+0xd7/0x130
[<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80
[<ffffffff8042f114>] ? xfs_buf_rele+0x124/0x190
[<ffffffff8042df2d>] ? xfs_buf_unlock+0x3d/0x80
[<ffffffff80421e69>] ? xfs_trans_brelse+0x219/0x2e0
[<ffffffff803e445f>] ? xfs_da_brelse+0x7f/0x150
[<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
[<ffffffff802ec220>] ? filldir+0x0/0x100
[<ffffffff802ec220>] ? filldir+0x0/0x100
[<ffffffff803e975c>] xfs_readdir+0x12c/0x140
[<ffffffff802ec220>] ? filldir+0x0/0x100
[<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
[<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
[<ffffffff802ec6b6>] sys_getdents+0x96/0x110
[<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
Code: 55 89 d1 48 89 e5 48 89 f2 48 83 ec 10 48 89 fe 65 48 8b 04 25
28 00 00 00 48 89 45 f8 31 c0 48 c7 c7 38 73 83 80 e8 25 a4 29 00 <0f>
0b eb fe 90 55 48 89 e5 41 57 49 89 d7 41 56 41 55 49 89 cd
RIP [<ffffffff8043abeb>] assfail+0x2b/0x30
RSP <ffff8800303c1b98>
---[ end trace bf7e45980908c8f7 ]---
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-06-01 16:09 ` Felix Blyakher
[not found] ` <B5660F1A-7940-4E4A-92E8-8C0F93C274BD-sJ/iWh9BUns@public.gmane.org>
2009-09-21 3:42 ` Eric Sandeen
1 sibling, 1 reply; 14+ messages in thread
From: Felix Blyakher @ 2009-06-01 16:09 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
On Jun 1, 2009, at 10:22 AM, Alexander Beregalov wrote:
> Hi
>
> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
Alexander, what test triggered this assertion?
>
> ------------[ cut here ]------------
> kernel BUG at fs/xfs/support/debug.c:109!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file: /sys/kernel/uevent_seqnum
> CPU 0
> Modules linked in:
> Pid: 30665, comm: emerge Not tainted 2.6.30-rc6-00144-g5805977 #1
> PowerEdge 1950
> RIP: 0010:[<ffffffff8043abeb>] [<ffffffff8043abeb>] assfail+0x2b/0x30
> RSP: 0018:ffff8800303c1b98 EFLAGS: 00010246
> RAX: 0000000000000054 RBX: 0000000000000000 RCX: 0000000000000301
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> RBP: ffff8800303c1ba8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000800000000
> R13: ffff880078c0ccc0 R14: 0000000000000002 R15: ffff88007eb3f000
> FS: 00007f7e92dbc6f0(0000) GS:ffff880005000000(0000) knlGS:
> 0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000001b0a024 CR3: 0000000074cb0000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process emerge (pid: 30665, threadinfo ffff8800303c0000, task
> ffff88007e335e10)
> Stack:
> ffff8800051cefa0 00000000780d89a3 ffff8800303c1d88 ffffffff803d6bad
> ffffffff804c9ad8 ffffffff814497f8 ffff880045a72000 ffff880045a72aa8
> ffffffff81449800 0000000000000000 0000000000000000 00000000780d89a3
> Call Trace:
> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
xfs_bmapi() here doesn't make sense at all.
Up to this point the stack backtrace seems to be right.
Strange ...
Felix
>
> [<ffffffff804c9ad8>] ? _atomic_dec_and_lock+0x88/0xb0
> [<ffffffff8042ef97>] ? xfs_buf_free+0xd7/0x130
> [<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80
> [<ffffffff8042f114>] ? xfs_buf_rele+0x124/0x190
> [<ffffffff8042df2d>] ? xfs_buf_unlock+0x3d/0x80
> [<ffffffff80421e69>] ? xfs_trans_brelse+0x219/0x2e0
> [<ffffffff803e445f>] ? xfs_da_brelse+0x7f/0x150
> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
> [<ffffffff802ec220>] ? filldir+0x0/0x100
> [<ffffffff802ec220>] ? filldir+0x0/0x100
> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
> [<ffffffff802ec220>] ? filldir+0x0/0x100
> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
> Code: 55 89 d1 48 89 e5 48 89 f2 48 83 ec 10 48 89 fe 65 48 8b 04 25
> 28 00 00 00 48 89 45 f8 31 c0 48 c7 c7 38 73 83 80 e8 25 a4 29 00 <0f>
> 0b eb fe 90 55 48 89 e5 41 57 49 89 d7 41 56 41 55 49 89 cd
> RIP [<ffffffff8043abeb>] assfail+0x2b/0x30
> RSP <ffff8800303c1b98>
> ---[ end trace bf7e45980908c8f7 ]---
>
> _______________________________________________
> xfs mailing list
> xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
> http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <B5660F1A-7940-4E4A-92E8-8C0F93C274BD-sJ/iWh9BUns@public.gmane.org>
@ 2009-06-01 17:38 ` Alexander Beregalov
[not found] ` <a4423d670906011038qd809ebay22aebca5aaf271a4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 17:43 ` Alexander Beregalov
1 sibling, 1 reply; 14+ messages in thread
From: Alexander Beregalov @ 2009-06-01 17:38 UTC (permalink / raw)
To: Felix Blyakher; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
2009/6/1 Felix Blyakher <felixb-sJ/iWh9BUns@public.gmane.org>:
>
> On Jun 1, 2009, at 10:22 AM, Alexander Beregalov wrote:
>
>> Hi
>>
>> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
>
> Alexander, what test triggered this assertion?
>
>>
>> ------------[ cut here ]------------
>> kernel BUG at fs/xfs/support/debug.c:109!
>> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> last sysfs file: /sys/kernel/uevent_seqnum
>> CPU 0
>> Modules linked in:
>> Pid: 30665, comm: emerge Not tainted 2.6.30-rc6-00144-g5805977 #1
>> PowerEdge 1950
>> RIP: 0010:[<ffffffff8043abeb>] [<ffffffff8043abeb>] assfail+0x2b/0x30
>> RSP: 0018:ffff8800303c1b98 EFLAGS: 00010246
>> RAX: 0000000000000054 RBX: 0000000000000000 RCX: 0000000000000301
>> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
>> RBP: ffff8800303c1ba8 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000800000000
>> R13: ffff880078c0ccc0 R14: 0000000000000002 R15: ffff88007eb3f000
>> FS: 00007f7e92dbc6f0(0000) GS:ffff880005000000(0000)
>> knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 0000000001b0a024 CR3: 0000000074cb0000 CR4: 00000000000006e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process emerge (pid: 30665, threadinfo ffff8800303c0000, task
>> ffff88007e335e10)
>> Stack:
>> ffff8800051cefa0 00000000780d89a3 ffff8800303c1d88 ffffffff803d6bad
>> ffffffff804c9ad8 ffffffff814497f8 ffff880045a72000 ffff880045a72aa8
>> ffffffff81449800 0000000000000000 0000000000000000 00000000780d89a3
>> Call Trace:
>> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
>
> xfs_bmapi() here doesn't make sense at all.
> Up to this point the stack backtrace seems to be right.
> Strange ...
It was Gentoo's `emerge --metadata`. It reads many small files (ebuilds).
I am sure it cannot be easily reproduced.
It runs fine everyday. I do not have a testcase.
I can try to run it forever in loop if you need.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <B5660F1A-7940-4E4A-92E8-8C0F93C274BD-sJ/iWh9BUns@public.gmane.org>
2009-06-01 17:38 ` Alexander Beregalov
@ 2009-06-01 17:43 ` Alexander Beregalov
[not found] ` <a4423d670906011043v52426cb9s547547479b5f885d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
1 sibling, 1 reply; 14+ messages in thread
From: Alexander Beregalov @ 2009-06-01 17:43 UTC (permalink / raw)
To: Felix Blyakher; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
By the way,
Felix, your last pull request was a month ago.
Final release of 2.6.30 is coming soon, could you please send the
fixes to Linus?
Just in case you do not read LKML.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <a4423d670906011043v52426cb9s547547479b5f885d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-06-01 17:53 ` Felix Blyakher
0 siblings, 0 replies; 14+ messages in thread
From: Felix Blyakher @ 2009-06-01 17:53 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
On Jun 1, 2009, at 12:43 PM, Alexander Beregalov wrote:
> By the way,
> Felix, your last pull request was a month ago.
> Final release of 2.6.30 is coming soon, could you please send the
> fixes to Linus?
>
> Just in case you do not read LKML.
Yes, I do. And it is on the top of my todo list today.
Thanks, for heads up, though.
Felix
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <a4423d670906011038qd809ebay22aebca5aaf271a4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-06-01 17:58 ` Felix Blyakher
[not found] ` <D7FB8214-6C2B-4D13-9B50-C53CB74885C2-sJ/iWh9BUns@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: Felix Blyakher @ 2009-06-01 17:58 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
On Jun 1, 2009, at 12:38 PM, Alexander Beregalov wrote:
> It was Gentoo's `emerge --metadata`. It reads many small files
> (ebuilds).
> I am sure it cannot be easily reproduced.
Right. Otherwise many more people would've reported it.
> It runs fine everyday. I do not have a testcase.
> I can try to run it forever in loop if you need.
Yes, that will be good.
The problem is that the traces are confusing. From one
side readdir stack makes sense based on your description
of the load, but OTOH the panic is from xfs_bmapi(), which
doesn't fit in that backtrace at all. It seems like
backtrace is from the concurrently running different thread.
Don't have good idea for this bug atm.
Felix
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <D7FB8214-6C2B-4D13-9B50-C53CB74885C2-sJ/iWh9BUns@public.gmane.org>
@ 2009-06-02 8:21 ` Alexander Beregalov
2009-06-02 11:32 ` Alexander Beregalov
0 siblings, 1 reply; 14+ messages in thread
From: Alexander Beregalov @ 2009-06-02 8:21 UTC (permalink / raw)
To: Felix Blyakher; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
2009/6/1 Felix Blyakher <felixb-sJ/iWh9BUns@public.gmane.org>:
>
> On Jun 1, 2009, at 12:38 PM, Alexander Beregalov wrote:
>
>> It was Gentoo's `emerge --metadata`. It reads many small files (ebuilds).
>> I am sure it cannot be easily reproduced.
>
> Right. Otherwise many more people would've reported it.
>
>> It runs fine everyday. I do not have a testcase.
>> I can try to run it forever in loop if you need.
>
> Yes, that will be good.
> The problem is that the traces are confusing. From one
> side readdir stack makes sense based on your description
> of the load, but OTOH the panic is from xfs_bmapi(), which
> doesn't fit in that backtrace at all. It seems like
> backtrace is from the concurrently running different thread.
> Don't have good idea for this bug atm.
The host is still running, SysRq-W shows two precesses with the same
stacktraces.
SysRq : Show Blocked State
task PC stack pid father
emerge D 0000000000000000 3856 8399 8387
ffff880078da7b48 0000000000000046 ffff8800074b4b40 ffff880078da7af4
0000000000000001 000000000000d948 00000000001d2000 0000000000000001
ffff8800074b4b40 ffff88007f4725a0 ffff8800074b4eb8 0000000100000246
Call Trace:
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff806d707d>] __mutex_lock_common+0x16d/0x4f0
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff80280eb0>] ? trace_hardirqs_on+0x20/0x40
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff806d7528>] mutex_lock_nested+0x48/0x70
[<ffffffff802e7328>] do_lookup+0xd8/0x270
[<ffffffff802e7776>] __link_path_walk+0x2b6/0xf00
[<ffffffff802e884c>] ? do_path_lookup+0xec/0x200
[<ffffffff802e884c>] ? do_path_lookup+0xec/0x200
[<ffffffff802e863e>] path_walk+0x7e/0x100
[<ffffffff802e8816>] do_path_lookup+0xb6/0x200
[<ffffffff802e9bd8>] do_filp_open+0xf8/0x9e0
[<ffffffff802f6199>] ? alloc_fd+0x49/0x170
[<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80
[<ffffffff802f6289>] ? alloc_fd+0x139/0x170
[<ffffffff802d7f6b>] do_sys_open+0x9b/0x130
[<ffffffff802d806e>] sys_open+0x2e/0x50
[<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
emerge D 0000000000000000 3280 1643 1901
ffff88000f43bb48 0000000000000046 ffff88002dc33870 ffff88000f43baf4
0000000000000001 000000000000d948 00000000001d2000 0000000000000003
ffff88002dc33870 ffff88007ea30000 ffff88002dc33be8 0000000300000246
Call Trace:
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff806d707d>] __mutex_lock_common+0x16d/0x4f0
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff80280eb0>] ? trace_hardirqs_on+0x20/0x40
[<ffffffff802e7328>] ? do_lookup+0xd8/0x270
[<ffffffff806d7528>] mutex_lock_nested+0x48/0x70
[<ffffffff802e7328>] do_lookup+0xd8/0x270
[<ffffffff802e7776>] __link_path_walk+0x2b6/0xf00
[<ffffffff802e884c>] ? do_path_lookup+0xec/0x200
[<ffffffff802e884c>] ? do_path_lookup+0xec/0x200
[<ffffffff802e863e>] path_walk+0x7e/0x100
[<ffffffff802e8816>] do_path_lookup+0xb6/0x200
[<ffffffff802e9bd8>] do_filp_open+0xf8/0x9e0
[<ffffffff802f6199>] ? alloc_fd+0x49/0x170
[<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80
[<ffffffff802f6289>] ? alloc_fd+0x139/0x170
[<ffffffff802d7f6b>] do_sys_open+0x9b/0x130
[<ffffffff802d806e>] sys_open+0x2e/0x50
[<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
I will try to reproduce it.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
2009-06-02 8:21 ` Alexander Beregalov
@ 2009-06-02 11:32 ` Alexander Beregalov
0 siblings, 0 replies; 14+ messages in thread
From: Alexander Beregalov @ 2009-06-02 11:32 UTC (permalink / raw)
To: Felix Blyakher; +Cc: Kernel Testers List, xfs
Again similar trace:
Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
------------[ cut here ]------------
kernel BUG at fs/xfs/support/debug.c:109!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file: /sys/kernel/uevent_seqnum
CPU 0
Modules linked in:
Pid: 1988, comm: emerge Not tainted 2.6.30-rc7-00227-gd9244b5 #66 PowerEdge 1950
RIP: 0010:[<ffffffff8043ac1b>] [<ffffffff8043ac1b>] assfail+0x2b/0x30
RSP: 0018:ffff88006db6bb98 EFLAGS: 00010246
RAX: 0000000000000054 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff880077336558 RDI: 0000000010000000
RBP: ffff88006db6bba8 R08: ffff880077335e10 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000800000000
R13: ffff8800581f2980 R14: 0000000000000002 R15: ffff88007eb87000
FS: 00007f63e31586f0(0000) GS:ffff880005000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001d04024 CR3: 000000005a70e000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process emerge (pid: 1988, threadinfo ffff88006db6a000, task ffff880077335e10)
Stack:
ffff88006db6bbd8 00000000b772307d ffff88006db6bd88 ffffffff803d6bdd
ffff880077335e10 ffffffff802d429b ffff880050450480 ffff88007e32e800
ffff88006db6bc08 ffffffff80280e6d 0000000000000000 00000000b772307d
Call Trace:
[<ffffffff803d6bdd>] xfs_bmapi+0xad/0x1ad0
[<ffffffff802d429b>] ? kmem_cache_free+0xbb/0x140
[<ffffffff80280e6d>] ? trace_hardirqs_on_caller+0x17d/0x1e0
[<ffffffff8042efc7>] ? xfs_buf_free+0xd7/0x130
[<ffffffff806d994f>] ? _spin_unlock+0x3f/0x80
[<ffffffff8042f144>] ? xfs_buf_rele+0x124/0x190
[<ffffffff8042df5d>] ? xfs_buf_unlock+0x3d/0x80
[<ffffffff80421e99>] ? xfs_trans_brelse+0x219/0x2e0
[<ffffffff803e448f>] ? xfs_da_brelse+0x7f/0x150
[<ffffffff803ee5f0>] xfs_dir2_leaf_getdents+0x640/0x7b0
[<ffffffff802ec270>] ? filldir+0x0/0x100
[<ffffffff802ec270>] ? filldir+0x0/0x100
[<ffffffff803e978c>] xfs_readdir+0x12c/0x140
[<ffffffff802ec270>] ? filldir+0x0/0x100
[<ffffffff80430b87>] xfs_file_readdir+0x47/0x70
[<ffffffff802ec550>] vfs_readdir+0xd0/0xf0
[<ffffffff802ec706>] sys_getdents+0x96/0x110
[<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
Code: 55 89 d1 48 89 e5 48 89 f2 48 83 ec 10 48 89 fe 65 48 8b 04 25
28 00 00 00 48 89 45 f8 31 c0 48 c7 c7 78 73 83 80 e8 c5 a4 29 00 <0f>
0b eb fe 90 55 48 89 e5 41 57 49 89 d7 41 56 41 55 49 89 cd
RIP [<ffffffff8043ac1b>] assfail+0x2b/0x30
RSP <ffff88006db6bb98>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
2009-06-01 15:22 Alexander Beregalov
[not found] ` <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-06-04 9:23 ` Dave Chinner
[not found] ` <20090604092330.GT16929-CJ6yYqJ1V6CgjvmRZuSThA@public.gmane.org>
1 sibling, 1 reply; 14+ messages in thread
From: Dave Chinner @ 2009-06-04 9:23 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: Kernel Testers List, xfs
On Mon, Jun 01, 2009 at 07:22:56PM +0400, Alexander Beregalov wrote:
> Hi
>
> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
.....
> Call Trace:
> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
I'd say this indicates a corrupted directory. Can you run
'xfs_repair -n' over the filesystem and see if it finds a bad
directory?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <20090604092330.GT16929-CJ6yYqJ1V6CgjvmRZuSThA@public.gmane.org>
@ 2009-06-05 9:23 ` Alexander Beregalov
[not found] ` <a4423d670906050223p4e72ceaaqa1dd942a2e52d1a3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: Alexander Beregalov @ 2009-06-05 9:23 UTC (permalink / raw)
To: Dave Chinner; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
2009/6/4 Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>:
> On Mon, Jun 01, 2009 at 07:22:56PM +0400, Alexander Beregalov wrote:
>> Hi
>>
>> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
> .....
>> Call Trace:
>> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
>> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
>> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
>> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
>> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
>> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
>> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
>
> I'd say this indicates a corrupted directory. Can you run
> 'xfs_repair -n' over the filesystem and see if it finds a bad
> directory?
Hi Dave
It is a rootfs. xfs_repair found and fixed all errors, but after
reboot the problem still persists (but at another stage of running
`emerge`).
localhost ~ # echo s > /proc/sysrq-trigger
localhost ~ # echo s > /proc/sysrq-trigger
localhost ~ # echo u > /proc/sysrq-trigger
localhost ~ # xfs_repair -nd /dev/sda2
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 4
- agno = 3
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <a4423d670906050223p4e72ceaaqa1dd942a2e52d1a3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-07-01 16:21 ` Alexander Beregalov
0 siblings, 0 replies; 14+ messages in thread
From: Alexander Beregalov @ 2009-07-01 16:21 UTC (permalink / raw)
To: Dave Chinner; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
2009/6/5 Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2009/6/4 Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>:
>> On Mon, Jun 01, 2009 at 07:22:56PM +0400, Alexander Beregalov wrote:
>>> Hi
>>>
>>> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
>> .....
>>> Call Trace:
>>> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
>>> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
>>> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
>>> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
>>> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
>>> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
>>> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
>>
>> I'd say this indicates a corrupted directory. Can you run
>> 'xfs_repair -n' over the filesystem and see if it finds a bad
>> directory?
Still cannot fix the filesystem. After repairing all corruptions from
LiveCD it still fails on the same workload.
Do you need metadump or anything else?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <824092896.830901246499419777.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
@ 2009-07-02 1:52 ` Lachlan McIlroy
[not found] ` <584076313.830951246499556455.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
0 siblings, 1 reply; 14+ messages in thread
From: Lachlan McIlroy @ 2009-07-02 1:52 UTC (permalink / raw)
To: Alexander Beregalov
Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ, Dave Chinner
Alexander,
Are you running with this fix?
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=commitdiff;h=d415867e0abc35e3b2f0d4196e98c339d6fe29a2
I've seen this assertion before and the above patch fixed it
for me. Hmmm, looks like you're running a recent kernel so
you should have this fix - maybe the fix wasn't quite right.
Lachlan
----- "Alexander Beregalov" <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2009/6/5 Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> > 2009/6/4 Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>:
> >> On Mon, Jun 01, 2009 at 07:22:56PM +0400, Alexander Beregalov
> wrote:
> >>> Hi
> >>>
> >>> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
> >> .....
> >>> Call Trace:
> >>> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
> >>> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
> >>> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
> >>> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
> >>> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
> >>> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
> >>> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
> >>
> >> I'd say this indicates a corrupted directory. Can you run
> >> 'xfs_repair -n' over the filesystem and see if it finds a bad
> >> directory?
>
> Still cannot fix the filesystem. After repairing all corruptions from
> LiveCD it still fails on the same workload.
>
> Do you need metadump or anything else?
>
> _______________________________________________
> xfs mailing list
> xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
> http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <584076313.830951246499556455.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
@ 2009-07-02 10:38 ` Alexander Beregalov
0 siblings, 0 replies; 14+ messages in thread
From: Alexander Beregalov @ 2009-07-02 10:38 UTC (permalink / raw)
To: Lachlan McIlroy
Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ, Dave Chinner
2009/7/2 Lachlan McIlroy <lmcilroy-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>:
> Alexander,
>
> Are you running with this fix?
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=commitdiff;h=d415867e0abc35e3b2f0d4196e98c339d6fe29a2
Yes, I use 2.6.31-rc1-git and it contains this fix.
>
> I've seen this assertion before and the above patch fixed it
> for me. Hmmm, looks like you're running a recent kernel so
> you should have this fix - maybe the fix wasn't quite right.
>
> Lachlan
>
>
> ----- "Alexander Beregalov" <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> 2009/6/5 Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> > 2009/6/4 Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>:
>> >> On Mon, Jun 01, 2009 at 07:22:56PM +0400, Alexander Beregalov
>> wrote:
>> >>> Hi
>> >>>
>> >>> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
>> >> .....
>> >>> Call Trace:
>> >>> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
>> >>> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
>> >>> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
>> >>> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
>> >>> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
>> >>> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
>> >>> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
>> >>
>> >> I'd say this indicates a corrupted directory. Can you run
>> >> 'xfs_repair -n' over the filesystem and see if it finds a bad
>> >> directory?
>>
>> Still cannot fix the filesystem. After repairing all corruptions from
>> LiveCD it still fails on the same workload.
>>
>> Do you need metadump or anything else?
>>
>> _______________________________________________
>> xfs mailing list
>> xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
>> http://oss.sgi.com/mailman/listinfo/xfs
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
[not found] ` <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 16:09 ` Felix Blyakher
@ 2009-09-21 3:42 ` Eric Sandeen
1 sibling, 0 replies; 14+ messages in thread
From: Eric Sandeen @ 2009-09-21 3:42 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: Kernel Testers List, xfs-VZNHf3L845pBDgjK7y7TUQ
Alexander Beregalov wrote:
> Hi
>
> Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
FWIW the same thing was just reported in oss bugzilla:
http://oss.sgi.com/bugzilla/show_bug.cgi?id=850
same backtrace more or less, and this time during install, so if it's
corruption, it's actually getting corrupted during the install, so
should have a testcase in there somewhere ...
-Eric
> ------------[ cut here ]------------
> kernel BUG at fs/xfs/support/debug.c:109!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> last sysfs file: /sys/kernel/uevent_seqnum
> CPU 0
> Modules linked in:
> Pid: 30665, comm: emerge Not tainted 2.6.30-rc6-00144-g5805977 #1 PowerEdge 1950
> RIP: 0010:[<ffffffff8043abeb>] [<ffffffff8043abeb>] assfail+0x2b/0x30
> RSP: 0018:ffff8800303c1b98 EFLAGS: 00010246
> RAX: 0000000000000054 RBX: 0000000000000000 RCX: 0000000000000301
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> RBP: ffff8800303c1ba8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000800000000
> R13: ffff880078c0ccc0 R14: 0000000000000002 R15: ffff88007eb3f000
> FS: 00007f7e92dbc6f0(0000) GS:ffff880005000000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000001b0a024 CR3: 0000000074cb0000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process emerge (pid: 30665, threadinfo ffff8800303c0000, task ffff88007e335e10)
> Stack:
> ffff8800051cefa0 00000000780d89a3 ffff8800303c1d88 ffffffff803d6bad
> ffffffff804c9ad8 ffffffff814497f8 ffff880045a72000 ffff880045a72aa8
> ffffffff81449800 0000000000000000 0000000000000000 00000000780d89a3
> Call Trace:
> [<ffffffff803d6bad>] xfs_bmapi+0xad/0x1ad0
> [<ffffffff804c9ad8>] ? _atomic_dec_and_lock+0x88/0xb0
> [<ffffffff8042ef97>] ? xfs_buf_free+0xd7/0x130
> [<ffffffff806d987f>] ? _spin_unlock+0x3f/0x80
> [<ffffffff8042f114>] ? xfs_buf_rele+0x124/0x190
> [<ffffffff8042df2d>] ? xfs_buf_unlock+0x3d/0x80
> [<ffffffff80421e69>] ? xfs_trans_brelse+0x219/0x2e0
> [<ffffffff803e445f>] ? xfs_da_brelse+0x7f/0x150
> [<ffffffff803ee5c0>] xfs_dir2_leaf_getdents+0x640/0x7b0
> [<ffffffff802ec220>] ? filldir+0x0/0x100
> [<ffffffff802ec220>] ? filldir+0x0/0x100
> [<ffffffff803e975c>] xfs_readdir+0x12c/0x140
> [<ffffffff802ec220>] ? filldir+0x0/0x100
> [<ffffffff80430b57>] xfs_file_readdir+0x47/0x70
> [<ffffffff802ec500>] vfs_readdir+0xd0/0xf0
> [<ffffffff802ec6b6>] sys_getdents+0x96/0x110
> [<ffffffff8020ba6b>] system_call_fastpath+0x16/0x1b
> Code: 55 89 d1 48 89 e5 48 89 f2 48 83 ec 10 48 89 fe 65 48 8b 04 25
> 28 00 00 00 48 89 45 f8 31 c0 48 c7 c7 38 73 83 80 e8 25 a4 29 00 <0f>
> 0b eb fe 90 55 48 89 e5 41 57 49 89 d7 41 56 41 55 49 89 cd
> RIP [<ffffffff8043abeb>] assfail+0x2b/0x30
> RSP <ffff8800303c1b98>
> ---[ end trace bf7e45980908c8f7 ]---
>
> _______________________________________________
> xfs mailing list
> xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org
> http://oss.sgi.com/mailman/listinfo/xfs
>
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-09-21 3:42 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <824092896.830901246499419777.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
[not found] ` <824092896.830901246499419777.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
2009-07-02 1:52 ` 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109! Lachlan McIlroy
[not found] ` <584076313.830951246499556455.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
2009-07-02 10:38 ` Alexander Beregalov
2009-06-01 15:22 Alexander Beregalov
[not found] ` <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 16:09 ` Felix Blyakher
[not found] ` <B5660F1A-7940-4E4A-92E8-8C0F93C274BD-sJ/iWh9BUns@public.gmane.org>
2009-06-01 17:38 ` Alexander Beregalov
[not found] ` <a4423d670906011038qd809ebay22aebca5aaf271a4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 17:58 ` Felix Blyakher
[not found] ` <D7FB8214-6C2B-4D13-9B50-C53CB74885C2-sJ/iWh9BUns@public.gmane.org>
2009-06-02 8:21 ` Alexander Beregalov
2009-06-02 11:32 ` Alexander Beregalov
2009-06-01 17:43 ` Alexander Beregalov
[not found] ` <a4423d670906011043v52426cb9s547547479b5f885d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 17:53 ` Felix Blyakher
2009-09-21 3:42 ` Eric Sandeen
2009-06-04 9:23 ` Dave Chinner
[not found] ` <20090604092330.GT16929-CJ6yYqJ1V6CgjvmRZuSThA@public.gmane.org>
2009-06-05 9:23 ` Alexander Beregalov
[not found] ` <a4423d670906050223p4e72ceaaqa1dd942a2e52d1a3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-01 16:21 ` Alexander Beregalov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).