Re: [2.4] Nforce2 oops and occasional hang (tried the lockups patch,no difference)
From: Bob
Date: Sat Dec 13 2003 - 00:13:03 EST
- Next message: Ross Dickson: "Re: Working nforce2, was Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered"
- Previous message: Bob: "Re: Working nforce2, was Re: Fixes for nforce2 hard lockup, apic,io-apic, udma133 covered"
- In reply to: Ross Dickson: "Re: [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference)"
- Next in thread: Disconnect: "Re: [2.4] Nforce2 oops and occasional hang (tried the lockupspatch, no difference)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ross Dickson wrote:
Oh, and the modules list:
Module Size Used by Tainted: P
i2c-dev 4548 0 (unused)
i2c-core 13604 0 [i2c-dev]
<snip>
I am not certain your problems are nforce2 type specific.
Standard response: I don't suppose you can try a different stick of ram?
Yes, and stock settings with tested ram may
be necessary with nforce2, possibly related to our
timing-related voodoo culture(might overclock
later on in life as timing-related patches evolve).
I have a via board that only recognizes two of
four generic ram sticks, but second stick will cause
an oops soon after. Another via setup will oops
if any fast ram settings(4-way,csl2 etc) is attempted,
though only using tested cas2 ram. "Try a different
stick of ram".
On nforce2 I'm able to use bios "performance"
ram timing but if I manually tweak all the ram
settings up like I can do on other systems, I
get mem-related OOPS with nforce2.
acpi apic lapic amd pre-empt nforce2ide
(once you start you have to go all the way)
The reason I say that is that oops were very uncommon on either the
epox 8rga+ or albatron km18G-pro MOBOS upon which I developed my
patches. Hard lockups were pretty much all I experienced prior to the
patches except for an occasional X fail. Base OS flavour I
use is Suse 8.2 including gcc version (web updates utilised)
The udma patches are really just a cleanup on the address setup timing so
I do not think that they are a factor.
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)
Also I now use a small patch to fixup proc info - only if you are using
the 64 bit jiffies var hz patch, avail here:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-12/0838.html
If you try acpi=off on boot and it is then not very stable then I think it has
little to do with lockups patch as that is my fallback mode when I am
playing with apic ioapic code.
Another fallback I use at times is
hdparm -Xudma3 /dev/hda
Hope this helps the confusion
Regards
Ross
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Next message: Ross Dickson: "Re: Working nforce2, was Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered"
- Previous message: Bob: "Re: Working nforce2, was Re: Fixes for nforce2 hard lockup, apic,io-apic, udma133 covered"
- In reply to: Ross Dickson: "Re: [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference)"
- Next in thread: Disconnect: "Re: [2.4] Nforce2 oops and occasional hang (tried the lockupspatch, no difference)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]