Description of Problem:
Following a large number of IO errors due to a corrupt fs, ext3 paniced with
Assertion failure in journal_forget_Rb6ebb66a() at transaction.c:1224:
kernel BUG at transaction.c:1224!
Version-Release number of selected component (if applicable):
Created attachment 85004 [details]
Kernel log of errors
Saw the same problem 3 times on 2 different servers the last 2 days.
One of them is connected to a serial console. Attaching the errors logged (note
that there's a problem with newline characters, therefore the log looks somewhat
This is RHAT 7.3, kernel 2.4.18-17.7.xsmp (2 1GHz processor).
Only in one case previous ext3 errors were logged.
I now rebooted and forced a fsck. There were unexpected inconsitencies, I had to
manually run fsck.
Any workaround for now (or should I be save for some time having now once
repaired the inconsistencies)?
Changing severity to high.
Created attachment 88963 [details]
kernel error log 1
Created attachment 88964 [details]
kernel error log 2
Hm, is this a dup of bug #71223 ?
This week another 2 servers crashed because of this.
Doesn't this happen to others, too? This is definitely a no-go for servers ...
Any chance this was fixed in the latest kernel update?
It wasn't fixed, as I haven't been able to trace down the exact code path
causing this. But recent ext3 does have a new mechanism to allow us to
downgrade the severity of assertion failures where there's a chance of
triggering the failures due to hardware corruptions or data corruptions, rather
than pure software faults, so there's an infrastructure there which will let me
relax this message from a panic later on.
patch included in U4 erratum candidate. moving to modified.
An errata has been issued which should help the problem described in this bug report.
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen
this bug report if the solution does not work for you.