[Top] [All Lists]

Re: What should to do with ASSERT failed

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: What should to do with ASSERT failed
From: Mike Gao <ygao.linux@xxxxxxxxx>
Date: Mon, 30 Aug 2010 17:56:07 -0500
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0HvOIrHPxos8m6yKi1X6XHcZhqQO/eEoDo9P5gociyA=; b=PhZ/J9Zeqh7lVxYOZAZANeORL3lYUJanvP4KAdDZwBH7lg6KevgUy3P9a5M/EmkwZf HDNY5XLC3GWI283yn7Hcb9Oe1pBc0SJ8sUGotEibaV+z/Xyr6pz4/q9C4dwtstSLEnS/ sKEKvW9z03jUaTM6NjJWOa1BM/rAYu1WwvYEU=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kHj0BtBIk6kCNlU0fAdhQbTkdppCBsguTgEnKiiwTSS8Q2FIiNQZ+GFZyJ6WylIPxI ThA2tvXTJnekfTNtErAI/lS0d4j1L6cvznTPQ4R35W538ipOxBa/ivQsLMmcXwZOqKth 9F/zoe+Agvi84a6MoPwVBEW0VFgDEnOHbkJ+U=
In-reply-to: <4C7C26E8.9070308@xxxxxxxxxxx>
References: <AANLkTin-zf0chkk68pGfwDRt03QaKmNdsP3=goDEUS+p@xxxxxxxxxxxxxx> <4C7C26E8.9070308@xxxxxxxxxxx>
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 very much,
> Mike
> ------------------------------------------------------------------------
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

<Prev in Thread] Current Thread [Next in Thread>