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): 2.4.9-21 How reproducible: Always 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).
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 ignore. 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.