Bug 99517 - Assertion failure on ext3fs
Summary: Assertion failure on ext3fs
Status: CLOSED DUPLICATE of bug 86035
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-21 15:08 UTC by Leos Bitto
Modified: 2007-04-18 16:55 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2006-02-21 18:57:07 UTC

Attachments (Terms of Use)
kernel log showing the assertion failure (4.80 KB, text/plain)
2003-07-22 15:29 UTC, Leos Bitto
no flags Details

Description Leos Bitto 2003-07-21 15:08:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET 
CLR 1.0.3705; .NET CLR 1.1.4322)

Description of problem:
We have a large disk array 1.7 TB (hardware raid 5) with only one partition on 
it, formatted with EXT3FS. See the attached log file for kernel error which 
appeared. After this error appeared, the filesystem was no more accessible - 
every process trying to access it froze.

Version-Release number of selected component (if applicable):

How reproducible:
Couldn't Reproduce

Steps to Reproduce:
Don't know how to reproduce.

Additional info:

Comment 1 Stephen Tweedie 2003-07-22 14:24:20 UTC
Please provide the kernel log showing the assertion failures.

Comment 2 Leos Bitto 2003-07-22 15:29:15 UTC
Created attachment 93045 [details]
kernel log showing the assertion failure

I am sorry, I obviously forgot to attach the most important part of the bug
report. Your bugzilla's "new bug wizard" scared me a lot. :-)

Comment 3 Stephen Tweedie 2003-07-22 21:22:54 UTC
This is a known problem.  There's a debug check in ext3 which triggers when
we're using a page which is marked uninitialised.  Unfortunately, that same
condition can be triggered by IO failures.  Please check your logs --- I suspect
you'll find IO failures prior to the panic.

A recent patch to upstream kernels relaxes this check in ext3 to be a warning,
not a panic, so we won't do the impolite kernel oops in this case, and future
releases will use that new behaviour.

Comment 4 Leos Bitto 2003-07-23 15:19:08 UTC
Yes, you are right - I found a lot of messages like "kernel: cciss: cmd 
c2de6078 has CHECK CONDITION, sense key = 0x3" prior to the panic, which I did 
not notice before; cciss is the name of the driver for the raid controller 
(Compaq Smart Array). The errors appeared in the log 22 hours prior to the ext3 
panic. I am going to check how to get the hardware behaving properly. BTW - is 
that relaxed ext3 patch already included in 2.4.20-19.7?

Comment 5 Stephen Tweedie 2004-09-10 12:23:18 UTC

*** This bug has been marked as a duplicate of 86035 ***

Comment 6 Red Hat Bugzilla 2006-02-21 18:57:07 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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