Red Hat Bugzilla – Bug 59527
Severe file system corruption w/ASUS P4B
Last modified: 2007-04-18 12:40:10 EDT
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):
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
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).
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!
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.
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.
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.
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.
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.