Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

EFI Update 2015-005 incompatibility w Bootcamp 5.1.5460?

Since installation of EFI Update 2015-005, one core is pegged at 90+% CPU utilization at all times when running Windows under Boot Camp.

I am running Windows 7 64-bit OS under Bootcamp 5.1.5460 on a Mac Pro w Retina display, late 2013. This was working correctly until the EFI update.

Mac OS is OS X v 10.9.5, Mavericks.

The result of this issue is raised core temperature, decreased battery life, and reduced performance when running Windows applications.

It is my suspicion that the cause of the issue is that Bootcamp drivers are not handling interrupts generated by the EFI update correctly.

Are others experiencing this? Is there a workaround or solution?

MacBook Pro (Retina, 15-inch, Late 2013), OS X Mavericks (10.9.5)

Posted on Jul 17, 2015 10:56 AM

Reply
6 replies

Jul 17, 2015 1:49 PM in response to Loner T

Thanks for your feedback. Here is some information I've gathered regarding how Windows power options relate to the issue I'm experiencing.

Thus far, changes I've made to Windows power option settings do little more than redistribute the workload among CPU cores. They don't resolve the fundamental issue. Since the EFI security update, 1/8 of processing power is occupied by the kernel. There is no user space process visible in Task Manager to account for this workload.

When my Macbook Pro is connected to power, I observe the following behavior for standard Windows power option settings...

High Performance -> 1 thread = ~100%, Balanced Performance -> 2 threads = ~50%, Power Saver -> 4-5 threads at 15-25%.

Note I say "threads" since I believe the i7 processor has only 4 cores, but Windows task manager shows 8 plots.

Prior to the EFI security update the system was idle with negligible workload on all CPUs.

I do not see the option "Power Options -> Advanced Settings -> Processor you mention. However, when I drill down into menus under Control Panel ->Power Options->High Performance->Change Plan Settings->Change advanced power settings->Processor power management with "High performance [Active]" I see:

Minimum Processor State -> On battery: 5%, Plugged In 100%
System cooling policy -> On battery: Active, Plugged in: Active
Maximum Processor State: On battery: 100%, Plugged in: 100%

Googling for solutions to my issue, I have found no resolution for Windows. However, I did discover that Linux users appear to work around a similar issue by disabling an ACPI interrupt. Perhaps something similar is possible under Windows?


A link provided with the Apple EFI security update mentions the Rowhammer bug and related security vulnerability. An approach to mitigate the risk of this attack is to increase the frequency of memory refreshes. My suspicion is therefore that the Apple EFI Security update has configured an interrupt to increase the frequency of memory refreshes. While OS X has a driver to service these, other operating systems (e.g. Windows, Linux) do not.

If this were the case, perhaps a future Boot Camp driver update might resolve this. Alternatively, perhaps I'll find another solution.

Has this information been helpful? Did I miss some power setting related information you were looking for?

Jul 17, 2015 3:24 PM in response to CleverUser

Note I say "threads" since I believe the i7 processor has only 4 cores, but Windows task manager shows 8 plots.

Thanks to Hyperthreading, each CPU core looks like 2 vCPUs to Windows.

Minimum Processor State -> On battery: 5%, Plugged In 100%

Change the plugged in state to 5%.

System cooling policy -> On battery: Active, Plugged in: Active

On Battery should be Passive.

Maximum Processor State: On battery: 100%, Plugged in: 100%

On Battery can be lower than 100%, if you want longer battery life.

A link provided with the Apple EFI security update mentions the Rowhammer bug and related security vulnerability. An approach to mitigate the risk of this attack is to increase the frequency of memory refreshes. My suspicion is therefore that the Apple EFI Security update has configured an interrupt to increase the frequency of memory refreshes. While OS X has a driver to service these, other operating systems (e.g. Windows, Linux) do not.

Technically, this should be addressed by the OS threads in Windows and Linux. Relying on interrupts is expensive and also causes CPU context switches. It is better to spread it across multiple cores. OS threads can be scheduled, even RT scheduling is available in Mach kernels (the basis for OSX) and is now on all *nix and some other major OSes. Windows DataCenter may also have it, but I do not dabble in it too much.

Has this information been helpful? Did I miss some power setting related information you were looking for?

Yes, concise and clear. 😉

Jul 18, 2015 3:01 PM in response to Loner T

Today I stumbled across a simple workaround that appears to completely resolve the issue by eliminating the mysterious kernel workload.


After booting into Windows...


1) Place the computer to sleep (e.g. Start->Sleep)

2) Wake the machine (e.g. Press the power button)


At least the few quick tests I've performed seem to confirm that after my system wakes from sleep my kernel utilization on all CPUs returns to close to zero.


As I typically boot into Windows to complete some work and then back into OS X, I don't typically put my system to sleep when running Windows. So I hadn't realized there was such a simple solution. At least in my case, I'm willing to take a few moments to have the system sleep/wake rather than potentially reducing performance by changing power options.


Thanks for your previous suggestions. I suspect that modifying power options may be helpful to users for whom the sleep/wake workaround I've described isn't practical.

Jul 18, 2015 3:20 PM in response to CleverUser

There are issues with Sleep/Hibernate on W7/W8. Thunderbolt devices, SD Cards, USB, BT and WiFi devices run into issues. I have seen Audio issues, but a bit rarer in my experience. The implementation of Sleep/Hibernate should allow the CPU context to be initialized and all processes re-queued and scheduled. CPU Affinity is never maintained across sleep/hibernate cycles in general OSes. RT OSes behave differently .

EFI Update 2015-005 incompatibility w Bootcamp 5.1.5460?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.