Re: VIA chipset

Re: VIA chipset

[Marco Colombo]

> > 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

Sorry to bother you again with this issue, Alan... by 'AMD chipsets'
you mean BOTH north and south bridges (eg. 761 + 766) or does it include
also AMD NB + VIA SB combo?
AMD 761 + VIA 686B based MBs are quite common this days: are they "safe"
(do you have failure reports)?
Thanx a lot (you may guess, I'm about to buy some MBs) B-) ...

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: VIA chipset

[Alan Cox]

> Sorry to bother you again with this issue, Alan... by 'AMD chipsets'
> you mean BOTH north and south bridges (eg. 761 + 766) or does it include
> also AMD NB + VIA SB combo?

I am using pure AMD chipsets. There are a large number of VIA boards that
work reliably too ask around.

Re: VIA chipset

[Jussi Laako]

Marco Colombo wrote:
> 
> Sorry to bother you again with this issue, Alan... by 'AMD chipsets'
> you mean BOTH north and south bridges (eg. 761 + 766) or does it include
> also AMD NB + VIA SB combo?
> AMD 761 + VIA 686B based MBs are quite common this days: are they "safe"
> (do you have failure reports)?

At least my ASUS A7M266 works very well. It has AMD 761 nb and VIA 686B sb
and the 686B is used only for IDE and IO interfaces. PCI bus comes from the
761, AFAIK.

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers

Re: VIA chipset

[Marco Colombo]

On Wed, 12 Sep 2001, Jussi Laako wrote:

> Marco Colombo wrote:
> >
> > Sorry to bother you again with this issue, Alan... by 'AMD chipsets'
> > you mean BOTH north and south bridges (eg. 761 + 766) or does it include
> > also AMD NB + VIA SB combo?
> > AMD 761 + VIA 686B based MBs are quite common this days: are they "safe"
> > (do you have failure reports)?
>
> At least my ASUS A7M266 works very well. It has AMD 761 nb and VIA 686B sb
> and the 686B is used only for IDE and IO interfaces. PCI bus comes from the
> 761, AFAIK.
>
>  - Jussi Laako
>

Thanks for your answer! Can you please confirm me that both the ATA/100
controller (at ATA/66 or ATA/100 speed) and Athlon optimized kernels work?

.TM.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: VIA chipset

[Anders Peter Fugmann]

I've got a A7M266 (1.33 Ghz, 133 Mhz fb), and all works perfectly:
ATA100 + DMA + K7/3DNOW optimization.

No craches yet (run for about 2 month).
I'm very satisfied with this mobo - IMHO it's a good buy.

Regards
Anders Fugmann


Marco Colombo wrote:

> On Wed, 12 Sep 2001, Jussi Laako wrote:
> 
> 
>>Marco Colombo wrote:
>>
>>>Sorry to bother you again with this issue, Alan... by 'AMD chipsets'
>>>you mean BOTH north and south bridges (eg. 761 + 766) or does it include
>>>also AMD NB + VIA SB combo?
>>>AMD 761 + VIA 686B based MBs are quite common this days: are they "safe"
>>>(do you have failure reports)?
>>>
>>At least my ASUS A7M266 works very well. It has AMD 761 nb and VIA 686B sb
>>and the 686B is used only for IDE and IO interfaces. PCI bus comes from the
>>761, AFAIK.
>>
>> - Jussi Laako
>>
>>
> 
> Thanks for your answer! Can you please confirm me that both the ATA/100
> controller (at ATA/66 or ATA/100 speed) and Athlon optimized kernels work?
> 
> .TM.
> 

Re: VIA chipset

[Jussi Laako]

Marco Colombo wrote:
> 
> Thanks for your answer! Can you please confirm me that both the ATA/100
> controller (at ATA/66 or ATA/100 speed) and Athlon optimized kernels 
> work?

Yes it does. I have one IBM ATA66 disk and one Maxtor ATA100 disk. Also HP
CD-RW drive. CPU is 1 GHz TB.

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers

Re: VIA chipset

[grouch]

First, my apologies to the list subscribers and to the person responding
privately to my questions. I assumed that person was posting to the list
and CC'ing replies to me, since I am not subscribed to the list. My
replies were CC'ed to the list because of that. The assumption was
wrong and the result is that I was rudely posting my half of a private
conversation to this public mailing list. Sorry.

Second, the system lockups appear to be cured! It appears to be a
problem with using Ultra ATA/100 drives on an Award BIOS + VIA chipset
motherboard that only supports up to Ultra ATA/33 drives. Note that even
the tests I ran with the BIOS set to disable UDMA and the kernel
configured to not use UDMA resulted in system hangs.

First clue came from a single line about (of all things, Windows 95) on
page 51 of this document from IBM: djna-dpta-dtla_digw.pdf . It warns of
system hangs when a UDMA 100 or UDMA 66 drive is used on some UDMA 33 or
lower motherboards.

Using the IBM Drive Feature Tool at
http://service.boulder.ibm.com/storage/hddtech/ibmftool-install-img.bin
I set the IBM-DTLA-305040 drive to report and use UDMA 33. This utility
http://www.wdc.com/service/ftp/dlgtools/dlgmaker.exe was used to do the
same for a WDC AC26400R drive.

I've only tested it for a night, shuffling a few G's of data around, but
much less was needed to lock the system under 2.4.x before. I have no
clue why it never locked using the default Debian 2.2.18pre21 kernel,
why it locked quickly with any 2.4.x kernel, why it locked only
occasionally with a 2.2.x kernel with ext3, nor why it appears stable
now.

Maybe this will save someone else some frustration. Then again, maybe
it's a fluke caused by the phase of the moon when the mobo was made.

Terry Vessels

Re: VIA chipset

[grouch]

On Mon, 15 Oct 2001, Mark Hahn wrote:
>> The stable machine that runs the same brand and model motherboard as the
>> one that is causing troubles is running 2.4.5. It has a WDC
>
>same bios revision?  I think you posted some excerpts of the PCI
>config, and they differed in USB, which is odd.
>

Same bios; I flashed both boards using the info here:
http://www.tyan.com/support/html/b_tr_100at.html
and this bios (why are they always .exe files?):
ftp://ftp.tyan.com/bios/trinity/s1590s_at100/v90w116c.exe

Re: VIA chipset

[grouch]

On Mon, 15 Oct 2001, Mark Hahn wrote:

>> RAM is cheap :). BIOS is the latest available from Tyan for this board.
>
>I meant to imply that such hardware was not originally designed for
>lots of memory (or rather, when it was designed and tested, "lots"
>meant something quite different!)

