|
|
AC In/Out OS Slow Response
( x0 M4 G: u( X+ ]9 v- Phenomenon
. Y; x' P: k- ?' [( Z8 v" e3 z
( }) B: c2 |4 E( @
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
2 ?+ U# r5 d/ F+ v2 E$ v- q$ H! I0 d- Why???& E$ y; W; A8 [3 C$ t0 q7 b
% x- Q1 M* Q) n. c, K0 o* o( J
3 I5 y6 x Y- Y: z刚看到这条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 如下述所示：5 O7 a, @9 ?" x ^" q$ D
// AC Change event. B; Q! }4 z; N: g J* n3 S* d& A
9 \7 |: ~& J% G6 `1 D fMethod(_QXX)
7 y2 ~+ j7 V( l3 R( L! W5 E9 L: \/ I/ M; B' T: ^+ L
{
1 \; c1 q9 a' Z* e+ g$ o7 K6 {$ V `( k' m0 A
Store(0x09, DBG8)0 A: I: n- S* q& K1 F# ^& E
) L4 p: M8 ^' Q, _2 ^" w, U- uNotify(\_SB. ADP,0x80)
|8 ?! z0 X' \! R//Power Source status changed
( i. E' h/ n2 F& h: }; I0 |4 n' Y4 l0 {
Store(0x0A, DBG8)
! ^; e3 r" j' J9 `7 q; O+ z6 X
# r& l3 k# T8 Z9 J5 O F+ e& S7 T' c. E- F/ n& ]# r# r! y
}: Q0 C' k9 {- y' i$ v& z+ B
! v5 L1 L$ I, R0 { J2 L, [: H6 \8 X. A5 S9 n5 H. r
* E P' ?0 T8 l- `& p C3 RMethod(_PSR,0)# }, e- O! h4 E
' L5 w& Z+ N# q2 I# i9 I
, q- v& o1 ]+ D! P{, Q/ {4 D* L" Y# A! w7 P k# X
" n7 T' o( t! y6 w5 K6 W" ^3 m; O+ c% ~9 q9 \$ s3 k: Y R* w
Store(0x0B, DBG8)( k" s1 B6 {7 S* L( g
: ~. b- S6 z9 q- @
1 r$ h+ E5 m7 r; bIf(ACST)- J8 z# O6 I: ^$ j8 n3 V
//check AC status4 t4 x: i5 |1 z6 Y5 R0 y
' W- ~4 {4 }- [ h0 I. M! w- _{/ e* _; x, p4 I( R' ?2 d
. k0 _8 ?* s+ X P- j& V
5 }- m! r: W$ I1 K; Greturn(One)0 V% ?, p7 q! Y$ x- O! W4 y
// AC Present
) w3 `. k$ B5 O+ Z9 @
" ~# r& ^ J H& }! r+ r4 @}
6 ^9 S) D+ K% F/ b% G& [3 }2 q$ L1 O
else; H9 D5 f1 Q; y; k! Q
+ s6 ^& O) T( R ^
{* J' _" t: ]9 v' u- _( l& B
& I" i& r3 S1 [" b8 T5 ~return(Zero), Y' e5 k" \7 T, F( B3 j1 R
// AC Not Present/ v" j" V9 H7 v6 C
9 u8 h1 E& I* F: ^$ W3 _
}0 t1 U& A* } y8 o2 V
: N$ H: Z: r1 l' a- o" \' p. h5 A8 B: PStore(0x0C, DBG8)
0 x$ a$ Y0 E6 |( `7 N3 \ k. a2 _" e! D" M
}
+ c: D5 T8 F7 \$ i' Y3 r5 q
1 U+ S, P8 H# x8 E! o* u U
- m8 K2 t% Y' f7 T" n1 {1 a. M我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
& _* r4 r: C: g5 u1 ^- v状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：+ E9 D$ @$ V l; Z8 r/ a
Method(_BST) J% A1 l) N( y$ a8 U- L S F
{" Q& S/ ?1 U4 N) E
9 {- S, {( h2 Q! |0 J X
Store(BSTS,Local0)
1 ^ x% {2 E5 {4 r9 h4 Y. y* t2 F
1 n& ^) y: V/ O! A' g# h4 `' F* h! H
If(LEqual(Local0,1)) //Check Battery Present Bit& M' T8 E& W* Q3 t; d4 i6 Y, z
* d4 H" Q6 j0 ]) w4 F{
1 s& z) O* a4 K1 y" k
3 U. e, H( ^% `, j: M* }
! t f ~, i4 h& m/ W4 b
& U! r7 `1 ?$ [, H. S/ D! @' [' t' s5 J7 r7 p; [2 ^6 Y4 f
5 l' u' @" {* {
//Read Battery information from EC
0 b6 v3 M- Y% u& L& Q/ f# Q# N: u9 |7 J7 I# Q* p
… …2 b8 I( V) A% S9 @% M- O+ n! ?0 o
5 S( p( U* G' q1 e0 x2 n) F
# G7 ^8 v" S9 Z% x4 R" H}& _* o! b5 l' i+ g
& V& T( f, @- I& e+ r' O1 yStore(0x0D, DBG8)0 V$ K2 o( z1 u, b7 e% K9 v
}
4 r. B9 u, T) @. t \那么问题好像是由读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所致。: v* [0 s( [& q: q+ ]2 \( B3 l
那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
4 Y) k' | ?8 e. D3 v) V" V3 }8 R3 f) R* [* _ s. U0 K
4 V, v9 a a. L1 m而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.
: E' D& K" j# k9 ? / u3 ~. @( d& w' j! ~
) G9 H/ x& J3 t3 I3 F- ]
0 F ^& z- u; R: N
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
% }" p7 z" J( I: f. O$ s$ }
# A' A- `7 W! `$ D4 ~9 [& J2 Q# a H, ]5 h4 K& k
6 H: `8 u2 g) a v' `5 r ( F" r) `+ f) q: w5 H1 g3 S
That’s all!
) o, _) i, p/ U" i1 x1 U 8 ^! @" o" i! T3 I x* X
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
