Dit is een stukje uit een mailtje van de discussie die ik met een aantal mensen hier al over gevoerd heb (van Asus, MSI, iemand uit Zuid Africa en een Rus)<BLOCKQUOTE><font size=1 face=Verdana, Arial, Helvetica>quote:</font><HR> Well about the IRQ-handling-problem on a KT133-based-board, I can only
refer to my own experience. None of the main-board manufacturers have
(officially) published any info relating this problem

But I can say the guys at Asus were really glad the problem also occurred
on the MSI-board (K7T-pro, not yet the k7t-pro-2) and vise-versa.
I've had some discussions with both about this problem, so far without any
result (well, my computer-knowledge has improved)
The problem:
While the CPU (Duron/T-bird) is occupied for almost 100% (like running
Seti@home) the other devices can't be accessed real-time.
Like the MP-3's you're playing are hicking.
likely-cause:
The AMD-proc.'s use the EV-6 bus to communicate with the chipset.
This is a dual-pumped-bus, so the communication with the chipset is quite
fast (almost like it's operating at 200 MHz)
The problem seems to occur when the buffers from and to the CPU (or
chipset) are filled, because of the slower communication with the memory (perhaps I'll test it on a machine with 2 single-sided Dimm's next
thursday, to test the bank-interleaving-performance (like 2*64 MB))
This because it happens more often with Seti than with RC-5. Both keep the
CPU for almost 100% busy, but Seti uses more mem.
So it seems that this causes a noticeable delay, when a proces-switch is
being made.
I also think that IRQ-steering has a pipe-line wich is a bit too long (If
I'm correct the KT-133 is based on a very simple PCI-communication
implementation and therfore has a deeper pipeline (read: longer
latency) than usual.
Tested on:
MSI K7T pro
Asus A7V
Jetway-Socket-A-board
Soltek-Socket-A-board
---------------------
Duron 600 (and also Duron 600@950, you're a tweaker, or you're not....)
Duron 750 (newer core/rev.)
Thunderbird 700, 800, 900 and a 750@900 (the last one wasn't completely
stable

)
--------------------
PC-133 mem @ both 100-bus (3-2-2) and 133-bus (3-3-3) (couldn't find any
PC133_2-2-2 modules)
-------------------
On-board-sound chips (MSI ans Asus-boards)
SB-128-vibra
SB-Live 1024
Guillemot 128
Guillemot Fortissimo
(both Guillemot cards have a Yamaha XG-chip)
--------------------
Win '98 (NL)
Win '98 SE (UK & NL)
Win ME (UK)
Linux 2.2.12-kernel
Linux 2.2.17-kernel
(both kernels self-made to include the sound-card support in the kernel and not using any module anymore. Note: The Duron didn't work with the
2.2.12 kernel)
So I think I can say that I've tested quite some possibilities

And with all test-systems the problem was reproduce-able
It's nice to have so much at stock and always the newest hardware to play
with (and get paid to play with;) )
Well I hope I made it a bit more clear what I meant and take into account
that the above mentioned possibe causes are just what I think of it and
are not officially supported by VIA.
regards.......[/quote]Dus 't is niet alleen Windows... 't lijkt me iets wat in de hardware zit.
'k moet zeggen een nieuw bios hebbik nog niet geprobeerd (althans niet een nieuwere dan +/- anderhalve maand geleden, toen dit speelde)
Een goedkope voeding is als een lot in de loterij, je maakt kans op een paar tientjes korting, maar meestal betaal je de hoofdprijs. mijn posts (nodig wegens nieuwe layout)