VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug)

VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug)

[Troels Walsted Hansen]

Remember the pci_fixup_via_athlon_bug() (AKA "Athlon bug stomper")
function which went into kernel 2.4.14 after much discussion?

Apparently the mysterious register 55 in the Northbridge controls a
buggy Memory Write Queue timer. They finally acknowledged the problem
when Nvidia drivers and Windows XP started pushing the hardware enough
to trigger the bug...

http://bbs.pcstats.com/viahardware/messageview.cfm?catid=19&threadid=863
8

-- 
Troels Walsted Hansen

Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon optimizations bug)

[Calin A. Culianu]

So does this mean we will be seeing a patch that clears bits 6,7, and 8 in
register 55 on the northbridge soon?

-Calin

On Wed, 5 Dec 2001, Troels Walsted Hansen wrote:

> Remember the pci_fixup_via_athlon_bug() (AKA "Athlon bug stomper")
> function which went into kernel 2.4.14 after much discussion?
>
> Apparently the mysterious register 55 in the Northbridge controls a
> buggy Memory Write Queue timer. They finally acknowledged the problem
> when Nvidia drivers and Windows XP started pushing the hardware enough
> to trigger the bug...
>
> http://bbs.pcstats.com/viahardware/messageview.cfm?catid=19&threadid=863
> 8
>
>

Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon

[Alan Cox]

> So does this mean we will be seeing a patch that clears bits 6,7, and 8 in
> register 55 on the northbridge soon?

We already have one. The Linux folks saw the problem much earlier than
windows people because our athlon optimised memory copies triggered it
reliably on many boards.

Whats sad is its taken VIA this long to finally acknowledge a bug that we
have shown existed months and months ago, and even had Linux fixes for a 
while in 2.4

Alan

Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon

[Petri Kaukasoina]

On Thu, Dec 06, 2001 at 12:41:36AM +0000, Alan Cox wrote:
> We already have one. The Linux folks saw the problem much earlier than
> windows people because our athlon optimised memory copies triggered it
> reliably on many boards.

The details were a bit different in that web page:

Linux looks for chip with id 1106:0305 (KT133) and clears only bit 7 of
register 55. The Windows driver checks for chips 1106:0305, 1106:3099,
1106:3102, 1106:3112, and clears three bits: bits 5-7 of that register. In
addition, the web page tells that it's probably not right for 1106:3099
(KT266) because there it should be register 95.

Maybe this is not relevant: maybe all BIOSes for KT266 chipsets already set
the right values and maybe KT133 boards with problems only have bit 7 set,
not bits 5 and 6. (PCs here with KT133 already have all bits 5-7 zero in
reg. 55 and PCs with KT266 have bits 5-7 both in reg. 55 and 95 zero.)

Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon

[Calin A. Culianu]

On Thu, 6 Dec 2001, Petri Kaukasoina wrote:

> On Thu, Dec 06, 2001 at 12:41:36AM +0000, Alan Cox wrote:
> > We already have one. The Linux folks saw the problem much earlier than
> > windows people because our athlon optimised memory copies triggered it
> > reliably on many boards.
>
> The details were a bit different in that web page:
>
> Linux looks for chip with id 1106:0305 (KT133) and clears only bit 7 of
> register 55. The Windows driver checks for chips 1106:0305, 1106:3099,
> 1106:3102, 1106:3112, and clears three bits: bits 5-7 of that register. In
> addition, the web page tells that it's probably not right for 1106:3099
> (KT266) because there it should be register 95.
>
> Maybe this is not relevant: maybe all BIOSes for KT266 chipsets already set
> the right values and maybe KT133 boards with problems only have bit 7 set,
> not bits 5 and 6. (PCs here with KT133 already have all bits 5-7 zero in
> reg. 55 and PCs with KT266 have bits 5-7 both in reg. 55 and 95 zero.)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Here is the webpage:

This patch detects the 0305, 3099, 3102, and 3112 (KT133x, KT266x, VT8662,
and KLE133) *only*. On these chipsets, it will patch register 55 in the
Northbridge, which will supposedly switch off a Memory Write Queue timer.
In the KT133A datasheet, register 55 is "reserved". But - yikes! - in the
KT266, the documented MWQ register is register 95, not 55. Register 55
contains unrelated DDR timing adjustments and could actually be dangerous
to program. For this reason, I do not recommend installing this driver on
the KT266x chipsets until VIA examines this issue. For now, use WPCREDIT
and set bits 5, 6, and 7 to zero in register 95 instead."

----

Clearly, we need to modify the via workaround patches to take into account
the other via device id's (namely 3099, 3102, and 3112), and for each one
change the appropriate register.  Either register 55 or in the case of the
kt266x, register 95.  I am grepping through quirks.c right now and it
seems this would be the correct file to modify.. any other suggestions on
what file to modify?

I am going to play with this right now myself using user-space tools and
experiment to see if it solves my issues with my 33-node beowulf cluster
(all nodes use the kt266) being very unstable.

