|
|
AC In/Out OS Slow Response
3 q6 d( R' h5 Q! n- Phenomenon5 I+ \; B4 K% ^6 T. n4 s6 X7 r
- h, G3 f( i; V0 c4 e0 }手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
5 ?4 g6 F* |& U: ^$ F# c9 d$ p* {- Why???
8 x6 j* n2 V' O$ ~% x2 B
; [4 l, y5 t$ E* Q6 c$ H" Y4 m
+ ?$ |# ~" |) r# ^" }4 }
刚看到这条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 如下述所示：
; X; [: t" W8 w3 v// AC Change event Z3 `+ X) Y6 H3 B% n
" e: \8 x h0 X* X7 H, W
Method(_QXX)
3 o3 A! P, p; V/ O9 C1 {+ }0 t1 S1 i+ [5 r0 g
{
5 ]" j4 |9 }3 h; r# N
, o N2 P5 w" D8 vStore(0x09, DBG8)
G3 d/ u8 ~$ Z! v
4 W$ ?/ B8 Z. k% H: B8 KNotify(\_SB. ADP,0x80)
$ H- F& `: r% W0 U//Power Source status changed
6 d+ u8 \1 u5 h+ o: ?! V8 O
& U* c) i- Y# AStore(0x0A, DBG8)
. }: F" T) i/ T" M
+ r, _/ a5 |7 o/ P2 W- U
9 ~3 Q; [) z; Q1 @# b. C ~' E}. T h+ r, g+ V6 D4 n' }. q
; Y3 b; N/ P5 {4 E3 t6 ~
1 o8 p* t5 v) ]
Q8 m# n6 v; Y# EMethod(_PSR,0)
1 `* T, D# n0 U2 c9 T! p4 a
7 i" \# _- C- Q/ D4 @2 Z! L. ?, R5 W1 g2 E5 i" x6 }
{$ N0 }3 k" c) w# ]; [5 [4 T
7 d7 h5 c$ ?& A! J8 ]+ _- @0 A3 W5 ?5 [1 ?
Store(0x0B, DBG8): y( g6 v& B( _% }: @+ ~
; C8 m W! X: r! T8 g* T2 w) {8 g ^& m$ X+ E, v
If(ACST)$ a% b- F' J* {! I
//check AC status/ A! n; l7 {7 d7 o
! U8 l, i( I7 e A' t{" h& v' U0 A- T) H0 C( H9 K
0 O% }1 X" Y7 |8 i8 c( D2 r; k
6 `7 s$ c4 j9 ?: T7 h9 ?return(One)( T1 U2 E1 _/ p; M
// AC Present/ b8 i- t' `' O5 ?0 `) T% `( `5 T
6 j: y8 {+ Q& D! i* e8 O/ N8 r
}4 |/ [/ m2 ~( t. f- h3 g) g9 W) |
- |& Z8 o1 F' E+ }" `' O6 G! Selse4 Z3 L* q! t# U% @+ z
! \$ m1 N8 K0 l0 @4 i {
{5 J, {9 d6 w- s0 L" @7 `3 ~, I
; `/ \2 U1 L8 i- E4 k% e, jreturn(Zero) X; @4 m0 ?, O
// AC Not Present$ V+ ?- ?' b" m$ Q9 F
6 t0 f; F' K$ n}5 R+ m: }; [; r9 Q3 e/ c
+ {$ |. W/ S _/ AStore(0x0C, DBG8)
* s* ^, v( A& b, u; q u9 N" t
' d$ v9 k5 R6 R" \/ E' V}
0 q1 Y1 C+ d% v5 q4 C0 y V' j
# M1 O! x9 p9 M* Q7 s2 X5 {6 D5 R+ B+ _2 }5 _9 I
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
) `, x: _3 _) R W7 b b状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：" e T7 c, z2 V( d* B
Method(_BST)! y& L6 i' [* w6 u
{, G( @# K" H7 }( i8 G) S, C( C! _
* \, D* c6 Q+ c4 @6 D4 R
Store(BSTS,Local0)6 w% C% |+ w+ V
' ?- e, |( ^ ]
7 u; P v( n2 g4 E6 o* _& ]- f
If(LEqual(Local0,1)) //Check Battery Present Bit" Q" z5 C( ^: [+ N/ I1 s
/ C- A7 _) h- e0 P$ o9 _! U% _9 D
{ `# a/ l+ z# V. W( X
1 o" C' _. r+ y/ W) Z1 ~
- {7 U, s R0 i/ }2 h& U
7 O/ ^2 u3 Y6 K/ L1 A6 q
; F! \2 f! r4 Y8 v+ L
6 d1 d/ T6 ^: G1 e4 |8 G//Read Battery information from EC
- w% A/ y+ u9 b: ^! v# }' h5 ?3 b3 e9 i" q# E1 O9 ~$ D
… …, Q$ U J1 Q1 t$ I
$ q0 d. o; O2 o7 Q5 d; Q6 T8 y6 h: M: z
}
. }* U" K, {4 s2 }: b1 T/ \- \( t2 a
: j4 x8 e! J8 D5 I+ v; {4 a3 MStore(0x0D, DBG8)
! n3 P: k* G" H1 s! [. H}
0 W$ V" j( ~+ N% G' J那么问题好像是由读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所致。
& z* f/ j2 y4 g' E" n: Z5 R6 q+ A那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
) _: n0 {- k1 \* b1 C- f7 M2 e# k; |. H9 p' V/ ?0 e
9 P0 p* r; d; z& r% ?. c( M" O而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.
5 e: m& _ Q3 `
9 v2 s" T/ t) x( ~
$ [+ z" f$ F* h5 |
9 a \% }' T+ b经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
% D; D, y' E/ g) O/ u2 L! a
% S. k. e& ?& S+ U+ i: V; J7 }5 ]2 v+ x/ H' K
9 c: n, v4 X1 i$ G# N
3 O5 o8 Z; q: }+ M" w8 o3 {/ kThat’s all!) W# ]: j4 f. l, x8 t( A& _
: W* ^. V T7 E) R- k
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
