|
|
AC In/Out OS Slow Response
3 w' W- F6 p8 G0 }4 ~- Phenomenon$ W$ P4 ?4 H2 Y7 Q6 E
9 O) h/ Q" l' r m' S# l0 e
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：' A) A/ \9 V6 t- L5 i
- Why???
6 u' Q5 l5 I* S' _+ c- c
3 ~4 X) q0 [) j* {, R0 E3 ^7 ]) { v1 r
刚看到这条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 如下述所示： p3 j8 \) f8 A9 L( T- X% ^$ o
// AC Change event9 k( p. ^3 b, u! p! W3 @5 m
9 O8 C/ `) a+ Q: Y2 Q$ qMethod(_QXX)1 @9 d$ R. K6 }5 N
. r/ @4 O$ Q0 a2 L7 s( F{
' `1 |1 H1 C4 j7 _( d& P: z/ g! | o# f7 L0 A" T
Store(0x09, DBG8)
5 g9 U" S# C. K) d; S
; ]; k" Q$ ?" o1 o+ k0 aNotify(\_SB. ADP,0x80)
+ ?1 H* j' Q3 j, r. y9 j//Power Source status changed
% L/ W0 w2 x' |8 n5 {
. B3 _1 y$ d) @5 t) YStore(0x0A, DBG8)
# z5 {& n4 ^, F; S! [8 Q* J
+ b0 @( x/ L% B+ ~' q0 m$ o% F$ b: @) k& p F7 N0 R+ I1 Z
}3 x1 Z4 G) @) G9 b% [4 F9 a9 ]7 a% [
0 }' q" F" A8 F0 \& R; N2 w
0 {, G6 |1 \% d
$ k' i" M! y9 F: U! A
Method(_PSR,0)8 K( q+ X( c) {
+ E( X- V" X1 j* ]" c
+ k9 K1 v+ z' G# U8 X0 C( _) ^5 B5 l
{
( M3 k/ F9 w' l* U- ~ B7 [! U
O3 f* b/ Z( a/ c
, y1 G* X# u+ _4 d- _) u. v3 K! w' QStore(0x0B, DBG8)
# N1 T' ]" q. c' _8 \1 `6 n. `( R/ H$ E
7 ~0 h# U; U# U9 f& j! v' e
If(ACST)& v3 g9 |% A$ }, Z/ [, T
//check AC status
/ Q& L, C* G# \4 |6 R: o. z+ f( j7 b- V- C: s5 e
{ {% U" D3 T; S0 F
s+ U3 `2 X0 I
: k1 O7 }) Z( Y( W
return(One)
2 v$ B1 h- ]4 ^6 O5 w: L// AC Present
9 G5 T' e) M# L6 ]
; A. z5 ]3 ?! h2 r( S}
; r7 u, V$ ]( s; r/ k" }+ @7 f! N' o y! {
else
8 M9 Y4 J: f4 h. `' [6 e/ b6 F7 M$ C$ Y$ {* w
{
) X. t. O0 T0 G; w. J. [4 L* h) H* Q2 \
return(Zero)
4 _+ ?1 g4 }7 {" }) Q' z: Y2 g" f- ]// AC Not Present* W; P& \( j: T5 q9 R3 ` R
5 S7 ]/ S# [" G
}6 X+ a1 U# o3 n& r4 ~6 U9 l8 n6 M
( w9 g) e4 Y9 @- P
Store(0x0C, DBG8)
6 h/ a$ o- w( e. \# b2 _# j( y, U- l( X9 g5 G3 a8 l5 a# Y
}( G# |* _& j2 [ j; X
R( b0 @9 M3 N1 X& G
) G# [5 @! m- o8 V我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
/ X0 a+ w6 [7 n/ B' m状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：7 {: m K+ J; @6 t2 l1 A
Method(_BST)4 G$ M1 o+ }! X
{$ T }/ D1 b( J+ a
8 p1 T% Z8 f+ f( q
Store(BSTS,Local0)
" r" |) e0 @2 k( T8 G: r$ z' }# x9 c! {0 O
/ f, x3 w# v. T @7 @( f; a
If(LEqual(Local0,1)) //Check Battery Present Bit. b& v* p- F8 S K) }! y0 M) }
' D; {" B# h9 A$ e* M0 b7 B& i+ d, G
{
" j# _1 B/ x$ ]/ n' ?9 u
0 V7 @! l0 I; S' n$ Z3 ?' c8 s1 w
+ d# N- u# m' f1 ^3 s3 J) O8 ~" M
# W) E% r5 D0 j: S. b
//Read Battery information from EC
, ]2 M/ }' w0 E
* E5 ^4 J/ Y/ K" O… …0 D# x2 s* o$ D1 J1 f
+ g1 o* T! E( n" s
: C" Z2 P6 v' t' \}
% c( [0 _0 W& R/ _ Y; f* A
1 j' W$ Y( }/ a8 Y( uStore(0x0D, DBG8)' w$ K) I4 v# i* L5 [1 i$ \ ~
}
7 J: b) w2 C1 e那么问题好像是由读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所致。
2 f" w; j5 k6 `1 c那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：$ v" ]; S* S. ~. U5 _ p
2 {( J: f8 R; [) I6 B6 q$ I
( p+ ~, Y; X) v5 v; V而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.
) n% n2 o# I5 j0 |
( N& y/ g/ A2 B5 L1 w
! I2 }5 h* O2 R/ v( N2 R2 L* w7 L2 X; e/ x1 h6 w( K. Y: F
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！% ]% `4 z# l) l m: W5 G7 Y
8 K, R8 V$ a+ f* u% N% P
: X- u6 d' p, F! E0 c- L) Q- y
% ^8 f9 P. S" ?' G' ^! D7 j + t- K s' s& W( c
That’s all!
6 s4 _5 Y$ M) F# ` ?3 v
5 U6 X7 k- O6 X+ `3 iPeter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
