Bug 99517

Summary:

Assertion failure on ext3fs

Product:

[Retired] Red Hat Linux

Reporter:

Leos Bitto <bitto>

Component:

kernel

Assignee:

Stephen Tweedie <sct>

Status:

CLOSED DUPLICATE

QA Contact:

Brian Brock <bbrock>

Severity:

high

Docs Contact:

Priority:

medium

Version:

7.3

CC:

riel, sct

Target Milestone:

---

Target Release:

---

Hardware:

i686

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2006-02-21 18:57:07 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:

Attachments:

Description	Flags
kernel log showing the assertion failure	none

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):
kernel-smp-2.4.20-18.7.i686.rpm

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.