Bios 2.50 with microcode fix for Extreme 7+ out

Hello parsec,

I've done some tests after an unexpectedly return to "triple attempt to post" behavior, after a simple CMOS clearing (without removing board battery).

My new tests consisted of several simple CMOS clearing (without removing battery) and 3 complete CMOS clearing (with battery removed during 5 hours, at least, in each clearing).

I did not flash again UEFI, keeping the same 2.50 version I upgraded from 2.20 version.

After each CMOS clearing I returned to my original UEFI configuration (including raid) and worked on the computer normally, doing my usual tasks for a few hours before making any new changes in UEFI setup.

The results I got are the following:

1. Again, against our expectations, the Samsung 950 PRO raid0 array survived safe and sound, without any little scar, all the UEFI's clearings and configs I made during my tests (and I did not remove the drives from sockets)!!!

 

2. The "triple attempt to post" issue is caused, in my rig, by changing in "H/W Monitor" the setting "CPU Fan 1 Type" from "Auto" to "4 Pin"!!!

This is a very weird and disconcerting conclusion, against all logical reasoning, and I cannot think of a single reason for it happening, but the results are repeatable each time I change that configuration in UEFI.

Any input on this is welcomed.

At first it passed unknowingly by me, because "CPU Fan 1 Type" setting was not a config I was focused on, instead I was searching something wrong in DRAM or Chipset Configurations.

BTW my CPU cooler is a Corsair H105 with the 4 pin fans connector attached to CPU_Fan1, and the 3 pin pump connector to CPU_Fan2.

 

Summary: in my rig, what I called "triple attempt to post", in the absence of a better name, only occurs in UEFI v. 2.50 when the "CPU Fan 1 Type" is set to "4 Pin" and the PSU is off before booting.

 

I don't know if this is, or not, a result of a bad UEFI flash or specific of my hardware configuration, and I suppose not many users, if any, would be affected by this.

 

Sorry for the long post and regards,

Edited by squawker - 01 Feb 2016 at 8:14am

Hi parsec,

Problem solved    and this time I did not have to take any precaution......lol...

I simply cleared CMOS by removing the board battery, and measuring it with a DVM the tension was a little on the low side (about 2.9 ~ 3.0 V), and as generally new batteries have about 3.3 V, I changed it for a new one, thanks for your suggestion!

Now, no more triple post and again 15/16 s from case power button to W10 desktop, irrespective of PSU being on or off before booting and I'm happy again...

 

About raid, I think you are correct, with NVMe drives, differences in performance between raid and single device can only be perceived in benches or very specific duties, but... but... I'm an unashamed raid fanboy ...

I've been using raid0 drives since old Seagate SATA2 hdd's (circa 2007), and passing by WD's Velociraptor, Intel SSD X-25M, etc, etc ...

And I suppose my love for raid is reciprocal  because I've never had a raid failure or corruption!!!, but as all love affairs can end sometime,  I always have my backups up to date... 

All in all, it seems my issue with UEFI v. 2.50 was caused by not clearing CMOS after updating and/or a low board battery.

Thanks for your suggestions

regards

Hi parsec,

Very interesting the observations about clearing or updating UEFI and killing the raid array.

i changed to ASRock because my previous Z170 board could not provide a booting NVMe raid array and i was very interested in trying this config with a pair of Samsung 950 PRO.

My Z170 EX7+ board arrived with UEFI 1.80 and after mounting the raid array, i updated it several times, including to UEFI 2.20 that now is removed from Global Download list.

And much against my expectations the raid array survived all UEFI updates, including an update to IRST 14.8.0.1042 driver! Against my expectations because like you said i've seen other people relating the array corruption after updating, and all this thing about IRST remapping.

The only precaution i take before updating UEFI is removing both 950 PRO from its sockets and clearing CMOS, and of course after update reestablishing the raid configs in UEFI, exactly like i was used to do with SATA drives. Also, it's possible my prayers had helped a little

About the triple attempt to post, i think you're right and it's related to the new UEFI improving memory compatibility and its training during post.

BTW, is it possible to revert UEFI to a former version using Instant Flash or i have to use another tool?  

i will continue trying to discover if there is an error in my configs and also i'll check the 3 V battery state as you pointed out, but i suppose the hours clock and UEFI configs would be messed if it was completely bad.

Regards,

Hi parsec,

Thanks for replying, well, i also noticed that Windows 10, build 10240, was somewhat faster than build 10586, and i always do a clean Windows 10 DVD installation, when there is a bootable ISO of the build.

But my observations regarding UEFI 2.50 were all made with 1511 version, build 10586.63, and with CPU and DRAM configurations in UEFI at default settings, as i'm getting accustomed to this board.

In my observation, UEFI 2.50 post behavior only is different from previous UEFIs that i tried (2.20, 2.10, 2.0 and 1.80), when previously the PSU is turned off (PSU AC power off).

In this condition, what happens maybe could be better called "triple attempt to boot", and it takes about 30 s to get to desktop:

1st attempt - Debug LED codes: 00 - 19 - motherboard shutdown

2nd attempt codes: 00 - 19 - board shutdown (again)

3rd attempt codes: 00 - 19 - 00 - 35 - .....- 97 - 99 - Ad - AA (O.S. desktop). Perhaps not exactly the codes, as they occur very fast. And i have a speaker connected to board, and only on this 3rd attempt there is a Post OK beep.

And yes, i observed that Stankyleg is using Ultra fast boot, and i changed this option from Disabled to Fast and to Ultra fast, without big differences.

 

As i've said, this happens only when PSU is turned off; after a Windows shutdown, without turning PSU off, UEFI 2.50 behaves exactly as previous UEFI's, providing a very fast boot, something as 15 s from case power button to W10 desktop! And Z170 EX7+ is the fastest board to boot I've ever had!

Same thing for shutdown time: about 2-3 s from desktop to board shutdown (it's really really fast)!!!

 

So, this is not a big issue to me, since i turn PSU off only a few times a day, but this board new behavior with UEFI 2.50 was what draw my attention to.

Anyway, I will be observing if someone after updating the bios to 2.50, can or cannot confirm  this.

Regards,

I use the same board, and using UEFI 2.31 Beta currently.

On the ASRock USA website, all the Beta UEFI versions are gone. At least on Sunday night, 1/24/16.

The standard UEFI versions now goes from 2.10 to 2.50.

squawker, please describe what you mean by a double boot. Are you seeing the ASRock screen during POST twice? If you have a POST beep speaker connected to your board, do you hear the single POST Ok beep twice?

Notice that STANKYLEG is using the Ultra Fast boot option, which will reduce total start up time somewhat compared to Fast Boot being Disabled.

On the subject of slower booting, I've noticed (I think) on two different PCs with Windows 10, that the newer builds of Win 10 boot slower than earlier builds. That behavior is also erratic, meaning the cold boot time (cold boot means starting after a Windows shutdown, but without turning the PSU off) is occasionally faster.

The Win 10 build I have for installation on a USB flash drive, taken from a DVD, is 10240. I've updated through Windows update to build 10586 just recently on my Z170 EX7+. The full start up/cold boot time is much longer now, after the single POST beep.

The Win 10 boot screen and spinning dots are visible much longer on build 10586. With build 10240 the desktop was displayed within three seconds of the POST single beep. That is with Fast Boot Disabled in both Win 10 builds. Currently it takes at least 10 seconds after the POST beep for the desktop to be displayed. Nothing has changed with my hardware or UEFI version between build 10240 and 10586.

Is anyone else using Win 10 noticing the slower start up behavior with the different builds? I'm wondering if squawker is really noticing that instead of something with UEFI 2.50.

It seems with the newer Win 10 build that Windows is doing something before the desktop is displayed, that was not being done previously. Such as checking for new updates, or who knows what else. I thought I was confused about the longer startup time with Win 10, but now that I seem to see it on two different PCs, I don't think it's my imagination.