Hi !
I'm a recent user of the duo VIA KT133A chipset/Athlon CPU and after
compiling a customized kernel and booting on it, I fall on kernel panic
at boot time, just little time after starting the init process.
After some search and test, it appears that it was the K7 mmx routines
which cause the crash
Using the "default" routines by replacing #ifdef CONFIG_MK7 by #ifdef 0
solves the problem.
I just wanted to mention that, here, this crash is systematic with
k7-mmx routines.
I also just wanted to know the current status of this problem since I
have not found clear answer on the different threads about this topic.
As I understand, this problem does not exist on every athlon but only on
some which work with the VIA KT133 chipset ? Right ?
Anyway, feel free to ask me more information if needed and please,
CC'ed me personally the answers/comments because I'm not subscribed to
the LKML.
Config.:
ABIT KT7A (without RAID)
Athlon 1.2 GHz
256 Meg RAM
FSB at 133 MHz
(Other card description is not imortant I think)
Running Mandrake 8.0 (*) (at home)
with kernel 2.4.7 (or 2.4.6) compiled with gcc 3.0 (same pb with gcc
2.96 (non-official, I know))
(*) In fact, this distribution has a special startup and switch
immediatly (at startup) in a graphic mode for showing the start of the
runlevel. And I think/suppose that this definitly causes the crash.
Thanks,
Pierre
> have not found clear answer on the different threads about this topic.
> As I understand, this problem does not exist on every athlon but only on
> some which work with the VIA KT133 chipset ? Right ?
Its heavily tied to certain motherboards. Some people found a better PSU
fixed it, others that altering memory settings helped. And in many cases,
taking it back and buying a different vendors board worked.
> Anyway, feel free to ask me more information if needed and please,
> CC'ed me personally the answers/comments because I'm not subscribed to
> the LKML.
http://www.linuxhardware.org/article.pl?sid=01/06/06/1821202&mode=thread
gives a good feel for the current state of play
On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
Its heavily tied to certain motherboards. Some people found a
better PSU fixed it, others that altering memory settings
helped. And in many cases, taking it back and buying a different
vendors board worked.
Does anyone know *why* stuff breaks? surely VIA do as they have a fix
for (some, all?) cases of breakage?
My guess is its some kind of timing or near-miss on a signal edge, and
the bios changes relax things so you don't miss whatever it was you
missed before.
--cw
> On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> Its heavily tied to certain motherboards. Some people found a
> better PSU fixed it, others that altering memory settings
> helped. And in many cases, taking it back and buying a different
> vendors board worked.
>
> Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> for (some, all?) cases of breakage?
At the moment the big problem is I don't have enough reliable info to
see patterns that I can give to VIA for study. VIAs fixes for board problems
are for the fifo problem normally seen with the 686B and SB Live but
sometimes in other cases.
(and it seems also we have a few via + promise weirdnesses on all sorts of
boards not yet explained)
I meant to send this to the list, but sent it straight to Alan instead.
PGA
"Paul G. Allen" wrote:
>
> Alan Cox wrote:
> >
>
> [SNIP]
> >
> > (and it seems also we have a few via + promise weirdnesses on all sorts of
> > boards not yet explained)
>
> I happen to have one of these boards. I was rather upset with it because it would lock Linux several times a day, especially while playing games. This is part
> of what drove me to purchase the K7 Thunder I now have and put the Asus A7V133 on the shelf.
>
> Is there anything I can do that might help track down the problem(s)? I still have the board. In fact, it is a complete system less the SB Live! and GeForce 3
> that I relocated to my K7 Thunder, and it's running a Duron 750. (I also have a second system with a SB Live! and Athlon 1.2, but I'd have to beg my wife for
> its use. ;)
>
> PGA
>
--
Paul G. Allen
UNIX Admin II/Programmer
Akamai Technologies, Inc.
http://www.akamai.com
Work: (858)909-3630
Cell: (858)395-5043
Hi Alan,
as I stumbled across the K7 KT133 MMX problem, let me report my failure.
MSI K7 Turbo Ver. 3 (BIOS 2.8). K7 1.2GHz. 256MB SDRam, tested fine by
memtes86 2.7.
The thing would Oops or just hand at random places at the boot process if
compiled with K7 optimization.
On Fri, Jul 27, 2001 at 09:40:09PM +0100, Alan Cox wrote:
> > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> > Its heavily tied to certain motherboards. Some people found a
> > better PSU fixed it,
PSU = Power supply? 300W should be fine IMHO.
> > others that altering memory settings helped.
Did not. Board allows you to set CL 3 which won't help (and I guess the SPDs
read out 3 anyway) and to turn off some PCI features which does not
help either.
It does also allow you to increase mainboard speed and multiplier but not
decrease!
> > And in many cases, taking it back and buying a different
> > vendors board worked.
The best option most probably.
> > Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> > for (some, all?) cases of breakage?
>
> At the moment the big problem is I don't have enough reliable info to
> see patterns that I can give to VIA for study.
Well, I did some testing, like reordering the MMX instructions, only using 4
instead of 8 registers, ... to no avail.
It all came down to replacing movntq with movq and the thing magically works.
Looks like the writes just get lost otherwise. (Maybe the sfence is just not
effective? But that would be a CPU bug, not a mainboard one.)
> VIAs fixes for board problems
> are for the fifo problem normally seen with the 686B and SB Live but
> sometimes in other cases.
It also has the 686b southbridge bug, but I believe the workaound works.
> (and it seems also we have a few via + promise weirdnesses on all sorts of
> boards not yet explained)
No Promise involved here, fortunately.
garloff@gum09:~ $ /sbin/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:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50)
[...]
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
at the moment they are both running 2.4.5 (athlon optimized), one box has
no problems at all while the other dies (no video, no keyboard, etc)
within an hour of being booted.
systems have no sound enabled, 512MB ram, 20G ata100 drives. D-Link quad
fast ethernet cards.
if you have any patch you would like me to test on these boxes let me know
(I am arranging to ship this one and three others like it that each have
one working and one failing system in them back to the factory to get the
MLB swapped out on the one that is failing.
David Lang
On Fri, 27 Jul 2001, Alan Cox wrote:
> Date: Fri, 27 Jul 2001 21:40:09 +0100 (BST)
> From: Alan Cox <[email protected]>
> To: [email protected]
> Cc: [email protected], [email protected], [email protected]
> Subject: Re: VIA KT133A / athlon / MMX
>
> > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> > Its heavily tied to certain motherboards. Some people found a
> > better PSU fixed it, others that altering memory settings
> > helped. And in many cases, taking it back and buying a different
> > vendors board worked.
> >
> > Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> > for (some, all?) cases of breakage?
>
> At the moment the big problem is I don't have enough reliable info to
> see patterns that I can give to VIA for study. VIAs fixes for board problems
> are for the fifo problem normally seen with the 686B and SB Live but
> sometimes in other cases.
>
> (and it seems also we have a few via + promise weirdnesses on all sorts of
> boards not yet explained)
> -
> 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/
>
Hi,
On Fri, Jul 27, 2001 at 05:23:07PM -0700, David Lang wrote:
> I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> at the moment they are both running 2.4.5 (athlon optimized), one box has
> no problems at all while the other dies (no video, no keyboard, etc)
> within an hour of being booted.
Somebody told he had the same MoBo already replaced a couple of times ...
> if you have any patch you would like me to test on these boxes let me know
Well, no kernel patches.
But some program which does the K7 optmizied copies and zeroing in userspace.
(Attached)
Strange enough it succeeds on the machine that fails to boot a K7 optimized
kernel.
So I'm puzzled now.
Seems we can trigger problems in kernelspace that we can't have in userspace?
Some problem with non-serialization if an interrupt occurs or something
esoteric like this?
> (I am arranging to ship this one and three others like it that each have
> one working and one failing system in them back to the factory to get the
> MLB swapped out on the one that is failing.
Good luck!
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
Chris Wedgwood a ?crit :
>
> On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
>
> Its heavily tied to certain motherboards. Some people found a
> better PSU fixed it, others that altering memory settings
> helped. And in many cases, taking it back and buying a different
> vendors board worked.
>
> My guess is its some kind of timing or near-miss on a signal edge, and
> the bios changes relax things so you don't miss whatever it was you
> missed before.
>
Ok, after reading that, I've tried to see if my BIOS setting changes
were implicated or not. And I've found a winner:
Disabling option "Enhance Chip Performance" makes kernel K7-mmx routines
work fine. Enabling it causes the kernel crash at boot time... (And I
haved it enable)
FYI, according to the user's manual, enabling this option "set the north
bridge chipset timing parameters more aggressively providing higher
system performance" (Default value is 'disable'). I can't say more about
what it does exactly.
I don't know if this will help you to locate the problem, but at least,
Abit's users will be warned...
Thanks for your help !
Pierre
Do these problems also affect Durons? I have a MSI K7T Turbo-R with Via
KT133A and I have nog problems at all. I even run my Duron 600 at 866(!)
(6,5 * 133) for several months now. Now I wonder if I could get problems
when i upgrade to a tbird at 1,4 ghz. I have a 300 PSU.
Victor
On Sat, Jul 28, 2001 at 01:29:04PM -0400, PEIFFER Pierre wrote:
> FYI, according to the user's manual, enabling this option "set the north
> bridge chipset timing parameters more aggressively providing higher
> system performance" (Default value is 'disable'). I can't say more about
> what it does exactly.
A lspci -vxxx of your northbridge with adn without the BIOS option will
reveal more.
Regards,
--
Kurt Garloff <[email protected]> [Eindhoven, NL]
Physics: Plasma simulations <[email protected]> [TU Eindhoven, NL]
Linux: SCSI, Security <[email protected]> [SuSE Nuernberg, DE]
(See mail header or public key servers for PGP2 and GPG public keys.)
> I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> at the moment they are both running 2.4.5 (athlon optimized), one box has
> no problems at all while the other dies (no video, no keyboard, etc)
> within an hour of being booted.
Same bios, same bios settings ?
lspci -vxx on both show the same settings ?
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
Subsystem: ABIT Computer Corp.: Unknown device a401
Flags: bus master, medium devsel, latency 8
Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00
10: 08 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 01 a4
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10
60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00
70: d4 88 cc 0c 0e 81 62 00 01 b4 19 02 00 00 00 00
80: 0f 40 00 00 c0 00 00 00 02 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 32 00 00
a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00
b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06
From: "Kurt Garloff" <[email protected]>
On Fri, Jul 27, 2001 at 05:23:07PM -0700, David Lang wrote:
> I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> at the moment they are both running 2.4.5 (athlon optimized), one box has
> no problems at all while the other dies (no video, no keyboard, etc)
> within an hour of being booted.
Somebody told he had the same MoBo already replaced a couple of times ...
Kurt, et al, I have been following this VIA vs Linux thing for some time
now. (My "big machine" is an Athlon based system. So it interests me.)
Comments have been made about the size of power supply needed to keep these
systems happy with 400 watts coming up in discussions frequently. But if you
pause to think on it a few minutes you begin to wonder about this concept.
The RAM runs at about 3.3 volts. The CPU core runs at about 1.7v (in my case.)
So both of these are running off of power supplies on the motherboards that
take the 5 volts down to something reasonable. If the problem is inadequate
power supply AND it is more of a problem with some motherboards than others
I look for the volts. Where are the losses which could cause this. One source
is the connector from the power supply to the motherboard. (This was a chronic
problem with A2000s, for example.) I don't see newer style connectors that
have less contact resistance on any systems. That is probably a factor. Since
the problem is greater with some boards than others I suspect that the
auxilliary power sipplies on the motherboards are better for some boards than
for others. Somebody with hardware access to a sufficient variety of mother-
boards should survey this. Do they all use exactly the same power supply parts?
Another issue is the speed of these systems. And the Athlon problem seems to
peak when driving the various buses at their peaks. RF crosstalk is an issue
that a lot of digital designers claim to understand when they design (and
model) their circuits. Now, I built my first circuit analysis program back
in about 1975. Results of that work fly on GPS satellites today. Since it was
MY program I used for design I was acutely aware of its deficiencies as well
as the modeling deficiencies. At some point in the analysis you cut a corner
or two in order to make the calculations tractable. You do not manage to get
all the "strays" into the models. What I ams saying is that board layout is
another area where problems may exist.
These are not thigs software settings in the VIA chips can cure. On another
mailinglist catering to developers for very exotic video cards some problems
with the latest INTEL based motherboards are appearing. (DigiSuite:E and its
kith and kin drive the PCI bus very hard.) I suspect we have a situation not
properly anticipated in modeling the backplanes on all these boards. And until
the designers can wrap their minds around the entire problem the software
solution may simply be, in the words of an old philospher, "Slow down! You move
too fast." At the same time someone with suitable test equipment needs to look
for voltage glitches out of the motherboard regulators and we need to develop
software tools for "forcing" the suspected crosstalk and ideally characterising
it with regards to data passing on the bus at the time of the bad data transfer.
The software based fixes seem to be shooting at black cats in a coal mine
without a flashlight or IR goggles.
{^_^} Joanne Dow, [email protected]
On Friday 27 July 2001 20:40, Alan Cox wrote:
> > On Fri, Jul 27, 2001 at 09:19:21PM +0100, Alan Cox wrote:
> > Its heavily tied to certain motherboards. Some people found a
> > better PSU fixed it, others that altering memory settings
> > helped. And in many cases, taking it back and buying a different
> > vendors board worked.
> >
> > Does anyone know *why* stuff breaks? surely VIA do as they have a fix
> > for (some, all?) cases of breakage?
>
> At the moment the big problem is I don't have enough reliable info to
> see patterns that I can give to VIA for study. VIAs fixes for board
> problems are for the fifo problem normally seen with the 686B and SB Live
> but sometimes in other cases.
>
> (and it seems also we have a few via + promise weirdnesses on all sorts of
> boards not yet explained)
Just FYI, I've been running 2.4.7-pre6 for a few weeks on a Abit-KT7-a
(hpt370) that uses the KT133/VIA chipset, with a 1.33Ghz Athlon and the
kernel compiled for an Athlon.
The machine is now rock solid. I've given it the usual tests, k7burn for 5
hours, cp'ing 30G+ across drives a few times etc, and all is good.
The broken sound (crackle/pop) with my SB128PCI (same problem as SBLive)
still didn't go away though, but enabling PCI DRAM PREFETCH on the VT8363
Bus-PCI Bridge does cure it. This took me a while to find as I can't set this
in my bios, but powertweak came to the rescue.
While DRAM Prefetch is supposed to be an option to increase performance, my
sound is totally unusable without this set. I've heard numerous people
explain the same problem and it would be interesting to find out if this
cures their sound troubles too. If this is the case, is this something that
belongs in quirks, or is it too hardware specific? and would enabling this by
default hurt anything anyway? Or is this just masking the underlaying problem
?
-- Regards, Gavin Baker
On Sun, Jul 29, 2001 at 04:03:29AM +0000, Gav wrote:
> The machine is now rock solid. I've given it the usual tests, k7burn for 5
> hours, cp'ing 30G+ across drives a few times etc, and all is good.
Sorry to jump in here, but where can I get "k7burn"? I've searched on
google.com for it and cannot find any reference. I am running 2.4.7-ac2
(with Athlon optimizations) with an AMD T-Bird 1.2GHz on an ASUS A7A266
and it appears quite stable. I would like to see how it fares with this
burn-in program you speak of.
Thanks,
Mike.
Hi Pierre,
thanks for your info!
On Sat, Jul 28, 2001 at 06:00:11PM -0400, PEIFFER Pierre wrote:
> Kurt Garloff a ?crit :
> In attached files are the result. I've only kept the (what I suppose to
> be) northbridge info.
> This doesn't tell me anything...
Me neither. I was hoping that only a bit differs. Unfortunately that's not
the case, so I need to have a look in the datasheet.
But those are not publically available :-(
Anybody having them?
> Note: both has been done after booting on Mandrake-kernel 2.4.3 which
> come with Mandrake distribution (i.e. with lot of patches and
> options...) I don't know the impact on the result...
With a newer lspci you would have seen that 1106:0305 is VT8363/8365
[KT133/KM133].
I removed everything except for the differences. Underlined. Anybody able to
decode? Otherwise trying out all of them can get boring. (Well, I'd start
with 0x68, followed by 0x6b and 0xac ...)
Working:
> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
> Subsystem: ABIT Computer Corp.: Unknown device a401
> Flags: bus master, medium devsel, latency 0
^ This looks wrong to me.
> Memory at d8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [a0] AGP version 2.0
> Capabilities: [c0] Power Management version 2
> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00
^ Latency.
> 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10
^^ ^^
> 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00
^^ ^^
> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00
^^
> b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00
^^
> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00
^^ ^^
Buggy: (Own, buggy settings in parens)
> 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03)
> Subsystem: ABIT Computer Corp.: Unknown device a401
> Flags: bus master, medium devsel, latency 8
^ That's more reasonable.
> Memory at d8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [a0] AGP version 2.0
> Capabilities: [c0] Power Management version 2
> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00
^ Latency
> 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10
^^ ^^ (47 8d here)
> 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00
^^ ^^ (41 .. 21 here)
> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00
^^ (6b here)
> b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00
^^ (22 here)
> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06
^^ ^^ (00 00 here)
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
Gav wrote:
> Just FYI, I've been running 2.4.7-pre6 for a few weeks on a Abit-KT7-a
> (hpt370) that uses the KT133/VIA chipset, with a 1.33Ghz Athlon and the
> kernel compiled for an Athlon.
>
> The machine is now rock solid. I've given it the usual tests, k7burn for 5
> hours, cp'ing 30G+ across drives a few times etc, and all is good.
>
> The broken sound (crackle/pop) with my SB128PCI (same problem as SBLive)
> still didn't go away though, but enabling PCI DRAM PREFETCH on the VT8363
> Bus-PCI Bridge does cure it. This took me a while to find as I can't set this
> in my bios, but powertweak came to the rescue.
>
> While DRAM Prefetch is supposed to be an option to increase performance, my
> sound is totally unusable without this set. I've heard numerous people
> explain the same problem and it would be interesting to find out if this
> cures their sound troubles too. If this is the case, is this something that
> belongs in quirks, or is it too hardware specific? and would enabling this by
> default hurt anything anyway? Or is this just masking the underlaying problem
> ?
Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct
me if i'm wrong) it's causing all the problems with the IDE controller (data trashing).
Regards,
--
Steffen Persvold Systems Engineer
Email : mailto:[email protected] Scali AS (http://www.scali.com)
Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6
Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway
> Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct
> me if i'm wrong) it's causing all the problems with the IDE controller (data trashing).
I think it was IDE Prefetch that should be off (I had this problem on a
AMD 486DX4-133 with Award Bios, turning it on trashed the boot record in
minutes (and many other sectors on the disk too).
Anyone here care to give a link to that program to enable DRAM Prefetch?
My sister has a Duron 750w with VIA motherboard and music and sound pop on
any graphics changes, maybe this is it?
Regards,
Maciej Zenczykowski
Hi Kurt!
On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
>Me neither. I was hoping that only a bit differs. Unfortunately that's not
>the case, so I need to have a look in the datasheet.
>But those are not publically available :-(
>Anybody having them?
Try to get a clue yourself from the WPCREDIT KT133 plugin (see below,
stripped down to the differing registers). Some differences look
suspicious to me...
>Working:
>> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00
> ^ Latency.
>> 50: 17 a3 eb b4 02 00 10 10 c0 00 08 10 10 10 10 10
> ^^ ^^
>> 60: 03 aa 02 20 e6 d6 d6 c6 51 28 43 0d 08 3f 00 00
> ^^ ^^
>> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2b 12 14 00
> ^^
>> b0: 49 da 00 60 31 ff 80 05 67 00 00 00 00 00 00 00
> ^^
>> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 00 00
^^ ^^
>Buggy: (Own, buggy settings in parens)
>> 00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 08 00 00
> ^ Latency
>> 50: 17 a3 eb b4 43 89 10 10 c0 00 08 10 10 10 10 10
> ^^ ^^ (47 8d here)
>> 60: 03 aa 02 20 e6 d6 d6 c6 45 28 43 0f 08 3f 00 00
> ^^ ^^ (41 .. 21 here)
>> a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 2f 12 14 00
> ^^ (6b here)
>> b0: 49 da 88 60 31 ff 80 05 67 00 00 00 00 00 00 00
> ^^ (22 here)
>> f0: 00 00 00 00 00 03 03 00 22 00 00 00 00 00 91 06
> ^^ ^^ (00 00 here)
PCR(PCI Configration Registers) Editor / WPCREDIT for WIN32
Copyright (c) 2000 H.Oda!
[COMMENT]=for HWup ng. members (Kx) edited by Guruad tnx to author
H.Oda!
[MODEL]=VT8363 (KT133)
[VID]=1106:VIA
[DID]=0305:Host to PCI Bridge
[54:7]=SDRAM Self-Refresh 0=disable 1=enable
[54:6]=Probe Next Tag State T1 0=disable 1=enable
[54:5]=High Priority DRAM Req. 0=disable 1=enable
[54:4]=Continuous DRAM Request 0=disable 1=enable
[54:3]=DRAM Speculative Read 0=disable 1=enable
[54:2]=PCI Master Pipeline Req. 0=disable 1=enable
[54:1]=PCI-to-CPU / CPU-to-PCI 0=disable 1=enable
[54:0]=Fast Write-to-Read 0=disable 1=enable
[55:0]=S2K Compensation CPU Halt0=disable 1=enable
[68:7]=SDRAM Open Page Control 0=precharge 1=remain act
[68:6]=Bank Page Control 0=same bank 1=different
[68:5]=(Reserved)
[68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch
[68:3]=EDO Test Mode 0=disable 1=enable
[68:2]=Burst Refresh(4 times) 0=disable 1=enable
[68:1]=System Frequency Divider 00= 66 MHz 01=100 MHz
[68:0]=10=133 MHz 11=Reserved
[6B:7]=Arbitration Parking Pol. 00=bus owner 01=CPU side
[6B:6]=10=AGP side 11=Reserved
[6B:5]=Fast Read to Write t-a 0=disable 1=enable
[6B:4]=(Reserved)
[6B:3]=MD Bus Second Level 0=Normal slew 1=More
[6B:2]=CAS Bus Second Level 0=Normal slew 1=More
[6B:1]=Virtual Channel-DRAM 0=disable 1=enable
[6B:0]=Multi-Page Open 0=disable 1=enable
[AC:7]=(Reserved)
[AC:6]=AGP Read Synchronization 0=disable 1=enable
[AC:5]=AGP Read Snoop DRAM P-W-B0=disable 1=enable
[AC:4]=GREQ# Priority 0=disable 1=enable
[AC:3]=2X Rate Supported 0=not 1=supported
[AC:2]=LPR In-Order Access 0=not 1=executed
[AC:1]=AGP Arbitration Parking 0=disable 1=enable
[AC:0]=AGP-PCI Master/CPU-PCI TC0=2T or 3T 1=1T
[B2:7]=GD/GBE/GDS, SBA/SBS Ctrl
[B2:6]=(Reserved)
[B2:5]=(Reserved)
[B2:4]=GD[31-16] Staggered Delay0=none 1=1ns
[B2:3]=(Reserved)
[B2:2]=(Reserved)
[B2:1]=AGP Voltage 0=1.5V 1=3.3V
[B2:0]=GDS Output Delay 0=none 1=0.4ns
[FE]=Back-Door Device ID
[FF]=Back-Door Device ID
'54'=BIU Control 00 RW
'55'=Debug (Do Not Program)
'68'=DRAM Control 00 RW
'6B'=DRAM Arbitration Control 01 RW
'AC'=AGP Control 00 RW
'B2'=AGP Pad Drive / Delay Control 00 RW
'FE..FF' Back-Door Device ID 0000 RW
Ciao,
Dani
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gr?fenberger Str. 34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
On Monday 30 July 2001 07:15, Steffen Persvold wrote:
> > While DRAM Prefetch is supposed to be an option to increase performance,
> > my sound is totally unusable without this set. I've heard numerous people
> > explain the same problem and it would be interesting to find out if this
> > cures their sound troubles too. If this is the case, is this something
> > that belongs in quirks, or is it too hardware specific? and would
> > enabling this by default hurt anything anyway? Or is this just masking
> > the underlaying problem ?
>
> Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on,
> because (and correct me if i'm wrong) it's causing all the problems with
> the IDE controller (data trashing).
Obviously I can only comment on my own hardware but the machine has been used
constantly since Thu Jul 12, its now Jul 30 and I havent had a single IDE
related problem.
As a hobby, i use the machine for DigitalVideo, and regularly grab 20-30GB
from my capture card, then process it, which means the IDE bus gets a lot of
use and seems to be an ideal situation for the data trashing problems to rear
their ugly heads (no pun intended) but, as i said, I haven't seen any here.
DRAM Prefetch makes my sound usuable, as the VIA fixups for the SB cards do
not work here, and for (at least) two other people who i have had email
correspondancy with.
-- Regards, Gavin Baker
Hi Daniela,
On Mon, Jul 30, 2001 at 08:04:54AM +0200, Daniela Engert wrote:
> On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
>
> >Me neither. I was hoping that only a bit differs. Unfortunately that's not
> >the case, so I need to have a look in the datasheet.
> >But those are not publically available :-(
> >Anybody having them?
>
> Try to get a clue yourself from the WPCREDIT KT133 plugin (see below,
> stripped down to the differing registers). Some differences look
> suspicious to me...
Hey thanks!
> [54:6]=Probe Next Tag State T1 0=disable 1=enable
Main suspect. (Should be 0)
> [54:0]=Fast Write-to-Read 0=disable 1=enable
Third candidate. (Should be 0)
> [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch
Second candidate (Should be 1)
> [68:2]=Burst Refresh(4 times) 0=disable 1=enable
Fourth candidate (Should be 0?)
> [6B:5]=Fast Read to Write t-a 0=disable 1=enable
Should this one match 54:0 (third candidate)?
> [6B:1]=Virtual Channel-DRAM 0=disable 1=enable
Strange, why does this one differ between the configs.
OK, I'll come up with a kernel patches (driver/pci/quirks ...)
for people to test.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
> > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
> > [54:6]=Probe Next Tag State T1 0=disable 1=enable
>
> Main suspect. (Should be 0)
That's set in my stable kt133a system.
> > [54:0]=Fast Write-to-Read 0=disable 1=enable
>
> Third candidate. (Should be 0)
as is this one.
> > [68:2]=Burst Refresh(4 times) 0=disable 1=enable
>
> Fourth candidate (Should be 0?)
I set this one yesterday to see if it would trigger the problem, it
didn't :o/ Same with a few differences between my system and 0x6b, which
didn't either.
Out of curiosity, where are you getting the 'should be 0/1' details from?
--
Michael.
I have this bios setting enabled, and no problems at all on two of my
athlons with VIA KT133A, kernel 2.4.7.
>From this full discussion comes out a big confusion.
For what I saw, many VIA KT133A do work well, many other
give problems to their sysadmins. but the chipset is almost the same,
and the processors are quite the same (they are all athlon, I read no
bug reports about duron).
this is enought for me to get confused.
My production systems do use scsi disks, and i can understand
they donot have troubles (adaptec 2940, 2980 29160....).
But also the ones with IDE disks are working quite well (some using
ata33, others ata100).
I NEVER used DDRAM, just normal SDRAM 133 Mhz.
So I was thinking to FSB. All my systems with ide disks have 200MhzFSB,
(while my latest production systems do have 266 MhzFSB). Maybe a 266
MhzFSB is just too mutch stress
for some via chipset. But i see no clear logic when problems do appear,
or any big difference with systems that are rock solid.
lets' try to make a point to see a logic for those instabilities...
which kind of hardware bug is this, if the same chipset can work or not
depending if you are lucky? or a full stock of chipset is buggy and
with a certain HW configuration you will see the bug or
what?
Luigi
On Mon, 30 Jul 2001, Maciej Zenczykowski wrote:
> > Hmm, I think "DRAM Prefetch" is the one you _don't_ want to turn on, because (and correct
> > me if i'm wrong) it's causing all the problems with the IDE controller (data trashing).
>
> I think it was IDE Prefetch that should be off (I had this problem on a
> AMD 486DX4-133 with Award Bios, turning it on trashed the boot record in
> minutes (and many other sectors on the disk too).
>
> Anyone here care to give a link to that program to enable DRAM Prefetch?
> My sister has a Duron 750w with VIA motherboard and music and sound pop on
> any graphics changes, maybe this is it?
>
> Regards,
>
> Maciej Zenczykowski
>
> -
> 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/
>
Hi Michael,
thanks for your comments!
On Mon, Jul 30, 2001 at 03:15:38PM +0100, Michael wrote:
> > > On Sun, 29 Jul 2001 22:28:30 +0200, Kurt Garloff wrote:
> > > [54:6]=Probe Next Tag State T1 0=disable 1=enable
> >
> > Main suspect. (Should be 0)
>
> That's set in my stable kt133a system.
But did you experience problems at all with your kernel when compiled for
K7? Note that most (if not all) systems seem to work stable with K6 or PPro
optimized kernels.
> > > [54:0]=Fast Write-to-Read 0=disable 1=enable
> >
> > Third candidate. (Should be 0)
>
> as is this one.
>
> > > [68:2]=Burst Refresh(4 times) 0=disable 1=enable
> >
> > Fourth candidate (Should be 0?)
>
> I set this one yesterday to see if it would trigger the problem, it
> didn't :o/ Same with a few differences between my system and 0x6b, which
> didn't either.
>
> Out of curiosity, where are you getting the 'should be 0/1' details from?
Comparing the lspci -vxxx output of working and non-working systems.
You did no comment on the second candidate:
> [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch
Second candidate (Should be 1)
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
Hi Kurt!
On Mon, 30 Jul 2001 15:44:58 +0200, Kurt Garloff wrote:
Just for reference: these are the values taken from my main machine
(Epox EP8KTA2, VIA KT133) with the latest BIOS:
>> [54:6]=Probe Next Tag State T1 0=disable 1=enable
>Main suspect. (Should be 0)
Set to 1 here.
>> [54:0]=Fast Write-to-Read 0=disable 1=enable
>Third candidate. (Should be 0)
Set to 1 here.
>> [68:4]=DRAM Data Latch Delay 0=Latch 1=Delay latch
>Second candidate (Should be 1)
Set to 1 here.
>> [68:2]=Burst Refresh(4 times) 0=disable 1=enable
>Fourth candidate (Should be 0?)
Set to 0 here.
>> [6B:5]=Fast Read to Write t-a 0=disable 1=enable
>Should this one match 54:0 (third candidate)?
Set to 0 here.
>> [6B:1]=Virtual Channel-DRAM 0=disable 1=enable
>Strange, why does this one differ between the configs.
Set to 0 here.
Unfortunately, this machine doesn't run Linux...
Ciao,
Dani
Hi,
OK, patches for different bits are attached.
The patch does modify up to 4 bits, which is more than I would like to do in
the end. But you can easily disable some parts of it, if the full patch
proves to solve your trouble.
Please test!
It seemed to solved the trouble here on first sight (booting went further
then normal) but in the end did not turn out to solve the trouble here.
(Here means: MSI K7T Turbo (Ver.3) with AMD K7 1.2GHz.)
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, DE SCSI, Security
Hi,
Kurt Garloff wrote:
> It seemed to solved the trouble here on first sight (booting went further
> then normal) but in the end did not turn out to solve the trouble here.
> (Here means: MSI K7T Turbo (Ver.3) with AMD K7 1.2GHz.)
from your lspci output I seem to have exactly the same system as you
have. I tried your patch (247-viakt133.diff) and came up with the same
result here: it seemed to come further than last time with only
2.4.6ac5, but then it crashed anyway. If you know of any BIOS parameters
that might help for this mobo, please let me know. I could not
identify a parameter that does the same as the "DRAM Prefetch" for Abit
mobos.
Regards,
Gerbrand van der Zouw
Hi,
FWIW,
I have an ASUS A7V133 with a T-Bird 900, running 2.4.7ac3+ext3 with K7
optimization enabled.
It's rock solid.
2.4.6ac5 and previous ran a long time without problems too.
'lspci -vxxx' shows:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
(rev 03)
Subsystem: Asustek Computer, Inc.: Unknown device 8042
Flags: bus master, medium devsel, latency 0
Memory at e4000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00: 06 11 05 03 06 00 10 a2 03 00 00 06 00 00 00 00
10: 08 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 42 80
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 17 a4 6b b4 06 28 20 20 88 80 08 08 10 18 20 20
60: 3f ff 55 a0 52 52 52 00 40 7c 86 0f 08 1f 00 00
70: de c0 cc 0c 0e a1 d2 00 01 b4 11 02 00 00 00 09
80: 0f 40 00 00 c0 00 00 00 03 00 e0 1f 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 c0 20 00 17 02 00 1f 00 00 00 00 6e 02 14 00
b0: 7f 69 02 c5 32 33 28 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 84 22 00 00 00 00 00 91 06
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
(prog-if 00 [N
ormal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: e0000000-e16fffff
Prefetchable memory behind bridge: e2f00000-e3ffffff
Capabilities: [80] Power Management version 2
00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 d0 00 00
20: 00 e0 60 e1 f0 e2 f0 e3 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00
40: cb cd 18 14 27 72 05 83 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 22 02 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
Subsystem: Asustek Computer, Inc.: Unknown device 8042
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management version 2
00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 42 80
30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
40: 08 41 00 00 00 80 62 ee 05 01 44 00 00 00 00 f3
50: 0e 06 00 00 00 b0 4a 30 00 04 ff 08 80 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 25 08 40 82 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 09 00 00 00 60 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 41 00 00 00 00 00 00 00 00 00
00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
[snipped]
00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
(prog-if 00 [UHCI])
[snipped]
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 40)
Subsystem: Asustek Computer, Inc.: Unknown device 8042
Flags: medium devsel, IRQ 9
Capabilities: [68] Power Management version 2
00: 06 11 57 30 00 00 90 02 40 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 42 80
30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00
40: 20 80 49 00 12 10 00 00 01 e4 00 00 48 10 00 00
50: 00 ff ff 04 90 04 00 00 00 ff ff 00 43 10 42 80
60: 00 00 00 00 00 00 00 00 01 00 02 00 00 00 00 00
70: 01 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 01 e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 01 00 00 00 40 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:04.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 50)
[snipped]
00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 (rev
02)
[snipped]
00:0b.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
[snipped]
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
[snipped]
00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265
(rev 02)
[snipped]
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP
(rev 03) (prog-if 00 [VGA])
[snipped]
Stefan
--
Jul 10 00:43:47 unknown kernel: Out of Memory: Killed process 24829
(eatmem).
I have not had a chance to examine all the BIOS settings but attached are
the lspci -vxx for 10 different systems with identical hardware configs.
the ones that end in .good have given me no problems, the three ending in
.bad die after a while. the framewall-b system dies with all LEDs on the
network card lit, all others die with no LEDs on.
David Lang
On Sat, 28 Jul 2001, Alan Cox wrote:
> Date: Sat, 28 Jul 2001 13:47:40 +0100 (BST)
> From: Alan Cox <[email protected]>
> To: [email protected]
> Cc: [email protected], [email protected], [email protected],
> [email protected]
> Subject: Re: VIA KT133A / athlon / MMX
>
> > I have a 1u box at my des that has two MSI boards in it with 1.2G athlons.
> > at the moment they are both running 2.4.5 (athlon optimized), one box has
> > no problems at all while the other dies (no video, no keyboard, etc)
> > within an hour of being booted.
>
> Same bios, same bios settings ?
>
> lspci -vxx on both show the same settings ?
>