Intel Announces a BIOS Implementation Test Suite

[nn_step]

"Intel announced the release of a BIOS Implementation Test Suite (BITS), a bootable pre-OS environment based on GNU GRUB2 that tests how well (or how badly) your BIOS has configured your platform hardware.


https://lwn.net/Articles/429812/
http://biosbits.org/

[zalbard]

Very interesting! Thanks!
I should give this a try!
I think it can tell if C6 is actually broken on EVGA boards the way I think it is.

[zalbard]

Gave it a try. Not looking good...

My results using BIOS 76 (results should be identical to 77 and 78) for EVGA Classified 4-Way SLI (E762):

1. MSR Consistency Test Suite
(MSR 0xe2 Consistent): FAIL
(MSR 0x199 Consistent): FAIL
Summary: 8169 passed, 2 failed.

2. Power Management Test Suite:
BUS Master Disable: FAIL
C1 Auto Demotion Enable: FAIL
C3 Auto Demotion Enable: FAIL
IO MWAIT Redirection Enable: FAIL
IO Capture C-State Range Consistent: FAIL
Summary: 6 passed, 5 failed.

3. SMRR Test Suite:
Summary: 6 passed, 0 failed.

4. Detect SMI frequency and latency
<skipping some stuff>
Summary of impact: observed maximum latency = 353 us.
Risk of OS timeouts exists with this observed latency (ideal < 150 us).

5. C-state exploration: residency and latency
*MWAIT C-States
MWAIT C1 is supported
MWAIT C1E is supported
MWAIT *C2 is supported
MWAIT *C3 is supported
MWAIT *C4 is NOT supported // this is done on stock with default BIOS settings
MWAIT *C5 is NOT supported // I specifically enabled C6 in BIOS
MWAIT *C6 is NOT supported // clearly not normal

[PatRaceTin]

wow i will try

[JohnZS]

Thanks nn_step

I ran BITS on my ASUS Rampage Extreme motherboard, not quite sure what to make of the results, but it did list some FAIL's and a cause for concern with latency.

MSR Tests


SMI frequency and latency


Any ideas?

Thanks
John

[Aerwidh]

Sounds like an interesting little thing to try out

[Cooper]

I sense a major failatron

[JohnZS]

I sense a major failatron

Very true, this is looking like a failatron or a fail train

The question is, whom is to blame for the failatron?
Our boardmakers for coding FAIL BIOS?

OR

Intel's BITS being riddled with bugs?

I reported the results I obtained to ASUS support purely as I was not sure what they meant and wondered if they were indicative of a potential issue which they could fix

[zalbard]

There is nothing wrong with Intel BIOS Bits, it seems pretty accurate to me.
It's testing pretty basic stuff by doing hardware calls. Blame ASUS...

[JohnZS]

There is nothing wrong with Intel BIOS Bits, it seems pretty accurate to me.
It's testing pretty basic stuff by doing hardware calls. Blame ASUS...

Thanks Zalbard
So theoretically, would it be possible to code a fix for those issues? Or is it beyond fixing?
John

[zalbard]

I don't see why not.
Do you have HPET enabled? It might be causing high latency for you. I know there's something wrong with HPET and C6 on EVGA, so disabling these reduces the lag tremendously.

[JohnZS]

Thanks again zalbard
Sadly my BIOS for the Rampage Extreme does not have options for the HPET
Will be interesting to see if ASUS support comment or at least acknowledge what can and cannot be done to rectify these issues. I hope eVGA resolve the issues you are having too.
If anything BITS has opened a whole new can of worms for board vendors as now they have a way of being "tested" by End Users!
John

[nn_step]

Thanks Zalbard
So theoretically, would it be possible to code a fix for those issues? Or is it beyond fixing?
John

Assuming you have the source code for your bios, then it'll be trivial to fix those issues; However if your motherboard doesn't support an open source bios. Well, you are screwed until your manufacture fixes the problems. Expect 9 months to never for that to be solved.

[Nikolasz]

It seems intel is trying out they own mainboards with that tool. To be 100% shure they sell good products. Is that right intel?

[alpha0ne]

Looks like a useful tool

thanks nn for the linkage

[saaya]

sweet... hope it contains a memory, cpu and gpu benchmark/stability test!

[squawker]

Very interesting, results for RIIIE, bios1102:

1. MSR Consistency Test Suite
Summary: 8177 passed, 0 failed

2. Power Management Test Suite:
C1 Auto Demotion Enable: FAIL
C3 Auto Demotion Enable: FAIL
IO MWAIT Redirection Enable: FAIL
C1E Enable:FAIL
Summary: 7 passed, 4 failed

3. SMRR Test Suite:
SMRR type must be Write-Back (best performance): FAIL
Summary: 5 passed, 1 failed

4. Detect SMI frequency and latency
Summary of impact: observed maximum latency = 5314 us
Risk of OS timeouts exists with this observed latency (ideal < 150 us)

5. C-state exploration:
*MWAIT C-States
MWAIT C1 is supported
MWAIT C1E is supported
MWAIT *C2 is supported
MWAIT *C3 is supported
MWAIT *C4 is not supported
MWAIT *C5 is not supported
MWAIT *C6 is not supported

OBS: In bios C1E and C-State are Disabled.

[Mumak]

Haha, I hope now the BIOS engineers start to tune their SMI handlers...

[ThePointer]

Haha, I hope now the BIOS engineers start to tune their SMI handlers...

The above link was due to the SMRR not having WB, and not really the SMI handler issue, i guess.

[glen]

I swear this makes me want to buy an Intel P67 over an Asus. On the otherhand there is the Gigabyte which folks can fix the bios themselves whereas with Intel and Asus this wouldn't be so easy.

This just seems to be a very interesting little application, due I dare say it will become very popular? Or is it a marketing tool that will be dismissed. Either way this is big news and I am sure will lead to a lot of discussions.

[Mumak]

Check the post more carefully.
A 5ms SMI handler latency sounds to me like a more serious issue than SMRR config.

The above link was due to the SMRR not having WB, and not really the SMI handler issue, i guess.

[ThePointer]

Check the post more carefully.
A 5ms SMI handler latency sounds to me like a more serious issue than SMRR config.

I was trying to tell you that the '5ms' is likely due to the SMRR is not WB, not because of an un-optimized SMI handler. (well, as i said, guess only)

[Mumak]

I doubt that WB scheme would have such a big impact.
I've seen so many heavy things in SMM handlers.. My guess are intensive I/O operations (with EC or similar components).. But that's just a guess...

I was trying to tell you that the '5ms' is likely due to the SMRR is not WB, not because of an un-optimized SMI handler. (well, as i said, guess only)