public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Disconnect <lkml@sigkill.net>
To: ross@datscreative.com.au
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference)
Date: Mon, 15 Dec 2003 11:40:12 -0500	[thread overview]
Message-ID: <1071506410.2030.35.camel@slappy> (raw)
In-Reply-To: <200312131225.34937.ross@datscreative.com.au>

Thanks greatly for the tips, btw.  Its much appreciated :)

Also, I think I forgot to mention (doh) its an Epox 8rda+.

On Fri, 2003-12-12 at 21:25, Ross Dickson wrote:
> I am not certain your problems are nforce2 type specific.
> Standard response: I don't suppose you can try a different stick of ram?

Unfortunately not - its a single kingston hyper-x 3200 stick.  (In
theory I'll be moving it up to 700M or a gig in the next couple months,
at which point I'll be in position to swap ram around and so forth.)  I
did get the bios all tuned and run memtest-mmx on it for 24 hours before
the system installation though, and it passed.  What I did yesterday is
turn the memory frequency down from 200 to 166. (Which leaves the cpu
overclocked by about 33 mhz, something I think it will survive just fine
;) ..)

> The local apic ack delay timing patch needs athlon cpu and amd/nvidia ide on in 
> kern config to kick in. If you are using it then I highly recommend uniprocessor 
> ioapic config as well to go with it to route the 8254 timer irq0 through pin 0 of 
> ioapic as using the apic config alone leaves a lot of ints generated on irq7 
> which can cause problems. (Reason for 8259 making them spurious on irq7 
> is explained in 8259A data sheet)

Thats how I'm running it now - its gone about 1 day without any oopses. 
(In the past it would go anywhere from hours to about a week, so the
results aren't in yet.)  

On the basis of it being a memory issue I poked around the epox site and
noticed something I hadn't seen before - they recommend what might be
different memory timings (I'll have to check if/when it crashes again):

If your PC3200 memory is not stable try the following BIOS settings:

Memory Frequency = 100%
Memory Timing = Expert
T(RAS) = 7
T(RCD) = 3
T(RP) = 3
CAS Latency = 2.5

Adjust the memory frequency above until you reach the resulting
frequency of 200MHz (for PC3200).

-- 
Disconnect <lkml@sigkill.net>


  parent reply	other threads:[~2003-12-15 16:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-13  2:25 [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference) Ross Dickson
2003-12-13  5:02 ` Bob
2003-12-15 16:40 ` Disconnect [this message]
2003-12-18 18:52   ` Disconnect
2003-12-19 17:24     ` Disconnect
2003-12-19 20:22       ` Craig Bradney
2003-12-19 20:32         ` Disconnect
2003-12-20 12:30         ` Voicu Liviu
  -- strict thread matches above, loose matches on Subject: below --
2003-12-11 16:16 Disconnect
2003-12-11 16:38 ` Josh McKinney
2003-12-11 17:19   ` Disconnect
2003-12-11 17:22 ` Disconnect

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=1071506410.2030.35.camel@slappy \
    --to=lkml@sigkill.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ross@datscreative.com.au \
    /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