NUC8i7BEH, BIOS version 0083 and eGPU issues (and a workaround) - Page 2

PavelPr · ‎08-19-2020

Hello everyone,

Yesterday I encountered an eGPU compatibility issue after a BIOS update, and was able to resolve it. I would like to share this in hope that it could help somebody who is struggling with the same problem, and to save them some time and frustration.

I've been successfully using a NUC8i7BEH unit with an eGPU (Gigabyte AORUS Gaming Box 2080 Ti) for several months now. Yesterday, I attempted to update the BIOS to the latest release (0083). After the update, I could no longer obtain HDMI signal from the eGPU, connected to the NUC. I am using Windows 10 Pro version 2004 (May 2020).

Strangely enough, once Windows is done loading, the embedded LEDs on the eGPU did light up as they normally would. No HDMI signal, though. I then started investigating (if you are not interested in the technical details, scroll down for a description of what I did to work around this issue).

When powering up the NUC with both the eGPU and the integrated GPU connected to different HDMI inputs on the TV, signal would appear to be coming from the integrated GPU. Then, only after having completed the Windows logon procedure (that usually means entering one's password), would the eGPU start emitting HDMI signal normally.

I then decided to test this "blindly": I shut down the machine, disconnected the HDMI cable that was connected to the internal GPU, and let the system boot. After some time, when I was certain that the logon screen should have appeared, I blindly entered my password, and voila – the standard Windows desktop appeared, out of nowhere.

As this would never happen before BIOS 0083, I decided to check its change log. Sure enough, I saw this:

"Fixed issues with Kernel DMA protection".

Interesting, now that made some sense. A change that was made to the DMA protection logic could have triggered this, because Kernel DMA protection (a relatively new feature, available starting from Windows 10 version 1803) has bearing on the way in which Thunderbolt 3 ports operate (for the curious, have a look here: https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt).

Eventually, I was able to pinpoint the issue: it seems that, for some reason unbeknownst, BitLocker, in combination with BIOS version 0083, will not let Thunderbolt 3 devices enumerate until Windows logon has been completed, as long as the "Intel Virtualization Technology for I/O (VT-d)" option is enabled in the BIOS, and the "Thunderbolt 3 Security Level" is set to anything but "Legacy".

N.B., It seems that others have encountered similar issues under different setups, and have come up with the same solution (https://egpu.io/forums/pc-setup/thunderbolt-devices-enabled-before-windows-login-possible/).

Here's what I did to work around that issue:

1. Power down the system;
2. Disconnect the eGPU from the NUC by unplugging the Thunderbolt 3 cable;
3. Connect the HDMI port of the integrated GPU to your display;
4. Power up the NUC and enter the BIOS by pressing the F2 key at POST;
5. Open the "Advanced" menu, navigate to "Security" and *disable* the "Intel Virtualization Technology for I/O (VT-d)" option (the other "Intel Virtualization Technology" option can remain enabled);
6. In the same tab, change the Thunderbolt Security Level to "Legacy";
7. Save your settings by pressing F10, and let the system boot normally;
8. Shut the system down, disconnect the HDMI cable from the integrated GPU and reconnect
the eGPU to the NUC. Then power on the system as you usually would (refer to the subsequent paragraph describing one remaining issue).

The system should now work normally.

Please note that if you have BitLocker enabled for any of your drives (to check this, search for "Manage BitLocker" in Windows 10, or open the "BitLocker Drive Encryption" applet through the Control Panel), make sure to obtain your BitLocker recovery key before changing these settings. You should have the key handy so that you could input it, should BitLocker require the key due to a detection of a configuration change.

To obtain the BitLocker recovery key, follow instructions by Microsoft here:

https://support.microsoft.com/en-us/windows/finding-your-bitlocker-recovery-key-in-windows-10-6b71ad...

Make sure to have the BitLocker recovery key in your possession and stored safely, just in case.

Please note that I have no knowledge of the possible security or virtualization implications of changing these settings.

One remaining issue is that when an eGPU is connected and the system is first powered on, there is no POST screen and picture appears only from within Windows, once the OS has finished loading. Subsequent computer restarts will show a POST screen, but when the computer is initially being turned on after being off (power-cycled), there is no POST screen coming through the eGPU during the initial boot procedure.

This has also been documented by other people, with different NUC models, here: https://egpu.io/forums/postid/69803/
And here: https://egpu.io/forums/pc-setup/activate-the-egpu-during-bootsplash/

In the latter link, one of the posters indicated that for Skull Canyon NUCs, this has been fixed as of a certain BIOS release. The NUC8i7BEH still exhibits this behavior, though.

**********************************************************************************************************************

Note to Intel:

Could you please investigate what exactly it is, in the changes made to the BIOS in version 0083, that could cause this incompatibility – and correct the issue so that eGPU initialization could work as it used to, before BIOS version 0083? Could you also please share with us what exactly, in the fix that was made to the Kernel DMA protection logic in BIOS 0083, is causing this?

On another note, the BIOS version 0083 change log states the following: "Due to the Intel® ME firmware update in BIOS version 0083, you can’t downgrade to version 0081 or earlier."

This, with all due respect, is an indiscretion. It should be up to the customer to decide whether to remain on the most current BIOS version or revert to an earlier one (despite any security implications), whatever the reason.

You see, had I not been able to determine what is causing this, I would have been left with a system that is in unusable state (i need the eGPU for work), and would have had to wait for Intel to (possibly) implement a fix. Being able to downgrade to version 0081 would have saved me a lot of time.

Please stop blocking BIOS downgrades, even when security fixes are concerned. The choice should be with the customer, not with Intel. The present issue is a very good example why.

Moreover, even though I understand that using an eGPU is not a very common practice, please test your BIOS releases under such configurations. Doing so will surely be of great value to us, NUC and eGPU-combo owners.

Thank you very much!

rockeyfish · ‎10-22-2020

@n_scott_pearson 0083 also does not describe any changes to the eGPU. No description does not mean that there are no changes.

PavelPr · ‎10-22-2020

Having updated to BIOS to version 0085 this morning I can confirm that no eGPU-related functionality has changed, and matters remain as they were with version 0083.

@n_scott_pearson, I respectfully disagree. Having been doing software for the last 15 years myself, I can say out that silent changes do happen. @rockeyfish has a point, too: reading through the change log of BIOS version 0083 (where the relevant entry reads "Fixed issues with Kernel DMA protection"), there was no way for the non-computer savvy to determine that after performing the update, the eGPU would no longer function as before. Still, we're here today, discussing the implications of such a change.

Combined with Intel's practice of blocking BIOS downgrades (while with version 0085, this is not the case as it does not contain any security content), people have their concerns.

SIDENOTE, UNRELATED TO THE TOPIC:

Moreover, Intel has had its share of problematic BIOS updates lately. Apart from BIOS 0083 that is discussed here, there was BIOS 0037 for the NUC8i7INH that outright bricked some systems beyond recovery (the first entry in the change log for the following BIOS version 0038 subsequently read: "Fixed issue where attempting to update NUC BIOS bricked the system"). I, myself, was affected by this with a newly-purchased NUC8i7INH that had to be RMA'd after that BIOS update.

I was not able to obtain an answer as to how exactly a faulty BIOS update could impact a unit to an extent where BIOS recovery functionality would be rendered inoperational (as far as proper design is concerned, the BIOS recovery functionality should reside on a separate subsystem, and should not be affected by a faulty BIOS update).

For reference, you can read more here: https://community.intel.com/t5/Intel-NUCs/I-tried-to-update-the-bios-for-my-new-Intel-NUC-8-Mainstream-G/td-p/661645

Now let's imagine what would happen had that unit not been under warranty. There is, you see, fear in computing, and a very practical one. I can understand @rockeyfish's caution.

n_scott_pearson · ‎10-23-2020

LOL! You guys can disagree with me all you want. I was told ahead of time that this was the only fix included in this BIOS release. In fact, it was rushed through to get this fix released as quickly as possible.

As for the 'undocumented' - or, more often, 'poorly/misleadingly documented' - issues, yes, this is a major problem and has been for many years. I was never happy with the decision to outsource BIOS development and validation and, AFAIC, they have paid a heavy price in terms of both reputation and sales. I was a part of this organization right up until I retired and part of the reason that I help out here is to increase their chances of success. Unfortunately, they have this great boat anchor holding them back.

...S

PavelPr · ‎10-24-2020

@n_scott_pearson

Thank you very much for investing your personal time to help people around here. That's greatly appreciated!

PavelPr · ‎10-23-2020

@Ronny_G_Intel

Following my previous reply to you, the "no POST screen after power cycle" issue I described has been encountered by people with NUC models, other than ours (specifically, a Skull Canyon-based KY NUC model).

One such person reported all the way back in April 2017 that this issue has been corrected for them with a BIOS update (see here: https://egpu.io/forums/pc-setup/activate-the-egpu-during-bootsplash/#post-9136). I have linked to this very thread in my initial post, too.

Sure enough, going through the change log for that model's (NUC6i7KYK) BIOS version 0045, reveals the following change (as this is a cumulative change log, please page 9, under "BIOS Version 0045"):

"Added support for Thunderbolt™ graphic device POST display."

Judging by this, there is a way for Intel to make this work. Why can't the same be done for us, NUC8i7BEH/NUC8i5BEH customers?

Thank you!

wil · ‎11-09-2020

@Ronny_G_Intel

Can you answer us?

Can you bring back same functionality as existed in BIOS version 0081 where POST screen shows on first boot?

POST screen on first boot with eGPU worked fine with BIOS version 0081.

POST screen on first boot with eGPU does not work with BIOS version 0083 and later.

As mentioned in this thread and the release notes, we cannot downgrade to version 0081.

Look forward to hearing from you.

Thank you!

wil · ‎01-13-2021

BIOS version 0087 is now out, has anyone tried it yet? Any feedback?

PavelPr · ‎01-13-2021

No updates from Intel and no solution to this issue in several months. Not very encouraging.

The explanation given does not address the fact that the very same issue has reportedly been corrected for other NUC models (see my reply here from 10-23-2020 02:00 AM, which is yet to be replied to by anyone from Intel).

As to BIOS 0087, it’s release notes state that it contains security fixes and as such, downgrades are blocked. Still, I don’t see any change entry describing a fix for this issue.

Sadly, my feedback regarding leaving downgrades to user discretion (even where security fixes are concerned) has not been implemented. I will as such be unable to update, out of concern that some compatibility will be once again broken (as with BIOS 0073), without the ability to roll it back.

PavelPr · ‎01-13-2021

As with BIOS 0083*, pardon.

patrick589 · ‎01-21-2021

Dear PavelPr,

Thank you very much for your detailed instructions. Without your instructions I would not have gotten my Intel NUC + eGPU up and running again.

At this point I would like to address Intel how unhappy I am with the current situation. During bios update 0087 of my NUC8BEB with eGPU connected, my bios was bricked and I had to restore it via recovery function. With bios version 0087 everything got even worse. Not only that I have to log in blind and reboot ,the system now hangs on the second boot POST "Intel Nuc" screen. However, this is only a display error. When I log in blindly again, the Windows desktop is displayed and I can use the system again.

The problem has been going on for months now. What is being done to restore the previous functionality?

Kind regards

Patrick

wil · ‎01-21-2021

Intel has completely failed eGPU users on the NUC platform.

This coincides with their overall failure as a company, i.e., Intel's well documented problems with its leading edge process technology at 10nm and 7nm. They are now outsourcing chip manufacturing to TSMC which is to start making Intel's Core i3 on its 5nm process. It is just a matter of time before Intel outsources everything (as they already did a long time ago with BIOS development, i.e., why it is we are here on this thread).

Another American manufacturer and global export powerhouse, driven into the ground by wall street's short term focus - generating cash on last generation leadership, not investing in the future, and losing relevancy. What a shame, first Boeing, now Intel. Who is next???

Companies start with their priorities as 1) Employees 2) Customers 3) Wall Street and as they mature this becomes 1) Wall Street 2) Customers 3) Employees. Intel has become 1) Wall Street 2) Wall Street 3) Wall Street. Intel has now become the Microsoft under Ballmer and the laughing stock of the industry. RIP Intel, it was great knowing you!

