|
|
AC In/Out OS Slow Response
0 T' F# X, a" e2 Y! t0 R- Phenomenon
: P) ~$ ^. r2 Q, {, Z3 g3 T
8 Z& ~- k) U$ E! F4 F5 \, p手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
+ D- p3 o3 _2 S( S+ x- Why???
, ^6 C1 s) G7 d8 K1 f0 m, ^
" D# A0 B3 _' E- m' v! |8 \& t' r( _. Q9 S! L8 k
刚看到这条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 如下述所示：9 L7 X3 V. Q8 s: M0 q% {! j
// AC Change event& x$ \/ ?/ v: C; L. U+ @
. F/ o' X1 ^5 ?4 j6 `9 g8 {, Y
Method(_QXX)% H+ y! ~. f8 W* l- a7 D. B
& X7 m; _/ y7 Q% R6 n) Q
{
* b0 O5 D/ R5 |- k1 a: ?3 y _) G0 F; P$ r
Store(0x09, DBG8)! |5 b* V# b' k4 r3 V: l, N
: _3 x& s/ a3 q; W: V
Notify(\_SB. ADP,0x80), y1 W0 b1 F. s; C6 `1 }( a3 A
//Power Source status changed
1 G; N; [- T' w
" S& B3 U, ?/ ^( L6 l) gStore(0x0A, DBG8)
, o7 B+ i) `" ] D, W
# f W+ a: I: P
8 i0 ^6 O J; N- \}
( w- Z3 l9 j! F4 a F
3 v+ `3 [& G( c. W( A4 \/ J) x' @* L
H" n* w; A0 @8 p
Method(_PSR,0)8 I/ T1 W. O! y2 u7 J3 _
3 O) a' P+ W( t( g' r0 Z& }
6 {, Z `$ ]/ W+ ]( k{3 w8 K4 \* z' q4 C, J7 u$ ]
* o+ c; H7 G$ w- a" A
! z+ D. ^* D" D8 O2 [Store(0x0B, DBG8)/ k! @& }$ H, D
0 O) R |$ K; K2 G! G5 ^! f" A7 d3 S5 M- a, `* e9 `
If(ACST)
( f& t, X: q9 O, x- k( O//check AC status
6 L+ f1 z1 Q2 G
$ j7 X: F3 A+ a/ v{& U- D" Z M* Q. Z. E0 v1 }$ {
7 p( n- d- A; g! D! Q& _! U" z& o
return(One)
1 F% B" m3 E" T- i3 V// AC Present, y1 E' x0 \1 p: e) `' {2 A
0 J% P* c4 k2 ?1 |: l" M}
7 B) Y F& V9 U x# ?" [
! {) U* S/ R J- j. [8 a% H" Z6 ^+ ~# Nelse% m7 f+ \8 T2 d5 ]) Q5 t& ?
. G/ P$ h- x$ E( P1 U' |( v
{
. O/ v( P: Q1 J% h( I" y, X. l8 i. y6 V
return(Zero)% E& i7 H5 L+ a! b, l. h( @" o
// AC Not Present3 X& O. k r8 i+ w, }
* U1 b/ k7 \- Z
}3 n5 ~' _' q# \ @
. \6 r E. G! FStore(0x0C, DBG8)/ a7 n& W {7 @; {7 ?
9 L B$ W/ U) ]+ H# g. ]$ X/ }+ i3 y}1 j' t+ W6 `& m" U% z
3 v& @% n F& y6 \8 }9 U4 j/ \1 w) U% s
) [ o9 {7 v4 U3 R. W; i我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
+ w% k, B8 @8 R) N+ ^状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：6 F" R0 z! |9 G- k
Method(_BST)
/ ^1 j. ]% H/ T& d' w B+ Z{
6 E/ F0 E- j( O- F. P. F) v( X( y- l- h% d
Store(BSTS,Local0)1 ?* b6 W" S/ g# u! [
+ S) F' b9 e4 G# n! c3 M5 d8 s! X$ Z$ b
If(LEqual(Local0,1)) //Check Battery Present Bit! ~: M8 Z! @8 [. j
5 w4 |' x! z, Z1 b! r
{( J. g# C' a* H) H
+ Y6 P6 N1 h4 V
2 y q. }0 W2 M/ n" g/ T8 V. P/ Z
) A8 k: b' f# C* g7 G$ v5 q
7 b$ P" @: j: b7 q: |
# Q' q- h1 ?- b+ _
//Read Battery information from EC/ f. l; d2 y$ m+ J1 B
7 M+ L1 a9 q; }% d; F… …
& m$ ^, ?. r5 ?: b W$ r' X. t% v# E. q
! J! u1 L7 _ J9 d* ?5 r0 O& S
}
7 j) B8 A# b2 _6 h+ }* e$ }# W& v3 l
Store(0x0D, DBG8)& u% F! } K: G6 x7 O5 n0 T4 F
} . d/ t9 l# K* I5 \
那么问题好像是由读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所致。3 a) U* r+ B- P4 h( R6 f6 L/ V
那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
8 x9 v) g! d/ b5 t+ {1 i
H/ d7 U2 O1 F
- {/ X& e% S, Z4 `1 c而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. i% W; |+ W5 e0 U
5 U6 ^) v" l. T. [/ O( V" }9 w4 K& V1 r& q, E) h8 m
- G' j2 y6 `, |* m3 y0 b( D
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
) Y9 j/ t/ ?* |* c9 S+ S0 P- n: U0 E( `: K
: A$ E7 u: `0 s6 J2 p5 u$ e
9 }! w$ F4 K$ p4 |
) q) i- W/ a p8 A* gThat’s all!
4 _9 D/ F$ |* G / a5 A4 e' x; q: D" p
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