Read again: I seriously believe that I am a person who is afflicted by
this (or some other unknown) hardware bug as any linux kernel I try is
relatively unstable (approx 5% per day chance of crash -- 13% chance if we
turn on athlon optimizations)!  This means that in a few weeks, almost all
of our beowulf nodes go down if left unattended!  And I KNOW it's not due
to cpu temperature, wrong GCC version, or any other really obvious thing..

-Calin

[PATCH][highly-experimental] via-mwq (Was: Re: VIA acknowledges North Bridge bug...)

[Martin Eriksson]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

----- Original Message -----
From: "Calin A. Culianu" <calin@ajvar.org>
To: "Petri Kaukasoina" <kaukasoi@elektroni.ee.tut.fi>
Cc: <linux-kernel@vger.kernel.org>
Sent: Thursday, December 06, 2001 11:09 PM
Subject: Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon

> Here is the webpage:
>
> This patch detects the 0305, 3099, 3102, and 3112 (KT133x, KT266x, VT8662,
> and KLE133) *only*. On these chipsets, it will patch register 55 in the
> Northbridge, which will supposedly switch off a Memory Write Queue timer.
> In the KT133A datasheet, register 55 is "reserved". But - yikes! - in the
> KT266, the documented MWQ register is register 95, not 55. Register 55
> contains unrelated DDR timing adjustments and could actually be dangerous
> to program. For this reason, I do not recommend installing this driver on
> the KT266x chipsets until VIA examines this issue. For now, use WPCREDIT
> and set bits 5, 6, and 7 to zero in register 95 instead."
>
> ----
>
> Clearly, we need to modify the via workaround patches to take into account
> the other via device id's (namely 3099, 3102, and 3112), and for each one
> change the appropriate register.  Either register 55 or in the case of the
> kt266x, register 95.  I am grepping through quirks.c right now and it
> seems this would be the correct file to modify.. any other suggestions on
> what file to modify?

I've (hastily) put these changes into "arch/i386/kernel/pci-pc.c" and had to
modify "include/linux/pci_ids.h" too.

The patch is included, but a warning: I have no VIA based computer that I
can test this on myself...

_____________________________________________________
|  Martin Eriksson <nitrax@giron.wox.org>
|  MSc CSE student, department of Computing Science
|  Umeå University, Sweden


[-- Attachment #2: via-mwq.patch --]
[-- Type: application/octet-stream, Size: 2693 bytes --]

--- linux-2.4.16/arch/i386/kernel/pci-pc.c	Fri Nov  9 22:58:02 2001
+++ linux-2.4.16-devel/arch/i386/kernel/pci-pc.c	Fri Dec  7 11:00:01 2001
@@ -1109,25 +1109,38 @@
 }
 
 /*
- * Nobody seems to know what this does. Damn.
- *
- * But it does seem to fix some unspecified problem
+ * This does seem to fix some unspecified problem
  * with 'movntq' copies on Athlons.
  *
- * VIA 8363 chipset:
- *  - bit 7 at offset 0x55: Debug (RW)
+ * VIA 8361/8363/8662 chipset:
+ *  - bit 7,6,5 at offset 0x55: Debug (RW)
  */
 static void __init pci_fixup_via_athlon_bug(struct pci_dev *d)
 {
 	u8 v;
 	pci_read_config_byte(d, 0x55, &v);
-	if (v & 0x80) {
-		printk("Trying to stomp on Athlon bug...\n");
-		v &= 0x7f; /* clear bit 55.7 */
+	if (v & 0xE0) {
+		printk("PCI: Disabling VIA VT8361/8363/8662 Memory Write Queue\n");
+		v &= 0x1f; /* clear bit 55.7, 6, 5 */
 		pci_write_config_byte(d, 0x55, v);
 	}
 }
 
+/*
+ * VIA 8366 chipset:
+ *  - bit 7,6,5 at offset 0x95: Debug (RW)
+ */
+static void __init pci_fixup_via_kt266_athlon_bug(struct pci_dev *d)
+{
+	u8 v;
+	pci_read_config_byte(d, 0x95, &v);
+	if (v & 0xE0) {
+		printk("PCI: Disabling VIA VT8366 Memory Write Queue\n");
+		v &= 0x1f; /* clear bit 55.7, 6, 5 */
+		pci_write_config_byte(d, 0x95, v);
+	}
+}
+
 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 },
@@ -1138,6 +1151,9 @@
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SI,	PCI_DEVICE_ID_SI_5598,		pci_fixup_latency },
  	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371AB_3,	pci_fixup_piix4_acpi },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8363_0,	pci_fixup_via_athlon_bug },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8366_0,	pci_fixup_via_kt266_athlon_bug },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8662_0,	pci_fixup_via_athlon_bug },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_8361_0,	pci_fixup_via_athlon_bug },
 	{ 0 }
 };
 
--- linux-2.4.16/include/linux/pci_ids.h	Fri Nov  9 23:11:15 2001
+++ linux-2.4.16-devel/include/linux/pci_ids.h	Fri Dec  7 00:25:12 2001
@@ -948,6 +948,9 @@
 #define PCI_DEVICE_ID_VIA_8233_0	0x3074
 #define PCI_DEVICE_ID_VIA_8233C_0	0x3109
 #define PCI_DEVICE_ID_VIA_8633_0	0x3091
+#define PCI_DEVICE_ID_VIA_8366_0	0x3099
+#define PCI_DEVICE_ID_VIA_8662_0	0x3102
+#define PCI_DEVICE_ID_VIA_8361_0	0x3112
 #define PCI_DEVICE_ID_VIA_8367_0	0x3099
 #define PCI_DEVICE_ID_VIA_86C100A	0x6100
 #define PCI_DEVICE_ID_VIA_8231		0x8231

Re: [PATCH][highly-experimental] via-mwq (Was: Re: VIA acknowledges North Bridge bug...)

[Pozsar Balazs]

On Fri, 7 Dec 2001, Martin Eriksson wrote:

> I've (hastily) put these changes into "arch/i386/kernel/pci-pc.c" and had to
> modify "include/linux/pci_ids.h" too.
>
> The patch is included, but a warning: I have no VIA based computer that I
> can test this on myself...


I noticed one little typo:

[...]
+static void __init pci_fixup_via_kt266_athlon_bug(struct pci_dev *d)
+{
+	u8 v;
+	pci_read_config_byte(d, 0x95, &v);
+	if (v & 0xE0) {
+		printk("PCI: Disabling VIA VT8366 Memory Write Queue\n");
+		v &= 0x1f; /* clear bit 55.7, 6, 5 */
                                       ^^^^^
+		pci_write_config_byte(d, 0x95, v);
+	}
+}
+

It should also be 95 imho.

regards,
-- 
Balazs Pozsar

Re: [PATCH][highly-experimental] via-mwq (Was: Re: VIA acknowledges North Bridge bug...)

[Calin A. Culianu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2238 bytes --]


I wrote a patch as well.. and tested it.. It works fine.  I would
recommend not writing an entirely new function.  It's a bit more efficient
just to overload the athlon bug stomper function and register it for a few
extra chipsets.

I will post my patch tha tbasically works just like your patch but has a
smaller footprint..  :)

-Calin


On Fri, 7
Dec 2001, Martin Eriksson wrote:

> ----- Original Message -----
> From: "Calin A. Culianu" <calin@ajvar.org>
> To: "Petri Kaukasoina" <kaukasoi@elektroni.ee.tut.fi>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Thursday, December 06, 2001 11:09 PM
> Subject: Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon
>
> > Here is the webpage:
> >
> > This patch detects the 0305, 3099, 3102, and 3112 (KT133x, KT266x, VT8662,
> > and KLE133) *only*. On these chipsets, it will patch register 55 in the
> > Northbridge, which will supposedly switch off a Memory Write Queue timer.
> > In the KT133A datasheet, register 55 is "reserved". But - yikes! - in the
> > KT266, the documented MWQ register is register 95, not 55. Register 55
> > contains unrelated DDR timing adjustments and could actually be dangerous
> > to program. For this reason, I do not recommend installing this driver on
> > the KT266x chipsets until VIA examines this issue. For now, use WPCREDIT
> > and set bits 5, 6, and 7 to zero in register 95 instead."
> >
> > ----
> >
> > Clearly, we need to modify the via workaround patches to take into account
> > the other via device id's (namely 3099, 3102, and 3112), and for each one
> > change the appropriate register.  Either register 55 or in the case of the
> > kt266x, register 95.  I am grepping through quirks.c right now and it
> > seems this would be the correct file to modify.. any other suggestions on
> > what file to modify?
>
> I've (hastily) put these changes into "arch/i386/kernel/pci-pc.c" and had to
> modify "include/linux/pci_ids.h" too.
>
> The patch is included, but a warning: I have no VIA based computer that I
> can test this on myself...
>
> _____________________________________________________
> |  Martin Eriksson <nitrax@giron.wox.org>
> |  MSc CSE student, department of Computing Science
> |  Umeå University, Sweden
>
>

Re: VIA acknowledges North Bridge bug (AKA Linux Kernel with Athlon

[Calin A. Culianu]

On Thu, 6 Dec 2001, Alan Cox wrote:

> > So does this mean we will be seeing a patch that clears bits 6,7, and 8 in
> > register 55 on the northbridge soon?
>
> We already have one. The Linux folks saw the problem much earlier than
> windows people because our athlon optimised memory copies triggered it
> reliably on many boards.
>
> Whats sad is its taken VIA this long to finally acknowledge a bug that we
> have shown existed months and months ago, and even had Linux fixes for a
> while in 2.4


There seems to be some confusion though.. I probably should just read the
code myself.. but it seems from what I've read that the patch we had
didn't clear all the bits and that maybe on the KT266, the chipset isn't
being detected as 'buggy' by the patch so nothing is being cleared... is
this correct?  If not would you mind taking the time to just tell me where
in the code I can grep for the patch?


> > Alan
>