AN8 [FATAL1TY] SLI // boot+restart problems

[Damian]

Specs:

A64 3500+
AN8 Fatal1ty [sli]
Pc3200 OCZ Gold VX ed. [2x512]
XFX 6800GT [pci-e]

1x WD 200GB [SATA]
1x CDRW

PSU: Tagan 480watt
.........Generic 300watt

(if i have missed anything else do ask)


Issue:

This machine had been suffering from a few problems, and so to find the cause of the problem as only the motherboard or graphics card where suspect, i sent off for a replacement motherboard..

Today i recieved the board and put the system together in hope that this would shed some light on the subject. after turning on the pc i found that it was completely fine, no problems what so ever...

after setting information in the cmos however (and restarting) i found that it would go to standby and hang, so i cleared the cmos.. and it was fine once again. (each time ending on a "post code 0.6), and with an error message noted as "checksum error" please press F1 to continue.. (now i cant remember if this was CMOS or BIOS bu i will find out tommorrow afternoon).

Anyways, this meant that i couldn't set anything in the bios, but to prove that everything (apart from this) was operating as normal i decided to install xp without setting the BIOS (with minimal kit and 512 of the 1gb of memory), and so i did. after installing i installed the drivers and so far it seems to be working fine, so i decided to install the second 512 stick and clear the cmos again, and this worked without fail....

at this point im wondering if it could be a BIOS compatibility problem where one of the components i have installed (cpu memory etc) is not being fully initialised, and then coming up with the "checksum error", i will check my bios version as soon as possible to find this out, but i have heard to have a a64 3500+ you need the 1.3 bios version, any ideas?

another thing is memory timings, now i know from previous history that incorrect timings could lead to this problem, but i get this on auto and "by spd" so this im thinking might have to be done manually, but i think i might need help on this... and in as much detail as possible to what the timings should look like?!? (im a bit "in the air" at the moment, and v.worried so the help would be appreciated!)


Sorry if this is a bit solid... but i was trying to include as much info as possible, and what ever i didn't i'll try and get for you as soon as possible, and do say if i have missed anything!

Damian,

[Damian]

Here's some info i found to explain:

A checksum is a form of redundancy check, a very simple measure for protecting the integrity of data by detecting errors in data that is sent through space (telecommunications) or time (storage). It works by adding up the basic components of a message, typically the bytes, and storing the resulting value. Later, anyone can perform the same operation on the data, compare the result to the authentic checksum, and (assuming that the sums match) conclude that the message was probably not corrupted.

BIOS ROM Checksum Errors
The read-only memory (ROM) containing the BIOS program is protected by a checksum value as a double-check that the ROM code is correct. This checksum is compared against the values in the ROM each time the PC is booted and if there is a mismatch, this code is generated.

Note: This error is not the same as a CMOS Checksum Error, which refers to corrupted values of the CMOS settings, the ones you set through the BIOS setup program. This error means the contents of the BIOS code itself are damaged.

Diagnosis: The BIOS ROM chip on the motherboard is probably faulty. It could also be another component on the motherboard.


CMOS checksum errors
A checksum is computed as an error-detecting code, to protect the BIOS settings stored in the CMOS memory. Each time the system is booted this number is recomputed and checked against the stored value. If they do not match, an error message is generated to tell you that the CMOS memory contents may have been corrupted and therefore some settings may be wrong. BIOSes react in different ways to encountering this sort of error. Some will warn the user and then continue on with whatever settings were in the CMOS. Others will assume that the settings that were in the CMOS were corrupted and will load default values stored in the BIOS chip "for safety reasons". The error message will indicate which your system is doing.

The most common cause of checksum errors in CMOS is a battery that is losing power. Viruses can also affect CMOS settings, and motherboard problems can also affect the stored values.

You should make sure that all of the BIOS settings in the system are correct, by rebooting the system, going into BIOS setup and double-checking all the values otherwise you could set default BIOS settings.

[Damian]

As far as i can remember its a CMOS "checksum error".. but i will confirm this as of tommorrow... i will be watching this thread closely this evening, so as i have already said, dont hesitate for information...

I got in a few hours troubleshooting there, and im all out for today of idea's so i wouldn't mind the help to come up with some results i can try out...

here's some info, and possibly somewhere you can find some answers that i didn't...
(and just to clarify with the above, this board is 1day old.. so im sure its not the battary)

Linky


Just thought i might post this, Linky , just going to find out the necessaries
prove this theory... Well the cpu part anyways...


Damian,

[BUFF]

BIOS 1.4 for AN8 just came out although I'm not certain that it adds anything other than support for a new model AN8-V.

[Damian]

Could it be possible that i would need to update if i where on version 11, i have seen on abit forum various recommendations to do so, but i cant see any information on the bios updates that tell me anything about what they fix, ro not much anyway...

Im still looking... any help on the timings?

cheers

Damian,

[BUFF]

Originally Posted by Damian

Could it be possible that i would need to update if i where on version 11

If that's an AN8 SLi then the first release BIOS for it was 1.3 ...

if the POST Code has a . in it then it is uGuru specific i.e. codes 06 & 0.6 are different with 0.6 being uGuru related.

[BUFF]

Originally Posted by Damian

Could it be possible that i would need to update if i where on version 11

As the 1st release for that board is supposed to be 13, yes.

btw you should get a checksum error every time that you clear CMOS iirc.

[Damian]

UPDATE!!

Just had the guys at abit on the phone, got the system running on 24pins and nothing but the necessities...

The thoery he gave me is the machine when the cmos clears runs at a slower speed, and when information is saved and the components actual normal speed is initialised.. and therefore from this point runs faster... so the aim is to get the components running at similar speeds to when the cmos is cleared in order to elimiate them one by one and find the problem.

He had me turn the memory down to ddr200 and manually set some of the settings, with no change... then try uping the voltage on the memory... nochange...

Reset's the cmos...

Then tried under clocking the cpu, got it down to half its speed and with this i was then able to save changes to the bios, the problem being that it crashed directly after rebooting from save, switched it off and on again and the saves where still there..

I then proceeded to reboot 12 times on each to show reliability:
[after each successful/unsuccessful post alt+ctrl+del is pushed]

Cpu 1200mhz

1 = successful post!!
2 = post code p2 [hangs]
3 = successful post!!
4 = post code EE [hangs]
5 = successful post!!
6 = post code 29 [hangs]
7 = post code FE [hangs]
8 = successful post!! +CPU in safemode?!?
9 = successful post!! +CPU in safemode?!?
10 = post code 92 [hangs]
11 = post code 92 [hangs]
12 = post code 92 [hangs]

{After this point it then booted again successfully, but told me to reset the cpu frequency...}


Memory @ 333ddr

1 = post code 92 [hangs]
2 = post code 92 [hangs]
3 = post code 92 [hangs]
4 = post code 29 [hangs]
5 = post code 92 [hangs]
6 = post code 92 [hangs]
7 = successful post!!
8 = post code 92 [hangs]
9 = post code 92 [hangs]
10 = post code 92 [hangs]
11 = No post, 1x endless beep [RAM/but tested to be fine!]
12 = successful post!!
13 = successful post!!
14 = post code 62 [hangs]
15 = post code 92 [hangs]


After this point he ran low on answers, and told me to check my bios version and update if possible, which mine is already 13/1.3..
so that leaves me out of anwsers.

I was told by the ABIT guys that the "90's" set of post codes relates to power, and that the minimum for this board was 400watts.. however, mine is 480 and it is a compatible model for this board...



I really need to find a way of testing the cpu/gpu so that i can fully determine out of the motherboard, graphics card, and cpu...
where the problem lies... and i cant afford to buy all of them, at a stretch possibly a new motherboard and cpu, but it sound a bit risky!!

HELP!!


Damian,

[BUFF]

I've got an AN8 Ultra on the way so we'll see how mine goes.
Wasn't going to use a Tagan but I can always swap PSUs out although I doubt that it's the problem.

[Damian]

AND SO THE ANSWER, from the evidence, HAS BEEN FOUND!!

After solving the last piece of the puzzle, and a long one at that...
and finding that the fail safe settings worked 100% of the times i booted i started to look that the difference between them both and turn on and off functions untill the machine would boot as it did when it was in "fail safe's"...

After a quick look around, and knowing that the motherboard was new and the memory worked 100%, i took a stab in the dark and started fiddling with the cpu options in the bios... from this i found that if i turned down the HT frequency to 1.5x and HT width to: \/8 /\16 and wow, i was excited to see it boot fine 4x in a row i can tell you!!

TWENTY TIMES AND COUNTING!!!



It might be a busted cpu, but with 2yrs warrenty left its sure not costing me anything!!

Thanks to everyone who made this possible so far, and to buff for the support and idea's... and the ABIT forum for there input.

Thanks all!


Damian,