2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!

All of lore.kernel.org
 help / color / mirror / Atom feed

* 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 15:22 ` Alexander Beregalov
  0 siblings, 0 replies; 26+ 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] 26+ messages in thread

* 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 15:22 ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-06-01 15:22 UTC (permalink / raw)
  To: Kernel Testers List, xfs

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 ]---

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 15:22 ` Alexander Beregalov
  (?)
@ 2009-06-04  9:23 ` Dave Chinner
       [not found]   ` <20090604092330.GT16929-CJ6yYqJ1V6CgjvmRZuSThA@public.gmane.org>
  -1 siblings, 1 reply; 26+ 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] 26+ messages in thread

[parent not found: <20090604092330.GT16929-CJ6yYqJ1V6CgjvmRZuSThA@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-04  9:23 ` Dave Chinner
@ 2009-06-05  9:23       ` Alexander Beregalov
  0 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-05  9:23       ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-06-05  9:23 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Kernel Testers List, xfs

2009/6/4 Dave Chinner <david@fromorbit.com>:
> 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.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <a4423d670906050223p4e72ceaaqa1dd942a2e52d1a3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-05  9:23       ` Alexander Beregalov
@ 2009-07-01 16:21           ` Alexander Beregalov
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-07-01 16:21           ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-07-01 16:21 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Kernel Testers List, xfs

2009/6/5 Alexander Beregalov <a.beregalov@gmail.com>:
> 2009/6/4 Dave Chinner <david@fromorbit.com>:
>> 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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 15:22 ` Alexander Beregalov
@ 2009-06-01 16:09     ` Felix Blyakher
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 16:09     ` Felix Blyakher
  0 siblings, 0 replies; 26+ messages in thread
From: Felix Blyakher @ 2009-06-01 16:09 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: Kernel Testers List, xfs


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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <B5660F1A-7940-4E4A-92E8-8C0F93C274BD-sJ/iWh9BUns@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 16:09     ` Felix Blyakher
@ 2009-06-01 17:38         ` Alexander Beregalov
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 17:38         ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-06-01 17:38 UTC (permalink / raw)
  To: Felix Blyakher; +Cc: Kernel Testers List, xfs

2009/6/1 Felix Blyakher <felixb@sgi.com>:
>
> 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.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <a4423d670906011038qd809ebay22aebca5aaf271a4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 17:38         ` Alexander Beregalov
@ 2009-06-01 17:58             ` Felix Blyakher
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 17:58             ` Felix Blyakher
  0 siblings, 0 replies; 26+ messages in thread
From: Felix Blyakher @ 2009-06-01 17:58 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: Kernel Testers List, xfs

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <D7FB8214-6C2B-4D13-9B50-C53CB74885C2-sJ/iWh9BUns@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 17:58             ` Felix Blyakher
@ 2009-06-02  8:21                 ` Alexander Beregalov
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-02  8:21                 ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-06-02  8:21 UTC (permalink / raw)
  To: Felix Blyakher; +Cc: Kernel Testers List, xfs

2009/6/1 Felix Blyakher <felixb@sgi.com>:
>
> 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.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ 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
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 16:09     ` Felix Blyakher
@ 2009-06-01 17:43         ` Alexander Beregalov
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 17:43         ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-06-01 17:43 UTC (permalink / raw)
  To: Felix Blyakher; +Cc: Kernel Testers List, xfs

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.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <a4423d670906011043v52426cb9s547547479b5f885d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 17:43         ` Alexander Beregalov
@ 2009-06-01 17:53             ` Felix Blyakher
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-06-01 17:53             ` Felix Blyakher
  0 siblings, 0 replies; 26+ messages in thread
From: Felix Blyakher @ 2009-06-01 17:53 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: Kernel Testers List, xfs


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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-06-01 15:22 ` Alexander Beregalov
@ 2009-09-21  3:42     ` Eric Sandeen
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-09-21  3:42     ` Eric Sandeen
  0 siblings, 0 replies; 26+ messages in thread
From: Eric Sandeen @ 2009-09-21  3:42 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: Kernel Testers List, xfs

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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <824092896.830901246499419777.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>]

[parent not found: <824092896.830901246499419777.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
       [not found] <824092896.830901246499419777.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
@ 2009-07-02  1:52     ` Lachlan McIlroy
  0 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-07-02  1:52     ` Lachlan McIlroy
  0 siblings, 0 replies; 26+ messages in thread
From: Lachlan McIlroy @ 2009-07-02  1:52 UTC (permalink / raw)
  To: Alexander Beregalov; +Cc: Kernel Testers List, xfs

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@gmail.com> wrote:

> 2009/6/5 Alexander Beregalov <a.beregalov@gmail.com>:
> > 2009/6/4 Dave Chinner <david@fromorbit.com>:
> >> 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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

[parent not found: <584076313.830951246499556455.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>]

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
  2009-07-02  1:52     ` Lachlan McIlroy
@ 2009-07-02 10:38         ` Alexander Beregalov
  -1 siblings, 0 replies; 26+ 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] 26+ messages in thread

* Re: 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109!
@ 2009-07-02 10:38         ` Alexander Beregalov
  0 siblings, 0 replies; 26+ messages in thread
From: Alexander Beregalov @ 2009-07-02 10:38 UTC (permalink / raw)
  To: Lachlan McIlroy; +Cc: Kernel Testers List, xfs

2009/7/2 Lachlan McIlroy <lmcilroy@redhat.com>:
> 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@gmail.com> wrote:
>
>> 2009/6/5 Alexander Beregalov <a.beregalov@gmail.com>:
>> > 2009/6/4 Dave Chinner <david@fromorbit.com>:
>> >> 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@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2009-09-21  3:42 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-01 15:22 2.6.30-rc6: BUG at fs/xfs/support/debug.c:109! Alexander Beregalov
2009-06-01 15:22 ` Alexander Beregalov
2009-06-04  9:23 ` Dave Chinner
     [not found]   ` <20090604092330.GT16929-CJ6yYqJ1V6CgjvmRZuSThA@public.gmane.org>
2009-06-05  9:23     ` Alexander Beregalov
2009-06-05  9:23       ` Alexander Beregalov
     [not found]       ` <a4423d670906050223p4e72ceaaqa1dd942a2e52d1a3-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-07-01 16:21         ` Alexander Beregalov
2009-07-01 16:21           ` Alexander Beregalov
     [not found] ` <a4423d670906010822l6e8e112dl3d6f7de9e2179850-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 16:09   ` Felix Blyakher
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
2009-06-01 17:38         ` Alexander Beregalov
     [not found]         ` <a4423d670906011038qd809ebay22aebca5aaf271a4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-01 17:58           ` Felix Blyakher
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  8:21                 ` Alexander Beregalov
2009-06-02 11:32                 ` Alexander Beregalov
2009-06-01 17:43       ` 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-06-01 17:53             ` Felix Blyakher
2009-09-21  3:42   ` Eric Sandeen
2009-09-21  3:42     ` Eric Sandeen
     [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   ` Lachlan McIlroy
2009-07-02  1:52     ` Lachlan McIlroy
     [not found]     ` <584076313.830951246499556455.JavaMail.root-rwXUz/BPrj9+R5eDjrG6zsCp5Q1pQRjfhaY/URYTgi6ny3qCrzbmXA@public.gmane.org>
2009-07-02 10:38       ` Alexander Beregalov
2009-07-02 10:38         ` Alexander Beregalov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.