That's interesting. Early on with my GA-P55M-UD2 I encountered that message in BIOS, when I had not changed anything just was poking around. But it soon disappeared and I've never seen it again.
Any luck getting your other problem solved? You should definitely be able to hist ESC to get out of the MIT Current Status screen. What BIOS version are you on? Have you upgraded to the latest? (If you haven't seen the warnings before, do not use the @BIOS software that can run in Windows. Instead, use the QFlash utility that can be run from inside the BIOS.)
I enabled some alarm settings, saved them to CMOS, and the error message went away. Seems like you need a "save" to CMOS.
Anyway, still, on the MIT Current Status screen, no keys work. ESC does not work either. Is this normal? The only way to get out of the Current Status screen is to reset the computer.
Some models ship with an F3 bios that doesn't let you exit some menus like the one where you see 'system info' with core temperatures.
Download @bios from gigabyte's homepage and update to the newest bios. When you do you also get some new options for sata configuration like enabling ahci on only some of the intel sata ports and not all (enabling you to change from ide to ahci driver without reinstalling windows).
I gotta caution again against using @bios. It has been known to brick boards. Qflash is a much safer router to take. And it's fairly straightforward.
1. Download the latest BIOS file
2. Run the file (or double-click it), the file is a self-extracting zip file
3. Copy the unpacked contents onto a USB stick
4. With the USB stick plugged into your computer, restart the machine
5. Enter BIOS
6. Enter the QFlash utility (I believe its F8 but it will say on the main BIOS menu)
7. Choose to update BIOS and then select your USB drive, which will be named something like HDD 0-0
8. When done, back in BIOS choose Load Optimized Settings, then set any RAM V if needed, then reboot and re-enter BIOS and configure the rest of your settings
Qflash is F11 on most boards, not F8 - and it has the huge flaw that it can't read the bios from the harddrive but requires an usb drive - it doesn't even always properly accept mobile phones pretending to be flash drives - so in the end you're still better off with @bios.
No, you're NOT! Unless you like the idea of taking a completely random throw at turning your MOBO into a doorstop, never use @BIOS! EVER! It, unlike any other method of flashing, appears to be able to overwrite the BIOS' boot block, which, among other things, is resposible for the 'dual BIOS' ability to 'revert' to the 'as-shipped' BIOS in case of disaster; if this happens, you ARE looking at an RMA - no other fix!
I always liken using @BIOS to playing Russian Roulette - you can get away with pulling that trigger once, and only get a 'click'; maybe the second time, too - but, by the third pull, the odds are stacking up against you - keep pulling it, and you will blow your brains out!
Well, if it worked, then it is fine. The only issue with it is when it does not work. In the future if you have to update the BIOS again I'd suggest not doing @BIOS, but for now there is nothing to worry about.
Can you guys point me to some places where @bios is proven to have broken something? I've used it on a GA-965P-DS4, GA-P35-DS4, GA-P55M-UD4, a GA-P55-UD3R and a GA-EX58-UD5 (my system), and all survived. Ofc. I can just be exceptionally lucky, but since my best friend's GA-8N-SLI (p4 board) back in 2005 or so and until now I've almost exclusively bought gigabyte boards and never heard of @bios not working as it should. I'm unsure if we've used it back then on the 8N board, but I know I've used it on every single board I've built into my, friends, and customers computers.
In fact since I started using gigabyte boards (in favor of epox for expensive systems and soltek for cheap ones) I've only bought four non gigabyte boards ... two Asrock 775Twins-HDTV, 1 Asus P6T Deluxe and a single msi KA790GX board.
That would appear to be the problem; unlike the other flashing mechanisms, @BIOS seems to be able to either overwrite or corrupt the BIOS' boot block, which, among other things, is responsible for 'dualBIOS' recovery, as well as the 'blind flash' recovery - you 'oops' a BIOS' Qflash utility ( <F8> ), or an SPIFlash from DOS, your board will gracefully 'revert' back to the 'as-shipped' BIOS in the second chip; you dump an @BIOS flash (which is way more likely to happen in the first place, as you have all the overhead of an [admittedly pretty 'flaky'] OS intervening between you and the hardware), you're pretty much hoping for a 'gracefull' RMA
This problem is not limited to GB; other manufacturers have 'in the OS' flashing setups, and, so far as I know, are also prone to difficulties that DOS or 'in-BIOS' flashing don't have; and, I have seen the solution - but never on a desktop board - I've come across servers, and especially, high-end server hardware, like RAID cards, that have their 'bad firmware recovery' code in a third, read-only chip; you FUBAR a flash, the 'recovery/start-up code' executes, and reverts to the original, read-only copy, in another ROM... Often, these setups have a seperate LAN port that accesses these features, so if you've trashed the card, you can still 'get at it' to try to recover... Apparently, the cost to GB of the @BIOS-triggered RMAs, is less than what it would cost to implement that solution across the board.(s)
Well - I think that may be one of the reasons a 'fix' does not seem to be a priority; a lot of people who manage, somehow, to 'toss' together a fairly simple system, and live to tell about it don't know what a BIOS is; and the ones who need to find out, often find out here or at TweakTown, where they're generally warned; and the remainder might get away with it a time or two... I flash a lot of BIOS, and a lot of firmware, both of my own, and building systems for others; I've trashed my own board twice in one day (kind of like shooting yourself in the foot, and not being satisfied with the job, so shooting yourself in the other foot, just to be sure ) by being unable to believe that a corrupted BIOS file could possibly pass checksum !!