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.
next prev 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