Bug 77839 - Assert failure in transaction.c:1224: "!jh->b_committed_data
Summary: Assert failure in transaction.c:1224: "!jh->b_committed_data
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
Depends On:
Blocks: 107565
TreeView+ depends on / blocked
Reported: 2002-11-14 10:23 UTC by Stephen Tweedie
Modified: 2006-03-11 03:57 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-04-22 01:02:59 UTC

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

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:017 0 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 1 2004-01-13 05:00:00 UTC
Red Hat Product Errata RHSA-2004:105 0 normal SHIPPED_LIVE Moderate: kernel security update 2004-04-21 04:00:00 UTC

Description Stephen Tweedie 2002-11-14 10:23:41 UTC
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):
2.4.18-14 athlon

Comment 1 Stephen Tweedie 2002-11-14 10:24:29 UTC
Created attachment 85004 [details]
Kernel log of errors

Comment 2 Michael Redinger 2002-12-28 17:03:33 UTC
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 17:06:00 UTC
Created attachment 88963 [details]
kernel error log 1

Comment 4 Michael Redinger 2002-12-28 17:06:25 UTC
Created attachment 88964 [details]
kernel error log 2

Comment 5 Michael Redinger 2002-12-28 17:12:11 UTC
Hm, is this a dup of bug #71223 ?

Comment 6 Michael Redinger 2003-02-07 13:02:15 UTC
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 14:20:37 UTC
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 22:49:40 UTC
patch included in U4 erratum candidate. moving to modified.

Comment 12 John Flanagan 2004-04-22 01:03:00 UTC
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.


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