With so many people reporting that 2.6.6 fixed the nForce2 hard lock
problem I soon started using it. However, on my system it would still
lock up! I tried disabling APIC, IO-APIC, ACPI, PREEMPT, etc. to no
avail.
After looking into the pci_fixup_nforce2() function, I saw that it was
expecting one of two cases for the PCI config value: 0x1F0FFF01 or
0x9F0FFF01, then, depending on the PCI revision ID it would set the
config value to 0x1F01FF01 or 0x9F01FF01 resp. I looked at the value
of my nForce2 board and saw that it was actually 0x8F0FFF01.
So the current 2.6.6 fixup was inadvertently flipping the high nibble
to 0x9 in my case. Since the fixup is actually idependent of the PCI
revision ID (the 5th nibble is changed from 0xF to 0x1 in either
case), I tried explicitly changing only that part of the config value.
Sure enough, for the first time in a while my system is finally stable
again.
My patch is attached. Comments please!
#
# Do not modify the entire PCI config dword, but only the C1 halt
# disconnect related nibble.
#
--- linux-2.6.6/arch/i386/pci/fixup.c Mon May 10 11:32:53 2004
+++ /usr/src/linux-2.6.6/arch/i386/pci/fixup.c Fri Jun 4 10:27:05 2004
@@ -202,9 +202,6 @@
static void __init pci_fixup_nforce2(struct pci_dev *dev)
{
u32 val, fixed_val;
- u8 rev;
-
- pci_read_config_byte(dev, PCI_REVISION_ID, &rev);
/*
* Chip Old value New value
@@ -214,9 +211,10 @@
* Northbridge chip version may be determined by
* reading the PCI revision ID (0xC1 or greater is C18D).
*/
- fixed_val = rev < 0xC1 ? 0x1F01FF01 : 0x9F01FF01;
pci_read_config_dword(dev, 0x6c, &val);
+ fixed_val = val & 0xFFF1FFFF;
+
if (val != fixed_val) {
printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");
pci_write_config_dword(dev, 0x6c, fixed_val);
--
Aric Cyr <acyr at alumni dot uwaterloo dot ca>
On Friday 04 of June 2004 04:26, Aric Cyr wrote:
> With so many people reporting that 2.6.6 fixed the nForce2 hard lock
> problem I soon started using it. However, on my system it would still
> lock up! I tried disabling APIC, IO-APIC, ACPI, PREEMPT, etc. to no
> avail.
>
> After looking into the pci_fixup_nforce2() function, I saw that it was
> expecting one of two cases for the PCI config value: 0x1F0FFF01 or
> 0x9F0FFF01, then, depending on the PCI revision ID it would set the
> config value to 0x1F01FF01 or 0x9F01FF01 resp. I looked at the value
> of my nForce2 board and saw that it was actually 0x8F0FFF01.
>
> So the current 2.6.6 fixup was inadvertently flipping the high nibble
> to 0x9 in my case. Since the fixup is actually idependent of the PCI
> revision ID (the 5th nibble is changed from 0xF to 0x1 in either
> case), I tried explicitly changing only that part of the config value.
> Sure enough, for the first time in a while my system is finally stable
> again.
>
> My patch is attached. Comments please!
If bit 0x10000000 is not set then C1 Halt Disconnect is disabled.
I have reports that it is unsupported on some boards.
So what about patch below instead?
[PATCH] apply nForce2 fixup only if C1 Halt Disconnect is enabled
Some boards don't support C1 Halt Disconnect.
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
linux-2.6.7-rc2-bk2-bzolnier/arch/i386/pci/fixup.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletion(-)
diff -puN arch/i386/pci/fixup.c~nForce2_C1Halt_fixup arch/i386/pci/fixup.c
--- linux-2.6.7-rc2-bk2/arch/i386/pci/fixup.c~nForce2_C1Halt_fixup 2004-06-03 16:52:46.556771744 +0200
+++ linux-2.6.7-rc2-bk2-bzolnier/arch/i386/pci/fixup.c 2004-06-03 16:58:17.275494856 +0200
@@ -226,7 +226,12 @@ static void __init pci_fixup_nforce2(str
fixed_val = rev < 0xC1 ? 0x1F01FF01 : 0x9F01FF01;
pci_read_config_dword(dev, 0x6c, &val);
- if (val != fixed_val) {
+
+ /*
+ * Apply fixup only if C1 Halt Disconnect is enabled
+ * (bit28) because it is not supported on some boards.
+ */
+ if ((val & (1 << 28)) && val != fixed_val) {
printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");
pci_write_config_dword(dev, 0x6c, fixed_val);
}
_
On Thu, Jun 03, 2004 at 05:12:51PM +0200, Bartlomiej Zolnierkiewicz wrote:
> If bit 0x10000000 is not set then C1 Halt Disconnect is disabled.
> I have reports that it is unsupported on some boards.
>
> So what about patch below instead?
Thanks Bartlomiej. I reversed my patch and have applied yours and am
testing it now. If my system doesn't freeze at all today, I think
that this should be a sufficient (and necessary!) patch.
One thing that bothers me though is that 2.6.5 was unstable in the
same way as far as I can recall. Since this fixup was not included,
do you think it could have been related to something else that was
fixed in 2.6.6? Maybe IO-APIC or the "acpi_skip_timer_override"
bootparam maybe?
Thanks again!
--
Aric Cyr <acyr at alumni dot uwaterloo dot ca>
On Fri, Jun 04, 2004 at 10:20:04PM +0900, Aric Cyr wrote:
> Thanks Bartlomiej. I reversed my patch and have applied yours and am
> testing it now. If my system doesn't freeze at all today, I think
> that this should be a sufficient (and necessary!) patch.
Well my system is still running strong after more than 3 hours, so I
think it is safe to say that your patch is working fine. Thanks for
getting this fixed. I hope it is in time for 2.6.7!
--
Aric Cyr <acyr at alumni dot uwaterloo dot ca>
On Friday 04 of June 2004 18:26, Aric Cyr wrote:
> On Fri, Jun 04, 2004 at 10:20:04PM +0900, Aric Cyr wrote:
> > Thanks Bartlomiej. I reversed my patch and have applied yours and am
> > testing it now. If my system doesn't freeze at all today, I think
> > that this should be a sufficient (and necessary!) patch.
>
> Well my system is still running strong after more than 3 hours, so I
> think it is safe to say that your patch is working fine. Thanks for
> getting this fixed. I hope it is in time for 2.6.7!
Thanks, this patch is merged now.