|
|
AC In/Out OS Slow Response
- Phenomenon N3 T$ `& p4 D( y v1 S, E$ C
) {4 U6 b$ Q" c+ |1 L' K) Y手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：* J3 y4 a. `) K: @/ B
- Why???
6 }5 ~- T( N0 {+ |$ _
0 I" \/ f t4 g3 v& L
, h! u' u9 I6 i- ]' r. u刚看到这条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 如下述所示：
0 L. H3 s2 D9 C// AC Change event
5 q8 ^9 V S* J; h
! M+ P" Y% u5 R2 h$ _2 gMethod(_QXX)9 N) E7 A0 D2 }
. h/ m; f9 Y6 F
{
+ _* g7 W( \- e {
* w3 t% V2 I( ]- h* ^' t8 M8 e/ `8 gStore(0x09, DBG8)* I" {7 u6 g- A/ N; v3 n
1 q3 z' e- h, L2 U9 `Notify(\_SB. ADP,0x80)
1 {% I8 r. F. [//Power Source status changed6 ~; J: @& ^: k6 @5 q
6 c m, I8 y/ f2 O3 bStore(0x0A, DBG8)" b5 d% p3 X1 W. Q4 d: I
( o5 w4 L, h: u) U2 ^) A/ g1 |6 r+ ?
}
8 v7 o) t& J/ R7 O$ P3 ~ ~0 E& }( P g1 T+ s& C
T. T- I! P: A$ b
4 U4 ~7 r6 t6 ?. CMethod(_PSR,0)
5 F) Q1 |! h% N: E; F* M3 K3 C0 I+ r& b5 j8 @6 H
" T' { Y7 f- g
{
[5 L. q+ ?, _2 D# C
V& ?' R# w; |- |( D8 R8 q2 u6 G- i
Store(0x0B, DBG8)) {0 s/ b4 z6 M, L/ x* o
) m8 ~% A$ B$ y! H9 E' F: M( `+ A. g" R
If(ACST)
; @& K9 z9 G+ R//check AC status
$ F6 e# Z/ X, q/ S, n" m; s
, x4 t3 E# @. G! D* J( r{
+ v0 X6 v3 L( J8 F: b: b5 t
6 H: o7 O! U1 e1 X& {7 z( x& o
v! |! T/ [+ r. G Mreturn(One)" u+ L9 y/ L0 W' H$ j
// AC Present6 t3 ~, e' I1 r
: }6 X- r( b- a1 i4 A
}
4 [2 G( R8 W& B& `. D+ E+ L
2 f5 f% [" F. N% X+ c' yelse
# a8 T9 N9 y3 r6 Q! T: y
' [/ t9 ^9 ~8 W l0 D8 d{0 S; s ?2 c4 w
; {; M" V' w2 K7 A" b: Breturn(Zero)2 Q F+ b) ~* \$ |2 j* j1 p. w6 O4 ?2 L
// AC Not Present1 [9 }8 h" I, p' S4 h
% g) V" K: }' D5 b: p
}& u$ D8 Z- f( k. i
" g: }5 ^* Y) z6 |
Store(0x0C, DBG8); y; A- ]: l) \* V
: H" J7 R) {" r8 {}
! U9 D) n; x) j% ^; F; U8 \! O# u0 m6 a' v& t: ^
8 ]! c/ Y2 K- U我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
# d0 T& @4 k% J3 q w状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：% U+ {& d6 E8 Z) M* F
Method(_BST)
: T, A4 i" c. ]& y{
' ^; r& c4 v$ t7 g- ~' P
3 T7 b7 Q8 d/ z: n9 f" jStore(BSTS,Local0)
6 j9 Z* }# \& F5 r1 p6 | H) [2 ~% b* d7 ?4 E5 `: T$ {8 ?9 X
) B1 a% e( C/ s0 c
If(LEqual(Local0,1)) //Check Battery Present Bit% C1 x) n# x! N4 t* F1 D u
! T; X2 M- |, {" K. s- k! G
{) ]5 Q# f8 g7 [" t/ W$ \5 X
2 n( }6 q. F" B4 @+ q& F9 V" W) H. l0 P& i: C8 o& o* I
- b; H7 F4 N) b, `" U: f) t4 x; q3 r* W
$ ^% G" s$ [8 O$ d. m) I, h* Q4 e/ {: `. M6 N. W* O; W( a- p
//Read Battery information from EC* M0 X. V" W& T) ]1 V- @2 I) c) O
* A2 x8 `3 j; W… …
8 H8 v7 ?1 f& a% J" h' p9 N0 z
2 j% Q3 u; K; \1 }
5 Z$ c6 S* P/ n- [- U/ ]$ I}" i m# J) W) P7 l! r4 {8 @) Y9 ~
) H! E0 D4 h# O8 R; ~" w6 W
Store(0x0D, DBG8)
4 `: ]6 \$ i+ R9 ?}
* c. c2 h% q0 T9 o$ y! q2 _) y那么问题好像是由读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所致。
" \' Y! Q% W7 a那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
! J! T: o0 h% V2 G+ Y7 \8 ~& l! e. f1 D
: }- p: A; P/ R而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.6 _/ @1 h& ~3 d O
5 q ], d( O: j9 |+ ?: |& s0 r5 a: d6 I! g$ C: H4 F
: S5 B3 v1 W+ }6 S
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！- d( J9 [( A6 ]
8 M: `# N! T0 E. \) z& T" g: o5 C
A2 [3 P% L5 R: z* y- w! l7 t# K) Q; p" ^( E+ L6 q( X& l- Y
! e7 |) U7 I, b
That’s all!1 `1 t. I0 Z4 L& |4 {
. R9 m+ k0 D- L W
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