rockeyfish · ‎01-22-2021

During bios update 0087 of my NUC8BEB with eGPU connected, my bios was bricked and I had to restore it via recovery function.

Me too.

dylanb · ‎10-23-2020

Hey, I appreciate this write up. I had a weird issue with video playback on a NUCi5BEH I just purchased. I was unable to update the drivers normally. Also, video playback on display, through remote desktop and video processing such as media on VLC and other media players would suddenly stop and have to be reloaded.

I tried a few things, but found your thread pretty quickly. I switched off VT-d virtualization and enabled legacy mode for thunderbolt 3. Afterwards, I was locked out of my windows instance, due to bitlocker. It asked me for a code I did not have.

I formatted the drive and reinstalled Windows. Now, I am not having the issue with video playback. I'm using driver that automatically loads with windows.

Do you think this issue is related?

PavelPr · ‎10-23-2020

In all honesty, no. I don’t think that the video playback issue you describe is related to the eGPU issue that is described here in any way. It does sound like a device driver issue.

PavelPr · ‎10-23-2020

By the way, in case that BitLocker is enabled, it indeed might be a good idea to obtain the BitLocker recovery key before trying the above steps. Here’s how it may be obtained:

https://support.microsoft.com/en-us/windows/finding-your-bitlocker-recovery-key-in-windows-10-6b71ad27-0b89-ea08-f143-056f5ab347d6

