[wildpossum]

Hi All.

I am having system hangs intermittantly between 2 to 24 hours dependant on OS flavour and memory/BIOS configurations.

A> MB uses Award BIOS of 790FX-F3 (the first release). I have been unable to update BIOS by either the Q-Flash USB Stick or Floppy methods, using "F8" during BIOS configuration or when booting and using "END" key interrupt. What happens is the BIOS see's the USB stick (a XP Pro formatted 1GB stick with only a master partition = all of disk), but does not see the BIOS update files (autoexec.bat [21B], FLASH895.EXE [172.7KB] and the ma79xdq6.fc5 [512KB] bios image).

I have tried the same method of update using the floppy device, with the same result. Hence there are issues with this firmware version to start with.

I tried to update to the latest BIOS update (F5C) in an effort to fix or in the worst case - narrow down the hanging problem [describe in detail below].


My question(s) finally!

Has anyone had the same issues with:

* GA-MA790FX-DQ6 MB ?

* AMD Phenom CPU ?

* Athlon X2-64 CPU on a GA-MA790FX-DQ6 MB ?

* Anyone found any verifiable solution to tracing and tracking this type of hanging situation in Linux - If so, would you kindly let us know what are your procedures for doing so !

Interestingly:
The motherboard is remarkably silent and heat-free with its inbuilt copper multi-sinks spread across the major heat emitting components and with the newer AMD CPU fan it is very silent indeed. Measured in-case ambient temperature averaged 29.3C while outside ambient temp was below 24C. IMHO this is an excellent reason for continuing efforts on debugging this board [in the hope of getting a very quite, low heat system that can be suitable for library use] .


What follows is a detailed summary of the problem and the testing procedure I took under Linux in trying to verify and track the unknown hang(s). Full H/W configuration is attached to this submission at end.
[WARNING - It is rather large txt file, for Linux OS Guru's mainly but your welcome to look]

B> System stripped to bare-ist h/w & s/w configuration.

I had riginally 8GB memory running Linux MemTest in excess of 90 hours, with heat and power cycling. During this testing I found that one 2GB Corsair DDR2-800 pair had multi-bit errors under ambient temperature ramping (41.2C to 44.6C); So the memory was swapped for another set - which in the end passed without errors.

The Gigabyte MB BIOS has built-in firmware to correct known faulty AMD Phemon Quad Core CPU "02 stepping" (aka corrects the Look Aside Memory cache errorious design) and hence I would have expected minimal if any, memory mapping issues with memory larger than 4GM on this system. Originally this was one of my concerns before purchasing the system. However I was assured by Gigabyte Support that this was not now nor is an issue anymore as BIOS firmware fixed it. However I have found that running with only 4GB memory generally postpones system hangs to much later. With 8GB, hangs are experienced within 5 hour or less.

On the Linux OS side, I have installed and used OpenSUSE 10.3, Ubuntu 8.04, FC8, and Knoppix 5.3.1. All but the Knoppix distro experienced a hang (system operates 24/7). Investigating further I have noticed that Knoppix uses only a i386 kernel config, i.e.: System Libraries are 32 bit, and CPU selection is for general X86 typing, not as X86_64 as the other selected distro have. Hence maybe there are issues with AMD Phenom with lib64 more so than lib32. So course I appreciate that I may be finding a "pattern" where none exist, i.e.: maybe this all is just a "red herring" and nothing to do at all with the system hang issue.

I have not yet try a 32bit versions of the above distro. I have tried SSH-ing into the hang system and at times I am able to do so, look aroung /proc and whilst running "top" I can see that several processes are made to be "forced delayed" awaiting some never to come event. This is especially so for input devices of the keyboard but not the mouse. Anyhow another investigation path to follow before I can formulate any conclusion.

Any comments or suggestions greatly recieved.
Thanks Grahame.

[technossomy]

If you google for "Phenom errors", you are likely to find many sources. One of my colleagues mentioned that 1 in every 5 million instructions is faulty for this CPU. So your problems are probably related to this. Price erosion in this chip are faster than most other processors too.

[wildpossum]

Thanks for your feedback.

Problem was three fold.

A> The initial BIOS is crap, and the latest does not correctly update the DMI (Direct Memory Interface) on-board BIOS tables (confirmed by Gigabyte support on 5th June,0. I got over the problem by a special sequence of loading the new BIOS from the original using DMI button confirmation. Apparently, DMI is a dynamic h/w routing method of appointing DMA IRQ's to h/w devices by the BIOS. Which I only found after adding another PCI card, and wasn't able to boot. Hence the DMI table needs to be updated by the BIOS prior to booting, otherwise your stuffed. (This investigation only took 9 hours of suck-and-see).

B> Motherboard was replaced only after I put the retailers/wholsalers technical support person throught <A> above. hehe... At least this way I was able to remove one variable I wasn't sure about.

C> On the original motherboard, I found a 200uF SMD cap which wasn't correctly soldered. Hence my pushing for the motherboard swap re <B>.

Now the system runs 96 hours without fault, running all four cores flat out doing a lot of I/O, MEM and Floating Point tasks. All up over 321 tasks with 17 active at any one time average. Now that pushing sh.. up hill for a test.