第七篇:风起于青萍之末-电源管理请求案例分析(下)

来源：互联网发布：怎样登录淘宝网页版编辑：程序博客网时间：2024/04/29 23:08

第五篇:风起于青萍之末-电源管理请求案例分析(上)

http://blog.csdn.net/u013140088/article/details/18180249

第六篇:风起于青萍之末-电源管理请求案例分析(中)

http://blog.csdn.net/u013140088/article/details/18218593

在前面两篇技术BLOG中,我给出了部分分析过程, 其中有些部分对于后续分析是有作用的,也有一些分析,属于走了一些弯路,但并非完全是无用功.

上篇中, 分析判断得出这一系列近20个BSOD都是系统发往第四级SS HUB的电源管理IRP(SET D3), 在规定的时间范围内, 该IRP没有被完成,所以产生了该BSOD DUMP FILE.

中篇里, 从IRP栈, 栈回溯, 相关线程与事件, 系统死锁, 以及前一个电源IRP(SET S4)的分析, 期望找到一些线索来得出最后结论, 但由于"Windbg"使用技巧与Windows 操作系统功底有限, 最终没有找到问题的根本原因.

问题的解决与发现,并非"自古华山一条路"!

就以本案例来讲, 如果在功底有限的情况下, 与其非要从原来的道路走到黑,不如停下来, 稍作休息与思考, 寻找其它的解决方法.

请大家看一下, 第五篇中的"SuperSpeed Interop Tree with Host Under Test"

我们可以发现, SS HUB4下面所带有的SS USB DEVICE/HUB.

SS HUB4:

-->Port 1: -->SS HUB5-----------------> Port 1: SS Lower Power Drive & (Port 2: SS video camera, 实际测试中, 由于市面上没有SS, 所以是HS, 忽略)

-->Port 2:

-->Port 3: -->SS Display adapter

-->Port 4:

发现, SS HUB4下面, 一共有两个SS DEVICE, 一个SS HUB.

说到这里, 简单提一下, 系统的睡眠过程是由外向内的过程, 在这里就表现为, 先SS HUB5下面的SS Lower Power Driver, 然后再SS HUB5.

要想让SS HUB4进入睡眠, 它的先决条件是SS HUB5与SS Display adapter都已经进入睡眠状态.

我们大胆地作一个猜测, 发给SS HUB4物理设备对象的IRP(SET D3)超时, 就是因为SS HUB4没有成功进入睡眠状态, 而纠其进一步的原因, 必定是:

要么SS Display adapter没有进入睡眠, 要么就是SS HUB5没有进入睡眠.

走到这一步, 我们又可以分别通过:

1. 分析BSOD DUMP FILE中, SS Display adapter与SS HUB5的行踪

2. 架起USB analyzer, 实实在在地"捕获" "东窗事发"时USB总线上的内容.

如果没有USB analyzer, 只能通过方法1继续在黑暗中, 打着"Windbg"这个手电, 慢慢摸索.

幸运的是, 我们作为USB xHCI HOST/Device IP的开发与验证工程师, USB analyzer与PCIe analyzer这样贵重的设备仪器却是必不可少的.

相对来讲, Lecroy的USB analyzer比较好用且容易上手, PCIe的只用过Lecroy, 不作评价.

既然有更加简单的方法, 就立马使用.

不过,这里还存在一个问题:

如果只有一台USB analyzer, 我们应该将它放在那个位置?

因为目前, 我们并不清楚, SS HUB4下面没有成功进入睡眠的是其中的哪一路, 还是两路都没有成功进入睡眠.

那么, 放在SS HUB4的down stream port (port 1 or port 3)中的任何一路, 都是不合适的, 因为这样存在一定的时间成本.

所以, 将USB analyzer放在SS HUB4 Up stream port.

在这种情况下, SS HUB4通过接收xHCI host发过来的USB control request来控制其下属的两个PORT.

set feature 来设置这个PORT是进入睡眠U3,还是正常工作U0.

Get status来取得这个PORT的状态.

问题发生的时候, 一次又一次, 频率非常高.

但当我们真要通过Lecroy USB ANALYZER去"捕获"它的时候, 问题的复现又变得特别不容易.

但是没有别的办法,只能慢慢地等待, 至少比起没有USB analyzer的情况, 条件是好多了.

最后, 被我的同事抓到了"现形".

经过分析, 我们发现, PORT 1上的SS HUB5已经成功进入睡眠状态U3.

而PORT3上的 SS DISPLAY ADAPTER起初, 也已经进入睡眠状态U3, 但随之而来的, 是系统又将它唤醒到U0状态.

