|
|
AC In/Out OS Slow Response
- G4 c4 W0 K) m1 w0 v% Y$ r- Phenomenon& R3 L8 i7 i8 I4 j3 ^
5 c$ {; ?) F7 r0 r手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：1 m$ Y1 U2 E2 a
- Why???) Q' ?+ Q) G6 k* M/ F/ n+ w
' @8 D/ s/ t. t
) E0 ]( N) ~% X; x: g b刚看到这条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 如下述所示：
& N. X3 ~ `7 D// AC Change event
/ _' x f. A" {8 n# a" o0 I' U) H6 k, s6 k( [
Method(_QXX)* [$ F' v' @2 ]! w- K
* {& |$ n. Z; \% _5 U7 U4 l{) W0 Q$ q L/ @- n2 m1 z' `
2 f- o9 m7 |2 }1 F* u1 Q" ^( q
Store(0x09, DBG8)
5 `7 E& w; j8 P8 f; b1 O
* j, K4 M$ _& `Notify(\_SB. ADP,0x80)& [4 l# v0 ~, ]) ~+ T
//Power Source status changed
8 P4 Y6 z v. o# N; o( ~) B0 p$ Z7 t6 l4 y$ o! C; G
Store(0x0A, DBG8); d7 y! i: |7 v7 z
' i' [3 X/ P0 |# ^4 G
" V/ Y. g; X1 f" e2 N0 x. q! w}6 J# j% g3 }2 c5 r$ y, `
; p T* t" ` B8 l2 f; L5 T6 \$ D# B1 G: R& E# J4 z
" q5 |! r( X0 V7 N1 i/ ?; p% ~, g+ z
Method(_PSR,0)7 w* Y: ^0 U1 D
, W5 B" s4 s- j! o# y; T
/ A. w* C( q7 w. S t4 h7 x
{
3 C) O w( d$ E8 W( m' f: l( }) Z6 C& w% H" w( ~/ g: J
b7 S6 j' M" y8 S' @Store(0x0B, DBG8)
/ m ?$ G; z5 A* y D( Z
% ^* ]+ _6 j( P# v1 R( N
& w! i3 ?* R0 O4 [% hIf(ACST)
4 U* \4 a& y) f. Q8 t//check AC status+ I D# v! Z, |& f& s0 `% l
0 O2 ^& k& P+ i# r5 g
{6 [! J* [( k# f8 R
$ x7 K/ k3 m) c1 T
$ ^" n. b0 v- z! E L+ b) f1 K/ H
return(One)$ F1 F' v4 N. w
// AC Present
}; ^4 L7 O( L0 a
: z* B {6 {. c1 c, A}
! @/ U0 P6 Q, b6 u3 L4 q& q4 e. S- S" B/ U& x$ a+ T
else$ r: P. H7 ^: U: F0 f. D
& G: v+ e; h1 v# c
{
. }) ~2 o- t% R& G5 H6 w/ G: x9 w2 P+ b. s: j
return(Zero)
/ H% R: |# l) {6 @+ e+ a3 Z* T// AC Not Present
7 @- i6 d* n3 Q& R1 T4 I3 z1 r# i$ e, t2 @- o2 G6 e9 B
} l; p- b9 t" Q" E
8 T" y5 }; W: Q% K4 P( SStore(0x0C, DBG8)3 S$ f1 h5 x0 J" W# x. s
6 w$ q G0 H- r3 G
}
3 a* O, P( j' V; [7 `0 E
4 j0 a0 D4 P9 `( C5 V2 D# J/ m3 |( s" K
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。& b! G5 b' p! _. A! ]
状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
\( t5 P' C0 F OMethod(_BST). i# N) y$ {' H
{
1 f) d& n4 a$ c: F) B( ~9 r0 r/ l/ u H, v+ L+ P" y( U
Store(BSTS,Local0)1 v# x9 q. y: {3 t5 ~ W. c( V6 r# e
# L0 P9 _: s9 ~9 P/ F
2 K9 W" C! ]/ r2 K2 wIf(LEqual(Local0,1)) //Check Battery Present Bit9 f3 ^, p: @3 I+ x) S$ `. Q8 b
% i- T5 X% y9 R% z2 X
{1 b4 v, t1 B# m t3 W3 T' x
! C2 c" b4 {, f+ Z1 A' N
% G- U; r8 z2 [% T: I% L( }+ x0 c, s* ~4 M5 r
; z% T- {+ F0 z
/ p' g* p! s7 X
//Read Battery information from EC* I6 }$ {# W( L. m/ ]
& |2 @9 A+ u( }) Q3 m0 |+ C… …4 K% I7 C! a( [- E6 E, z1 k
% w) I& \: \2 k- [: \ f
4 T' z$ h9 F5 p4 S7 b2 s! {
}
7 E' ?* e% @6 c( C$ [* D& j5 D* v; w) I! A( x
Store(0x0D, DBG8); M& X" V. z7 c) g- `4 b
} 8 a- ]! h6 p+ `( {2 H
那么问题好像是由读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所致。
% a0 H" d. M% p" s那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：' U3 {9 N6 J; {! r. m: }+ l# J
. h( d: k! y& z& G# k% a/ A' u* s4 n7 o5 s& h" D$ ?3 h( f
而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.
: q- h6 n" \0 a& S
- C+ u7 h2 l2 X! J- t
6 T0 y6 j ^7 L9 }' v; L2 |5 Q* W' h z4 u; @
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！; g: k& U: z* G2 \5 D8 J0 n/ ?" R
0 l! o9 S# l% U+ \) f
4 F" }: H0 G. r/ Z# {* u' ]# h1 I
& I, [+ x# }' v% {
0 Z1 q4 A$ h8 A( H: \4 u; VThat’s all!
; y; n' r* F# q4 V: U1 c* z
0 Z+ V) z7 `' H: f" y$ v* FPeter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
