From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: mkfs.ext2 triggerd RAM corruption
Date: Mon, 07 May 2007 14:42:18 -0400 [thread overview]
Message-ID: <f1nrtn$qqv$1@sea.gmane.org> (raw)
In-Reply-To: <20070504203956.GL25077@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Fri, 2007-05-04 16:59:51 +0200, Bernd Schubert <bs@q-leap.de> wrote:
>> To see whats going on, I copied the entire / (so the initrd) into a tmpfs
>> root, chrooted into it, also bind mounted the main / into this chroot and
>> compared several times /bin of chroot/bin and the bind-mounted /bin while the
>> mkfs.ext2 command was running.
>>
>> beo-05:/# diff -r /bin /oldroot/bin/
>> beo-05:/# diff -r /bin /oldroot/bin/
>> beo-05:/# diff -r /bin /oldroot/bin/
>> Binary files /bin/sleep and /oldroot/bin/sleep differ
>> beo-05:/# diff -r /bin /oldroot/bin/
>> Binary files /bin/bsd-csh and /oldroot/bin/bsd-csh differ
>> Binary files /bin/cat and /oldroot/bin/cat differ
>> ...
>>
>> Also tested different schedulers, at least happens with deadline and
>> anticipatory.
>>
>> The corruption does NOT happen on running the mkfs command on /dev/sda1, but
>> happens with sda2, sda3 and sda3. Also doesn't happen with extended
>> partitions of sda1.
>
> Is sda2 the largest filesystem out of sda2, sda3 (and the logical
> partitions within the extended sda1, if these get mkfs'ed, too)?
>
> I'm not too sure that this is a kernel bug, but probably a bad RAM
> chip. Did you run memtest86 for a while? ...and can you reproduce this
> problem on different machines?
>
> MfG, JBG
>
Was this missing from your copy of the original post, or did you delete
it without reading? Note last sentence...
> Summary: The system ramdisk (initrd) gets corrupted while running
> mkfs.ext2 on a local sata disk partition.
>
> Reproduced on kernel versions: vanilla 2.6.16 - 2.6.20 (<2.6.16
> doesn't run on any of the systems I can do tests with). Please note:
> I could reproduce this on serveral systems, all of them use ECC
> memory and the memory of most of them the memory is monitored using
> EDAC.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
prev parent reply other threads:[~2007-05-07 18:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-04 14:59 mkfs.ext2 triggerd RAM corruption Bernd Schubert
2007-05-04 18:49 ` Theodore Tso
2007-05-05 1:36 ` Bernd Schubert
2007-05-05 18:57 ` Theodore Tso
2007-05-05 19:12 ` Jan Engelhardt
2007-05-05 22:06 ` Bernd Schubert
2007-05-05 23:09 ` Bernd Schubert
2007-05-04 20:39 ` Jan-Benedict Glaw
2007-05-05 1:38 ` Bernd Schubert
2007-05-07 18:42 ` Bill Davidsen [this message]
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='f1nrtn$qqv$1@sea.gmane.org' \
--to=davidsen@tmr.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.