javispedro
Member
Since I've been started getting bit by the "30% idle CPU usage", I've started to try to diagnose the problem.
The symptoms of this "issue" are more or less well-known and defined, from what I read on these forums: on some boots, the "System" plus the "System Interrupts" item on task manager will be stuck to a combined ~30% CPU usage, and thus the CPU will never idle to 0%, as it does on "normal boots". This results in a system that is quite warm to the touch even if it's been used only to browse Bing News.
Possible causes:
So today I ran LatencyMon while affected by the problem. This problem is designed to estimate "average" latency of system timers, and it does this by measuring how much time is spent processing interrupts or DPCs, which may delay system timers.
Obviously, for the issue at hand, I was more interested in the second aspect of the tool: measuring time spent processing interrupts. Here are some interesting tidbits from the results. But first, my hardware specs:
5% of CPU time is spent on a ISR from one driver: ACPI.sys. While the system is idle. Ergo, this is where the problem is.
Also, 300k interrupts during 1min while idle.
Again, 6.8% of CPU time spent on DPCs from ACPI.sys
Unfortunately, I don't know enough about Windows kernel debugging to go any further. My intuition says some ACPI DSDT code is livelocked. Does anyone know any Windows ACPI "tracers" or debuggers?
Maybe I can try getting the issue reproduced under Gentoo..
The symptoms of this "issue" are more or less well-known and defined, from what I read on these forums: on some boots, the "System" plus the "System Interrupts" item on task manager will be stuck to a combined ~30% CPU usage, and thus the CPU will never idle to 0%, as it does on "normal boots". This results in a system that is quite warm to the touch even if it's been used only to browse Bing News.
- "System" often has a slightly larger CPU use than "System interrupts", but the two combined always use around 25-30% CPU.
- No other processes are involved.
- All Surface Pro 2 models affected (4300U, 4200U included).
- A reboot, sleep or hibernate is often enough to get back to normal. The issue seems to only appear after a cold power-on.
Possible causes:
- I use mostly Gentoo on my Surface so my Windows partition is "as is", except that I run all the updates as they come in. Thus none of my experiences can be blamed on "3rd party programs". Also, Gentoo never shows these symptoms: therefore this is not a hardware problem.
- Lots of people mention it is related to whether a SD card has been inserted or not. Personally I doubt SD card hardware has any relation (SD card reader is basically a simple USB device). See following discussion for more details.
- Audio may be related. In my experience, starting playing audio using e.g. Windows Media Player makes the problem go away. CPU usage only goes back to 30% when I close Windows Media Player.
So today I ran LatencyMon while affected by the problem. This problem is designed to estimate "average" latency of system timers, and it does this by measuring how much time is spent processing interrupts or DPCs, which may delay system timers.
Obviously, for the issue at hand, I was more interested in the second aspect of the tool: measuring time spent processing interrupts. Here are some interesting tidbits from the results. But first, my hardware specs:
Code:
OS version: Windows 8 , 6.2, build: 9200 (x64)
Hardware: Surface Pro 2, Microsoft Corporation
CPU: GenuineIntel Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz
RAM: 8112 MB total
Code:
REPORTED ISRs
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.
Highest ISR routine execution time (µs): 78,728148
Driver with highest ISR routine execution time: ACPI.sys
Highest reported total ISR routine time (%): 5,166394
Driver with highest ISR total time: ACPI.sys
Total time spent in ISRs (%) 5,199141
ISR count (execution time <250 µs): 328173
ISR count (execution time 250-500 µs): 0
...
5% of CPU time is spent on a ISR from one driver: ACPI.sys. While the system is idle. Ergo, this is where the problem is.
Also, 300k interrupts during 1min while idle.
Code:
REPORTED DPCs
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.
Highest DPC routine execution time (µs): 154,694868
Driver with highest DPC routine execution time: Wdf01000.sys
Highest reported total DPC routine time (%): 6,835592
Driver with highest DPC total execution time: ACPI.sys
Total time spent in DPCs (%) 15,016029
DPC count (execution time <250 µs): 1318446
DPC count (execution time 250-500 µs): 0
...
Unfortunately, I don't know enough about Windows kernel debugging to go any further. My intuition says some ACPI DSDT code is livelocked. Does anyone know any Windows ACPI "tracers" or debuggers?
Maybe I can try getting the issue reproduced under Gentoo..
Last edited: