Athlon Optimization Problem

Athlon Optimization Problem

[Steven Hassani]

	I'm running a compaq presario 700us: duron 950 mhz on a via mobo
(vt8363/8365 etc).  When running kernel 2.4.17 with athlon optimizations,
the box has kernel panics, segmentation faults, and other errors.
When setting to K6 though, the box appears to be stable.  So does the fix
included in pci-pc.c not work with my system?  Has anyone else been
getting these errors after using this fix?  Thanks.
Steve

Re: Athlon Optimization Problem

[Steven Hassani]

On Sat, 26 Jan 2002, Steven Hassani wrote:

> 	I'm running a compaq presario 700us: duron 950 mhz on a via mobo
> (vt8363/8365 etc).  When running kernel 2.4.17 with athlon optimizations,
> the box has kernel panics, segmentation faults, and other errors.
> When setting to K6 though, the box appears to be stable.  So does the fix
> included in pci-pc.c not work with my system?  Has anyone else been
> getting these errors after using this fix?  Thanks.
> Steve
>
>
	Yea, I just found out that this problem is fixed in the latest
pre...all the bits in register 55 are set to 0, rather than just the high
bit.

Steve

Re: Athlon Optimization Problem

[Calin A. Culianu]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1080 bytes --]



On Sat, 26 Jan 2002, Steven Hassani wrote:

> 	I'm running a compaq presario 700us: duron 950 mhz on a via mobo
> (vt8363/8365 etc).  When running kernel 2.4.17 with athlon optimizations,
> the box has kernel panics, segmentation faults, and other errors.
> When setting to K6 though, the box appears to be stable.  So does the fix
> included in pci-pc.c not work with my system?  Has anyone else been
> getting these errors after using this fix?  Thanks.
> Steve

The new pci-pc.c fix is not in kernel 2.4.17.  You can try the 2.4.18-pre
kernels, or you can try applying the patch youself to the 2.4.17 source
tree.

After you do that, one easy way to tell if the fix is being applied to your system is
to look at your dmesg output and see if something like "Trying to stomp on
VIA Northbridge bug..." is one of the early bootup messages.....


I am attaching the pci-pc.c patch to this email.  It may or may not help
you.  There are also other issues with Athlons/Durons and AGP, that kernel
developers are now working on.. so it could also be one of those issues.
:)

-Calin

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2962 bytes --]

diff -u -r vanilla/arch/i386/kernel/pci-pc.c patched/arch/i386/kernel/pci-pc.c
--- vanilla/arch/i386/kernel/pci-pc.c	Fri Dec 21 12:41:53 2001
+++ patched/arch/i386/kernel/pci-pc.c	Sat Dec 22 08:24:44 2001
@@ -1109,22 +1109,29 @@
 }
 
 /*
- * Nobody seems to know what this does. Damn.
+ * Addresses issues with problems in the memory write queue timer in
+ * certain VIA Northbridges.  This bugfix is per VIA's specifications.
  *
- * But it does seem to fix some unspecified problem
- * with 'movntq' copies on Athlons.
- *
- * VIA 8363 chipset:
- *  - bit 7 at offset 0x55: Debug (RW)
+ * VIA 8363,8622,8361 Northbridges:
+ *  - bits  5, 6, 7 at offset 0x55 need to be turned off
+ * VIA 8367 (KT266x) Northbridges:
+ *  - bits  5, 6, 7 at offset 0x95 need to be turned off
  */
-static void __init pci_fixup_via_athlon_bug(struct pci_dev *d)
+static void __init pci_fixup_via_northbridge_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 */
-		pci_write_config_byte(d, 0x55, v);
+	int where = 0x55;
+
+	if (d->device == PCI_DEVICE_ID_VIA_8367_0) {
+		where = 0x95; /* the memory write queue timer register is 
+				 different for the kt266x's: 0x95 not 0x55 */
+	}
+
+	pci_read_config_byte(d, where, &v);
+	if (v & 0xe0) {
+		printk("Trying to stomp on VIA Northbridge bug...\n");
+		v &= 0x1f; /* clear bits 5, 6, 7 */
+		pci_write_config_byte(d, where, v);
 	}
 }
 
@@ -1137,7 +1144,10 @@
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_SI,	PCI_DEVICE_ID_SI_5597,		pci_fixup_latency },
 	{ 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_8363_0,	pci_fixup_via_northbridge_bug },
+	{ 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 },
 	{ 0 }
 };
 
diff -u -r vanilla/include/linux/pci_ids.h patched/include/linux/pci_ids.h
--- vanilla/include/linux/pci_ids.h	Fri Dec 21 12:42:03 2001
+++ patched/include/linux/pci_ids.h	Sat Dec 22 08:16:55 2001
@@ -946,7 +946,9 @@
 #define PCI_DEVICE_ID_VIA_8233_7	0x3065
 #define PCI_DEVICE_ID_VIA_82C686_6	0x3068
 #define PCI_DEVICE_ID_VIA_8233_0	0x3074
+#define PCI_DEVICE_ID_VIA_8622		0x3102
 #define PCI_DEVICE_ID_VIA_8233C_0	0x3109
+#define PCI_DEVICE_ID_VIA_8361		0x3112
 #define PCI_DEVICE_ID_VIA_8633_0	0x3091
 #define PCI_DEVICE_ID_VIA_8367_0	0x3099
 #define PCI_DEVICE_ID_VIA_86C100A	0x6100

Re: Athlon Optimization Problem

[Alan Cox]

Im still not convinced touching the register on the 266 chipset at 0x95 is
correct. I now have several reports of boxes that only work if you leave it
alone

Alan

Re: Athlon Optimization Problem

[Rene Rebe]

On: Mon, 28 Jan 2002 20:24:38 +0000 (GMT),
    Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Im still not convinced touching the register on the 266 chipset at 0x95 is
> correct. I now have several reports of boxes that only work if you leave it
> alone

We have a Druon-700 box based on the "Asus A7V" lspci:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0a.0 Multimedia audio controller: Avance Logic Inc. ALS4000 Audio Chipset
00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 82)

With an Athlon optimized 2.4.[16,17,18-pre7] all programs are getting
sig-11s everytime. Even mem=nopentium doesn't help, using generic i386
code generation seems to help. An Athlon optimized 2.4.4 kernel seems
also to run fine (and running memtest86 for some hours did not showed
a memory error ...).

> Alan

k33p h4ck1n6
  René

-- 
René Rebe (Registered Linux user: #248718 <http://counter.li.org>)

eMail:    rene.rebe@gmx.net
          rene@rocklinux.org

Homepage: http://drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: Athlon Optimization Problem

[Calin A. Culianu]

On Mon, 28 Jan 2002, Alan Cox wrote:

> Im still not convinced touching the register on the 266 chipset at 0x95 is
> correct. I now have several reports of boxes that only work if you leave it
> alone
>
> Alan
>

Hmm.  What do you recommend?  I remember seeing a spec sheet and register
0x95 was the memory write queue timer.. but I could have dreamed it..

Anyone know what register 0x95 does?

Re: Athlon Optimization Problem

[Alan Cox]

> Hmm.  What do you recommend?  I remember seeing a spec sheet and register
> 0x95 was the memory write queue timer.. but I could have dreamed it..
> Anyone know what register 0x95 does?

It may well the case. All I know is that for some people at least leaving
0x95 as the bios set it up works and touching it does not - while for
the 0x55 case on older chips it all seems to be positive. VIA's own stuff
doesn't touch 0x95 - maybe there is a reason

Re: Athlon Optimization Problem

[Denis Vlasenko]

On 28 January 2002 18:28, Rene Rebe wrote:
>     Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Im still not convinced touching the register on the 266 chipset at 0x95
> > is correct. I now have several reports of boxes that only work if you
> > leave it alone
>
> We have a Druon-700 box based on the "Asus A7V" lspci:

[snip]

> With an Athlon optimized 2.4.[16,17,18-pre7] all programs are getting
> sig-11s everytime. Even mem=nopentium doesn't help, using generic i386
> code generation seems to help. An Athlon optimized 2.4.4 kernel seems
> also to run fine (and running memtest86 for some hours did not showed
> a memory error ...).

Ugh... Does 686 kernel work?
--
vda

Re: Athlon Optimization Problem

[Daniel Nofftz]

On Mon, 28 Jan 2002, Calin A. Culianu wrote:

> Hmm.  What do you recommend?  I remember seeing a spec sheet and register
> 0x95 was the memory write queue timer.. but I could have dreamed it..
>
> Anyone know what register 0x95 does?

hmmm ... when i was working on the athlon disconnect patch i found that
the pcr files (resorce files) for the wpcredit programm (windows tool for
changing the configuration of chipset) are a good source of information.
but this register isn't discribed in this file ... sorry

daniel
(i placed the pcr file on the web, if you are interested, have a look at:
http://cip.uni-trier.de/nofftz/linux/kt266_pcr.txt ... the webserver is
down at the moment, but should be up again in 1-2 hours)


# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: daniel@nofftz.de

Re: Athlon Optimization Problem

[Paul G. Allen]

FWIW, I've been compiling kernels since 2.4.8 with Athlon optimizations
and have not had a problem with them. This is on a Tyan Thunder K7.

PGA

Alan Cox wrote:
> 
> Im still not convinced touching the register on the 266 chipset at 0x95 is
> correct. I now have several reports of boxes that only work if you leave it
> alone
> 
> Alan
> -
> 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/

-- 
Paul G. Allen
Owner, Sr. Engineer, Security Specialist
Random Logic/Dream Park
www.randomlogic.com

Re: Athlon Optimization Problem

[Rene Rebe]

On: Tue, 29 Jan 2002 09:04:45 -0800,
    "Paul G. Allen" <pgallen@randomlogic.com> wrote:
> FWIW, I've been compiling kernels since 2.4.8 with Athlon optimizations
> and have not had a problem with them. This is on a Tyan Thunder K7.
> 
> PGA

I have also compiled every kernel with Athlon optimization since
2.3.<whatever> but I have no Via boards! Irongates and SiS-735 are in
use here ... No problem! - The only problem is this box of a friend
... - which seems to be a Linux on Via hardware issue ... (Or a
general stupid Via hardware issue ...)

> Alan Cox wrote:
> > 
> > Im still not convinced touching the register on the 266 chipset at 0x95 is
> > correct. I now have several reports of boxes that only work if you leave it
> > alone
> > 
> > Alan
> > -
> > 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/
> 
> -- 
> Paul G. Allen
> Owner, Sr. Engineer, Security Specialist
> Random Logic/Dream Park
> www.randomlogic.com


k33p h4ck1n6
  René

-- 
René Rebe (Registered Linux user: #248718 <http://counter.li.org>)

eMail:    rene.rebe@gmx.net
          rene@rocklinux.org

Homepage: http://drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

Re: Athlon Optimization Problem

[Calin A. Culianu]

On Tue, 29 Jan 2002, Daniel Nofftz wrote:

> On Mon, 28 Jan 2002, Calin A. Culianu wrote:
>
> > Hmm.  What do you recommend?  I remember seeing a spec sheet and register
> > 0x95 was the memory write queue timer.. but I could have dreamed it..
> >
> > Anyone know what register 0x95 does?
>
> hmmm ... when i was working on the athlon disconnect patch i found that
> the pcr files (resorce files) for the wpcredit programm (windows tool for
> changing the configuration of chipset) are a good source of information.
> but this register isn't discribed in this file ... sorry
>
> daniel
> (i placed the pcr file on the web, if you are interested, have a look at:
> http://cip.uni-trier.de/nofftz/linux/kt266_pcr.txt ... the webserver is
> down at the moment, but should be up again in 1-2 hours)

Thank you kindly, Daniel.  It's strange that register 95 is ommitted.  We
definitely can conclude that register 55 is not the one to set on the
kt266 motherboards (whereas on the other via motherboards it *is* the one
to set...  I even have the spec sheet to prove it! :) )

I really wish VIA were more willing to cooperate with us and give us spec
sheets.  It's to their advantage to have us make their buggy motherboards
work well with linux, for crying out loud!  I really don't get what the
big deal is.  I mean it's not like the concept of setting bytes on a pci
device to change functionality is so revolutionary it deserves to be
obfuscated...

-Calin

Re: Athlon Optimization Problem

[Calin A. Culianu]

On Mon, 28 Jan 2002, Alan Cox wrote:

> > Hmm.  What do you recommend?  I remember seeing a spec sheet and register
> > 0x95 was the memory write queue timer.. but I could have dreamed it..
> > Anyone know what register 0x95 does?
>
> It may well the case. All I know is that for some people at least leaving
> 0x95 as the bios set it up works and touching it does not - while for
> the 0x55 case on older chips it all seems to be positive. VIA's own stuff
> doesn't touch 0x95 - maybe there is a reason
>

Really?  VIA's own stuff doesn't touch 0x95?  Hmm.  Well is there ever a
case where touching 0x95 solved ANYTHING?

What do you think?  Should I change the patch to not touch 0x95?

Re: Athlon Optimization Problem

[Trever L. Adams]

On Tue, 2002-01-29 at 16:05, Calin A. Culianu wrote:
> > It may well the case. All I know is that for some people at least leaving
> > 0x95 as the bios set it up works and touching it does not - while for
> > the 0x55 case on older chips it all seems to be positive. VIA's own stuff
> > doesn't touch 0x95 - maybe there is a reason
> >
> 
> Really?  VIA's own stuff doesn't touch 0x95?  Hmm.  Well is there ever a
> case where touching 0x95 solved ANYTHING?
> 
> What do you think?  Should I change the patch to not touch 0x95?

I know it is fairly common for Award BIOS to touch 0x95.  For example
Soyo Dragon Plus and Epox 8kha+.  Either that or the chipset on these
boards defaults to something that doesn't require the fixup.

Trever Adams

Re: Athlon Optimization Problem

[Calin A. Culianu]

You can view a pseudo-spec (basically a wpcredit .pcr file) for the
kt266/kt266a northbridges by hitting this link:
http://www.rtlab.org/kt266-kt266a-northbridge-spec.txt.  This does say
that 0x95.5,6,7 are the memory write queue timer bits...

It is still an open question whether or not setting these to off actually
do more harm than good in the pci-pc.c patch, but we can at least be sure
that 0x95 is the right register.

Alan tells me that basically 0x95.5, 0x95.6, and 0x95.7 being turned off
have done more harm than good.  In all my tests those bits being turned
off has done more good than harm.  :/ What to do?

-Calin

On Tue, 29 Jan 2002, Calin A. Culianu wrote:

> On Tue, 29 Jan 2002, Daniel Nofftz wrote:
>
> > On Mon, 28 Jan 2002, Calin A. Culianu wrote:
> >
> > > Hmm.  What do you recommend?  I remember seeing a spec sheet and register
> > > 0x95 was the memory write queue timer.. but I could have dreamed it..
> > >
> > > Anyone know what register 0x95 does?
> >
> > hmmm ... when i was working on the athlon disconnect patch i found that
> > the pcr files (resorce files) for the wpcredit programm (windows tool for
> > changing the configuration of chipset) are a good source of information.
> > but this register isn't discribed in this file ... sorry
> >
> > daniel
> > (i placed the pcr file on the web, if you are interested, have a look at:
> > http://cip.uni-trier.de/nofftz/linux/kt266_pcr.txt ... the webserver is
> > down at the moment, but should be up again in 1-2 hours)
>
> Thank you kindly, Daniel.  It's strange that register 95 is ommitted.  We
> definitely can conclude that register 55 is not the one to set on the
> kt266 motherboards (whereas on the other via motherboards it *is* the one
> to set...  I even have the spec sheet to prove it! :) )
>
> I really wish VIA were more willing to cooperate with us and give us spec
> sheets.  It's to their advantage to have us make their buggy motherboards
> work well with linux, for crying out loud!  I really don't get what the
> big deal is.  I mean it's not like the concept of setting bytes on a pci
> device to change functionality is so revolutionary it deserves to be
> obfuscated...
>
> -Calin
>
> -
> 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/
>

Re: Athlon Optimization Problem

[Daniel Nofftz]

On Tue, 29 Jan 2002, Calin A. Culianu wrote:

> Thank you kindly, Daniel.  It's strange that register 95 is ommitted.  We
> definitely can conclude that register 55 is not the one to set on the
> kt266 motherboards (whereas on the other via motherboards it *is* the one
> to set...  I even have the spec sheet to prove it! :) )

oh .. .there are some differences between the registers in the chipsets
... the kt 133 and the kt133 are very simmilar, the kx133 also ... the
kt266 and 266a are a bit different from the kt/kx ....
i uped the pcr files for the kt133 and kx133 also
so the urls for the three files:
http://cip.uni-trier.de/nofftz/linux/kt266_pcr.txt
				     kt133_pcr.txt
				     kx133_pcr.txt
this are all i have at the moment ...

> I really wish VIA were more willing to cooperate with us and give us spec
> sheets.  It's to their advantage to have us make their buggy motherboards
> work well with linux, for crying out loud!  I really don't get what the
> big deal is.  I mean it's not like the concept of setting bytes on a pci
> device to change functionality is so revolutionary it deserves to be
> obfuscated...

yes ... the support of via and some other big vendors could really be
better :(
maybee they are getting used to that we do the work for them ...

daniel

# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: daniel@nofftz.de

Re: Athlon Optimization Problem

[Daniel Nofftz]

On Tue, 29 Jan 2002, Calin A. Culianu wrote:

>
> You can view a pseudo-spec (basically a wpcredit .pcr file) for the
> kt266/kt266a northbridges by hitting this link:
> http://www.rtlab.org/kt266-kt266a-northbridge-spec.txt.  This does say
> that 0x95.5,6,7 are the memory write queue timer bits...

oh yes ... this version of the pcr file looks newer then my version ...
and much more complete ... thank you for this link :)
i updated the pcr file on my server ...

daniel




# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: daniel@nofftz.de

Re: Athlon Optimization Problem

[Alan Cox]

> Really?  VIA's own stuff doesn't touch 0x95?  Hmm.  Well is there ever a
> case where touching 0x95 solved ANYTHING?
> 
> What do you think?  Should I change the patch to not touch 0x95?

I don't know. I want to take just that bit out of the next 2.2.21pre and
see what is reported

Re: Athlon Optimization Problem

[Calin A. Culianu]

No problem! :)

No how official are these pcr files?  Are they as good as via specs?  Do
they ultimately come from via specs?

-Calin

On Wed, 30 Jan 2002, Daniel Nofftz wrote:

> On Tue, 29 Jan 2002, Calin A. Culianu wrote:
>
> >
> > You can view a pseudo-spec (basically a wpcredit .pcr file) for the
> > kt266/kt266a northbridges by hitting this link:
> > http://www.rtlab.org/kt266-kt266a-northbridge-spec.txt.  This does say
> > that 0x95.5,6,7 are the memory write queue timer bits...
>
> oh yes ... this version of the pcr file looks newer then my version ...
> and much more complete ... thank you for this link :)
> i updated the pcr file on my server ...
>
> daniel
>
>
>
>
> # Daniel Nofftz
> # Sysadmin CIP-Pool Informatik
> # University of Trier(Germany), Room V 103
> # Mail: daniel@nofftz.de
>
> -
> 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/
>

Re: Athlon Optimization Problem

[Daniel Nofftz]

On Tue, 29 Jan 2002, Calin A. Culianu wrote:

> No problem! :)
>
> No how official are these pcr files?  Are they as good as via specs?  Do
> they ultimately come from via specs?

oh ... in my case they gave me the information i needed. so i think they
are quite good and reliable. i don't know how they are produced ...
maybe some testing and some via stuff ...

daniel

# Daniel Nofftz
# Sysadmin CIP-Pool Informatik
# University of Trier(Germany), Room V 103
# Mail: daniel@nofftz.de

Re: Athlon Optimization Problem

[Calin A. Culianu]

Feel free!  You're the boss... :)

On Tue, 29 Jan 2002, Alan Cox wrote:

> > Really?  VIA's own stuff doesn't touch 0x95?  Hmm.  Well is there ever a
> > case where touching 0x95 solved ANYTHING?
> >
> > What do you think?  Should I change the patch to not touch 0x95?
>
> I don't know. I want to take just that bit out of the next 2.2.21pre and
> see what is reported
> -
> 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/
>

Re: Athlon Optimization Problem

[Bill Davidsen]

On Tue, 29 Jan 2002, Calin A. Culianu wrote:

> On Mon, 28 Jan 2002, Alan Cox wrote:
> 
> > > Hmm.  What do you recommend?  I remember seeing a spec sheet and register
> > > 0x95 was the memory write queue timer.. but I could have dreamed it..
> > > Anyone know what register 0x95 does?
> >
> > It may well the case. All I know is that for some people at least leaving
> > 0x95 as the bios set it up works and touching it does not - while for
> > the 0x55 case on older chips it all seems to be positive. VIA's own stuff
> > doesn't touch 0x95 - maybe there is a reason
> >
> 
> Really?  VIA's own stuff doesn't touch 0x95?  Hmm.  Well is there ever a
> case where touching 0x95 solved ANYTHING?
> 
> What do you think?  Should I change the patch to not touch 0x95?

If this is the code I recall, we beat this to death ages ago. Some people
can't run without the fix, period, because user code will crash the
system. I have two like that, and while I could run the kernel as an i686
kernel, I can't protect the user code that way.

I haven't seen any case where this makes a system unstable, and I have
several which certainly are not stable without it. If there is really a
set of systems which are actively hurt by this feel free to make it an
optional feature, but let's not go back to the patch again. The code was
put in after much discussion, and I believe there were no documented cases
of a system being hurt by it. I could easily have missed something,
obviously, but "my system doesn't need it" isn't a good reason to pull
code.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Athlon Optimization Problem

[Alan Cox]

> put in after much discussion, and I believe there were no documented cases
> of a system being hurt by it. I could easily have missed something,
> obviously, but "my system doesn't need it" isn't a good reason to pull
> code.

For the 0x55 case I have no negatives. For the 0x95 case I have several
disk corruption cases from 2.2.21pre

Re: Athlon Optimization Problem

[Bill Davidsen]

On Wed, 30 Jan 2002, Mark Hahn wrote:

> > > Really?  VIA's own stuff doesn't touch 0x95?  Hmm.  Well is there ever a
> > > case where touching 0x95 solved ANYTHING?
> > > 
> > > What do you think?  Should I change the patch to not touch 0x95?
> > 
> > If this is the code I recall, we beat this to death ages ago. Some people
> > can't run without the fix, period, because user code will crash the
> > system. I have two like that, and while I could run the kernel as an i686
> > kernel, I can't protect the user code that way.
> 
> you have two kt266 boxes that crash without the fix to 0x95,
> or are you talking about kt133/kx/etc and their 0x55 fix?

You are so correct, I remembered the byte incorrectly, 0x55 is the one
needed. It was NOT the code I (almost) recall. 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Athlon Optimization Problem

[Serguei Miridonov]

Hello again.

Just as followup... I was trying to find a minimum deviation
from BIOS settigns to make Soyo Dragon Plus stable:

In KT266A northbridge 1106:3099:

Reg[0x75] = 0x07; // this was set to 0x01 by BIOS
Reg[0x76] = 0x00; // this was 0x10

Without this change I had filesystem corruptions during
kernel compilation...

Unfortunately, some issues with Zoran ZR36067 based cards
are still open. VIA wrote me that they are looking for
DC10plus card to test it in their labs...

BTW, with the settings above DC10plus behaves much better in
Linux, though I can not say that it is fully functional now:
I don't have freezes anymore, but it seems that sometimes
the kernel itself gets corrupted after running DC10plus
related stuff: some programs, like ls, crash immediately
with segfaults but after reboot filesystems are clean
(fsck.ext3 -f does not report any errors). Also, there are
some indications of PCI malfunction: to catch PCI errors I
have added, to the ZR36067 driver, test of PCI status
register on DC10plus every IRQ and it sometimes reports
about every PCI error possible at once (master and target
aborts, parity error, etc.). I don't think it is ever
possible, therefore I suspect problem with CPU-PCI path
(NB-Vlink-SB-PCI). Right after such an error message I have
these kernel problems... Perhaps, PCI DMA gets rerouted to
the wrong place in memory... Hmm, can the hardware be so
broken to make it possible?

In Windows the situation with DC10plus card does not change
much even after the same KT266A settings are applied: the
same lockups as before. However, now I have removed well
known George Breeze PCI latency patch (which also sets NB
latency time to 0), and still don't have filesystem
corruptions...

Please, note that settings above might be OK for my
motherboard but may cause problems for others. I have
received very mixed reports about both: my PCI latency patch
and these new settings, so I can not recommend to include it
to the kernel...

Another important information: with these settings my system
is extremely stable if I don't touch Zoran 36067 card, but
if I run anything related with this video capture hardware,
I have problems... For those who may think about broken
DC10plus: the card works great in a system with Intel 430TX,
and I also have reports from others about the same problems.

--
Serguei Miridonov

Re: Athlon Optimization Problem

[Denis Vlasenko]

On 5 February 2002 01:22, Serguei Miridonov wrote:
> Just as followup... I was trying to find a minimum deviation
> from BIOS settigns to make Soyo Dragon Plus stable:
>
> In KT266A northbridge 1106:3099:
>
> Reg[0x75] = 0x07; // this was set to 0x01 by BIOS
> Reg[0x76] = 0x00; // this was 0x10
> Without this change I had filesystem corruptions during
> kernel compilation...

[MODEL]=VT8366 (KT266) Athlon NB
[VID]=1106:VIA
[DID]=3099:Host to PCI Bridge

[75:7]=Arbitration Mode         0=REQ-based 1=Frame-based
(75:6)=CPU Latency Timer                read only
(75:5)=(same as above)
(75:4)=(same as above)
[75:3]=(Reserved)
[75:2]=PCI Master Bus Time-Out  000=Disable
[75:1]=001=1x32 PCICLKs         010=2x32 PCICLKs
[75:0]=011=3x32 PCICLKs ...     111=7x32 PCICLKs

Note: other doc I have (for KT266A) says 75.3 is used for PCI Master Bus 
Time-Out too (thus max timeout is 1111 = 15x32 PCICLKs)

[76:7]=I/O Port 22 Enable
[76:6]=(Reserved)
[76:5]=Master Priority Rotation 0x=every PCI master grant
[76:4]=10=after every 2 PCI     11=after every 3 PCI
[76:3]=REQn# to REQ4# Mapping   00=REQ4#    01=REQ0#
[76:2]=10=REQ1#    11=REQ2#
[76:1]=(Reserved)
[76:0]=REQ4# Is High Priority   0=disable   1=enable

KT266A doc says:
76.5-4: Master Priority Rotation: 00 disable
        01 every PCI master grant
        10 every 2 PCI master grant
        11 every 3 PCI master grant
--
vda