Chapter 1. describled story comp setup 10.juni.2001

As some may have noticed i had the great idea to switch my Asus a7v-133 to epox 8k7a+ which is a DDR

mainboard. The board was shipped very fast, including 512mb Micron DDR memory.

Friday around 12:00 it arrived. My last words in chat to Orion were "ill be back in around 1 hour".

Today is Sunday 18:26 as i type this. What happened in the meantime. A short overview over an odysse in 3 acts.

Here you see the Epox 8k7a+ raid board with the Swiftech 462 mounted on it. The CPU on it "was"

the thunderbird 1.33ghz AXIA

disassembling old comp setup.

the epox short before beeing placed inside. At this moment the axia 1.33 wa still alive covered by

Arctic Silver thermal paste.

the mess on the second desk. you see the removed asus a7v-133

here i already was unable to start the full installed computer longer than 5 sec, and made the a7v133

ready to take the cpu to see if it was crunched or overheated after removing all others components of

the new setup didnt showed the problem.

Ghetto Hardware would be proud of me.

As i removed the Swiftech 462 i noticed it didnt had made any contact to the cpu. The Problem with the

swiftech is that it has no clipping mechanic but is mounted directy in the mounting holes around the socket.
As the spacers that are usually placed on the holes doesnt fits i used a self made spacer with the old board but decided to leave them out this time as i had read in multiple reviews that they had no probs without spacers to let the cooler make good contact with the cpu.

While on the a7v-133 i could look with a lamp under the socket to check if it made good connection, the epox socket is surrounded by capacitators which makes it more than difficult, so i didnt double checked on first run.

 

As an overheat mechanic after the thermal sensor in the Epox socket reached around 60° it stopped to boot. my bad i didnt knew it had this protection.
To test if the cpu after this actually was still alive i installed it in the a7v-133 but wasnt up mounting the swiftech (it takes a lot of time and i wanted to have something that i can doublecheck that it makaes "contact". so i had some aluminium part of a coolermaster and used 2 old coolers of a slot A setup to cool it. (like you see funny on the picutre;)
As i turned it on it gave an error code like a siren. Now in the manual you find 4 possible error beep codes but of course not the siren. So i went over the router to the Award page just to read that theres only 1 error code and every other may relay to memory. MAY(or so) they say.. god i was on the manufacturer page. So i searched in the web for the codes and found fast out that it was as i thought the code for a not working CPU.
I went in the town, brought the old CPU rma (worth a try) and bought an 1.4 ghz.
Actuall y thats the first CPU i ever destroyed in 13 years mounting computer things. hm.

new 1.4ghz thunderbird cpu. Watch the sticker on the side "waranty void if removed" over the L1

and L2 bridges to prevent "waranteed" overclocking by unlocking it. Funny it was factory unlocked

anyway.

hm 17:30, i still can make it in chat today.. ?

The great moment. After installing the new CPU and trying to mount the swiftech with the self made

mounting-hole spacers and using a little lamp and a swiss army knifes blade as mirror to look under the

socket i tried to get the system up: success.. but is the swiftech mounted right or will it frie the next cpu?

37° .. phew.

Meanwhile i needed some relax from time to time in Living room to jump around lol:

actually the best besides a box-puppet

system mounted, os installed, first hardcore crash test

hm very good for a not yet tweaked or oc`ed system

that was the state friday night. well the problem started actually when i was installing and listening mp3 and

heard the first time the cracking noise out of the soundblaster, which after 2 days research turned out to be

the 686b southbridge bug

one of 7 boards where i tried to seek the answer.

actually the replies and my tests were pretty good. you can get whole thread here

with the AMD 761 northbridge register specifications and some literature about the via southbridge bug i started

to find the parameters that would get the cracking problem away

H-Oda`s WCPREDIT changing pci registers

Now there are a lot of hints and a lot of parameters. due to the complexity of the pci 2.1 specification problem

resulting in the infamous bug in the current southbridge release atm i still look for the right parameter although

reducing the cracking already by like 95%.

TC HQ now ;o)

finally after downloading and reading the amd techdoc and playing with the pci latency timer

i could find the long searched latency driver in the 761chipset and

begin to search the troublefree setting.

 

the whole problem turns out to be a little complex as all i tweaked still is not 100% but
the problem is very complex cause its a prob in pci 2.1 specification. the needed parameters are
pci latency timer: test low
pci master read caching: off (are in newer bios off already as part mainboard-bios southbridge fix)
delay transaction : off
(are in newer bios off already as part mainboard-bios southbridge fix)
PCI arbitration
thats the timing in register 0x84 bit 23
also a part of southbridge problem but for cracking noise next is more important

the "Disconnect enable when STPGNT Detected" named so in via kt133A ad "solve any problems with sound distortion caused by registers 0x40 und 0x84 registers (these registers now referred to amd761)." writes George E Breese of viahardware in his sourcecode-documentation for his driver.(thats only for full via-chipset boards (but its the same problem). i think now that the via STPGNT register "STPGNT" is Stp_Grant_Discon_En bit im BIU Status/Control register 0x60 bit 17 for AMD 761 what after tec doc is "this action causes the amd-761 system controller to react to the stop grant special cycle on the amd athlon system bus simply by forwarding the cycle to the pci bus, but not attempting any processor disconnect." the default of the stp_grant_discon_en bit is 1. sadly this cant be altered so easy cause it jumps back to 0. that could be cause following registers are dependant of stp_grant_discon_en bit: the 0x85 bit 19 dram refresh has to be 1 if stp_grant_discon_en is 1. the question is if its also dependant if stp_grant_discon_en is set to 0 and the self-refresh in status/control register 0x70 bit 18 which also has to be 1 as default if stp_grant_discon_en is 1