|
|
AC In/Out OS Slow Response
- Phenomenon
( \2 H# ]! ~$ U7 j
5 K2 [$ z" b/ [3 k手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
! r. |) @& L* b( M- Why???
; L7 ?1 _3 q: U& H: @% f* l
! ]& [& y$ g5 p
! ~9 O. Q6 ^2 H: V5 U; }- l
刚看到这条bug时，我有点不以为然，因为有些机种也有这样的状况，所以我以为这个有可能是不同的测试人员认知上差异。而且超薄NB为了解决好功耗、导热的问题都使用比较低的配置，我最初还觉得可能跟配置有关。但是他们找了个相同chipset的机器去试，反应很流畅没有这样的现象L!我的猜测站不住脚了，这时我觉得应该是FW有些地方没有处理好导致的了。随后我们开始debug，首先我们要理清AC in/out 过程中EC、BIOS、OS都做了哪些动作,我所知道的状况是这样：1. EC检测到AC in/out的中断，更新EC ram中的AC状态并引发SCI IRQ通知OS。2.OS收到SCI IRQ后调用BIOS中的_Q method并通过Notify function通知OS power source change。3.OS调用_PSR function获取AC的状态并据此更新power icon显示。上述過程sample code 如下述所示：/ {2 S2 I" L' v; n2 p5 ~9 _- y
// AC Change event
5 c# u, B5 A$ @; ~* C, }) m8 K# F8 Q# Z' u& z' ] h' N" S
Method(_QXX)+ e& K' m/ {! t7 |
+ o |' @& i/ b{9 B$ g9 \6 w9 ] P% X$ P* E3 P* H& ]
: B. Y1 @4 o% ~$ Y0 `' F8 j. S
Store(0x09, DBG8)
6 E e5 o) S, ^: Y3 d; M9 h, Q6 w4 ?; |( \; {
Notify(\_SB. ADP,0x80)
9 \4 M4 I9 k9 r7 v3 L9 @0 M//Power Source status changed/ ]1 L2 Y$ ?* M- O) Q
( Y0 Z# J3 V! S& d2 s5 ^: ` ^ |Store(0x0A, DBG8)
5 N1 y2 f+ s; i: y F
8 \# w/ P9 \# }+ T. p2 r- \9 g, m0 e* P& A; N1 o) A9 A4 J
}
# V6 E9 C3 O) \1 |# _, n* ?6 E$ c
4 X1 |" u1 K0 e# g0 E* A* R8 M* k+ k! B k
Method(_PSR,0)
' Q- c. U7 k0 l; x: v% ?8 c+ V' M8 u: y0 _
+ w5 c' F" T9 s' S. c# I" R
{
8 a: \7 j. B1 C# q* F8 `( T# g7 Y+ x
7 [# X, e/ k# [" o- M; A- D
Store(0x0B, DBG8): V7 O0 x8 v+ ~) r: v
$ U5 ?3 P! M. L2 i
( d8 p4 f) W+ L0 X0 M, T) r( I
If(ACST)
2 M/ j) G! W+ V+ u//check AC status; B: ~" m9 ^4 i% z
; s3 k1 [$ e/ R4 I& t' t$ e2 L+ t{
3 V0 k$ m6 @9 g! D4 F' u, j+ ^) k2 k- q$ G; S/ e: |
, ]7 m- a/ \2 T6 Z& [% P" r8 h$ X* Zreturn(One)
) V4 ^( A* d" x8 Q// AC Present
5 v, M7 V* Z( O" W r# o4 o% S8 B a4 b4 y; h
}
3 A, r1 {" X! Y0 ~3 ?: J% Z8 \2 v6 ]; r
else
: |9 F- L3 l% `4 I7 Q( M% }/ G7 @! S
{
+ x) u2 ] a, v4 J6 U; M
; N: _8 a. j$ hreturn(Zero)1 Y I8 e! o0 a1 K! ~' `4 f Z
// AC Not Present' O/ p+ l4 e' \ s( K! r8 |
. C6 Q: a2 g- j! K! C
}$ C' j, H+ x+ q( d
' m! B' F( Z# n5 g3 E: t! U6 WStore(0x0C, DBG8)' e9 N1 [' i0 F) P+ j) }% l' Y
( g8 ^6 c; O. M$ j- }8 @
}0 G- {+ k' v( J$ o( b
6 W% z2 V! r/ X* G- Q: [
+ Y+ l& A3 p6 ]# I3 B我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
3 e% R& a5 b, y9 m# j7 j. G% y状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：. _' v9 c0 b, u: r
Method(_BST)6 L' s8 x/ I! t
{
2 T6 F" s4 ?4 y7 ^1 m6 e( W/ H1 S# ^
$ d8 R+ {* j( Y! ]# wStore(BSTS,Local0)# {& a( l% p* m2 v6 r
$ J) D9 `% _. Z+ V$ g/ A
0 i; v* a! w( y
If(LEqual(Local0,1)) //Check Battery Present Bit) F0 V: G0 o8 {0 Y
3 x* v2 h6 A4 a/ z
{
+ k" m1 `4 ?) k# E( c' N& r
" c9 Q4 t: ?8 R2 e! ~7 P2 G
8 x# M! X1 C! }+ Y2 s: Q
# D& ?4 C, C) r8 F$ a9 A" \5 X1 b# X1 j% }) r- h
7 n! {8 b0 R+ s1 U& U
//Read Battery information from EC
, a8 w ?* V2 W1 {4 s( B; P# q/ T8 ^+ A, V q) `4 O
… …8 C2 Q6 ?8 X# M5 X" F( q/ _# x. T
m1 c) \9 |$ K3 q
* x/ u! I" j" k. ~4 ?5 R}
8 `) a9 f8 m- l5 a/ Z8 U
: k6 L- i$ N9 zStore(0x0D, DBG8), G2 A/ f ~! \# \4 f, G! W! B
}
2 e& [5 y/ w1 L6 ]0 s那么问题好像是由读EC ram导致的，ACPI中读取EC内容的方式是发0x80 cmd到ox66 port，随后EC产生一个SCI通知OS，接着OS将EC ram index发给0x62 port，EC将数据送给0x62 port再产生一个SCI通知0S，接着OS读0x62 port就获得了EC ram指定位置的数据了。我在EC 端加入debug信息，发现出现状况时0x80 cmd EC很晚才收到，0x80 cmd是OS发的，所以貌似和EC也没什么关系吗？继续思考，EC产生一个SCI的目的应该是产生一个IRQ让ACPI driver获悉前面的指令已经完成，ACPI driver可以继续送指令下来了。如果某一条指令慢则有可能是前一个SCI IRQ通知 ACPI drive而 driver还没有处理好导致，也有可能ACPI driver已经处理好但是EC没有ready所致。) c" n: ?6 b* n) r) S/ h* A
那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示： L3 r( D6 L) n
& C B% C3 ^( s6 ~( @4 s# m
/ O$ Y) T; L+ d- h) s1 w
而BIOS对SB SCI pin通常配置成low edge trig， SCI的pulse trig有个优点就是它能够自动复位，产生一个中断后SCI pin会pull high。可是因为BIOS是下降沿触发，所以EC SCI保持64us低电平会不会太长呢？会不会导致ACPI driver收到IRQ后下命令给EC,而EC SCI pin还没有复位而太久才收到？又或者说EC SCI pin保持低会影响到ACPI driver IRQ latency？有了这个想法以后，我就开始放大它，修改EC SCICFG将SCI IRQ配置成128 us pulse trig，然后再做AC in/out的实验，嘿嘿病情加重了，fail率接近了80%之前只有10%；那我再将pulse width调整为16us再试，结果200次竟然没有一次出现症状J.4 p, l1 K' F" D8 v% m% @
$ Z. q' T1 Y Z& a O" T/ p% Z: t) R: D: S" ~
& F; Z' t; y' X
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
7 Y$ J S1 ^% B. {. h8 |' P4 W
& W% {* o1 `) B4 R' A l5 w9 ~
2 G7 ~* f) u5 H4 ^3 s& o3 x% \1 v/ q( e
& m m4 j$ T) C' G
That’s all!
; w9 g4 x5 N8 Y8 e3 ^. O : K# [$ T3 W$ e( O J e7 F
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
