> I have this bug in ext4: > ------------[ cut here ]------------ > Kernel BUG at ffffffff802eb8cc [verbose debug info unavailable] > invalid opcode: 0000 [1] SMP > CPU 2 > Modules linked in: > Pid: 215, comm: pdflush Tainted: G W 2.6.27-rc1 #1 > RIP: 0010:[] [] jbd2_journal_dirty_metadata+0x5c/0xee > RSP: 0018:ffff88021e3a5660 EFLAGS: 00010246 > RAX: 0000000000000000 RBX: ffff88021c240040 RCX: 0000000000000004 > RDX: ffff8801eff35e00 RSI: ffff880018075930 RDI: ffff88021edf4c78 > RBP: ffff88020a667240 R08: 0000000000000000 R09: 0000000000000000 > R10: 000000000000000c R11: ffff88021e2f1800 R12: ffff880018075930 > R13: ffff88021edf4c78 R14: ffff88021d57c000 R15: ffff88021e2f1800 > FS: 00007f60fdc92740(0000) GS:ffff88021f022700(0000) knlGS:0000000000000000 > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > CR2: 00007f99dc481000 CR3: 000000021dfa0000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process pdflush (pid: 215, threadinfo ffff88021e3a4000, task > ffff88021f253c80) > Stack: ffff88021c240040 ffff88021edf4c78 ffff880018075930 ffffffff804ab7b0 > 0000000000464e73 ffffffff802dec8e ffff88021efee3f0 ffff88021c240040 > ffff88021efee3f0 ffff88021e2f1b00 ffff88021d57c400 ffffffff802e312a > Call Trace: > [] ? __ext4_journal_dirty_metadata+0x1e/0x46 > [] ? ext4_mb_mark_diskspace_used+0x375/0x3c2 > [] ? ext4_mb_new_blocks+0x19f/0x4f8 > [] ? ext4_ext_get_blocks+0xbe2/0xde9 > [] ? get_request+0x241/0x2fb > [] ? deadline_add_request+0x21/0x5d > [] ? elv_insert+0x14e/0x20e > [] ? ext4_get_blocks_wrap+0xf8/0x177 > [] ? ext4_da_get_block_write+0x86/0x10d > [] ? mpage_da_map_blocks+0x81/0x287 > [] ? mpage_bio_submit+0x22/0x26 > [] ? mpage_da_submit_io+0x121/0x136 > [] ? ext4_da_get_block_write+0x0/0x10d > [] ? __mpage_da_writepage+0x2b/0xe6 > [] ? find_get_pages_tag+0x46/0xdd > [] ? write_cache_pages+0x174/0x2be > [] ? __mpage_da_writepage+0x0/0xe6 > [] ? ext4_da_writepages+0x15f/0x1fa > [] ? find_busiest_group+0x28a/0x725 > [] ? ext4_da_get_block_write+0x0/0x10d > [] ? do_writepages+0x20/0x2d > [] ? __writeback_single_inode+0x16f/0x35e > [] ? generic_sync_sb_inodes+0x290/0x3ca > [] ? writeback_inodes+0x7d/0xcc > [] ? wb_kupdate+0x9f/0x111 > [] ? pdflush+0x122/0x1cb > [] ? wb_kupdate+0x0/0x111 > [] ? pdflush+0x0/0x1cb > [] ? kthread+0x47/0x73 > [] ? schedule_tail+0x27/0x5f > [] ? child_rip+0xa/0x11 > [] ? kthread+0x0/0x73 > [] ? child_rip+0x0/0x11 > > Code: 04 24 a9 00 00 20 00 75 f3 f0 41 0f ba 2c 24 15 19 c0 85 c0 75 e8 > 83 7d 10 00 75 19 c7 45 10 01 00 00 00 41 8b 45 08 85 c0 7f 04 <0f> 0b > eb fe ff c8 41 89 45 08 48 39 55 28 75 10 83 7d 0c 01 75 > RIP [] jbd2_journal_dirty_metadata+0x5c/0xee > RSP > ---[ end trace 4e18ceb49f50065e ]--- > Where I need post it? > Which kernel you are running into this problem? The stack looks familer, there is a known issue , journal credit reservation is not enough in the delayed allocation page writeout path. We are working on it. Mingming > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
