mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ross Dickson <ross@datscreative.com.au>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	"Allen Martin" <AMartin@nvidia.com>,
	<linux-kernel@vger.kernel.org>
Cc: "Len Brown" <len.brown@intel.com>,
	Jesse Allen <the3dfxdude@hotmail.com>,
	"Prakash K. Cheemplavam" <PrakashKC@gmx.de>,
	Craig Bradney <cbradney@zip.com.au>,
	christian.kroener@tu-harburg.de,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Jamie Lokier <jamie@shareable.org>,
	Daniel Drake <dan@reactivated.net>, Ian Kumlien <pomac@vapor.com>
Subject: Re: IO-APIC on nforce2 [PATCH] + [PATCH] for nmi_debug=1 + [PATCH] for idle=C1halt, 2.6.5
Date: Wed, 5 May 2004 22:14:38 +1000	[thread overview]
Message-ID: <200405052214.38855.ross@datscreative.com.au> (raw)
In-Reply-To: <200405040111.01514.bzolnier@elka.pw.edu.pl>

On Tuesday 04 May 2004 09:11, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 04 of May 2004 00:09, Allen Martin wrote:
> > I'm happy to be able to make this information public to the Linux
> > community.  This information has been previously released to BIOS /
> > board vendors as an appnote, but in the interest of getting a workaround
> > into the hands of users the quickest we're making it public for possible
> > inclusion into the Linux kernel.
> 
> This is a great news!  Below is an untested patch to address this issue.
> 
> Cheers.
> 
> 
> [PATCH] fixup for C1 Halt Disconnect problem on nForce2 chipsets
> 
> Based on information provided by "Allen Martin" <AMartin@nvidia.com>.
> 
>  linux-2.6.6-rc3-bk2-bzolnier/arch/i386/pci/fixup.c |   39 +++++++++++++++++++++
>  1 files changed, 39 insertions(+)
> 
> diff -puN arch/i386/pci/fixup.c~nforce2_fix arch/i386/pci/fixup.c
> --- linux-2.6.6-rc3-bk2/arch/i386/pci/fixup.c~nforce2_fix	2004-05-04 00:27:18.114421672 +0200
> +++ linux-2.6.6-rc3-bk2-bzolnier/arch/i386/pci/fixup.c	2004-05-04 01:02:29.821393416 +0200
> @@ -187,6 +187,39 @@ static void __devinit pci_fixup_transpar
>  		dev->transparent = 1;
>  }
>  
> +/*
> + * Fixup for C1 Halt Disconnect problem on nForce2 systems.
> + *
> + * From information provided by "Allen Martin" <AMartin@nvidia.com>:
> + *
> + * A hang is caused when the CPU generates a very fast CONNECT/HALT cycle
> + * sequence.  Workaround is to set the SYSTEM_IDLE_TIMEOUT to 80 ns.
> + * This allows the state-machine and timer to return to a proper state within
> + * 80 ns of the CONNECT and probe appearing together.  Since the CPU will not
> + * issue another HALT within 80 ns of the initial HALT, the failure condition
> + * is avoided.
> + */
> +static void __devinit 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
> +	 * C17   0x1F01FF01  0x1F0FFF01
> +	 * C18D  0x9F01FF01  0x9F0FFF01
> +	 */
> +	fixed_val = rev < 0xC1 ? 0x1F01FF01 : 0x9F01FF01;
> +
> +	pci_read_config_dword(dev, 0x6c, &val);
> +	if (val != fixed_val) {
> +		printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnet fixup\n");
> +		pci_write_config_dword(dev, 0x6c, fixed_val);
> +	}
> +}
> +
>  struct pci_fixup pcibios_fixups[] = {
>  	{
>  		.pass		= PCI_FIXUP_HEADER,
> @@ -290,5 +323,11 @@ struct pci_fixup pcibios_fixups[] = {
>  		.device		= PCI_ANY_ID,
>  		.hook		= pci_fixup_transparent_bridge
>  	},
> +	{
> +		.pass		= PCI_FIXUP_HEADER,
> +		.vendor		= PCI_VENDOR_ID_NVIDIA,
> +		.device		= PCI_DEVICE_ID_NVIDIA_NFORCE2,
> +		.hook		= pci_fixup_nforce2
> +	},
>  	{ .pass = 0 }
>  };
> 
> _
> 
> 
> 
> 

Minor typo 
printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnet fixup\n");
should be
printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");

For 2.4.26 follows a rediffed patch. 
Note as per other postings this 
+static void __devinit pci_fixup_nforce2(struct pci_dev *dev)
should be
+static void __init pci_fixup_nforce2(struct pci_dev *dev)
which would match other 2.4 fixups e.g.
static void __init pci_fixup_transparent_bridge(struct pci_dev *dev)

Works well for 2.4.26 on my epox 8rga+. Yet to try on my albatron KM18G-pros.

To my knowledge the only thing left to sort out for the normal kernel
distro is what to do about the timer_ack issue in check_timer().

We need it off for nforce2 to get nmi_watchdog=1 working with ioapic
8254 timer pin0  timer override patch routing. I vote to revisit Maciej's
patch that was dropped by Linus after appearing in 2.6.3-mm3. 
For those with problems of clock skew with the timer into pin0 routing, 
that patch gave a virtual wire timer routing which worked well for those
users.

It also works around problems for ibm users.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/4421.html

That patch is last posted here (Maciej please correct me if i'm wrong)
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/3174.html

Here is rediffed nforce2 patch for 2.4.26

--- linux-2.4.26/arch/i386/kernel/pci-pc.c.orig 2003-11-29 04:26:19.000000000 +1000
+++ linux/arch/i386/kernel/pci-pc.c     2004-05-04 22:54:32.000000000 +1000
@@ -1326,10 +1326,43 @@ static void __init pci_fixup_transparent
        if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
            (dev->device & 0xff00) == 0x2400)
                dev->transparent = 1;
 }
 