Maximum RAM for the motherboard is 768MB; it has 3 168 pin DIMM sockets.

>> That's an interesting point. This thing does not like 80 conductor
>> cables at all.
>
>that can only mean that the driver is correctly sensing whether
>you have 40 or 80, and limiting speed with 40 to udma33, and that
>the lower speed doesn't provoke as much trouble.

The motherboard supports only up to UDMA 33 which, IIUC, does not
require 80 conductor cables. The board shipped with a 40 conductor cable
when new. I only tried an 80 to try to cover all bases.

>I don't remember whether I asked this or not, but are you sure
>of your clocks?  ie, not overclocking, and have agp at 66,
>pci at 33?

CPU bus speed is at 100 MHz, memory is at 100 MHz, PCI is at 33 MHz, AGP
is unused.

>personally, I don't see any real point to using obsolete 2.2 kernels;
>I'd rather figure out how to make it work with a modern kernel.
>I acknowlege that other people may have different priorities ;)

This is the first PC I've been unable to get to be stable using Linux.
Up until about 2 months ago this system was used by a Windows user
(maybe some of his lockups were not due to windows?). I have two
machines running 2.2 kernels and three running 2.4 kernels constantly,
with another machine that dual boots with a 2.4 kernel.

>I have a K6-2/300 with a via board that works perfectly
>with 2.4.something (probably around 9).  I think it's doing some
>reasonable udma mode, as well, though not with a DTLA.

The stable machine that runs the same brand and model motherboard as the
one that is causing troubles is running 2.4.5. It has a WDC
WD400BB-00AUA1 hard drive as hda and an ASUS CD-S400/A 40x cd as hdb. I
started testing by duplicating as much as possible from the setup of the
stable machine.

Re: VIA chipset

[grouch]

On Mon, 15 Oct 2001, Mark Hahn wrote:

->> RAM: 256MB pc133
->
->that's a lot of ram for an old system like this.  have you scrutinized
->the bios settings/jumpers?  reasonably up-to-date bios installed?

RAM is cheap :). BIOS is the latest available from Tyan for this board.

->> HD: tested with WDC AC26400R, 6149MB w/512kB Cache
->>     and with IBM-DTLA-305040, 41174 MB w/380KiB Cache
->>     (tested with each separately and together)
->>     IBM drive tested both before and after setting it to report as
->>     a PIO mode 0 drive, using IBM's "Drive Feature Tool".
->
->pio is almost never a sane setting; certainly not for a dtla.

I moved the IBM drive to another system and experienced a lockup. A
search showed that some BIOS/chipsets locked when these drives reported
as UDMA 100 and a solution is to use the IBM "dft 2.30" to cause the
drive to report itself at some lower capability. This worked in the
other system so I tried the drive in the VIA chipset system again. It
still locks.

->mixing vendors on the same cable is asking for trouble;

Tested with both and with each.

->do you see problems with just one disk per channel?

Yes.

->> Other IDE: ATAPI 4x CDROM
->
->on its own channel, I presume?

Tested as slave, master on secondary, not connected.

->also, is the ide config valid?  (ie, cables <= 18", both ends plugged in,
->preferably with 80-conductor cables?)

That's an interesting point. This thing does not like 80 conductor
cables at all. I first suspected a damaged motherboard instead of a
buggy chipset/BIOS. I went through all tests at
http://www-106.ibm.com/developerworks/linux/library/l-hw1/ and
http://www-106.ibm.com/developerworks/linux/library/l-hw2/ to check the
hardware. Continuous kernel compiles overnight caused no locks using
default Debian (stable) kernel. memtest86 ran its full test (over 10
hours) with no problems.

->> CONFIG_APM is not set
->> CONFIG_ACPI is not set
->
->but how about the corresponding bios settings?

APM is disabled in BIOS.

->> Is there a way to grab kernel messages or registers or something just before
->> a lockup occurs?
->
->sure, magic sys-rq, a kernel compile option.
->

D'oh! Thanks, I will try that.

Update: system locked overnight using 2.2.19 with ext3 while doing
apt-get dist-upgrade. Some directories were mounted via NFS, but it
locks under 2.4.x whether NFS is involved or not. Will go back to 2.2.19
with ext2 and see how long it can do disk work.

Re: VIA chipset

[grouch]

My apology beforehand for a long message.

Problem: system locks with 2.4.x kernels
Symptoms: no response to keyboard input, no disk activity, no response to
	NumLock or Caps Lock, no response to ssh, http or ping
Suspect: VIA chipset
Conditions at lock: varies, usually during disk activity. Nothing left
	behind in /var/log/messages

Motherboard: Tyan Trinity 100AT S1590S rev. 1.20 (UDMA 33)
CPU: AMD K6-2 350
RAM: 256MB pc133
HD: tested with WDC AC26400R, 6149MB w/512kB Cache
    and with IBM-DTLA-305040, 41174 MB w/380KiB Cache
    (tested with each separately and together)
    IBM drive tested both before and after setting it to report as
    a PIO mode 0 drive, using IBM's "Drive Feature Tool".
Other IDE: ATAPI 4x CDROM
Video: tested with an ATI and an old Cirrus Logic, no X tried as yet

Using kernel 2.2.19-ext3, output of /sbin/lspci

00:00.0 Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:0b.0 VGA compatible controller: Cirrus Logic GD 5430/40 [Alpine] (rev 47)

Another system uses the same brand and model of motherboard
and has been stable using kernel 2.4.5 since August, but
/sbin/lspci produces:

00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 02)
00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
00:09.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo Banshee (rev 03)
00:0b.0 SCSI storage controller: Tekram Technology Co.,Ltd. TRM-S1040 (rev 01)

Kernels tested:

  No locks:
	2.2.18pre21, 2.2.18, 2.2.18 w/jfs 1.0.5, 2.2.19, 2.2.19 w/ext3

  Locks:
	2.4.5 (copied from stable system), 2.4.5 (compiled on locking system),
	2.4.9-k6 (kernel package from people.debian.org/~bunk), 2.4.9,
	2.4.10-pre13, 2.4.10-pre13 w/xfs 1.0.1, 2.4.10, 2.4.10-ac7,
	2.4.10 w/xfs 1.0.1, 2.4.10 w/jfs 1.0.6, 2.4.12, 2.4.12-ac2,
	2.4.12-ac2 w/ext3

Each kernel config was tried with i386 and i586. Also, where available,
CONFIG_BLK_DEV_VIA82CXXX=y or CONFIG_BLK_DEV_VIA82C586=y
Tested with UDMA enabled and disabled.

Based on search results of the kernel mailing list archive,
(in this thread --
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/1034.html )

CONFIG_APM is not set
CONFIG_ACPI is not set

I'm all out of ideas for what to try next and all out of search leads. Does any
of this make sense to somebody or should I just resign myself to using this
particular system with a 2.2.x kernel and cross my fingers about it never locking
under that?

Judging by the amount of discussion I found about VIA-related problems, I'm
guessing this is not so rare that it might be a waste of programmer time. If
a test subject would help, I'm very willing to pound on the misbehaving
machine in whatever way is needed. I can easily strip it down to the bare
necessities for booting and configure test kernels any way desired for testing.
Is there a way to grab kernel messages or registers or something just before
a lockup occurs?

