public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Cc: rmager@vgkk.com (Rainer Mager), linux-kernel@vger.kernel.org
Subject: Re: Is this kernel related (signal 11)?
Date: Mon, 22 Jan 2001 21:47:58 +0000 (GMT)	[thread overview]
Message-ID: <200101222147.f0MLlxe01758@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200101220753.IAA12360@cave.bitwizard.nl> from "Rogier Wolff" at Jan 22, 2001 08:53:13 AM

Rogier Wolff writes:
> Harware problems are normally not reproducable. Can you attach a
> debugger to your X server, and catch it when things go bad? (And
> give the Xfree86 people a backtrace)

Bad RAM can be extremely reproducable though, and can certainly produce
SEGVs.

Evidence: I recently had a bad 128MB SDRAM which *always* failed at byte
address 0x220068, which was the middle of the mem_map array.  All I
needed to do was 'dd if=/dev/hda of=/dev/null' and the machine would
die within 5 minutes due to an invalid buffer_head pointer.

The SDRAM naturally passed each and every single memory test I could
throw at it.  However, a new SDRAM fixed the problem.

It is quite common for SDRAMs to fail in this way - think about the
failure mode.  Some of the silicon in the SDRAM is damaged.  This isn't
going to move about, so its going to be in a fixed position.  A fixed
position means a specific set of transistors, gate, and therefore
memory location.

In answer to the original posters question, the first step would be
to grab a copy of memtest86 (iirc its a program that is run from floppy
disk) and run that on your system.  That /should/ (and I stress should
there) detect any RAM problems you have.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2001-01-22 22:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-19 22:27 [patch] smbfs cache rewrite for 2.4.1-pre Urban Widmark
2001-01-22  5:17 ` Is this kernel related (signal 11)? Rainer Mager
2001-01-22  7:34   ` David Woodhouse
2001-01-22  8:03     ` Rainer Mager
2001-01-23  2:47       ` David Ford
2001-01-23  8:37         ` Rainer Mager
2001-01-24  0:56           ` Rainer Mager
2001-01-25  0:45             ` Rainer Mager
2001-01-22  7:53   ` Rogier Wolff
2001-01-22 21:47     ` Russell King [this message]
2001-01-23  0:15       ` Paul Jakma
2001-01-22 14:27   ` Barry K. Nathan

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=200101222147.f0MLlxe01758@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmager@vgkk.com \
    /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