至此, 我们找到了SS HUB4电源管理IRP无法完成的原因.

将xHCI host硬件IP排除出了该问题怀疑对象的范围.

后记:

1. 如果没有Windbg的前期定位, 要将USB analyzer正确放置在哪一级, 要发现问题的原因都无从谈起.

2. 曾经和一个开发上层应用软件的工程师无意间谈论起PCIe与USB, 由于现在行业细分起来起明显, 同样是搞IT这一行的, 但细分之后, 仍然可以用"隔行如隔山"来形容.

有意思的是, 这个工程师的固有观念就是:

PCI/PCIe比USB复杂;

CPU比PCIe复杂;

搞底层接口的工程师, 主要的工作就是画板子, 只要把几根导线接对了就可以了.

事实上,

了解过一点PCIe与USB3.0协议的工程师,都知道, 这两者的差异非常非常小.

而从设计CPU与PCIe/USB3.0的IP的角度(不是应用角度), 也没有他脑海中, 这种一个天,一个地的差距.

而底层接口工程师, 所需要具备的素质, 我已经在:

第一篇：践履实录2006-2013

http://blog.csdn.net/u013140088/article/details/17325589

提到过:

各种协议, 操作系统(Linux/Windows), x86/ARM CPU, 软件调试等一系列内容.

3. 仍然一些遗留问题, 不得而知:

比如说:

通过!poaction的输出:

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

Allocated power irps (PopIrpList - 825fb560)
IRP: 8a90af48 (wait-wake/S3), PDO: 891050f0
IRP: 91da2f00 (wait-wake/S4), PDO: 890dba50
IRP: 80e7cc98 (wait-wake/S4), PDO: 86a54500
IRP: 80eb4d50 (wait-wake/S4), PDO: a805c650
IRP: 80fb8c30 (wait-wake/S4), PDO: a806a030
IRP: 80f9cce0 (wait-wake/S4), PDO: 86a1e4d0
IRP: 80eded70 (wait-wake/S4), PDO: 86a22620
IRP: 81b8a9f0 (wait-wake/S4), PDO: b6cda080
IRP: be9da9f0 (wait-wake/S4), PDO: b5186ce0
IRP: 80350aa0 (wait-wake/S4), PDO: b6df2878
IRP: b597c8a8 (wait-wake/S4), PDO: b5119ce0
IRP: be8b4960 (wait-wake/S4), PDO: b511a030
IRP: aed5a9f0 (wait-wake/S4), PDO: bae779e0
IRP: 814c8aa0 (wait-wake/S4), PDO: b6df2bd8
IRP: 80396b78 (wait-wake/S4), PDO: baf13490
IRP: ab7b4aa0 (set/S4), PDO: 85be34c0, CURRENT: baf54bf8, NOTIFY: 86a3e038
IRP: bcd5eaa0 (set/D3,), PDO: 85be34c0, CURRENT: baf54bf8
IRP: bb7fcb78 (wait-wake/S4), PDO: baf42ac8
IRP: aa70cde0 (wait-wake/S4), PDO: 85b81030
IRP: 815eaeb8 (wait-wake/S3), PDO: 890de030
IRP: 80ef0c50 (wait-wake/S4), PDO: 943aa148
IRP: bb754e48 (wait-wake/S4), PDO: 8e0d7028
IRP: ba774de0 (wait-wake/S4), PDO: 943b3650
IRP: b58e4eb8 (wait-wake/S3), PDO: 890dc030
IRP: bb7b6e48 (wait-wake/S4), PDO: 8e0ca028
IRP: 97512d28 (wait-wake/S4), PDO: 86a37178

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

除了set/S4与set/D3, 其它的都是wait-wake/S4, 那么我们可以认为, 与这些wait-wake/S4对应的PDO已经进入了睡眠状态.

但是, 我根据系统设备树与这些IRP的一一配对, 才发现:

IRP: 81b8a9f0 (wait-wake/S4), PDO: b6cda080 USB\VID_17E9&PID_C300\DDR3Test usbccgp

这个就是SS HUB4 PORT3下面的SS DISPLAY ADATPER设备, 操作系统认为他已经进入睡眠了.

而事实上, 它是经过了睡眠,又被唤醒了.

我们不知道是什么原因被唤醒, 有一种可能, 是SS DISPLAY ADAPTER的驱动程序, 做了什么事情.

更进一步的猜测是, SS DISPLAY ADAPTER的驱动程序没有做好电源管理这一块代码, 导致了

1. 设备按要求进入D3, 又被唤醒

