2.4.18 File System Corruption

[Adam Warner <lists@consulting.net.nz>]

Hi all,

I have experienced massive file system corruption on my main computer
after installing Woody and upgrading the kernel to 2.4.18-686-smp
(2.4.18-5). The filesystems were ext3. Hardware is an ABit BP6.

The install disks were also the 2.4.18-bf series.

This is an example of the kernel error messages I received when
transferring files to the box over NFS:

kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
kernel: hde: drive not ready for command
kernel: hde: status error: status=0x50 { DriveReady SeekComplete }
kernel: hde: no DRQ after issuing WRITE
kernel: hde: status error: status=0x50 { DriveReady SeekComplete }
kernel: hde: no DRQ after issuing WRITE
kernel: hde: status timeout: status=0xd0 { Busy }
kernel: hde: no DRQ after issuing WRITE
kernel: ide2: reset: success
kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
kernel: hde: drive not ready for command
kernel: hde: status error: status=0x50 { DriveReady SeekComplete }
kernel: hde: no DRQ after issuing WRITE
kernel: hde: status error: status=0x50 { DriveReady SeekComplete }
kernel: hde: no DRQ after issuing WRITE
kernel: hde: status timeout: status=0xd0 { Busy }

After forcing a file system check I find that the partitions are
massively corrupt.

I find this post:
http://groups.google.co.nz/groups?hl=en&selm=20020503203623.25862.qmail%40web21503.mail.yahoo.com

Which specifically mentions 2.4.18 IDE corruption and 0x58 status
errors. Note the post is very recent.

Other potential confirmation:
http://groups.google.co.nz/groups?hl=en&selm=i1h6aa.qin.ln%40giganator.family.lan

Compounding my problems may also be a 2.4.18 SMP bug:

http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.19.log
(02/03/15 1.197.2.5)
	[PATCH] boot_cpu_data corruption on SMP x86

http://www.ussg.iu.edu/hypermail/linux/kernel/0203.1/0774.html

I seriouly suggest that anyone using a 2.4.18 kernel downgrade and do a
fsck straight away. ext3 will disguise any kernel corruption because
even a lockup or forced reboot only leads to the journal being replayed.

It's late in NZ and I'm off to bed. So just consider this a heads up.

Regards,
Adam



-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org