+/*
+ * Fixup for C1 Halt Disconnect problem on nForce2 systems.
+ *
+ * From information provided by "Allen Martin" <AMartin@nvidia.com>:
+ *
+ * A hang is caused when the CPU generates a very fast CONNECT/HALT cycle
+ * sequence.  Workaround is to set the SYSTEM_IDLE_TIMEOUT to 80 ns.
+ * This allows the state-machine and timer to return to a proper state within
+ * 80 ns of the CONNECT and probe appearing together.  Since the CPU will not
+ * issue another HALT within 80 ns of the initial HALT, the failure condition
+ * is avoided.
+ */
+static void __devinit 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
+       * C17   0x1F01FF01      0x1F0FFF01
+       * C18D  0x9F01FF01      0x9F0FFF01
+       */
+       fixed_val = rev < 0xC1 ? 0x1F01FF01 : 0x9F01FF01;
+
+       pci_read_config_dword(dev, 0x6c, &val);
+       if (val != fixed_val) {
+               printk(KERN_WARNING "PCI: nForce2 C1 Halt Disconnect fixup\n");
+               pci_write_config_dword(dev, 0x6c, fixed_val);
+       }
+}
+
 struct pci_fixup pcibios_fixups[] = {
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82451NX,    pci_fixup_i450nx },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_DEVICE_ID_INTEL_82454GX,    pci_fixup_i450gx },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_UMC,      PCI_DEVICE_ID_UMC_UM8886BF,     pci_fixup_umc_ide },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_SI,       PCI_DEVICE_ID_SI_5513,          pci_fixup_ide_trash },
@@ -1341,10 +1374,11 @@ struct pci_fixup pcibios_fixups[] = {
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8622,         pci_fixup_via_northbridge_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8361,         pci_fixup_via_northbridge_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_VIA,      PCI_DEVICE_ID_VIA_8367_0,       pci_fixup_via_northbridge_bug },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_NCR,      PCI_DEVICE_ID_NCR_53C810,       pci_fixup_ncr53c810 },
        { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_INTEL,    PCI_ANY_ID,                     pci_fixup_transparent_bridge },
