From: "Luis A. Montes" <lmontes@worldnet.att.net>
To: linux-kernel@vger.kernel.org
Cc: andre@linuxdiskcert.org, axboe@suse.de
Subject: Re: 2.4.17 filesystem corruption
Date: Sat, 9 Feb 2002 11:06:20 -0800 [thread overview]
Message-ID: <20020209110620.A247@penguin.montes2.org> (raw)
Well, I have been testing different kernels and filesystems in my
system lately. To recap, my system is a ECS mobo with the SiS 735
chipset, Athlon CPU, pc133 memory and IDE caviar hd. The problem is
that the kernel 2.4.17 produces massive filesystem corruption. Things
I have been able to eliminate as sources of the problem:
- Memory/CPU: ran memtest86, several full passes, without a problem. I'm
not overclocking. It's also been stable with other kernels.
- CPU optimization in the kernel: Corruption has happened with i386, K6
and K7 optimization, and stable kernels have had K7 enabled without
problem.
- filesystem: I've tried XFS-only systems, mixtures of XFS and ext2 and
ext2-only systems with identical results.
- I've got a second hd plugged in the system, and I did wonder whether
it could be the problem as it happens to be on the black list, but
again whether I have or not connected doesn't seem to change things.
- My harddrive itself. Passes Western Digital test, so there doesn't seem
to be anything physically wrong with it. And it's worked fine with
other kernels.
After more test during this week, I think I have something close to a
smoking gun: Compiled a 2.4.5 and a 2.4.17 kernel with identical config
files. Ran 2.4.5 during about 24 hours with continous i/o (compiling
kernels and XFree86), and the filesystem survived. Ran 2.4.17 and it
crashed within the first hour. In either case I didn't use hdparm to
change anything, the hdparms where as they are set by default, everything
off. Again, keeping identical config file I compiled 2.4.17 changing only
the drivers/ide/sis5513.c file as per Lionel Bouton's patch. The system
has been running for a week now with my normal load, compiling lots of
stuff. I still didn't want to turn on dma (this is my workstation, I need
to have it mostly up!). Then I did try the exact same kernel but I did
enable dma with hdparm -c 1 -d 1 -m 8 and ran the same test I did for the
other kernels, and it didn't crash (ran for about 12 hours fine). I'll
probably test it longer before using it in my good partitions, but I'm
confindent it will survive, crashes usually occurred within the first
hour.
Conclusion: It seems to me that something within sis5513.c got broken
between 2.4.5 and 2.4.17 and was repaired by Bouton's patch.
Please let me know if I should do some more tests. I still have the
"sacrificial" partition around and I'm willing to test patches/whatever.
But
it seems to me that Bouton's patch just fixed it.
Thanks to everybody who answer
next reply other threads:[~2002-02-09 19:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-09 19:06 Luis A. Montes [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-02-03 5:38 2.4.17 filesystem corruption Luis A. Montes
2002-02-03 6:01 ` Pierre Rousselet
2002-02-03 13:44 ` Alan Cox
2002-02-09 8:45 ` Luis A. Montes
2002-02-04 16:55 ` Denis Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020209110620.A247@penguin.montes2.org \
--to=lmontes@worldnet.att.net \
--cc=andre@linuxdiskcert.org \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox