As noted in my
previous topic, I recently returned a Phenom II X4 955 processor and GA-MA790FXT-UD5P board after numerous problems including non-working ECC memory, spontaneous power-offs (after which the machine had to be physically unplugged before being able to be turned back on), hangs during POST if certain keys (such as F12) are held down, and - the final straw - an inability to boot Linux.
What was happening was that the boot process would freeze for 30 seconds during early-boot, and later examination of 'dmesg' output showed that the kernel was timing-out whilst attempting to initalise the on-processor APICs, required for SMP operation. This meant that even once the kernel started, only a single processor core was visible to the kernel.
This happened with Gentoo and Ubuntu distributions, and with Ubuntu's 2.6.28 kernel and a stock 2.6.30 kernel. Windows did not appear to be affected.
On receiving the replacement board, I booted Linux and found that all of these problems were gone - which was a relief. Incidentally, at this point I upgraded the Gentoo kernel to the very latest release, 2.6.31. However, when I updated the new board to the F7a BIOS, the exact same problems returned. I downgraded to F6 and the problems were still present, and then downgraded back to F5 and the APIC problem was resolved. I do notice that there are still some issues which I didn't notice before upgrading in the first place (such as the BogoMIPS rating for the 4 cores each being different - and a warning of a timeout whilst calculating the loops-per-jiffy rating of each core. I can't say for certain, however, that these weren't present initially in F5 - but I strongly suspect that they weren't. I do notice that, whilst there are no obvious errors in the log, Ubuntu does take about 45 seconds to boot now I've downgraded back to F5, whereas it was instant before upgrading.
(My selected BIOS options have been identical in all cases, incidentally)
I've upgraded and downgraded using the Windows @BIOS utility from 64bit Windows 7 (I have the Microsoft Technet final release). I may try performing the procedure from DOS this evening, to see whether I can perform a more comprehensive downgrade/reload of the F5 BIOS to try to resolve the timeouts and Ubuntu issues.
I did notice that, with the old board at least, this problem did not seem to affect the Ubuntu LiveCD. This may be a 32bit kernel, or may be a non-SMP kernel. I have tested with Ubuntu 9.04 64bit desktop edition. I tried reinstalling 64bit Ubuntu onto a hard-drive twice, and both instances were likewise affected.
Given the popularity of Ubuntu (or, indeed, potentially any 64bit Linux), it seems a startling omission on Gigabyte's part that a stable BIOS update can prevent an OS from being able to operate correctly.
Is anyone else able to test to confirm these findings?
