public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vojtech Pavlik <vojtech@suse.cz>
To: Rob Landley <landley@webofficenow.com>
Cc: Ville Herva <vherva@mail.niksula.cs.hut.fi>,
	linux-kernel@vger.kernel.org
Subject: Re: Hardware testing [was Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))]
Date: Wed, 11 Jul 2001 11:11:59 +0200	[thread overview]
Message-ID: <20010711111159.A2026@suse.cz> (raw)
In-Reply-To: <E15JIVD-0000Qc-00@the-village.bc.nu> <01070912485904.00705@localhost.localdomain> <20010710121724.Z1503@niksula.cs.hut.fi> <01071011282504.00634@localhost.localdomain>
In-Reply-To: <01071011282504.00634@localhost.localdomain>; from landley@webofficenow.com on Tue, Jul 10, 2001 at 11:28:25AM -0400

On Tue, Jul 10, 2001 at 11:28:25AM -0400, Rob Landley wrote:
> On Tuesday 10 July 2001 05:17, Ville Herva wrote:
> > On Mon, Jul 09, 2001 at 12:48:59PM -0400, you [Rob Landley] claimed:
> > > (P.S. What kind of CPU load is most likely to send a processor into
> > > overheat? (Other than "a tight loop", thanks.  I mean what kind of
> > > instructions?) This is going to be CPU specific, isn't it?  Our would a
> > > general instruction mix that doesn't call halt be enough?  It would need
> > > to keep the FPU busy too, wouldn't it?  And maybe handle interrupts. 
> > > Hmmm...)
> >
> > See Robert Redelmeier's cpuburn:
> >
> > http://users.ev1.net/~redelm/
> 
> Cool.  If nothing else, this is a much better starting point for further work 
> than starting from scratch...
> 
> > It is coded is assembly specificly to heat the CPU as much as possible. See
> > the README for details, but it seems that floating point operations are
> > tougher than integers and MMX can be even harder (depending on CPU model,
> > of course). Not sure what kind of role SSE, SSE2, 3dNow! play these days.
> > Perhaps Alan knows?
> 
> There's at least three seperate things that need testing here.  memtest86 
> tests whether your memory is OK.  CPUburn seems to do a good job testing 
> processor heat (not that I'm running it on my laptop, which doesn't seem to 
> have a thermal readout thingy anyway...)
> 
> The third thing (which started this thread) was memory bus.  The new 3DNow 
> optimizations drove a memory bus into failure, and that IS processor 
> specific...

Don't forget the L1/L2/L3 caches. I had once a mainboard with a faulty
L2 cache chip ('twas a K6-3 CPU, plus a FIC VA-503+ mainboard). No memory
or CPU test found the failure, yet kernel compliation was still crashing
after 6-8 hours.

I modified the 'memtest.c' little proggy (not the big memtest86, just a
little utility that runs under Linux), to use patterns and test size
that tests the L1 and then L2, and the error has shown after ten seconds
of running the test.

-- 
Vojtech Pavlik
SuSE Labs

  parent reply	other threads:[~2001-07-11  9:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-25  6:17 Crash on boot (2.4.5) Andy Ward
2001-06-25  6:32 ` VIA Southbridge bug (Was: Crash on boot (2.4.5)) Steven Walter
2001-06-25  7:06   ` Alan Cox
2001-06-30 13:58     ` Pavel Machek
2001-07-08 17:37       ` Alan Cox
2001-07-09 16:48         ` Rob Landley
2001-07-10  9:17           ` Ville Herva
2001-07-10 15:28             ` Hardware testing [was Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))] Rob Landley
2001-07-11  4:18               ` Albert D. Cahalan
2001-07-11  8:43               ` Ville Herva
2001-07-11  9:11               ` Vojtech Pavlik [this message]
2001-07-11 15:05                 ` Rob Landley
2001-07-12  6:57                   ` Ville Herva
2001-07-10 21:24             ` VIA Southbridge bug (Was: Crash on boot (2.4.5)) Adam Sampson
2001-07-11  8:32               ` Ville Herva
2001-07-11  9:03             ` Eyal Lebedinsky

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=20010711111159.A2026@suse.cz \
    --to=vojtech@suse.cz \
    --cc=landley@webofficenow.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vherva@mail.niksula.cs.hut.fi \
    /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