+       { PCI_FIXUP_HEADER,     PCI_VENDOR_ID_NVIDIA,   PCI_DEVICE_ID_NVIDIA_NFORCE2,   pci_fixup_nforce2},
        { 0 }
 };
 
 /*
  *  Called after each bus is probed, but before its children


Regards
Ross.






  parent reply	other threads:[~2004-05-05 12:10 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-03 22:09 Allen Martin
2004-05-03 23:11 ` Bartlomiej Zolnierkiewicz
2004-05-04  8:28   ` Prakash K. Cheemplavam
2004-05-04 21:10   ` Jeff Garzik
2004-05-04 21:29     ` Bartlomiej Zolnierkiewicz
2004-05-05 12:14   ` Ross Dickson [this message]
2004-05-05 12:27     ` Ian Kumlien
2004-05-05 13:12       ` Ross Dickson
2004-05-05 13:23         ` Ian Kumlien
2004-05-05 12:58     ` Maciej W. Rozycki
2004-05-05 12:48   ` Patrick Dreker
2004-05-05 13:34     ` Patrick Dreker
2004-05-05 11:24 ` Ross Dickson
2004-05-05 12:18   ` Ian Kumlien
2004-05-05 12:52     ` Ross Dickson
2004-05-05 13:08       ` Ian Kumlien
2004-05-06  1:50         ` Jesse Allen
  -- strict thread matches above, loose matches on Subject: below --
2004-05-04 20:38 Jesse Allen
2004-05-04 21:14 ` Craig Bradney
2004-05-03  8:08 Allen Martin
2004-04-23  1:30 Jesse Allen
2004-05-07  4:47 ` Richard James
2004-05-07  7:13   ` Craig Bradney
2004-05-08  5:33   ` Richard James
     [not found] <1KkKQ-2v9-9@gated-at.bofh.it>
     [not found] ` <1Kqdx-6E1-5@gated-at.bofh.it>
     [not found]   ` <1KH4I-3W9-11@gated-at.bofh.it>
     [not found]     ` <1LgOQ-7px-3@gated-at.bofh.it>
     [not found]       ` <1LlEY-36q-11@gated-at.bofh.it>
2004-04-15 23:07         ` Andi Kleen
2004-04-21 22:00           ` Len Brown
2004-04-13  1:17 IO-APIC on nforce2 Ross Dickson
2004-04-13  7:03 ` Ross Dickson
2004-04-14  1:02   ` IO-APIC on nforce2 [PATCH] Len Brown
2004-04-15 15:10     ` IO-APIC on nforce2 [PATCH] + [PATCH] for nmi_debug=1 + [PATCH] for idle=C1halt, 2.6.5 Ross Dickson
2004-04-15 20:17       ` Len Brown
2004-04-15 21:04         ` Craig Bradney
2004-04-21 20:22           ` Len Brown
2004-04-21 20:33             ` Ian Kumlien
2004-04-21 20:45             ` Craig Bradney
2004-04-21 21:28             ` Prakash K. Cheemplavam
2004-04-21 22:41               ` Len Brown
2004-04-22  7:26                 ` Prakash K. Cheemplavam
2004-04-22 14:58                   ` Len Brown
2004-04-22  8:45                 ` Craig Bradney
2004-04-22 15:03                   ` Len Brown
2004-04-22 20:50                     ` Craig Bradney
2004-04-22  8:50                 ` Arjen Verweij
2004-04-22 16:39                 ` Jesse Allen
2004-04-22 17:21                   ` Len Brown
2004-04-22 21:29                     ` Len Brown
2004-04-23  8:48                       ` Prakash K. Cheemplavam
2004-04-23  9:01                         ` Arjen Verweij
2004-04-23  9:08                           ` Prakash K. Cheemplavam
2004-04-23  9:11                           ` Prakash K. Cheemplavam
2004-04-23 12:18                       ` Maciej W. Rozycki
2004-04-26 11:41                     ` Ross Dickson
2004-04-27 17:02                       ` Arjen Verweij
2004-04-27 17:35                         ` Ian Kumlien
2004-04-27 18:00                         ` Len Brown
2004-04-27 18:24                           ` Arjen Verweij
2004-04-27 18:51                           ` Jussi Laako
2004-04-28 11:33                           ` Ross Dickson
2004-04-28 20:59                             ` Jesse Allen
2004-04-29 11:44                               ` Ross Dickson
2004-04-29 11:54                                 ` Maciej W. Rozycki
2004-04-29 12:00                                   ` Jamie Lokier
2004-04-29 12:26                                     ` Maciej W. Rozycki
2004-04-29 11:57                                 ` Jamie Lokier
2004-04-29 12:16                                 ` Craig Bradney
2004-04-29 20:24                                 ` Jesse Allen
2004-04-29 20:31                                   ` Prakash K. Cheemplavam
2004-05-03 20:45                                     ` Jesse Allen
2004-05-17 15:26                                       ` Prakash K. Cheemplavam
2004-05-17 19:32                                         ` Craig Bradney
2004-05-17 19:37                                           ` Prakash K. Cheemplavam
2004-05-17 19:57                                             ` Craig Bradney
2004-04-27 21:31                       ` Prakash K. Cheemplavam
2004-04-28 11:26                         ` Prakash K. Cheemplavam
2004-05-01  6:51                 ` Prakash K. Cheemplavam
2004-04-15 21:56         ` Arjen Verweij

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=200405052214.38855.ross@datscreative.com.au \
    --to=ross@datscreative.com.au \
    --cc=AMartin@nvidia.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=PrakashKC@gmx.de \
    --cc=cbradney@zip.com.au \
    --cc=christian.kroener@tu-harburg.de \
    --cc=dan@reactivated.net \
    --cc=jamie@shareable.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=pomac@vapor.com \
    --cc=the3dfxdude@hotmail.com \
    /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

Powered by JetHome