I've been suspicious of Tyan - particularly their bios - due to their response (many years ago) when I experienced problems with one of their dual Pentium boards, that was limited to 100mhz parts (wouldn't take the 133mhz) wouldn't take MMX parts (only "classic" Pentiums) and would only cache 64meg (not Gig, this was a long time ago) meg of RAM. In a dual processor system, even at the time, that was a low limit.

Their tech support spin some delaying story, depending on who you spoke to. I finally got someone new there who just told me the board design was fundamentally bad and would never be reliable with more than 64meg.

More recently, their early 2460 dual Athlon boards were great, but later shipments of the boards were often flakey or DOA. They did seem to fix things with the 2466 - but I now avoid Tyan unless they have some feature I need that's otherwise unavailable.

Given these recent reports, it seems they still can't build a bios.

Are any other manufacturer's boards having similar issues? I have an MSI server with 6gig of RAM running SuSE EL and it seems to be just fine (and other MSI Opteron systems with 4gig or less, also fine). There is one setting on the MSI board (IOMMU?) that must be set properly for

4gig operation. Our Arima boards haven't had any trouble, either, but

none have more than 4gig of RAM installed, so that's no test.

Dan

-----Original Message----- From: John McCorquodale [mailto:mcq1@viz.cacr.caltech.edu] Sent: Thursday, November 20, 2003 3:06 PM To: Michael Madore Cc: John McCorquodale; Mark Horton; suse-amd64@suse.com Subject: Re: [suse-amd64] SUSE 64-bit + 3ware controller = Corrupt filesystem

What sort of AGP problems are you seeing? We are seeing poor performance with > 4GB.

Yes, it's pathetic with 8GB installed. Bandwidth across the AGP connector is about 17MB/s, due mostly to a bogus uncachable MTRR entry that BIOS sets up, the removal of which blows the system away (reason unknown; I don't know why it's there in the first place). With 1GB installed, the frame buffer can be mapped write-combining and AGP b/w jumps to about 250MB/s. This is the fastest I've been able to observe actual data transport (about 1x AGP) depite the fact that the AGP connector is signalling as fast as 8x AGP v3 (on an ATI X1).

The 8151 is on its own HT link, and that link is running at 16 bit, 600 MHz, so there's no architectural reason it should be this slow.

There is clearly something incredibly and obviously wrong going on with way things are getting set up on the board, and being as it's been weeks since I initially started talking to Tyan and have heard nothing back, I'm not hopeful that they're even bothered to reproduce the problem let alone do anything about it. I am afraid they're of the mindset that "picture on screen == works" -- I sure wish they'd correct this misconception if it is one.

Anyway, I'm still of the belief that there's just a crazy memory mapping and requests to AGP are getting stalled/deferred because of some deranged table entries somewhere. I haven't found them yet 'tho. :)

See my posts to the suse-amd64 archives for Oct/Nov timeframe for more details and pointers to a benchmark you can play with if you're that motivated.

I really want to start making my own boards...

Well, I'll keep my fingers crossed. :-)

Yeah.

-mcq