2. 驱动中该设备的状态,与系统记录的状态不符合.

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

IRP: 8a90af48(wait-wake/S3), PDO: 891050f0 ACPI\PNP0C0C\aa

IRP: 91da2f00 (wait-wake/S4), PDO: 890dba50 PCI\VEN_8086&DEV_1503&SUBSYS_20308086&REV_04\3&11583659&0&C8

IRP: 80e7cc98 (wait-wake/S4), PDO: 86a54500 HID\VID_046D&PID_C05A\7&285a05ca&0&0000 mouhid

IRP: 80eb4d50 (wait-wake/S4), PDO: a805c650 USB\VID_046D&PID_C05A\6&5197d5b&0&7 HidUsb

IRP: 80fb8c30 (wait-wake/S4), PDO: a806a030 HID\VID_046D&PID_C31C&MI_00\8&72a4da2&0&0000 kbdhid

IRP: 80f9cce0 (wait-wake/S4), PDO: 86a1e4d0 USB\VID_046D&PID_C31C&MI_00\7&2670f20a&0&0000 HidUsb

IRP: 80eded70 (wait-wake/S4), PDO: 86a22620 USB\VID_046D&PID_C31C\6&173dd442&0&6 usbccgp

IRP: 81b8a9f0 (wait-wake/S4), PDO: b6cda080 USB\VID_17E9&PID_C300\DDR3Test usbccgp

IRP: be9da9f0 (wait-wake/S4), PDO: b5186ce0 HID\VID_046D&PID_C05A\a&2da4de9c&0&0000 mouhid

IRP: 80350aa0 (wait-wake/S4), PDO: b6df2878 USB\VID_046D&PID_C05A\9&256f82f9&0&4 HidUsb

IRP: b597c8a8 (wait-wake/S4), PDO: b5119ce0 HID\VID_05A4&PID_9862&MI_00\c&100e23b3&0&0000""kbdhid"

IRP: be8b4960 (wait-wake/S4), PDO: b511a030 USB\VID_05A4&PID_9862&MI_00\b&1fd64059&0&0000""HidUsb"

IRP: aed5a9f0 (wait-wake/S4), PDO: bae779e0 USB\VID_05A4&PID_9862\a&3a3c313d&0&3""usbccgp"

IRP: 814c8aa0 (wait-wake/S4), PDO: b6df2bd8 "USB\VID_05A4&PID_9837\9&3829339e&0&3""USBHUB3"

IRP: 80396b78 (wait-wake/S4), PDO: baf13490 "USB\VID_0424&PID_2514\8&390024e6&0&2""USBHUB3"

IRP: ab7b4aa0 (set/S4), PDO: 85be34c0,CURRENT: baf54bf8, NOTIFY: 86a3e038

"USB\VID_2109&PID_8110\9&1a101867&0&1""USBHUB3"

IRP: bcd5eaa0 (set/D3,), PDO: 85be34c0,CURRENT: baf54bf8

IRP: bb7fcb78 (wait-wake/S4), PDO: baf42ac8 USB\VID_0424&PID_2514\8&390024e6&0&3""USBHUB3"

IRP: aa70cde0 (wait-wake/S4), PDO: 85b81030 USB\VID_8087&PID_0024\5&1c755ea1&0&1""usbhub"

IRP: 815eaeb8 (wait-wake/S3), PDO: 890de0 PCI\VEN_8086&DEV_1E26&SUBSYS_20308086&REV_04\3&11583659&0&E8""usbehci

IRP: 80ef0c50 (wait-wake/S4), PDO: 943aa148 USB\VID_050D&PID_0233\7&29fe3c0&0&2""USBHUB3"

IRP: bb754e48 (wait-wake/S4), PDO: 8e0d7028 USB\ROOT_HUB20\4&2be67a78&0""usbhub"

IRP: ba774de0 (wait-wake/S4), PDO: 943b3650 USB\VID_8087&PID_0024\5&213ddfc&0&1""usbhub"

IRP: b58e4eb8 (wait-wake/S3), PDO: 890dc030 PCI\VEN_8086&DEV_1E2D&SUBSYS_20308086&REV_04\3&11583659&0&D0""usbehci"

IRP: bb7b6e48 (wait-wake/S4), PDO: 8e0ca028 USB\ROOT_HUB20\4&1c3caa2d&0""usbhub"

IRP: 97512d28 (wait-wake/S4), PDO: 86a37178 "USB\VID_2109&PID_2811\6&19bbf76c&0&2""USBHUB3"

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

希望能有操作系统与WINDBG的大牛给出这些遗留问题的解决方法.

0 0