Via chipset
I'm sorry if this question has been answered recently (I'm not subscribed to the list).
I'm planning on getting a new workstation, and I kinda want an AMD system. But it seems that most (all?) motherboards for the amd cpu's use VIA chipsets, and some people have experienced problems with via chipsets and linux.
Have these problems been fixed, or are they still present?
would I be better off getting a P4 system?
Øystein Haare
Quoted 5 lines · Øystein Haare
I'm planning on getting a new workstation, and I kinda want an AMD system. But it seems that most (all?) motherboards for the amd cpu's use VIA chipsets, and some people have experienced problems with via chipsets and linux.
Have these problems been fixed, or are they still present?
It seems more dependent on the motherboard design than strictly the chipset itself. For example the MSI K7T-Pro2A is a known good quantity (in fact for me, it is the single most stable motherboard I have ever used and that includes intel boards).
Quoted 1 line
would I be better off getting a P4 system?
Nope
Signature · 1 line
[-] Omae no subete no kichi wa ore no mono da. [-]
Quoted 5 lines
I'm planning on getting a new workstation, and I kinda want an AMD system. But it seems that most (all?) motherboards for the amd cpu's us= e
VIA chipsets, and some people have experienced problems with via chipsets and linux.
We have seen two big problem sets with the VIA chipsets and Athlon. The first is a bug in some of the bridges that caused corruption. We had partial workarounds but as of 2.4.7ac releases (and I sent it to Linus for 2.4.8pre) we have an official workaround based on VIA provided info.
The second problem is that some VIA chipset boards lock up running the Athlon optimised kernel. This seems to be board specific and we've also had 'setting CAS3 not CAS2' and 'bigger PSU' reports of fixing it for some people. I'm still trying to put together a detailed enough study of what is going on to actually take it to VIA and AMD engineers.
So pick a board other folks say work. Personally I am using AMD chipset boards but I don't think thats actually a required solution to avoid the problem.
As to the PIV. Right now I see no reason to go that way. The PIV is going to need new compiler tools to get good performance at the moment. It also requires rambus memory. The rambus memory requirement will change soon, the processor will go down to a smaller die size (0.13u) and should get both cheaper and cooler. Hopefully intel will also fix the performance problems with the extra silicon space they will get out of it.
So if you think PIV wait for the new socket, new die size then study reviews IMHO.
Alan
This is a reoccurring question on this (and many other) list[s]. It seems like someone ought to maintain a database of boards that are known to work and what they are used for. For example, lots of people say "such and such works for me" but what they don't say is "I only have 1 disk and 1 CDROM and nothing else".
I've had fairly good luck with just about any board as long as I don't beat on the IDE on a VIA chipset board. I switched all my servers over to 3ware Escalades to get off the IDE; that helped tremendously but it adds about $400 to a system (3ware card and you will probably want a better PS and cooling, so maybe more).
Yeah, I know, if I'm whining I should volunteer the space. OK, I'll do the
following: if someone starts gathering the data in a simple way (see below) then I'll archive it all in a database and make it accessible via the web. If you are interested in doing this, which means you write the script that gathers the info, contact me offline and we'll set it up.
The data format I want is simple. Imagine a perl script gathering the info into an associative array, the key is the field name like "cpu" or "motherboard" etc., and the value is the value, like "AMD K7" or "ASUS A7V". It would be good to have a set of required fields so people can query across those fields, but there need not be any limit on how many fields and all fields need not be present in all records.
Once you have that, I can send you some code that will shlep over that data to me and I have tools here that will eat it and store it into a database. Our bugdatabase is lot like this, it's a fairly trivial change to support this as a sort of bugdatabase like thing.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Quoted 7 lines · Øystein Haare
I'm sorry if this question has been answered recently (I'm not subscribed to the list).
I'm planning on getting a new workstation, and I kinda want an AMD system. But it seems that most (all?) motherboards for the amd cpu's use VIA chipsets, and some people have experienced problems with via chipsets and linux.
My Asus A7V (not 133, not 266) is fine with Red Hat 7.1, but it only supports B-type (100/200 MHz FSB) Athlons. I haven't yet tested it with kernels newer than what Red Hat provides, though.
Quoted 1 line
Have these problems been fixed, or are they still present?
I'm not having any that aren't being caused by my hard drives right now.
Quoted 1 line
would I be better off getting a P4 system?
Certainly not. I've seen benchmarks where an Athlon 1.4 beats the stuffing out of a P4 1.8. I realize its just a benchmark, but when it happens in about 70% of the benchmarks (oriented at different subsytstems) it HAS to be more than just coincedence.
And have you seen the price difference lately? Even if the Athlon was slower, it's still a lot cheaper.
Quoted 1 line
Øystein Haare
Signature · 1 line
Ignacio Vazquez-Abrams <[email protected]>
Quoted 4 lines · Øystein Haare
I'm planning on getting a new workstation, and I kinda want an AMD system. But it seems that most (all?) motherboards for the amd cpu's use VIA chipsets, and some people have experienced problems with via chipsets and linux.
FWIW, I (and several others that I have corresponded with) have had good luck with an ASUS A7A266 as a replacement for a VIA-based board. It supports at least 1.2G processors, and I believe I have corresponded with someone using the 1.33G processor on that board as well.
It's a bit pricey, but if you intend to build a fast system you would want to compare that to the price of going with a P IV with similar performance (if that's even possible).
Good luck,
Bobby Bryant
Austin, Texas
Quoted 5 lines
This is a reoccurring question on this (and many other) list[s]. It seems like someone ought to maintain a database of boards that are known to work and what they are used for. For example, lots of people say "such and such works for me" but what they don't say is "I only have 1 disk and 1 CDROM and nothing else".
I have 2 ide drives + scsi (with stuff) + sblive + nic (3c905c) + tv-card (+ usb + acpi)
abit KT7A didn't work as I hoped. (KT133A chipset) (many problems with SCSI card however
I used the new aic7xxx driver)
asus a7a266 didn't work as I hoped (Ali Magick) (tv card would freeze the machine) asus KT133-C has worked with everything just fine so far (even better). I think I have
1.03 (or was it 1.3) revision of the board (I can check if someone wants to know) (using old aic7xxx until I get #gentoo properly installed)
Signature · 2 lines
Janne echo [email protected] | tr acefhiklnptu utpnlkihfeca
Quoted 25 lines · Larry McVoy
This is a reoccurring question on this (and many other) list[s]. It seems like someone ought to maintain a database of boards that are known to work and what they are used for. For example, lots of people say "such and such works for me" but what they don't say is "I only have 1 disk and 1 CDROM and nothing else".
I've had fairly good luck with just about any board as long as I don't beat on the IDE on a VIA chipset board. I switched all my servers over to 3ware Escalades to get off the IDE; that helped tremendously but it adds about $400 to a system (3ware card and you will probably want a better PS and cooling, so maybe more).
Yeah, I know, if I'm whining I should volunteer the space. OK, I'll do the
following: if someone starts gathering the data in a simple way (see below) then I'll archive it all in a database and make it accessible via the web. If you are interested in doing this, which means you write the script that gathers the info, contact me offline and we'll set it up.The data format I want is simple. Imagine a perl script gathering the info into an associative array, the key is the field name like "cpu" or "motherboard" etc., and the value is the value, like "AMD K7" or "ASUS A7V". It would be good to have a set of required fields so people can query across those fields, but there need not be any limit on how many fields and all fields need not be present in all records.
Quoted 5 lines
Once you have that, I can send you some code that will shlep over that data to me and I have tools here that will eat it and store it into a database. Our bugdatabase is lot like this, it's a fairly trivial change to support this as a sort of bugdatabase like thing.
First, we need to filter out unrelated info. E.g., I'm happily running many MSI K7V Pro2-As, all with 1 or 2 fast ATA/100 disks (IBM DTLA-307030), SW RAID 0 or 1 for dual disks systems. Never seen any problem, but those are all Red Hat 6.2 with Red Hat's latest kernel (2.2.19-something). I doubt this info is useful at all.
We should create a checklist of requirements an user has to meet to provide useful info, e.g.:
- what kernel version(s) to test, what compile options to set/unset;
- what subsystems to test (e.g. IDE driver?), how, and also how to check that the test conditions are ok (DMA really enabled, and so on);
- what type of problems to look for (data corruption, OOPSes, ...).
Otherwise, you could receive a lot of works-for-me reports, most useless.
.TM.
Signature · 5 lines
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [email protected]Quoted 11 lines · Alan Cox
Quoted 5 lines
I'm planning on getting a new workstation, and I kinda want an AMD system. But it seems that most (all?) motherboards for the amd cpu's us= e
VIA chipsets, and some people have experienced problems with via chipsets and linux.We have seen two big problem sets with the VIA chipsets and Athlon. The first is a bug in some of the bridges that caused corruption. We had partial workarounds but as of 2.4.7ac releases (and I sent it to Linus for 2.4.8pre) we have an official workaround based on VIA provided info.
Quoted 5 lines
The second problem is that some VIA chipset boards lock up running the Athlon optimised kernel. This seems to be board specific and we've also had 'setting CAS3 not CAS2' and 'bigger PSU' reports of fixing it for some people. I'm still trying to put together a detailed enough study of what is going on to actually take it to VIA and AMD engineers.
I just took the plunge this past weekend and bought a Tyan 2390B (KT-133A chipset) and an Athlon 1.2/266 processor.
The system is running smoothly, performance is quite good, and I'm not getting anything scary like random lockups or reboots.. if I use 2.4.8 compiled for Pentium Pro (previous motherboard was PPro).
HOWEVER, if I try to boot an Athlon optimized kernel, I get a variety of problems. In the 2-3 attempts I've tried, I've been able to boot the kernel, but when the kernel runs init and starts processing init scripts, I get a variety of lockups, PANICs, etc..
Alan, what can we do to help provide information? I'll volunteer to run some tests on this system and report the results to try to assist in nailing down the problem. I just don't know what tests to run.. :)
It's running Redhat 7.1 with kernel 2.4.8. This system has two Netgear FA310TXs, two Promise Ultra100 cards, AGP video of some sort and two PC133 256M DIMMs. There's a 15G Maxtor EIDE drive on the via controller, along with an EIDE cdrom on the secondary channel, everything else is on the Promise controllers..
I'm running most BIOS options (especially the scary stuff like memory settings) at their out-of-the-box defaults.
-------------------------------------------------------------------------------
Maxwell Spangler "Don't take the penguin too seriously.
Program Writer It's supposed to be kind of goofy and fun,
Greenbelt, Maryland, U.S.A. that's the whole point" - l.t.
Washington D.C. Metropolitan Area
Quoted 3 lines
Alan, what can we do to help provide information? I'll volunteer to run some tests on this system and report the results to try to assist in nailing down the problem. I just don't know what tests to run.. :)
We know it happens on some boards that apparently cant keep up. We dont know why, there is no time estimate for a cure. That unfortunately is about it
Quoted 2 lines · Alan Cox
We know it happens on some boards that apparently cant keep up. We dont know why, there is no time estimate for a cure. That unfortunately is about it
FWIW (qualitative data point), my EPoX system with the VIA chipset seems to run a few *hours* without an oops when I boot a PIII kernel and run it with X, but a few *days* on the same kernel when I don't start X.
Sometimes it barfs early even without X, but there seems to be a significant difference in the expected uptime between using X and not using X.
Bobby Bryant
Austin, Texas
Quoted 2 lines · Alan Cox
We know it happens on some boards that apparently cant keep up. We dont know why, there is no time estimate for a cure. That unfortunately is about it
Someone should be able to forward failure cases to some AMD contacts. A day or so with a bus analyzer should pin things down, AMD certainly has the hardware to check this.
-Dan
Signature · 1 line
[-] Omae no subete no kichi wa ore no mono da. [-]
Quoted 3 lines
Someone should be able to forward failure cases to some AMD contacts. A day or so with a bus analyzer should pin things down, AMD certainly has the hardware to check this.
It doesnt happen with AMD chipsets. Although if anyone from AMD is interested I'd be happy to know
Alan
Quoted 5 lines · Alan Cox
Quoted 3 lines
Someone should be able to forward failure cases to some AMD contacts. A day or so with a bus analyzer should pin things down, AMD certainly has the hardware to check this.
It doesnt happen with AMD chipsets. Although if anyone from AMD is interested I'd be happy to know
But AMD would certainly be interested in knowing why it fails, especially if it turns out to be a CPU errata with some northbridges, or a CPU errata on its own.
I doubt anyone at VIA is going to cooperate in bug hunting.
-Dan
Signature · 1 line
[-] Omae no subete no kichi wa ore no mono da. [-]
Quoted 5 lines
But AMD would certainly be interested in knowing why it fails, especially if it turns out to be a CPU errata with some northbridges, or a CPU errata on its own.
I doubt anyone at VIA is going to cooperate in bug hunting.
Actually I've talked to a VIA person about it - the problem is I don't have clean concrete repeatably way to generate the problem and generate it rapidly.
Alan
a> Actually I've talked to a VIA person about it - the problem is I a> don't have clean concrete repeatably way to generate the problem a> and generate it rapidly.
Right. The closest I've come to a reproducible setup is "keep the PCI bus very busy and hope for the best". This yields roughly 1 bad byte read out of 150 million for stock 2.4.7, or 1 per 400 million for 2.4.8-ac3.
With error rates like this, it's not likely to be easy to find.
<b
Quoted 9 lines · Alan Cox
Quoted 4 lines
Someone should be able to forward failure cases to some AMD contacts. A day or so with a bus analyzer should pin things down, AMD certainly has the hardware to check this.
It doesnt happen with AMD chipsets. Although if anyone from AMD is interested I'd be happy to know
Alan
I have a MSI-6195 slot-A , AMD chipset with a visiontek nvidia vanta 32mb agp card, RH 7.1 installed. I have experienced complete system lockups with random uptimes < 1 day to 4 days, no mouse, keyboard, VCs, can't even telnet in or ping. I finally made the connection it was happening when I was away from the box and not using it interactively, which lead me to xscreensaver and sure enough after I disabled it, no more lockups, up 30 days now. But I haven't figured what in xscreensaver is doing this, don't know if it might be kernel related or not, probably not. I suspect xscreensaver is triggering something in the xserver that is not normally getting hit in normal use.
Signature · 1 line
Bob Martin
Quoted 4 lines · Bob Martin
I have a MSI-6195 slot-A , AMD chipset with a visiontek nvidia vanta 32mb agp [...]
related or not, probably not. I suspect xscreensaver is triggering something in the xserver that is not normally getting hit in normal use.
Its probably the vanta.
xscreensaver is most likely starting one of the GL screensavers.
xfree86 opengl does not like the vanta on any of my systems -- intel or amd. it locks up after ~10-15 sec of running a gl app.
-Dan
Signature · 1 line
[-] Omae no subete no kichi wa ore no mono da. [-]
Quoted 7 lines · Dan Hollis
Quoted 4 lines · Bob Martin
I have a MSI-6195 slot-A , AMD chipset with a visiontek nvidia vanta 32mb agp [...]
related or not, probably not. I suspect xscreensaver is triggering something in the xserver that is not normally getting hit in normal use.
Quoted 7 lines
Its probably the vanta.
xscreensaver is most likely starting one of the GL screensavers.
xfree86 opengl does not like the vanta on any of my systems -- intel or amd. it locks up after ~10-15 sec of running a gl app.
I think i'd have to disagree. I have a PII-450 with a cheapo Vanta card in it, and i run GL apps ranging from Quake 3 to various GL programs of my own... no hangs. And i leave my system for days on end with a GL screensaver running. Still no hangs. I've used NVidia drivers all the way from 0.9-6 to 1.0-1251 and i never got that kind of instability.
Quoted 6 lines · Adrian V. Bono
I think i'd have to disagree. I have a PII-450 with a cheapo Vanta card in it, and i run GL apps ranging from Quake 3 to various GL programs of my own... no hangs. And i leave my system for days on end with a GL screensaver running. Still no hangs. I've used NVidia drivers all the way from 0.9-6 to 1.0-1251 and i never got that kind of instability.
Thanks for that info. before upgrading to RH7.1 I was using the nvidia drivers and had no problems at all. It's now using the nv driver shipped with xfree 4.03 so that might be the problem, although with xfree 3.3.6 there wasn't a problem with either the nvidia or xfree drivers. I'll grab nvidia driver and give it a try.
Signature · 1 line
Bob Martin