Thanks for taking time to read this far. Since I'm a program abuser, not a
programmer, and almost all the conversation is over my head, please CC any
reply to grouch@apex.net. I'm not subscribed to the mailing list, I've only
been searching and sifting through it for the month or so I've been chasing
this problem. (If anyone wants me to run tests and my subscribing to the
list would make things more convenient for them, just say so).

Terry Vessels

VIA chipset

[amit yajurvedi]

Hello,
   I bought a new VIA Apollo Pro Plus mother board. I have Mandrake Linux 8.0(2.4.3) installed. Whenever I start X(KDE,GNOME,Bluefish) first or second click of mouse results in rebooting of the system. Please help me.

Thank you,
Amit


Make a difference, help support the relief efforts in the U.S.
http://clubs.lycos.com/live/events/september11.asp

Re: Via chipset

[Bob Martin]

"Adrian V. Bono" wrote:
> 
> 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.
-- 

Bob Martin

Re: Via chipset

[Adrian V. Bono]

Dan Hollis wrote:
> 
> On Thu, 16 Aug 2001, Bob Martin wrote:
> > 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.
> 

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.

Re: Via chipset

[Dan Hollis]

On Thu, 16 Aug 2001, Bob Martin wrote:
> 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

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: Via chipset

[Alan Cox]

> 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.

Thats actually quite possible. In paticular it uses arc's which basically no
other X app ever does. Report that info to either XFree or nvidia (depending
on whose X server)

Alan

Re: Via chipset

[Bob Martin]

Alan Cox wrote:
> 
> > 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.

-- 

Bob Martin

Re: Via chipset

[Bryan O'Sullivan]

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

Re: Via chipset

[Alan Cox]

> 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

Re: Via chipset

[Dan Hollis]

On Wed, 15 Aug 2001, Alan Cox wrote:
> > 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

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: Via chipset

[Alan Cox]

> 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

Re: Via chipset

[Dan Hollis]

On Wed, 15 Aug 2001, Alan Cox wrote:
> 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

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

RE: Via chipset

[Ryan C. Bonham]

Alan,

Is anyone keeping a list of which boards with VIA chipsets are having
problems, and which aren't.. Or is the problem more random then that, like
some Abit board work and some don't??  If there is a list, would someone
send it to me.. I am interested in trying to help debug this problem, and I
need to know what boards I should test this out on.. 

Thanks

Ryan

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Wednesday, August 15, 2001 12:10 PM
> To: bdbryant@mail.utexas.edu
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Via chipset
> 
> 
> > Alan Cox wrote:
> > > 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.
> 
> If you are running XFree servers then provide info on the 
> card, the machine
> configuration and XFree version, whether you use DRI or not. 
> Also send the
> same info to XFree86 themselves. It's entirely possible the Xserver is
> the trigger some of the bugs, and getting the info to both 
> parties will
> really help
> -
> 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: Via chipset

[Alan Cox]

> Alan Cox wrote:
> > 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.

If you are running XFree servers then provide info on the card, the machine
configuration and XFree version, whether you use DRI or not. Also send the
same info to XFree86 themselves. It's entirely possible the Xserver is
the trigger some of the bugs, and getting the info to both parties will
really help

Re: Via chipset

[Bobby D. Bryant]

Alan Cox wrote:

> 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

Re: Via chipset

[Alan Cox]

> 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

Re: Via chipset

[Maxwell Spangler]

On Wed, 8 Aug 2001, Alan Cox wrote:

> > 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.

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

Re: Via chipset

[Marco Colombo]

On Tue, 7 Aug 2001, Larry McVoy wrote:

> 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.
>

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.
-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

Re: Via chipset

[Janne Pänkälä]

> 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)

-- 
Janne
echo peufiuhu@tt.lac.nk | tr acefhiklnptu utpnlkihfeca

Re: Via chipset

[Ignacio Vazquez-Abrams]

On 8 Aug 2001, Øystein Haare wrote:

> 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.

> 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.

> 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.

> Øystein Haare

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Via chipset

[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.  

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.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Via chipset

[Alan Cox]

> 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

Re: Via chipset

[Dan Hollis]

On 8 Aug 2001, Øystein Haare wrote:
> 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).

> would I be better off getting a P4 system?

Nope

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Via chipset

[Ø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.

Have these problems been fixed, or are they still present?

would I be better off getting a P4 system?


Øystein Haare

Re: Via chipset

[Bobby D. Bryant]

Øystein Haare wrote:

> 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