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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.