Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 May 2006 11:21:00 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-acpi@freebsd.org
Cc:        Andriy Gapon <avg@icyb.net.ua>
Subject:   Re: 5.4=>6.1 regression: nforce2 vs. APIC [+fix]
Message-ID:  <200605191121.01775.jhb@freebsd.org>
In-Reply-To: <200605191116.06248.jhb@freebsd.org>
References:  <446DD5EB.6030300@icyb.net.ua> <200605191116.06248.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 19 May 2006 11:16, John Baldwin wrote:
> On Friday 19 May 2006 10:27, Andriy Gapon wrote:
> > [Disclaimer, just in case: I do mean APIC, not ACPI]
> >
> > This is a good lesson for me for not trying any RCs or BETAs in due time.
> >
> > Short description of my system: nforce2 based motherboard NF-7 v2 with
> > the latest BIOS (v2.7), CPU is Athlon XP.
> >
> > ...
> >
> > Based on that info and the linux patch in that thread I came up with the
> > following PCI fixup. Now I am running 6.1 with both APIC and "C1
> > disconnect" enabled for 2 days without any problems.
>
> Good find!  The patch looks good.  I've modified it slight to expand
> the comment and to make it more paranoid and only trigger for
> bus/slot/function 0/0/0 like the post mentions along with a minor
> tweak to the printf.  Can you test to make sure I didn't break anything in
> the process?

So somehow I lost the patch, so here's another try:

Index: fixup_pci.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/pci/fixup_pci.c,v
retrieving revision 1.6
diff -u -r1.6 fixup_pci.c
--- fixup_pci.c	30 May 2004 17:57:41 -0000	1.6
+++ fixup_pci.c	19 May 2006 15:14:26 -0000
@@ -51,6 +51,7 @@
 
 static int	fixup_pci_probe(device_t dev);
 static void	fixwsc_natoma(device_t dev);
+static void	fixc1_nforce2(device_t dev);
 
 static device_method_t fixup_pci_methods[] = {
     /* Device interface */
@@ -76,6 +77,9 @@
     case 0x12378086:		/* Intel 82440FX (Natoma) */
 	fixwsc_natoma(dev);
 	break;
+    case 0x01e010de:		/* nVidia nForce2 */
+	fixc1_nforce2(dev);
+	break;
     }
     return(ENXIO);
 }
@@ -100,3 +104,37 @@
     }
 #endif
 }
+
+/*
+ * Set the SYSTEM_IDLE_TIMEOUT to 80 ns on nForce2 systems to work
+ * around a hang that is triggered when the CPU generates a very fast
+ * CONNECT/HALT cycle sequence.  Specifically, the hang can result in
+ * the lapic timer being stopped.
+ *
+ * This requires changing the value for config register at offset 0x6c
+ * for the Host-PCI bridge at bus/dev/function 0/0/0:
+ *
+ * Chip	Current Value	New Value
+ * ----	----------	----------
+ * C17	0x1F0FFF01	0x1F01FF01
+ * C18D	0x9F0FFF01	0x9F01FF01
+ *
+ * We do this by always clearing the bits in 0x000e0000.
+ *
+ * See also: http://lkml.org/lkml/2004/5/3/157
+ */
+static void
+fixc1_nforce2(device_t dev)
+{
+	uint32_t val;
+
+	if (pci_get_bus(dev) == 0 && pci_get_slot(dev) == 0 &&
+	    pci_get_function(dev) == 0) {
+		val = pci_read_config(dev, 0x6c, 4);
+		if (val & 0x000e0000) {
+			printf("Correcting nForce2 C1 CPU disconnect hangs\n");
+			val &= ~0x000e0000;
+			pci_write_config(dev, 0x6c, val, 4);
+		}
+	}
+}

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605191121.01775.jhb>