Re: What should to do with ASSERT failed

[Mike Gao <ygao.linux@xxxxxxxxx>]

Thanks very much for help. The kernel is pretty old, 2.6.19 but the xfs is pretty new.

the block size is 512 and use mmap for test with write and read compare. (xfstest 074).

If I ignored this ASSERT(comment out), the test will failed. I guess because some pages never written to disk.

Assertion failed: !buffer_dirty(bh), file: fs/xfs/linux-2.6/xfs_aops.c, line: 1399

BUG: failure at fs/xfs/support/debug.c:108/assfail()!

Kernel panic - not syncing: BUG!

 

EIP: 0073:[<b76f5424>] CPU: 0 Not tainted ESP: 007b:b75a6fa8 EFLAGS: 00000246

    Not tainted

EAX: 00000000 EBX: 00000e97 ECX: 00000013 EDX: 00000e97

ESI: 00000e93 EDI: 00000011 EBP: b75a6fc4 DS: 007b ES: 007b

0a7d7c94:  [<0806bd41>] show_regs+0xc5/0xca

0a7d7cc0:  [<0805a920>] panic_exit+0x25/0x3f

0a7d7cd4:  [<0807b5d5>] atomic_notifier_call_chain+0x1d/0x33

0a7d7cf4:  [<0807048f>] panic+0x4c/0xcf

0a7d7d10:  [<081724cd>] xfs_hex_dump+0x0/0x7

0a7d7d1c:  [<08168e26>] xfs_vm_writepage+0x226/0x656

0a7d7dbc:  [<0809092f>] generic_writepages+0x164/0x27b

0a7d7e4c:  [<0816926c>] xfs_vm_writepages+0x16/0x18

0a7d7e5c:  [<08090a6a>] do_writepages+0x24/0x38

0a7d7e70:  [<080bbe8b>] __writeback_single_inode+0x16d/0x2de

0a7d7ebc:  [<080bc1ba>] sync_sb_inodes+0x1be/0x25c

0a7d7ef4:  [<080bc299>] writeback_inodes+0x41/0x6c

0a7d7f08:  [<080905b5>] background_writeout+0x66/0x93

0a7d7f54:  [<0809106a>] pdflush+0xca/0x154

0a7d7f88:  [<08080a83>] kthread+0xb6/0xe6

0a7d7fb4:  [<080663ee>] run_kernel_thread+0x37/0x41

0a7d7fe0:  [<0805acee>] new_thread_handler+0x64/0x8b

0a7d7ffc:  [<a55a5a5a>] 0xa55a5a5a

On Mon, Aug 30, 2010 at 4:47 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:

Mike Gao wrote:
> xfs_vm_writepage
> {
>                /*
> * A hole may still be marked uptodate because discard_buffer
> * leaves the flag set.
> */
> if (!buffer_mapped(bh) && buffer_uptodate(bh)) {
> ASSERT(!buffer_dirty(bh));
> imap_valid = 0;
> continue;
> }
> }
>
> I met this case that buffer is marked as dirty which make assert failed.
> What does this mean and what I can do with it?

You can report it here, with more information on what load you were running,
and the full backtrace that the ASSERT generated... thanks!

And it means that we think we are in a hole, but the buffer for
that hole is marked dirty, which we did not expect ...

The change went in with this commit:

3d9b02e3c76531687ab5314e0edf266256f13c2d xfs: fix corruption case for block size < page size

which was attempting to fix a very specific file corruption case.

What kernel are you running on?

What block size are you using?  (xfs_info will tell you)

Thanks,
-Eric

> Thanks very much,
> Mike
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs