I had a motherboard failure (Asus K8V Deluxe) and when I got a replacement everything worked again, except for kernel panics every 2-3 hours! I'll give the hard drives names. So I moved all data onto one hard drive [Disk Alpha], formatted one of the drives [Disk Beta] and reinstlled fedora core 1 on the new drive.

Installation went fine and then on reboot it failed because Disk Alpha had filesystem problems. running fsck on it resulted in a kernal panic. In 10 years dealing with linux/solaris I have never seen a version of fsck fail to fix a file system without a hardware problem, much less cause a kernel panic!! Maybe I was just lucky?

So I thought, it must be a hardware problem with Disk Alpha, so I started moving all the data from Disk Alpha to Disk Beta, which was clean. So I booted fedora core from CD and went into rescue mode. I would move files from the error partition on Disk Alpha to the clean partition and periodic filesystem errors or kernel panics would result in having to reboot to continue moving more files. The same was true if copying files from disk to disk using tar. So it seemed that accessing those files could cause kernel panics and the location of the problem within the filesystem was not consistent. So after 30 or so reboots I got the 80GB of data (home directories, source code, web sites, multimedia) moved over to Disk Beta.

I formatted Disk Alpha and now it was fine, but now Disk Beta was unclean and running fsck.ext3 would result in kernel panics consistently. Moving files back to a clean disk would make the other disk unclean. It was like a taint that I could move around. I would try moving over a subset of files, unmounting it, do a fsck.ext3 -C 0 -f -v /dev/hda1 (or whatever device) and one I moved some directories over I would get a kernal panic. After over a day of this, I decided to move all the taint onto one disk and leave it unmounted. I did have to move over some mimimal amount of my data to the clean root disk. Although the filesystem was clean, it did panic after 2 days while using mozilla. [yikes! A panic while surfing the web?!] I assume that's from accessing home directories, which were mostly restored from backups (Drive Gamma) and only updated files were updated from files on the tainted disk. After reboot, fsck did have errors that had to be repaired, so perhaps there is a continuing problem even on the clean area.... These errors were fixable as normal.

All lost+found directories are empty.

Here are some common error messages from my multi-day ordeal:
kernel BUG at journal.c:1847!
filemap_fdatasync (fsck usually)
journal_remove_journal_head (mv usually)
run_time_list kernel panic after bug krash

<from Logwatch> [/dev/hdc1 is tainted disk]
WARNING: Kernel Errors Present
EXT3-fs error (device ide0(3,1...: 2Time(s)

[root@passion root]# uname -a
Linux passion.tkz.net 2.4.22-1.2115.nptl #1 Wed Oct 29 15:31:21 EST 2003 i686 athlon i386 GNU/Linux

Software: Stock Fedora Core 1 with everything- no updates of kernel or software

Hardware: ASUS K8V Deluxe, Athlon 64 3200+, Lite-On|LNE100TX NIC, Intel Corp.|82557/8/9 [Ethernet Pro 100] NIC, Geforce 4 Ti4800, C-Media Electronics CM8738 sound card, floppy, 3 hard drives, CD Rom.

I don't know if it's related, but I've noticed that hard drive and CD-Rom are on the same IDE connector, it slows down IDE detection and grub loading, but seems to be fast otherwise. I did not have this problem when using an removable harddrive enclosure next to the CD-Rom.

" EXT3-fs error (device ide0(3,1...: 2Time(s)"

In the past I had a lot of problems with a Maxtor secondary IDE controller using a Promise chipset. The I/O errors were sometimes reported as disk errors and sometimes reported against the IDE port. Since you are having errors on IDE0 I would cast a suspicious eye at the IDE chipset.

Does your new motherboard have a different IDE chipset than the old? Does your kernel have support for the new IDE chipset or is it still configured for the old IDE chipset?

"In 10 years dealing with linux/solaris I have never seen a version of fsck fail to fix a file system without a hardware problem, much less cause a kernel panic!! Maybe I was just lucky?"

I have seen it happen on my Maxtor secondary IDE controller (which is now residing a long throw away in my backyard).

There is a problem found on several IDE chipsets that you might investigate. The chipsets are supposed to have two independent data paths, one through IDE0 and one through IDE1. Several IDE chipsets have a hardware bug where they can only use one path at a time. An attempt at simultaneous access through IDE0 and IDE1 results in a hardware error. The manufacturers fix this problem by writing Windows drivers that never allow simultaneous access. Then the manufacturer keeps mum about the fact that the top transfer speed on their chipset is only half of what it should be. They also refuse to release this information to the public so the Linux driver developer has to reverse engineer how the device work, errors and all. So even if you have the correct Linux driver then it still may be flaky because the driver does not play the bugs correctly.

If you suspect that you have a driver/chipset problem then the best place to look for the problem is on the development board used by the people who developed that driver. Also you can go to www.kernel.org and scan every changelog for kernel versions newer than yours for your chipset name. See if you can find where a developer makes kernel IDE driver changes to get around hardware and/or driver bugs.


___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeBo...home.page.html

Steve Stites

I switched to an Athlon 2700+ and an older motherboard and the system that fixed the file corruption. fsck fixed a couple errors on one of the disks and that was the end of the data corruption. No more crashes for fsck or anything. There still seems to be problems related to sound, but that's for the start of another question.

That motherboard and CPU that I swapped out worked fantastic as the basis of a windows machine. So I guess it was just bad linux support for the hardware.