Microsoft states that if users "are unable to locate a required BitLocker recovery key and are unable to revert and configuration change that might have cause it to be required, [they'll] need to reset [their] device using one of the Windows 10 recovery options."

From this text one can reasonably assume that enabling the VT-d option back should make the BitLocker prompt go away. It is a good idea to obtain the recovery key in advance, though.

In my case, the prompt never got triggered.

PavelPr · ‎10-23-2020

Might reasonably assume, rather.

dylanb · ‎10-23-2020

Cool. I appreciate the feedback. Thank you!

Snick · ‎01-23-2021

Hey I've heard of this issue in prior threads but the fix of power management didn't work for me so im asking if there is another option... Im having the freezing issue in which while not running a game the whole system will freeze and go unresponsive until a reset is done. Any fix for this or do I always need to have a game running in the background.

PavelPr · ‎01-25-2021

After a friend (who does not use an eGPU) has updated their BIOS to version 0087, I was able to test my eGPU with their system. It worked just like before. As such, I decided to perform the update myself.

I was able to update to BIOS 0087 without error (I always disconnect the eGPU before performing the upgrade using the "Express" method). Indeed, no eGPU-related functionality has changed and everything works like it did with BIOS versions 0083 and 0085.

@patrick589

You're welcome!

I just tested this with BIOS 0087, and there are no changes in behavior since version 0083 (given my settings). Even though I don't see the initial POST, after the machine has booted into Windows, I am still able to input the passphrase. I do see the password prompt and don't by any means have to input the passphrase blindly. I am not sure why you keep experiencing this issue.

