LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ali Akcaagac <aliakc@web.de>
To: linux-kernel@vger.kernel.org
Subject: 2.6.0-preX causes memory corruption
Date: Tue, 25 Nov 2003 20:45:56 +0100 [thread overview]
Message-ID: <1069789556.2115.16.camel@localhost> (raw)
Hello,
Sorry for the subject but I have been noticing this problem for quite
some time now under 2 totally different machines and I now belive that
this may be a Kernel issue.
Machine 1 (old):
Elitegroup k7s5a, 256mb, g400, 15gb
After installing 2.6.0-pre9 the System seemed to work normally, all the
stuff I did before worked normally but when doing large fileoperation
including crunching stuff using bzip2 (e.g. checking out modules from
CVS and tar'ing them up) the archives get corrupt. I was first assuming
that this was a onetime mistake and thus I deleted the corrupt file and
re-run my normal operations. But after a while I noticed that this
problem occoured more and more and I was starting to worry. Archives are
showing to be corrupted but after an reset these archives can be
unpacked normally again.
I was really worrying myself if this could be my machine e.g. defective
Ram modules or something thus I ran memtest86 for 3 passes and the
memory was ok. Later on after this problem showed up again I thought
that this may be something else e.g. Motherboard (dying capacitors) my
CPU or whatever.
Anyways I bought totally new hardware (not only because of the problem,
because I wanted to do this anyways and this problem was a good excuse
to go for new stuff 2 days later). So I bought brand new mobo, ram,
harddisk and stuff like that and build the system up:
Machine 2 (new):
Shuttle AK39N, Radeon 9200, 512mb, 40gb Harddisk
Updated my System to 2.6.0-pre10 but the problem still exists. I'm now
really worried what the cause of this problem could be. I know there
could be dozen of reasons such as compiler used, stuff compiled and
things like this but the really strange thing is that I was doing CVS
(and tar'ing up stuff) on a daily basis even with my old machine and
earlier 2.6.0-preX kernels without any problems, the only stuff that I
consistently update is mainly GNOME or KDE, basically NO system updates
happened during 2.6.0-pre5/6 and all in all my system is quite clean.
I know all this is quite vague but now that I totally changed 2
different hardware and that this problem showed up first time with
2.6.0-pre9 (and exists in 10) I may have the tendency to shift this
problem to the Kernel. Also normal operations such as compiling stuff
sometimes end in e.g. telling me that libraries are NOT ELF or that
libraries show wrong stuff etc. and a normal reset usually solved this
which tells me that this is not filesystem related and that the files
itself are in best shape.
Anyways I hope I didn't caused any worries or something but I thought to
let you know about this issue, chances may be that this may indeed be a
kernel issue. May or may not...
greets.
PS: CC me, I'm not subscribed.
next reply other threads:[~2003-11-25 19:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 19:45 Ali Akcaagac [this message]
2003-11-25 20:09 ` Måns Rullgård
2003-11-25 20:26 Ali Akcaagac
2003-11-26 9:33 ` Michael Buesch
2003-11-26 5:52 Ali Akcaagac
2003-11-26 6:00 Ali Akcaagac
2003-12-06 20:31 Ali Akcaagac
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=1069789556.2115.16.camel@localhost \
--to=aliakc@web.de \
--cc=linux-kernel@vger.kernel.org \
--subject='Re: 2.6.0-preX causes memory corruption' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).