zoukankan      html  css  js  c++  java
  • ThinkPad x200为何总是CPU占用50%

    2009年,我从美国买回一台ThinkPad X200 Tablet,Windows XP Tablet PC Edition 2005版,服役几年一直很正常。直到2012年初的时候,突然发现电脑非常的慢,打开文件夹都特别慢。十分奇怪,于是我打开任务管理器Task Manager,吃惊的看到system进程持续占用50%,傻眼了。这让正常的进程怎么活啊。

    于是,我便开始了漫长的寻找原因的过程。

    首先,用Process Explorer看看进程的情况,在System进程下,子进程Interrupts占用50%。说明有大量的中断请求反复的出现,而且是潮水般的非正常的情况。立刻怀疑可能是某个硬件故障,导致大量无效的中断。打开Interrupts属性,看看线程Threads的情况,一个家伙反复出现,ntkrnlpa.exe,而且CSwitch非常高。由于ntkrnlpa是一个WinNT Kernel核心,所以初步估计是一个基础硬件功能不停的触发中断所致。

    无奈只能继续分析ntkrnlpa.exe的中断请求统计情况。使用KrView工具,输入kernrate_i386_XP.exe -s 5 -z ntkrnlpa -v。这时能看见中断执行模块的统计结果,此时占用率最高的是KdDebuggerDataBlock和RtlIpv6StringToAddressA。开始稍微有点眉目了,怀疑是网卡出问题了。
    关于KrView的使用情况,可以看看这里
    http://forum.sysinternals.com/kernrate-trace-rtlipv6stringtoaddressa_topic19138.html
    http://forum.sysinternals.com/hardware-interrupts-30-kernrates-ntkrnlpaexe_topic19231.html

    这里要强调一个地方,使用KrView需要下载symbols(dbghelp.dll,symsrv.dll),不然模块名会出现NtBuildNumber,那就真的一头雾水了。
    关于symbols的下载,详细看这里
    http://forum.sysinternals.com/kernrate-trace-need-help_topic14768.html

    问题跟踪到了这里,棘手的问题开始出现了。我怎么知道这个KdDebuggerDataBlock和RtlIpv6StringToAddressA是由谁调用的?如果不能找到问题的源头,就根本不能解决问题。我开始迷茫了。

    于是我开始研究系统中断DPCs原理,希望能找到问题的根源。
    无奈,看了一部分资料后,我放弃了。DPCs非常复杂,一时半伙弄不明白。即使道理弄懂了,离实际解决问题还有很大的距离。
    http://analyze-v.com/?p=598

    研究中断原理的道路,走到这里就到尽头了。以我现有的能力无法进行下去,有太多基础的知识需要补充了。
    为了解决问题,我只能另辟蹊径。

    我先开始试试,把网卡禁用,问题依旧。
    然后我便尝试寻找lenovo的技术支持。结果皇天不负有心人,真的给我发现了这个。
    http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x200-Hardware-Interrupts-constantly-at-40-of-CPU-resources/td-p/98869

    根据第3页MikeSL的回答,问题出在显卡的驱动上,更新驱动的版本就可以解决了
    原话如下

    This isn't a specific fix for this specific issue, but I've found with a very similar "excessive hardware interrupts" scenario I experienced over the past few months (Windows XP, Thinkpad T61) that:

    1. There was ample evidence in the output of the KrView.exe tool (KernRate from Microsoft) that these issues were caused by drivers that were responding to (or firing off) APIs with names like "AddDevice()", and that the vast majority of the unnecessary/excessive/CPU-consuming interrupts were directly related to these API calls.  (Note: KernRate is likely not supported on Windows Vista - at the very least, Microsoft strongly encourages those with Vista/Server 2008 or later to use the Windows Performance Analysis Tools in place of KernRate.  I have no experience using these tools, and cannot guess whether they provide similar detailed kernel tracing capabilities, but I surely hope so.)
    2. Disabling the "Intel(R) Management Engine Interface" helped reduce the number of occasions of this problem.
    3. Upgrading the "Mobile Intel(R) 965 Express Chipset Family" driver to the latest (v6.14.10.5029) finally stopped the last remaining case of these excessive Hardware Interrupts from occurring.
    My conclusion?  This is not an uncommon type of API call for a driver to make/respond to - since many device drivers, such as multi-output video adapters and other hardware-controlling devices are trying to emulate the Windows "plug and play" behaviour.  Thus, it's likely there are many potential sources of these "excessive Hardware Interrupts", and addressing each potential troublesome driver is the only way to drive *all* the sources of the error to ground.  Thankfully I don't seem to *need* the Intel ME Interface driver for my computer to operate, and thankfully there was a recently-released version of the 965 video driver that didn't have the issue.  YMMV, and it's a long road to travel (I spent at least two months obsessively pursuing this issue), but I suspect there almost always *are* solutions, if you're patient and persistent enough.

    至此,真的是山穷水复疑无路,柳暗花明又一村啊。心情非常激动,立刻开始更新驱动,问题完美解决。

  • 相关阅读:
    PHP 快递单号查询api接口源码指导
    电商平台适用基础快递查询api接口对接demo解决方案
    智能物流查询api接口demo(php示例)
    解决在TP5中无法使用快递鸟查询API接口方案
    解析快递鸟在线预约取件API接口对接编码
    快递鸟批量打印电子面单接口及控件安装
    「note」原根照抄
    「atcoder
    Solution -「NOI 2021」轻重边
    Solution Set -「ARC 124」
  • 原文地址:https://www.cnblogs.com/keanuyaoo/p/3327621.html
Copyright © 2011-2022 走看看