Jammer genoeg was er op het topic van PCI latency patch al een slote gezet 
Ik wou namelijk even een toelichting geven op dit zeer irritante probleem en mijn bevindingen delen.
Het is al een tijd geleden toen deze bug naar voren kwam. Deze werd veroorzaakt door met name sblive en southbridge die strijden om PCI bus toegang.
Er zijn toen allerhande patches uitgebracht. Bios upgrades etc. Voor de meesten werd geadviseerd om de volgende settings uit te schakelen als dat al niet gebeurd was.
PCI Delay transaction disabled
PCI master read caching disabled
PCI bus master Timeout 32 cycles.
Ik vermoedde op gegeven moment dat ik datacorruptie had met kopieren nog steeds. Ik heb verschillende dingen zitten testen. GEEN een van de bovenstaande settings veroorzaakte bij mijn mobo (Zie specs onder) datacorruptie.
Na wat spitten kwam ik erachter dat Master priority rotation de oorzaak was. Juist ja de setting die het veroorzaakte was onaangetast gebleven. Deze setting bepaalt wanneer de CPU toegang krijgt tot de PCI bus. Dit kan zijn na iedere 2 of 3 PCI cycles of na iedere PCI grant (Na elke keer dat een PCI apparaat toegang heeft gekregen van de PCI bus)
Deze stond standaard op 2 clockcycles. Nadat ik deze setting op every PCI master grant had gezet waren alle problemen als sneeuw voor de zon weg. Ik heb dit aangepast met een proggie wat chipset registers kan lezen en wijzigen.
http://hp.vector.co.jp/authors/VA002374/src/download.html
Dus voor iedereen met de KT133(A) chipset en een 686B southbridge bekijk die registers en let vooral op de instelling Master priority rotation.
De crashes in 3dmark 2001 en de infinite loopbug in windows xp wordt opgelost door bit 7 van register 55 op nul te zetten. Dit had te maken met een memory write queue die overbelast werd. Met register 55 kan deze uitgeschakeld worden. Extra koeling voor je CPU en lowpower mode kan enabled worden door bit 7 van register 52 te setten.
De betreffende registers zijn bij mij nu als volgt ingesteld.
Register 52: EB (Bit 7 Disconnect enable when STPGNT detected)
Register 55: 09 (Bit 7 dient op 0 gezet te worden)
Register 70: CE (PCI master read caching en Delay transaction op enabled. Bits 1, 2
Register 76: D2 (Master priority rotation. Bits 4 en 5 dienen ingesteld te worden op
every PCI master grand. Dus bit 5=0 en bit 4=1)
Voor iedereen die nog met een KT133A chipset werkt is het een aanrader om dit te controleren. Het is dus nog heel goed mogelijk dat er datacorruptie optreed maar dat je het niet zo gauw merkt. Ik heb het dus uitvoerig zitten testen. En bij mijn bord met betreffende chipset veroorzaakt dus Master priority rotation datacorruptie. Ik heb dit zitten testen door van verschillende ide poort groot bestand te kopieeren. AVI van 700 Mb van cdrom op IDE sec. naar HD op IDE prim.
Dit lost uiteraard alles op. Ook het gekraak met soundblaste live. Het dient zeker wel aan te raden om PCI delay transaction aan te hebben staan ondanks het onterechte advies van via Dit neemt namelijk onnodig veel PCI tijd in beslag als de bus continue moet wachten op ISA bus die vele malen trager is. Met PCI delay transaction zal de PCI bus alle data richting ISA bus naar buffer schrijven en zich met andere taken bezighouden.
En plz mensen met de laatste DDR bordjes en fancy stuff kom niet met flame opmerkingen of bijdehande opmerkingen over het feit dat dit verhaal al zolang bekend is. Er zijn nog mensen die deze bordjes gebruiken en dit niet in deze details weten.
Bedankt.
Ik wou namelijk even een toelichting geven op dit zeer irritante probleem en mijn bevindingen delen.
Het is al een tijd geleden toen deze bug naar voren kwam. Deze werd veroorzaakt door met name sblive en southbridge die strijden om PCI bus toegang.
Er zijn toen allerhande patches uitgebracht. Bios upgrades etc. Voor de meesten werd geadviseerd om de volgende settings uit te schakelen als dat al niet gebeurd was.
PCI Delay transaction disabled
PCI master read caching disabled
PCI bus master Timeout 32 cycles.
Ik vermoedde op gegeven moment dat ik datacorruptie had met kopieren nog steeds. Ik heb verschillende dingen zitten testen. GEEN een van de bovenstaande settings veroorzaakte bij mijn mobo (Zie specs onder) datacorruptie.
Na wat spitten kwam ik erachter dat Master priority rotation de oorzaak was. Juist ja de setting die het veroorzaakte was onaangetast gebleven. Deze setting bepaalt wanneer de CPU toegang krijgt tot de PCI bus. Dit kan zijn na iedere 2 of 3 PCI cycles of na iedere PCI grant (Na elke keer dat een PCI apparaat toegang heeft gekregen van de PCI bus)
Deze stond standaard op 2 clockcycles. Nadat ik deze setting op every PCI master grant had gezet waren alle problemen als sneeuw voor de zon weg. Ik heb dit aangepast met een proggie wat chipset registers kan lezen en wijzigen.
http://hp.vector.co.jp/authors/VA002374/src/download.html
Dus voor iedereen met de KT133(A) chipset en een 686B southbridge bekijk die registers en let vooral op de instelling Master priority rotation.
De crashes in 3dmark 2001 en de infinite loopbug in windows xp wordt opgelost door bit 7 van register 55 op nul te zetten. Dit had te maken met een memory write queue die overbelast werd. Met register 55 kan deze uitgeschakeld worden. Extra koeling voor je CPU en lowpower mode kan enabled worden door bit 7 van register 52 te setten.
De betreffende registers zijn bij mij nu als volgt ingesteld.
Register 52: EB (Bit 7 Disconnect enable when STPGNT detected)
Register 55: 09 (Bit 7 dient op 0 gezet te worden)
Register 70: CE (PCI master read caching en Delay transaction op enabled. Bits 1, 2
Register 76: D2 (Master priority rotation. Bits 4 en 5 dienen ingesteld te worden op
every PCI master grand. Dus bit 5=0 en bit 4=1)
Voor iedereen die nog met een KT133A chipset werkt is het een aanrader om dit te controleren. Het is dus nog heel goed mogelijk dat er datacorruptie optreed maar dat je het niet zo gauw merkt. Ik heb het dus uitvoerig zitten testen. En bij mijn bord met betreffende chipset veroorzaakt dus Master priority rotation datacorruptie. Ik heb dit zitten testen door van verschillende ide poort groot bestand te kopieeren. AVI van 700 Mb van cdrom op IDE sec. naar HD op IDE prim.
Dit lost uiteraard alles op. Ook het gekraak met soundblaste live. Het dient zeker wel aan te raden om PCI delay transaction aan te hebben staan ondanks het onterechte advies van via
Dit neemt namelijk onnodig veel PCI tijd in beslag als de bus continue moet wachten op ISA bus die vele malen trager is. Met PCI delay transaction zal de PCI bus alle data richting ISA bus naar buffer schrijven en zich met andere taken bezighouden.En plz mensen met de laatste DDR bordjes en fancy stuff kom niet met flame opmerkingen of bijdehande opmerkingen over het feit dat dit verhaal al zolang bekend is. Er zijn nog mensen die deze bordjes gebruiken en dit niet in deze details weten.
Bedankt.