Status of the VIA KT133a and 2.4.x debacle?

Status of the VIA KT133a and 2.4.x debacle?

[Simen Thoresen]

Alan, list, et all,

I've picked up a KT133a board (EpoX 8KTA/3) and a 1.2GHz Thunderbird processor (133MHz FSB), and have seen the same problems that have been reported previously with the KT133a. Random oops'es, both fatal and non fatal, when running the system on a 2.4 kernel with CONFIG_MK7.

The bord seems rock solid with 2.2.x kernels, and also with 2.4.x kernels with CONFIG_M686 set for basic i686 + MMX. I've also run the board with a 100MHz FSB, but that has not improved anything. Also turning off /some/ optimizations in bios have not helped.

Currently, I'm running with a CONFIG_MK7 2.4.9 kernel, but with the Athlon-specific MMX-optimizations in arch/i386/lib/mmx.c turned off, and using the generic mmx-functions available from non-K7 processers. This seems to be working, and I've not been able to provoke a fatal crash oops, nor seen signs of non-fatal oopses.

I have not determined if it is static void fast_clear_page(void *page), or  static void fast_copy_page(void *to, void *from) which is to blame here, but I will continue investigating.

Does this match the results other people have had? Is anything else known about this problem?

Yours,
-Simen Thoresen
--
Simen Thoresen, Beowulf-cleaner and random artist - close and personal.

Er det ikke rart?
The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart

Re: Status of the VIA KT133a and 2.4.x debacle?

[Simen Thoresen]

>Alan, list, et all,
>
I've now realised that this discussion is ongoing, and would just like to chip in with my newer results.

<znip>

>I have not determined if it is static void fast_clear_page(void *page), or  static void fast_copy_page(void *to, void >*from) which is to blame here, but I will continue investigating.
>

I've determined that with the Athlon-optimized fast_copy_page, the machine is easy to push into oopsing. Just starting a dd with blocksize 128M (half available ram) provokes an oops. This is repeatable, consistent and almost fun.

With the Athlon-optimized fast_clear_page, tho, the machine seems stable. I can start the above dd, and two more like it (eating some 128MB into swap as well), and then start using the machine.

It's now been churning away like that for half an hour, and I've never had to wait that long for an oops.

How much is gained using the Athlon-optimized fast_copy_page over the normal fast_copy_page?

Yours,
-S
--
Simen Thoresen, Beowulf-cleaner and random artist - close and personal.

Er det ikke rart?
The gnu RART-project on http://valinor.dolphinics.no:1080/~simentt/rart

Re: Status of the VIA KT133a and 2.4.x debacle?

[Nicholas Knight]

On Saturday 01 September 2001 07:19 am, Simen Thoresen wrote:
> Alan, list, et all,
>
> I've picked up a KT133a board (EpoX 8KTA/3) and a 1.2GHz Thunderbird
> processor (133MHz FSB), and have seen the same problems that have been
> reported previously with the KT133a. Random oops'es, both fatal and non
> fatal, when running the system on a 2.4 kernel with CONFIG_MK7.
>
> The bord seems rock solid with 2.2.x kernels, and also with 2.4.x
> kernels with CONFIG_M686 set for basic i686 + MMX. I've also run the
> board with a 100MHz FSB, but that has not improved anything. Also
> turning off /some/ optimizations in bios have not helped.

Just out of curiosity, can you drop that to 100Mhz FSB and a multiplier 
of 8? I don't know about the manual clocking support on EpoX boards, but 
if you can, it might be good to give it a shot. Most likely it has 
nothing to do with clock speed whatsoever, but I'm really beginning to 
wonder. I don't think I've seen a single reported case under 900-1000Mhz, 
and thunderbirds were made below 900Mhz.

(reason I chose 800MHz is my non-tbird Athlon is 800 and is rock solid)

Re: Status of the VIA KT133a and 2.4.x debacle?

[Gerbrand van der Zouw]

Simen Thoresen wrote:

> Does this match the results other people have had? Is anything else known about this problem?


I have a MSI K7T Turbo board with Athlon 1.2 GHz. Recently I upgraded my 
Award Bios from 2.7 to 2.9. This new version has "memory bank 
interleaving". It also improves the stability of my system a lot. I do 
not know if these are related, but is may be a hint for some of the 
experts out there.

Cheers,

Gerbrand van der Zouw

Re: Status of the VIA KT133a and 2.4.x debacle?

[Patrick Chase]

Gerbrand van der Zouw wrote:
> I have a MSI K7T Turbo board with Athlon 1.2 GHz. Recently I 
> upgraded my Award Bios from 2.7 to 2.9. This new version has 
> "memory bank interleaving". It also improves the stability of 
> my system a lot. I do not know if these are related, but is 
> may be a hint for some of the experts out there.

Are you enabling or disabling bank interleaving with the new BIOS?

I would say that given the nature of the prefetch optimizations 
which appear to be causing instabilities, problems related to
SDRAM bank interleaving of lack thereof should be near the top 
of any list of suspects.

Very briefly, SDRAM parts have multiple banks (either 2 or 4 
depending on capacity). Bank select lines are used to control 
which bank is active for a given access cycle. The existence 
of the banks is significant for two reasons:

1.	Each bank can have a separate page (~= row address) 
open. If you're alternating accesses between two separate address
ranges, then performance may be higher if they're in separate 
banks, as this could potentially avoid a lot of page openings.

2.	Unselected banks can process previously issued multi-
cycle commands while the selected bank is returning data. For 
example, you could request a new address from one bank, and 
then transfer previously requested data from another bank during 
the first bank's CAS latency. 

The "native" address layout of SDRAM devices has each bank a 
contiguous region (i.e. no interleave). An SDRAM controller may 
instead cause the banks to appear interleaved to the processor 
by simply remapping a few address bits. The "interleave" option
in your BIOS enables exactly such a remapping in the north 
bridge's SDRAM controller.

Here's why the Athlon prefetch optimization could potentially
interact with the interleave setting: The entire point of 
prefetching is to cause consecutive cache lines to be fetched
with as much overlap as possible (i.e. the next line is 
requested before the current one has been read in). When 
this is done with interleave enabled, the result is consecutive 
accesses to alternating pages, in which case the chipset will
be able to exploit overlap as described in (2) above to hide
latencies. I can come up with rationales for why this could either 
cause instability or help it, though I think I'll leave that to
those who knows more than I.

-- Patrick Chase

Re: Status of the VIA KT133a and 2.4.x debacle?

[Gerbrand van der Zouw]

Patrick Chase wrote:


> Are you enabling or disabling bank interleaving with the new BIOS?


As it turned out, the oopses are not correlated with the bank 
interleaving. I can turn the feature on and off and system stability 
remains the same (which is good enough to write this mail under X and 
compile a kernel).
The other features that this BIOS upgrade (Award v. 2.9) includes are 
(from the MSI site):

-Add Bank Interleave item in the BIOS Chipset setup
-Adjust Vcore Voltage Sensitivity on Hardware Monitor
-Show CPU L1 and L2 cache size
-Don't Display Ghz for AMD K7 CPU
-Fixed that WD WD400BB-00AUA1 HDD fail in FDISK with nVidia Geforce2 AGP Card


In fact I do have a nVidia Geforce2 card. Another hypothesis is that the 
last fix, also fixes the oopses.

Tomorrow I will flash the BIOS back to 2.7 and see if I get the system 
back to the previous, unstable state.

Regards,

Gerbrand van der Zouw