On Sun, Jan 11, 2009 at 01:14:59AM +0300, Alexander Beregalov wrote: > On Sat, Jan 10, 2009 at 10:28:03AM -0500, Christoph Hellwig wrote: > > On Sat, Jan 10, 2009 at 06:09:05PM +0300, Alexander Beregalov wrote: > > > > That would be odd as 7f7c39ccb6045cf1fd5e7684a484c445291b44d4 only > > > > changes the tracing code which currently isn't enabled. Or we > > > > get some sort of miscompilation due slightly different noop > > > > macros. > > > I meant the first bad commit is between these two commits. All of them > > > fail to compile as is, > > > I added xfs_btree_trace.h manually to compile it, I got different bugs > > > on these commits, > > > but I am not sure if they are really different. Like this: > > > > Ah crap. When lachlan checked in the btree tracing he forgot to > > add that header and it only got in after that. Can you bisect > > further between those commit by just using xfs_btree_trce.h from > > a newer version? It hasn't had a single change yet since it was > > commited. > > > > This is quite important as all changes between these two revisions > > are quite large and deal with consolidating the btree code. > > > > I can not reproduce it now, I get the following message instead: > I will try to repair the filesystem. > > Filesystem "sdb1": XFS internal error xfs_btree_check_lblock at line 86 of file fs/xfs/xfs_btree.c. Caller 0xc024af42 > > Pid: 251, comm: pdflush Not tainted 2.6.28-09244-g3d14bda #4 > Call Trace: > [<c0261462>] ? xfs_cmn_err+0x32/0x60 > [<c02614de>] xfs_error_report+0x4e/0x50 > [<c024af42>] ? xfs_btree_check_block+0x32/0x40 > [<c024adcd>] xfs_btree_check_lblock+0x4d/0x190 > [<c024af42>] ? xfs_btree_check_block+0x32/0x40 > [<c0286bf0>] ? xfs_trans_read_buf+0x470/0x530 > [<c024af42>] xfs_btree_check_block+0x32/0x40 > [<c024b124>] xfs_btree_read_buf_block+0xe4/0x100 > [<c024ce2d>] xfs_btree_lshift+0xbd/0x580 > [<c026157b>] ? xfs_error_test+0x1b/0xc0 > [<c024f29b>] xfs_btree_make_block_unfull+0x5b/0x140 > [<c0248972>] ? xfs_bmbt_recs_inorder+0x32/0x70 > [<c024f9be>] xfs_btree_insrec+0x63e/0x6c0 > [<c024faa9>] xfs_btree_insert+0x69/0x190 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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
