|
|
AC In/Out OS Slow Response
0 a" R) f8 L% y5 b1 s& \6 ^; M- Phenomenon
3 N# O% e* n) F& S
) c1 N6 f6 F# P
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
0 y7 |. t! n5 k) v0 H- Why???
. K# D! { j* l5 L) m( {
* P; g/ f9 [# m2 |0 y
( A# t5 U& z$ j. z1 F5 R' h刚看到这条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 如下述所示：
U0 |2 `6 @9 J// AC Change event
& u7 Q3 L% Y) A8 b3 D: @7 X1 R' h
5 _% W0 Y( D2 r0 I' ~: C' lMethod(_QXX)
4 w1 o+ y) i' [, K) B( O& a7 c! N% t) O$ f
{$ X9 y2 J* ?6 y$ q' E( w
9 N1 T+ x3 D, P3 g# _9 }0 H7 F
Store(0x09, DBG8)) j4 G+ h1 y* y+ J% J& f5 v8 _8 H9 R
+ e2 K# f7 d4 P
Notify(\_SB. ADP,0x80)( C' d" ]4 [! T
//Power Source status changed
$ v* x) {5 q# L, x( C# [
3 a# T! q3 |- L. s/ Z7 B3 QStore(0x0A, DBG8)) Y4 V* c7 x0 l" S' s' Q: \
: w0 ~! j9 F% {7 s+ K' q! w4 O2 f' o$ w8 k, u$ M
}
2 ~- z8 A" s f2 _7 C1 }6 f$ L. ~; f/ s- ^, ] g/ ^
1 u5 k* A8 ]3 @) p
/ k4 ~1 t5 h# _+ a2 E- O- H" OMethod(_PSR,0)
A$ @9 m% V3 D t. A' l2 y j% H: Q$ X& g1 {, c
: Z+ V B* T8 ]4 u- X9 V* ~4 ^
{
) l% f4 m: Q y& w1 Z1 E
5 J# B3 Z$ X2 B6 g
! f9 t. z4 ~2 I0 H6 j+ ~Store(0x0B, DBG8)
& E2 V6 @* ]6 B/ @
% ~8 k" o% q4 @. s; w" ~; ?. P9 u& z, b# F! p
If(ACST)3 ?8 [5 S: {0 w: G0 @1 \5 E1 n
//check AC status1 ~! p$ |* ^4 j/ O
- r% K! ^& C- g5 G
{1 p' Q, D) C# U9 T
! V' ~! B D) D! j1 ?
9 o4 |1 f' _4 ~8 q; Rreturn(One)
2 f- K3 P4 H( t6 z- I6 s// AC Present0 n" U* z9 w1 u& f& u+ y
1 p" y, ^2 \: a9 L2 x
}
) f( T# f( Z6 W
# U# J) m N4 Q; belse' s0 s4 Q) u5 Z$ b& u9 l! @
. u- x9 G$ p* d7 X* Q' Y
{
4 Y p$ P* K7 E. u# Y2 n! J9 n* f$ t) V
return(Zero)
* G [4 q. k& D) y: r// AC Not Present o/ \$ I2 w; a7 S0 s
( @9 a! g+ L9 L
}
& c/ ?5 B. B; r: a7 i4 @" b3 e
% I; a- o! `' l [/ }Store(0x0C, DBG8)1 a* B* [; {8 _8 y. n8 f
+ e0 B) @9 d* y; \# R" y/ |
}/ N" F- n* k& o& z: @* g4 P
, F; D$ Q" p8 c; G5 P
6 {( w7 _. |1 ^+ G' y# `% S我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
' N/ t! D% e2 A3 G, }状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
8 ]3 z0 v7 F7 h6 PMethod(_BST)$ r4 N r# A- m+ i" X' y
{* V8 Q0 c& F9 s4 m- I
/ o+ y6 J. _# C/ r6 u1 u6 J! qStore(BSTS,Local0)
0 e+ U: z! c% z0 N1 @; n: q
9 H! l$ e7 X( _* |2 |, B' z ?
) \0 k5 \- S' u r" t, ZIf(LEqual(Local0,1)) //Check Battery Present Bit
6 x2 j9 d/ W$ }/ h/ {; r0 i7 b( v
+ j1 G% f# d3 a3 k/ e{: _5 N9 D$ N* b5 D8 K. K' d
1 g% U- @& a$ R# Y' L$ y# D% |( V0 P$ x0 U/ m- \
# T& `' X- l- }& `2 V9 m
# @2 K; `3 p5 h$ C4 M. Z6 g
3 S( q- X, T0 F//Read Battery information from EC
+ Q/ P7 x4 W. w' e
5 J, s. W7 o9 s' Z* P$ `… …8 u" ^( }5 A! j2 [ I" O/ W; M
$ E3 k% C! f/ m% i* L& `
+ d- w1 ]# l+ V( ?1 s* C s, |
}7 H V% G' {* k/ e
6 `, {3 s7 |# D. M! K! }Store(0x0D, DBG8)0 L4 H# a7 b, v& C1 I. \: }
} a6 L; }) W% ~9 @" V( c0 b" S0 ^
那么问题好像是由读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所致。
& O. I; F% C0 h% k5 |' y那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
% l% W* N* q1 k( f8 ~' p8 \) E( x2 |( Y
, z5 J# z. v3 H而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.
" Z4 I5 ^0 N1 N5 C; M# Y8 r8 L
9 V' T- a; k. }7 W4 G# [* ^2 v. w$ }; T8 K8 q) T+ j$ Q
- \* h3 q- E$ E1 x* o! e6 T
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
. u- @" x* O4 S
+ Z. g$ t. n! J# s9 x5 i
9 j7 U: v: L; r- t4 t/ y" J: `) a/ i' F5 z( c+ T' L6 B
, U& s1 w; p: L, Q1 W' T8 r4 eThat’s all!8 p% a9 F* F9 N# G& y: ^( f$ \
' k. c e5 P- Y/ o' ^- j* W$ f O' yPeter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
