Michael Renner wrote: > > hiya! > > see the attached file for the resolved bug() call. my kernel spit out 185 > messages like this: > > Mar 9 17:15:13 srck@trottelkunde attempt to access beyond end of device > Mar 9 17:15:13 srck@trottelkunde 16:42: rw=0, want=0, limit=12289725 > > right before the bug(). > > this message didn't get parsed by ksymoops > > Mar 9 17:15:13 srck@trottelkunde Assertion failure in journal_start() at transaction.c:226: "handle->h_transaction->t_journal == journal" This one is a bit of a red herring. The real error is this one: > Dec 9 19:55:30 srck@trottelkunde Kernel panic: EXT3-fs panic (device ide1(22,66)): load_block_bitmap: block_group >= groups_count - block_group = 131071, groups_count = 94 Which called panic(), which called sys_sync(), which tried to sync some other filesystem while inside this filesystem's transaction. Really, panic() shouldn't be calling sys_sync(). So the question is, why is truncate trying to access such a wild blockgroup number? ext3_free_blocks() checks the block number so possibly some of the in-memory superblock information has been corrupted. Hard to say. Are you running anything unusual on the machine? Anything which could help us to understand why you get this happening, but (to my knowledge) nobody else does? Is it good quality hardware? -
