Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[David Balazic]

Rob Landley (landley@webofficenow.com) wrote :
> On Sunday 08 July 2001 13:37, Alan Cox wrote: 
> > > > possible on the memory bus. Several people have reported that machines 
> > > > that are otherwise stable on the bios fast options require the proper 
> > > > conservative settings to be stable with the Athlon optimisations 
> > > 
> > > Do we need patch to memtest to use 3dnow? 
> > 
> > Possibly yes. Although memtest86 really tries to test for onchip not bus 
> > related problems 
> 
> What else tends to fail on the motherboard that might be easy to test for? 
> Processor overheating? (When the thermometer circuitry's there, anyway.) 
> Something to do with DMA? (Would DMA to/from a common card like VGA catch 
> chipset-side DMA problems?) There was an SMP exception thing floating by 
> recently, is that common and testable? 
> 
> I know there's a lot of funky peripheral combinations that behave strangely, 
> but without opening that can of worms what kind of common problems on the 
> motherboard itself might be easy to test for in a "run this overnight and see 
> if it finds a problem with your hardware" sort of way? 
> 
> Rob 
> 
> (P.S. What kind of CPU load is most likely to send a processor into overheat? 

CPUburn from http://users.ev1.net/~redelm/

My Celeron 300 oc'ed to 450 run RC5 and Mersenne Prime for hours,
but locked up after 5 minutes of CPU burn.

The best CPU ( and bus/memory) test program that exists, IMHO

>  (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...) 
> 
> I wonder... The torture test Tom's Hardware guide uses for processor 
> overheating is GCC compiling the Linux kernel. (That's what caught the 
> Pentium III 1.13 gigahertz instability when nothing else would.) I wonder, 
> maybe if a stripped down subset of a known version of GCC and a known version 
> of the kernel were running from a ramdisk... It USED to fit in 8 megs with 
> no swap, might still fit in 32 with a decent chunk of kernel source. Throw 
> the compile in a loop, add in a processor temperature detector daemon to kill 
> the test and HLT the system if the temperature went too high... 
> 
> I wonder what bits of the kernel GCC actually needs to run these days? 
> (System V inter-process communication? sysctl support? Hmmm... Would 
> 2.4.anything be a stable enough base for this yet, or should it be 2.2.19? 
> Is 2.4 still psychotic with less swap space than ram (I.E. no swap space at 
> all)?) 
> 
> Off to play... 
> 
> Still Rob. 

-- 
David Balazic
--------------
"Be excellent to each other." - Bill & Ted
- - - - - - - - - - - - - - - - - - - - - -

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Eyal Lebedinsky]

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/

I took this program for a spin and I noted the reported CPU temp
went up by 12dc (43->55).

However, more interesting, the +5V line dropped from 4.82 to 4.72.
This is on a Gigabyte GA-7ZX with an Athlon/1200 and 2x128MB.

Some mobos may actually have their voltages pushed outside accepted
levels and cause a failure, which is actually not related to the
temperature. And you do not need to run the test for a long time,
the drop is immediate and stable.

I can only imagine what will happen if some game pushes the CPU to
the limit while running a hot video card hard, as I expect some
highly optimized graphics drivers might do. May cause some
interesting crashes.

Anyone up to enhancing the program to stress the video memory at the
same time?


In other words, this is a good stress test for the whole mobo design
and setup, not just the CPU/HSF combo.

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.anu.edu.au/eyal/>

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Ville Herva]

On Tue, Jul 10, 2001 at 10:24:21PM +0100, you [Adam Sampson] claimed:
> Ville Herva <vherva@niksula.hut.fi> writes:
> 
> > 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?
> 
> I would have thought this would be a nice problem for a genetic
> algorithm to solve---start with random blocks of data, execute them
> repeatedly for a period of time (restarting upon CPU traps), and
> "breed" those that cause the greatest temperature increase. Any bored
> research students out there?

I'm sure getting an Intel or AMD engineer to comment on this would be far
more fertile. After all, engineers developed a computer in just 50 years,
but it took millions of years for the evolution to come up something like a
human being... [1]


-- v --

v@iki.fi

[1] Now, of course someone will insist that it was in fact God who created
    man... Perhaps someone ought to go to the desert and wait for an
    enlightenment on the Right Instruction Sequence.

    Ob-;), no offense intended.

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Adam Sampson]

Ville Herva <vherva@niksula.hut.fi> writes:

> 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?

I would have thought this would be a nice problem for a genetic
algorithm to solve---start with random blocks of data, execute them
repeatedly for a period of time (restarting upon CPU traps), and
"breed" those that cause the greatest temperature increase. Any bored
research students out there?

-- 
Adam Sampson <azz@gnu.org>                  <URL:http://azz.us-lot.org/>

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Ville Herva]

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/

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?
 
> I wonder...  The torture test Tom's Hardware guide uses for processor 
> overheating is GCC compiling the Linux kernel. 

That shouldn't really be that good a test. During compilation, CPU spends a
_lot_ of time waiting for the memory and even for the disk io. For maximum
heat, you really want a tight loop of instructions, that sits firmly in L1
cache.