@rockeyfish

In avoidance of potential trouble, I never perform BIOS updates with the eGPU connected. To perform a BIOS update I first disconnect the eGPU, connect the TV to the NUC's HDMI output, boot into Windows and use the "Express" method.

@Snick

This does not appear to be related to the issue described here. With that being said, I have knowledge of that issue, having experienced it as well. Just like you, my system would freeze under light load situations. Give the following a try:

Open the NVIDIA Control Panel (to do that, right click anywhere on your desktop and select "NVIDIA Control Panel"). Then, under "3D Settings" select "Manage 3D Settings". In the list that appears on the right pane, locate the "Power management mode" option and set it to "Prefer maximum performance". Click "Apply" when you're done. This resolved that issue for me, completely. Good luck!

@Ronny_G_Intel

Could we get an official, detailed response to this, after such a long time?

In particular, it appears as though the "no POST with eGPU" issue has been addressed with an BIOS update for other (Skull Canyon) NUC models (for example, see: https://egpu.io/forums/pc-setup/activate-the-egpu-during-bootsplash/#post-9136). Why can't the same be achieved for us, NUC8i*BEH customers?

Moreover, why does Intel not change the policy of blocking BIOS downgrades (where security fixes are concerned) and leave the discretion with the consumer?

Why should we not be allowed to downgrade, in case that the upgrade breaks crucial functionality?

Again, had I not been able to locate said workaround, I would have had to buy a new computer – just to keep properly using my eGPU.

PavelPr · ‎01-25-2021

@Snick

For the sake of completeness I should add that setting the "Power management mode" option to "Prefer maximum performance" will lock the eGPU into a higher voltage and clock state. That state will, in turn, be constant and the system will not switch to an "idle"-like state during light load. This may consequentially result in higher eGPU thermals and increased power consumption.

Still, this surely beats the hell out of having an unstable system that would freeze under light load.

Using the Gigabute AORUS Gaming Box 2080 Ti (water cooled) eGPU, my thermals are still excellent (around 37c during light load). I have therefore come to terms with this situation, and am no longer trying to figure out how to achieve system stability while keeping the default power management mode active.

PavelPr · ‎01-25-2021

Gigabyte AORUS Gaming Box 2080 Ti*, my bad.