Bug 77839 - Assert failure in transaction.c:1224: "!jh->b_committed_data
Assert failure in transaction.c:1224: "!jh->b_committed_data
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
:
Depends On:
Blocks: 107565
  Show dependency treegraph
 
Reported: 2002-11-14 05:23 EST by Stephen Tweedie
Modified: 2006-03-10 22:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-21 21:02:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Kernel log of errors (12.51 KB, text/plain)
2002-11-14 05:24 EST, Stephen Tweedie
no flags Details
kernel error log 1 (4.33 KB, text/plain)
2002-12-28 12:06 EST, Michael Redinger
no flags Details
kernel error log 2 (3.42 KB, text/plain)
2002-12-28 12:06 EST, Michael Redinger
no flags Details

  None (edit)
Description Stephen Tweedie 2002-11-14 05:23:41 EST
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:
"!jh->b_committed_data"
kernel BUG at transaction.c:1224!

Version-Release number of selected component (if applicable):
2.4.18-14 athlon
Comment 1 Stephen Tweedie 2002-11-14 05:24:29 EST
Created attachment 85004 [details]
Kernel log of errors
Comment 2 Michael Redinger 2002-12-28 12:03:33 EST
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
strange ...).

This is RHAT 7.3, kernel 2.4.18-17.7.xsmp (2 1GHz processor).
(SMP prob?)

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.
Comment 3 Michael Redinger 2002-12-28 12:06:00 EST
Created attachment 88963 [details]
kernel error log 1
Comment 4 Michael Redinger 2002-12-28 12:06:25 EST
Created attachment 88964 [details]
kernel error log 2
Comment 5 Michael Redinger 2002-12-28 12:12:11 EST
Hm, is this a dup of bug #71223 ?
Comment 6 Michael Redinger 2003-02-07 08:02:15 EST
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?
Comment 7 Stephen Tweedie 2003-02-10 09:20:37 EST
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.
Comment 11 Jason Baron 2004-02-27 17:49:40 EST
patch included in U4 erratum candidate. moving to modified.
Comment 12 John Flanagan 2004-04-21 21:03:00 EDT
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.

http://rhn.redhat.com/errata/RHSA-2004-105.html

Note You need to log in before you can comment on or make changes to this bug.