Official GIGABYTE Forum
Questions about GIGABYTE products => Motherboards with AMD processors => Topic started by: stuart on September 18, 2009, 10:58:09 am
-
As noted in my previous topic (http://forum.giga-byte.co.uk/index.php/topic,449.0.html), 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?
-
i've played with ubuntu only once so i don't have enough experience :P, maybe you'd better contact gigabyte directly at:
http://www.gigabyte.eu/Support/ServiceCenter.aspx
-
After performing the BIOS upgrade again using FLASHSPI.exe from DOS, all of these problems has disappeared. After further testing, all of the hardware & software problems I've encountered seem to be as a result of using the Gigabyte @BIOS tool to perform a BIOS upgrde from (a legitimate, Technet) 64bit Windows 7 installation. When the upgrade is performed from Windows, these problems return. Upgrade from DOS, and everything is fine.
-
G'ah! It's still happening, but no longer all the time now. After loading Windows 7, a reboot into Linux triggers the APIC problem (although I also powered down an eSATA drive), but powering the machine off completely before starting Linux works correctly.
This is an improvement, since before I upgraded the BIOS from DOS the bad behaviour would occur on every boot.
It makes be think that the BIOS isn't completely resetting the state of the machine on reboot - what else could trigger these issues?
-
try with F7 bios: http://www.giga-byte.co.uk/Support/Motherboard/BIOS_Model.aspx?ProductID=3005
as F7a was just beta one
-
I've been trying with F7 for the last few days - the APIC problem has gone (although read on), but I'm seeing cases of the board powering down and refusing to come back on until the mains-power lead has been removed for at least 30 seconds.
In addition, Windows 7 seems to be unable to resume from sleep if certain ECC memory options are selected - but I'm still investigating.
I now believe, though, that the original Linux APIC initialisation issue is actually the same one I'm currently seeing. Previously, Windows was able to resume in all circumstances - Linux would almost always to boot. I'm now noticing that I can try known-good BIOS settings, and Windows will resume. I then try known-bad BIOS settings, and the machine locks-up on resume. If I can recover from this without removing power to the machine entirely, then reverting the the exact same known-good settings will also fail to resume in the same way! The only way to get the known-good settings to work again are to remove power from the machine.
If I can trigger this circumstance again, then I'll try booting Linux - and I believe that I'll see the APIC issue. There seems to be some element of the machine's state which isn't being correctly reset even with a cold-boot, and even if left powered-off for hours.
My theory is that F7 is more broken than F6 in this regard, and so rather than WIndows being unaffected it is now also encountering problems. Thinking back, the times when Linux broke would follow having put Windows 7 into hibernation, and the times when it suddenly started working again could well have coincided with the mains power having been disconnected.
I plan to investigate further and update Gigabyte Support with my findings - given the number of combinations of BIOS options and the number of reboots needed to test even one case, progress is slow.