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>
next prev 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