> > I upgraded the kernel to 2.4.18-19.7.x, changed the memory, but still got problems. > > I'd start by running memtest86 on it. Your oops: > > > EIP is at copy_files [kernel] 0x169 (2.4.18-19.7.x) > > Call Trace: [<c011763e>] do_fork [kernel] 0x2ce (0xca5fdf6c)) > > [<c0107515>] sys_fork [kernel] 0x15 (0xca5fdfac)) > > [<c010893b>] system_call [kernel] 0x33 (0xca5fdfc0)) > > isn't actually anything to do with ext3; rather, the "copy_files" > function is an internal function which copies the the list of open files > from a parent process to its child when a process forks. Getting an > oops there is usually a sign of memory corruption, and the > > > And now and then I see this messages (sometimes without any effects) > > EXT3-fs error (device ide0(3,2)): ext3_free_blocks: Freeing block in system zone - block = 2 > > fsck: contains a file system with errors, check forced. > > errors are consistent with that. > > You said you've changed the memory, but it could be many other problems > --- a CPU fault, the CPU overheating (check the fan!), cache problems, a > chipset fault --- contributing to the memory corruption even if the RAM > itself is fine; or the hardware might be perfect but the BIOS settings > wrong. memtest86 is definitely the next diagnostic for you to try in > this case, as if that shows an error, you know it's definitely not a > kernel problem and you can start narrowing down which part of the > hardware is causing the trouble. The memtest is now running more than 24h without any errors. So I think I can presume mem is OK. i.m.h.o. it now can only be a bad chipset regarding the IDE, the HD itself, or a software bug (sorry I don't want to offend someone). I did some normal cp en rsync to see if I can reproduce the error, but nothing happened. Are there some stress-test for the HD, or is there a website where I can more info on what all the errors mean. Best Regards, Pascal _______________________________________________ Ext3-users@redhat.com https://listman.redhat.com/mailman/listinfo/ext3-users