The "30% CPU at idle because of System + Interrupts" issue

[javispedro]

I don't think it's the EC as it appears to be using GPE 0x38.

To reproduce this issue in Linux you will have to enable interrupts for GPE 0x6D by writing 'enable' to /sys/firmware/acpi/interrupts/gpe6D and re-insert the SD card. The following GPEs seem to be valid: 0x09, 0x1E, 0x38 (EC), 0x61, 0x66, 0x69 and 0x6D. In Linux, interrupts are enabled by default only for 0x1E, 0x38, 0x61 and 0x66.

Checking the ACPI PM base IO space (0x1800) with R&W Everything, I see that the following GPEs are enabled in Windows: 0x11, 0x1E, 0x38, 0x61, 0x66 and 0x6D. When a sound is played, GPE 0x6D is disabled temporarily. GPE 0x6D is also masked when the sound card is disabled.

Ok, It seems that 0x6D is the GPE used by the EHCI, XHCI, and HDEF devices to wake the device from S3. Or at least that's what the _PRW methods for the devices say. That explains what _L6D does.

Its weird that GPE 0x6D would be masked when the sound card is disabled, as that would mean the device would not wake upon a key press on the type cover (unless there's other method?) .

I've not yet reprocuded the issue on Linux. Enabling GPE 0x6D only results in some ~1000 interrupts if I suspend and press a few keyboard keys while it's suspended (it does not wake up the device for unknown reasons...), but the storm does not happen.

 

[javispedro]

Taking out the card initially brings CPU use back to 0% for roughly 20 seconds, at which point, it goes right back up to 26%.

That's probably the "device ejected" chime playing + audio idle timeout.

 

[HypermagiK]

Its weird that GPE 0x6D would be masked when the sound card is disabled, as that would mean the device would not wake upon a key press on the type cover (unless there's other method?) .

Since this is a wake GPE, my expectation would be for the OS to enable it just before putting the device to sleep. This GPE might be the same reason why the device wakes up on its own sometimes. If the status bit is stuck and the GPE is enabled when the device is put to sleep, it will probably wake up right away. This happens to me from time to time.

 

[Philtastic]

I had it happen again when waking my SP2 from sleep with an SD card inserted today so I decided to very simply test the audio hypothesis. I had task manager running and simply muted and unmuted sound a bunch and you can clearly see the usage go back to 0% for 5'ish seconds but then spike back up to 24% then back to 0% when I mute/unmute again for another 5'ish seconds. In fact, moving the volume slider continuously so that no sound is made also keeps the CPU usage down continuously as long as you are still moving the slider: if you stop moving the slider while still holding on it, the CPU usage will go back up in that same 5 second time period from when you stopped moving the slider.

Further testing with music, I opened iTunes (this itself did not make a difference) and started playing a song. Immediately, the CPU usage dropped to like 1-3% and stayed that low while the song was playing. I paused the song and this still kept the CPU usage low. Closing iTunes, however, resulted in the usage going back up. To see if all audio sources worked the same way, I then used the Xbox Music app and saw a similar phenomenon except IT STAYED LOW EVEN WHEN I CLOSED THE APP.

This indicates that, perhaps, it's a problem with the way either the tablet-based apps use the audio driver, thus using one sort of "reboots" the audio driver and fixes the problem, or perhaps the desktop mode has a problem with the driver, thus using an app similarly "reboots" the driver and fixes it.

In summary, the fix that I have discovered is to load up a song in the Xbox Music app which allows you to regain low CPU usage without rebooting your device.

EDIT: I should note that my sample size is 1 attempt so not sure how reproducible this result is. I should also note that my SD card was never removed.

 

[jrapdx]

I had it happen again when waking my SP2 from sleep with an SD card inserted today so I decided to very simply test the audio hypothesis. I had task manager running and simply muted and unmuted sound a bunch and you can clearly see the usage go back to 0% for 5'ish seconds but then spike back up to 24% then back to 0% when I mute/unmute again for another 5'ish seconds. In fact, moving the volume slider continuously so that no sound is made also keeps the CPU usage down continuously as long as you are still moving the slider: if you stop moving the slider while still holding on it, the CPU usage will go back up in that same 5 second time period from when you stopped moving the slider.

.....

EDIT: I should note that my sample size is 1 attempt so not sure how reproducible this result is. I should also note that my SD card was never removed.

Interaction among mSD card present in slot, audio driver, startup conditions and high CPU utilization have been reported since December 2013 if not earlier.

SP2 CPU rates of >=25% have occurred quite variably, sometimes randomly, which makes it difficult to pin down what's going on. Like many others, I've experienced the CPU "spinning", primarily on startup from cold boot, but only when there was an mSD card in slot, and sound driver enabled. Usually, initiating sleep and waking again would give normal CPU rate.

In the last month or so, I've noticed much more frequent random high CPU utilization which mostly does not respond to the sleep/wake procedure. At times nothing at all has worked except to completely shut it down, and then start up again. The randomness of the problem makes it difficult to test whether the sound driver or mSD card play a role. In fact, it may not even be the same problem noted a few months ago even if the main symptom appears to be identical.

I guess we'll continue to scratch our heads wondering about the origin of--and solutions to--such SP2 glitches. Meanwhile, all we can do is to remain vigilant: keep an eye on CPU behavior, and take action when unaccountably high CPU rates occur.

 

[Philtastic]

Interaction among mSD card present in slot, audio driver, startup conditions and high CPU utilization have been reported since December 2013 if not earlier.

I admit that I could have typed less as I was summarizing my tests as I was testing them but my main new contribution (granted, I haven't really done an in depth search on what people have done to fix the problem other than disable sound) is discovering a potential band-aid fix for when the high CPU usage appears: play some music specifically in the Xbox Music app. This seems to restore the system to its low CPU usage state without having to have audio playing all the time or even leaving the app open or completely disabling audio. I'll test this again when I encounter the high CPU usage again. So far, I've brought it out of sleep a handful of times since stumbling on this "fix" without restarting or shutting down and haven't had it come back yet.

 

[Philtastic]

So it looks like there are two kinds of high CPU use: one that goes away with audio usage and one that doesn't. The latter presents similarly to the audio one with the System process consuming ~24% CPU usage but not consistently holding the clockspeed at 1.88 GHz: it tends to be in the lower 2 GHz clockspeed. I don't remember having this issue that drains the battery before I got an SD card so I am pretty confident that both phenomenon have been caused by having an SD card in the device when waking the device from sleep and hibernate. I think I'm going to remove my SD card and see if these issues come back.

 

[javispedro]

I then used the Xbox Music app and saw a similar phenomenon except IT STAYED LOW EVEN WHEN I CLOSED THE APP.

The Xbox Music process stays around if you close it the Metro way. Use the task manager to verify.

So it looks like there are two kinds of high CPU use: one that goes away with audio usage and one that doesn't. The latter presents similarly to the audio one with the System process consuming ~24% CPU usage but not consistently holding the clockspeed at 1.88 GHz: it tends to be in the lower 2 GHz clockspeed. I don't remember having this issue that drains the battery before I got an SD card so I am pretty confident that both phenomenon have been caused by having an SD card in the device when waking the device from sleep and hibernate. I think I'm going to remove my SD card and see if these issues come back.

You can use LatencyMon to try to guess if it's the same issue or not. More ideally, the ACPI trace log (as above) could be used, but I haven't figured out how to setup it yet.

In any case and as seen above there is still no link between the SD card and the issue other than the fact the SD card is a USB device (so technically using any USB device could cause this).

 

[HypermagiK]

You can use LatencyMon to try to guess if it's the same issue or not. More ideally, the ACPI trace log (as above) could be used, but I haven't figured out how to setup it yet.

Here's what I used to get the ACPI trace logs:

@echo off
logman create trace acpi -ow -o c:\acpi.etl -p "Microsoft-Windows-Kernel-Acpi" 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode 0x2 -max 2048
logman start acpi
echo Enter any key to stop tracing...
pause
logman stop acpi
logman delete acpi

You can also get the Read & Write Utility from RW - Read & Write and go to Specific -> IO Space -> ACPI PM Base. The issue appears when the value at offset 0x8D is stuck at 0x20 (status bit for GPE 0x6D is set) while the value at offset 0x9D is also 0x20 (GPE 0x6D is enabled).

 

[Philtastic]

Since I removed my SD card on the 17th, I haven't had a reoccurrence of any high CPU usage for no reason scenarios upon waking from sleep. I'll keep monitoring but at least some of these are definitely due to an SD card issue.

 

[Philtastic]

Had the high CPU usage come back without having inserted my SD card at any time since the 17th. Definitely 2 separate issues then: one that's SD card related and probably interacts with the sound driver somehow and another that is SD card independent and is not affected by playing sounds.

EDIT: Interesting... just as I posted both here and on Microsoft's forums, I go back to my task manager and the usage has gone back to normal after an hour or so of 23-30% usage by the "System" process. Not sure what to think of this episode now. Does it go away after a time for anyone else?

EDIT2: To test whether it would come back, I put my SP2 to sleep, waited 20 seconds, then woke it up, and it's back at 26-27% System usage. Blah.

EDIT3: Although they seem like independent problems, I never noticed this issue until I first inserted an SD card so I'm going to try something - I'm going to insert my SD card and then manually uninstall the driver from Device Manager and then eject and not insert my SD card for awhile and see if this comes back. Sigh, I dislike guessing games, and I just want my device back to working properly without having to worry whether my battery is going to suddenly drain on any given wake from sleep...

 

[GoodBytes]

I just had the CPU usage. Was stuck at 17%, I have no microSD card, like I don't have one anywhere.
The only thing I could see, is that the wireless was showing limited connectivity error, and could not find any wireless network.
Doing a restart, just make Windows stuck at the restart process, so I had to the power button several second to power it down, and to fix the issue, I had to do PowerUp + Volume.

While it might be another issue, or just a fluke, so I am thinking, if the wireless card might be crappy and is the one 'causing the issues, not the sound chip.