The gcc compile is a good test for many other tests - it uses a lot of
memory with complex pointers references (tests memory, and bit errors in
pointers are likely to sig11 rather than produce subtle errors in output),
stresses chipset somewhat (memory throughput), and cpu somewhat. But to test
CPU overheating and nothing else, cpuburn should be a lot better. (Even
seti@home is better as it uses FPU). Just run them an observe the sensors
readings. Cpuburn gets several degrees higher.

> the compile in a loop, add in a processor temperature detector daemon to kill 
> the test and HLT the system if the temperature went too high...

Cpuburn exists when CPU miscalculates something (sign of overheat).

I'm not sure if cpuburn is included in cerberus these days (istr it is), but
a nice test set for memory, cpu, disk etc to run over night or over weekend
to catch most of the hw faults would definetely be nice. 


-- v --

v@iki.fi

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Rob Landley]

On Sunday 08 July 2001 13:37, Alan Cox wrote:
> > > possible on the memory bus. Several people have reported that machines
> > > that are otherwise stable on the bios fast options require  the proper
> > > conservative settings to be stable with the Athlon optimisations
> >
> > Do we need patch to memtest to use 3dnow?
>
> Possibly yes. Although memtest86 really tries to test for onchip not bus
> related problems

What else tends to fail on the motherboard that might be easy to test for?  
Processor overheating?  (When the thermometer circuitry's there, anyway.)  
Something to do with DMA?  (Would DMA to/from a common card like VGA catch 
chipset-side DMA problems?)  There was an SMP exception thing floating by 
recently, is that common and testable?

I know there's a lot of funky peripheral combinations that behave strangely, 
but without opening that can of worms what kind of common problems on the 
motherboard itself might be easy to test for in a "run this overnight and see 
if it finds a problem with your hardware" sort of way?

Rob

(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...)

I wonder...  The torture test Tom's Hardware guide uses for processor 
overheating is GCC compiling the Linux kernel.  (That's what caught the 
Pentium III 1.13 gigahertz instability when nothing else would.)  I wonder, 
maybe if a stripped down subset of a known version of GCC and a known version 
of the kernel were running from a ramdisk...  It USED to fit in 8 megs with 
no swap, might still fit in 32 with a decent chunk of kernel source.  Throw 
the compile in a loop, add in a processor temperature detector daemon to kill 
the test and HLT the system if the temperature went too high...

I wonder what bits of the kernel GCC actually needs to run these days?  
(System V inter-process communication?  sysctl support?  Hmmm...  Would 
2.4.anything be a stable enough base for this yet, or should it be 2.2.19?  
Is 2.4 still psychotic with less swap space than ram (I.E. no swap space at 
all)?)

Off to play...

Still Rob.

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Alan Cox]

> > possible on the memory bus. Several people have reported that machines that
> > are otherwise stable on the bios fast options require  the proper conservative
> > settings to be stable with the Athlon optimisations
> 
> Do we need patch to memtest to use 3dnow?

Possibly yes. Although memtest86 really tries to test for onchip not bus
related problems

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Pavel Machek]

Hi!

> > Great, glad to here it.  Who (if anyone) is still attempting to unravel
> > the puzzle of the Via southbridge bug?  You, Andy, should try and get in
> > touch with them and help debug this thing, if you're up to it.
> 
> The IWILL problem seems unrelated. Its the board that more than others people
> report fails totally when streaming memory copies using movntq instructions.
> 
> The Athlon optimised kernel places pretty much the absolute maximum load 
> possible on the memory bus. Several people have reported that machines that
> are otherwise stable on the bios fast options require  the proper conservative
> settings to be stable with the Athlon optimisations

Do we need patch to memtest to use 3dnow?
									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[pazke]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Mon, Jun 25, 2001 at 01:27:56PM -0700, David Grant wrote:

> I'd be interested in testing any fixes for the VIA Southbridge chip.  I have
> an ASUS A7V133.  I was having problems with the IDE controller, but I've
> switched to the on-board Promise IDE and it works fine.  I couldn't get rid
> of the DMA timeout errors with my VIA vt82c686b, even with the latest
> patches.  I even completely disabled DMA (through .config options) and I
> although I didn't get DMA timeout errors anymore, everything still came to a
> halt under heavy disk usage.
> 
> Would it be a good idea to form a small mailing list of people with VIA
> chipsets (vt82c686b only)?  Then perhaps we could communicate with Vojtech
> more easily, and the VIA southbridge problems might end a little quicker.
> It seems like there are a bunch of people still having the VIA problems.

linux-via@gtf.org

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[David Grant]

I'd be interested in testing any fixes for the VIA Southbridge chip.  I have
an ASUS A7V133.  I was having problems with the IDE controller, but I've
switched to the on-board Promise IDE and it works fine.  I couldn't get rid
of the DMA timeout errors with my VIA vt82c686b, even with the latest
patches.  I even completely disabled DMA (through .config options) and I
although I didn't get DMA timeout errors anymore, everything still came to a
halt under heavy disk usage.

Would it be a good idea to form a small mailing list of people with VIA
chipsets (vt82c686b only)?  Then perhaps we could communicate with Vojtech
more easily, and the VIA southbridge problems might end a little quicker.
It seems like there are a bunch of people still having the VIA problems.

David Grant

----- Original Message -----
From: "Andy Ward" <andyw@edafio.com>
To: "Steven Walter" <srwalter@yahoo.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, June 25, 2001 12:57 PM
Subject: RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))


> I'd love to help out with testing (alas, my kernel coding skills aren't
> up to fixing this kind of problem).  Heck, if it trashes my linux
> install, no biggie... I've got it ghosted to an image elsewhere...
>
> Anyone wanting to work on this just drop me an email.
>
> -- andyw
>

RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Andy Ward]

I'd love to help out with testing (alas, my kernel coding skills aren't
up to fixing this kind of problem).  Heck, if it trashes my linux
install, no biggie... I've got it ghosted to an image elsewhere...

Anyone wanting to work on this just drop me an email.

-- andyw

-----Original Message-----
From: Steven Walter [mailto:srwalter@yahoo.com]
Sent: Monday, June 25, 2001 1:33 AM
To: Andy Ward
Cc: linux-kernel@vger.kernel.org
Subject: VIA Southbridge bug (Was: Crash on boot (2.4.5))


Great, glad to here it.  Who (if anyone) is still attempting to unravel
the puzzle of the Via southbridge bug?  You, Andy, should try and get in
touch with them and help debug this thing, if you're up to it.

On Mon, Jun 25, 2001 at 01:17:57AM -0500, Andy Ward wrote:
> Well, I have tried your suggestion, and it works beautifully...  The
> only change I made was to the cpu type (to 686), and everything *just*
> works now...  Thanks, all!!!
> 
> > From the look of things, you're being bitten by the VIA southbridge
> > problem.  As I've gathered, its some sort of interaction with that
chip
> > and the 3DNow! fast copy routines the kernel uses.
> > 
> > If you compile the kernel for a 686, does the problem go away?  What
> > about 586 or lower?  If so, I believe there are some people working
on
> > finding common aspects of the hardware that experience this problem,
> > though I don't remember who.  You should get in contact with them,
or
> > they might get into contact with you.
> > 
> > Good luck on working this out.
> > -- 
> > -Steven
> > In a time of universal deceit, telling the truth is a revolutionary
act.
> > 			-- George Orwell
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Andy Ward]

oh really?   I have my memory timings set to 133/cas2/6-4-4-4.  One
wonders... *ponder*

I have noticed some general flakyness (hard to pin down) on the system,
though...  random program crashes, minor visual corruption in X (which
fixes itself when you move things around), etc...  Anyone want to take a
swing at that?

-- andyw

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Monday, June 25, 2001 2:07 AM
To: Steven Walter
Cc: Andy Ward; linux-kernel@vger.kernel.org
Subject: Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))


> Great, glad to here it.  Who (if anyone) is still attempting to
unravel
> the puzzle of the Via southbridge bug?  You, Andy, should try and get
in
> touch with them and help debug this thing, if you're up to it.

The IWILL problem seems unrelated. Its the board that more than others
people
report fails totally when streaming memory copies using movntq
instructions.

The Athlon optimised kernel places pretty much the absolute maximum load

possible on the memory bus. Several people have reported that machines
that
are otherwise stable on the bios fast options require  the proper
conservative
settings to be stable with the Athlon optimisations

Alan

Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Alan Cox]

> Great, glad to here it.  Who (if anyone) is still attempting to unravel
> the puzzle of the Via southbridge bug?  You, Andy, should try and get in
> touch with them and help debug this thing, if you're up to it.

The IWILL problem seems unrelated. Its the board that more than others people
report fails totally when streaming memory copies using movntq instructions.

The Athlon optimised kernel places pretty much the absolute maximum load 
possible on the memory bus. Several people have reported that machines that
are otherwise stable on the bios fast options require  the proper conservative
settings to be stable with the Athlon optimisations

Alan

VIA Southbridge bug (Was: Crash on boot (2.4.5))

[Steven Walter]

Great, glad to here it.  Who (if anyone) is still attempting to unravel
the puzzle of the Via southbridge bug?  You, Andy, should try and get in
touch with them and help debug this thing, if you're up to it.

On Mon, Jun 25, 2001 at 01:17:57AM -0500, Andy Ward wrote:
> Well, I have tried your suggestion, and it works beautifully...  The
> only change I made was to the cpu type (to 686), and everything *just*
> works now...  Thanks, all!!!
> 
> > From the look of things, you're being bitten by the VIA southbridge
> > problem.  As I've gathered, its some sort of interaction with that chip
> > and the 3DNow! fast copy routines the kernel uses.
> > 
> > If you compile the kernel for a 686, does the problem go away?  What
> > about 586 or lower?  If so, I believe there are some people working on
> > finding common aspects of the hardware that experience this problem,
> > though I don't remember who.  You should get in contact with them, or
> > they might get into contact with you.
> > 
> > Good luck on working this out.
> > -- 
> > -Steven
> > In a time of universal deceit, telling the truth is a revolutionary act.
> > 			-- George Orwell
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell