Bug 77839

Summary: Assert failure in transaction.c:1224: "!jh->b_committed_data
Product: [Retired] Red Hat Linux Reporter: Stephen Tweedie <sct>
Component: kernelAssignee: Stephen Tweedie <sct>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: high    
Version: 8.0CC: jbaron, michael.redinger, mitr, nobody+wcheng, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-04-22 01:02:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 107565    
Attachments:
Description Flags
Kernel log of errors
none
kernel error log 1
none
kernel error log 2 none

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:
"!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 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.

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