Bug 59527 - Severe file system corruption w/ASUS P4B
Summary: Severe file system corruption w/ASUS P4B
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-09 14:13 UTC by Joachim Frieben
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-11 19:12:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joachim Frieben 2002-02-09 14:13:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014

Description of problem:
File system corruption on ASUS P4B Pentium 4 based system. 

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

How reproducible:

Steps to Reproduce:
1. Install Red Hat Linux 7.2 (w/all updates).

Actual Results:  After a short period of time, file system corruption occurs up
to the complete loss of entire partitions!

Expected Results:  Systm should work properly

Additional info:

The first incident resulting in complete loss of the content of all partitions
occured when an audio CD was accessed. However, even without using the CD-ROM
drive (for audio), file system corruption occurs. For instance, some files have
absolutely cryptic attributes and are not accessible anymore. The problem is
maybe related to some improper function of the IDE UDMA/100 interface (INTEL 845
chipset with ordinary SDRAM).

Comment 1 Joachim Frieben 2002-02-09 19:45:59 UTC
Well, looks like a problem with the kernel sound support. Sound support in
kernels later than 2.4.7-10 does -not- work on the cited platform ASUS P4B
(INTEL i845). After downgrading to the original kernel 2.4.7-17, sound is back,
and the interference with file operations seems to have ceased. The latter
observation remains to be confirmed. Anyway, this is a really nasty bug!

Comment 2 Need Real Name 2002-02-10 10:26:01 UTC
I`ve had the same problem twice on a P II with Intel 440BX chipset using the 
kernel shipped with the original 7.2 distribution (2.4.7-10). The system hung, 
i was forced to press the reset button. After reboot, fsck stopped due to the 
severely broken filesystem.
Sound works despite of some sound-module related error messages that i tend to 
I wonder, when this will happen again.

Comment 3 Joachim Frieben 2002-02-10 11:17:32 UTC
Finally, I had to reinstall Red Hat Linux 7.2 from scratch, because, as time
went by, file system errors creeped into the system partitions again, affecting
the proper functioning of various applications, e.g. GNOME would not work any
more. Because the system had worked nicely running Red Hat Linux 7.1, I decided
to choose "ext2" as default format, as the introduction of "ext3" was the major
change between the two releases. Since having performed this installation, the
system behaves normally. Applying "rpm -V" to various essential packages like
"gnome-core", ... yields no output whereas before plenty of modifications had
been reported. It seems that the sound problem that affects kernels 2.4.9 and
later is an independent issue.

Comment 4 Stephen Tweedie 2002-02-11 16:56:08 UTC
When you reinstalled 7.2, did you also then upgrade the kernel to a current
errata, or are you still using one of the old kernels?  

There are basically two things this could be.  It could be a bad area on disk
which was fixed by the re-install (rewriting data over a bad sector can cause a
soft error to disappear as the disk remaps the disk block concerned away to a
known-good part of the disk surface.)  Or, it could be an odd hardware or driver
interaction --- buggy hardware, for example.

We'd need to know whether the problem remains if you use the same kernel you had
trouble with before, and whether it remains associated with use of the sound
hardware or not.

Comment 5 Joachim Frieben 2002-02-11 19:09:00 UTC
I can only repeat my last statement: various attempts of installing Red Hat
Linux 7.2 failed (namely: monotonously increasing file system corruption), as
long as the "ext3" option was chosen. The only difference between the stock
kernel 2.4.7-10 and the later kernel 2.4.9-x was that for the latter ones, the
sound support was broken, too! Every time the disk had been fully formatted,
once also checked for bad blocks without any sign of of hardware flaw. To
summarize: on the concerned system based on a ASUS P4B mainboard, -only-
selection of "ext2" as default file system type allowed to ensure data
integrity. "ext3" screwed up the disk regardless which one of the different
kernels was installed.

Comment 6 Stephen Tweedie 2002-11-11 22:05:10 UTC
There have been too many cases in the past where ext3's accesses patterns
triggered bugs that were actually in the hardware, or in a device driver. 
Without any more info, we really can't debug this any further.

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