public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: gjury <gjury@grips.com>
To: Mark Hahn <hahn@physics.mcmaster.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Athlon/MSI mobo combo broken?
Date: Thu, 09 Aug 2001 10:59:56 +0200	[thread overview]
Message-ID: <3B72510C.2020503@grips.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10108082057430.10284-100000@coffee.psychology.mcmaster.ca>

I did not say chipset at all.
You seem to miss the fact, that >= 40 % of the SDRAM modules are not 
even close to the spec.
The german magazin ct can sing a song about it. http://www.heise.de/ct
Software has nothing to do with this.
The windows installation on my PC suffert from the same effects.
It was just harder to spot there below ... .
Every memory tester i tried was showing no problems at all.
It may be triggered more likely or not, but bad SDRAM cannot be fixed in 
software.
Thats my own only plausible theory.

regards
gerold

Mark Hahn wrote:

>>If you have PC100 SDRAM try to replace it with PC133.
>>
>
>ugh, this is the same (mistaken) approach as turning off CONFIG_MK7:
>cripple performance enough that your system works.  turning off 
>CONFIG_MK7 disables Arjan's nice code in mmx.c which delivers 
>2-4x the copy/zero-page bandwidth...
>
>there *are* stable via/athlon systems, and that indicates that the 
>problem is not inherent to the chipset.  I have a gigabyte ga-7zx,
>duron/600, pc133 system that has always been rock-solid.  and I 
>recently built an Asus a7v-133, tbird/1199, pc133 system that is
>also entirely stable.  both run cas2 pc133, CONFIG_MK7 kernels, etc.
>both have fairly generous power supplies.
>
>so far, the only plausible theory is that some individual factor(s)
>(MB, bios settings, power quality, dram quality, etc) causes 
>the instability that some people report.
>
>regards, mark hahn.
>



  reply	other threads:[~2001-08-09  8:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-23 16:02 Athlon/MSI mobo combo broken? Felix von Leitner
2001-07-23 17:32 ` Alan Cox
2001-07-23 22:05   ` Dan Hollis
2001-07-25 14:25     ` Miloslaw Smyk
2001-07-26 19:39   ` Gerbrand van der Zouw
2001-08-08 17:08     ` jury gerold
2001-08-08 21:08       ` Mark Hahn
2001-08-09  8:59         ` gjury [this message]
2001-08-09 14:55           ` Mike Frisch
  -- strict thread matches above, loose matches on Subject: below --
2001-08-08 21:35 Manuel A. McLure
2001-08-08 22:14 ` Mike Frisch

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=3B72510C.2020503@grips.com \
    --to=gjury@grips.com \
    --cc=hahn@physics.mcmaster.ca \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox