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
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
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
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
On: Mon, 28 Jan 2002 20:24:38 +0000 (GMT),
Alan Cox <[email protected]> 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: [email protected]
[email protected]
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.
On 28 January 2002 18:28, Rene Rebe wrote:
> Alan Cox <[email protected]> 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
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?
> 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
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: [email protected]
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 [email protected]
> 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
http://www.randomlogic.com
On: Tue, 29 Jan 2002 09:04:45 -0800,
"Paul G. Allen" <[email protected]> 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 [email protected]
> > 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
> http://www.randomlogic.com
k33p h4ck1n6
Ren?
--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)
eMail: [email protected]
[email protected]
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.
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
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?
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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: [email protected]
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: [email protected]
> 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
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: [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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: [email protected]
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> 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
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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