Re: File Corruption in Kernel 2.4.18

[Kelledin]

This could possibly be a problem with your hard drive.  Judging 
from the model number, you have a 45GB IBM DeskStar 75GXP, one 
of the first IBM drives to earn the nickname "DeathStar" for its 
high failure rate.  What does IBM's Drive Fitness Test tell you?

I'll see about performing your test tonight; I've got a hefty 
little DivX directory I can throw around as I wait for 
j2sdk-1.4.0 to finish compiling.  Such a test should be 
sufficient...

This could also be a recurrence of ye olde VIA686B PCI+IDE issue.  
IIRC, some VIA686B motherboards that had that flaw were 
effectively unfixable, simply because certain motherboard 
manufacturers spotted the problem before everyone else (even 
VIA?) and tried their own partial kludge fixes for it.  Gotta 
love VIA.

On Wednesday 17 July 2002 09:00 pm, J. Hart wrote:
>      A large directory tree (70652 files, 7.6G) is copied
> recursively to an empty destination directory using the
> following commands :
>
>      mkdir aminet1/
>      cp -a aminet aminet1/
>
>      The source and destination directories are then compared
> using the following commands:
>
>      diff -r aminet aminet1/aminet > difflist
>
>      A few of the files at the copy destination, typically
> three or four, will usually be corrupt while the source files
> will be correct.  Occasionally the copy will be done without
> any corrupt files at the destination.  The mem=nopentium
> option appears to have no effect on this.  An overnight test
> using the memtest86 utility shows no memory errors.  The
> corruption in each file occurs in precise 4096 byte blocks. 
> An overnight test using the memtest86 utility shows no memory
> errors.  The corruption in each file occurs in precise 4096
> byte blocks.  System logs show no evidence of any trouble, and
> no kernel panics, warning messages or crashes are observed. 
> If there is any other user activity while the copy is running,
> the system will frequently lock up requiring a hard reset and
> reboot.  This forces a file system check due to the lack of a
> clean unmount.  System logs also show no evidence of any
> trouble after the lockup, and no kernel panics or other
> messages have been observed.
>
>      If a tar file is made of the source directory and then
> extracted, and the resultant extracted directory compared with
> the original, similar effects are observed.
>
>      Are there any kernel boot or build parameters which could
> be used to give additional diagnostics ?
>
> motherboard   : ASYS-A7V
> Linux version : Slackware 8
> Kernel        : 2.4.18
> hard disk     : ATA100 IBM-DTLA-307045 45gb
> hd controller : Promise Technology, Inc. 20265
> cpu           : 900mhz AMD Athlon

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"