2009/1/12 Alexander Beregalov <a.beregalov@xxxxxxxxx>: >> Hmmmm - this might be getting closer to the source of the bug. >> It's being detecting when reading in the buffer to do a left shift >> now, not during the delete of a record. >> >> I'd suggest that you treat this as the same failure and continue >> the bisect to try to find when no problems show up at all. > > 687b890a184fef263ebb773926e1f4aa69240d01 is the first bad commit. > Does it make sense? > It can not be reverted from the current git to be sure it is guilty > due to merge conflicts. > No! I got similar bug message on 9eaead5 two hours later. 9eaead5 is previous to 687b890. 9eaead5 might be the first bad commit or earlier one. It seems I need to test the kernel for few hours before mark it good. Filesystem "sdb1": XFS internal error xfs_btree_check_lblock at line 200 of file fs/xfs/xfs_btree.c. Caller 0xc024c132 Pid: 2481, comm: pdflush Not tainted 2.6.28-rc2-00208-g9eaead5 #4 Call Trace: [<c025f212>] ? xfs_cmn_err+0x32/0x60 [<c025f28e>] xfs_error_report+0x4e/0x50 [<c024c132>] ? xfs_btree_check_block+0x32/0x40 [<c024bfbd>] xfs_btree_check_lblock+0x4d/0x190 [<c024c132>] ? xfs_btree_check_block+0x32/0x40 <...> Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_private.b.allocated == 0, file: fs/xfs/xfs_btree.c, line: 348 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:81! invalid opcode: 0000 [#1] PREEMPT DEBUG_PAGEALLOC last sysfs file: /sys/devices/platform/w83627hf.656/name Modules linked in: w83627hf hwmon_vid i2c_nforce2 Pid: 2481, comm: pdflush Not tainted (2.6.28-rc2-00208-g9eaead5 #4) EIP: 0060:[<c029d6ee>] EFLAGS: 00010282 CPU: 0 EIP is at assfail+0x1e/0x30 <..> Call Trace: [<c024bcd0>] ? xfs_btree_del_cursor+0x60/0x80 [<c02445be>] ? xfs_bmapi+0x48e/0x1c90 [<c014b7a5>] ? __lock_acquire+0x2c5/0x1000 [<c014b7a5>] ? __lock_acquire+0x2c5/0x1000 [<c0270cd4>] ? xfs_iomap_write_allocate+0x254/0x450 -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html