public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: jury gerold <geroldj@grips.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Thodoris Pitikaris <thodoris@cs.teiher.gr>, linux-kernel@vger.kernel.org
Subject: Re: is this a bug?
Date: Fri, 10 Aug 2001 14:22:01 +0200	[thread overview]
Message-ID: <3B73D1E9.9020800@grips.com> (raw)
In-Reply-To: <3B6FD644.7020409@cs.teiher.gr> <3B716E0A.8030005@grips.com> <m1g0b0th21.fsf@frodo.biederman.org>

Hi Eric

The CPU is a 1.1GHz tbird 200MHz FSB and i am running it this way.
The motherboard can do 100 and 133 MHz but i run
the SDRAM at 100MHz from the beginning, since i have seen lot's
of boards with memory problems and i wanted to be on the good side.
Both, the old 128MB and the new 256MB SDRAM where sold as PC133.
It is a single DIMM in both cases.

When i started to sue the SDRAM for the trouble i checked the SPD and found
the 128MB-PC133 was actually a PC100 with a few steps towards PC66 
(major brand).
So i tried a new one that, at least from the SPD, is a real PC133 and 
suddenly ...

I have tried to kill it

kernel 2.4.7-xfs from cvs at the moment
athlon optimisations
UDMA on ide0 and ide1
2 harddrives, 1 cdrom, 1 cd/rw

since then, but it works, works, works.


This weekend does not see me at home.
I will send the timings on sunday/monday.

What do you expect to get out of this ?

Gerold


Eric W. Biederman wrote:

>jury gerold <geroldj@grips.com> writes:
>
>>I have the same motherboard, same chipset, same CPU and the same crash.
>>No memory test cpu burn UDMA on/off, replace or remove of components
>>did any good.
>>Then i replaced the 100mhz SDRAM with a 133mhz and it is 100 % stable since
>>then.
>>
>>No matter which compiler, kernel version, cputype.
>>It simply works now.
>>
>
>Do you happen to have the SDRAM timings of the two sets of DIMMS?
>It would be interesting to see what changed besides the clock speed on
>the DIMMS.  I'm assuming your PC133 DIMMs are running at at 133Mhz,
>and you aren't over clocking anything.
>
>Eric
>



  reply	other threads:[~2001-08-10 12:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-07 11:51 is this a bug? Thodoris Pitikaris
2001-08-07 13:51 ` Andrzej Krzysztofowicz
2001-08-08  2:19 ` Dr. Kelsey Hudson
2001-08-08  3:15   ` J Sloan
2001-08-08  3:45     ` Dr. Kelsey Hudson
2001-08-08 10:53       ` David Weinehall
2001-08-08 11:05   ` Alan Cox
2001-08-08 12:59   ` Ron Flory
2001-08-08 16:51 ` jury gerold
2001-08-10  9:12   ` Eric W. Biederman
2001-08-10 12:22     ` jury gerold [this message]
2001-08-10 16:22       ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2011-03-24  0:46 Jay
2011-03-25 15:18 ` Steven Rostedt
2017-06-21  3:08 Is " Peter Teoh

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=3B73D1E9.9020800@grips.com \
    --to=geroldj@grips.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thodoris@cs.teiher.gr \
    /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