|
|
AC In/Out OS Slow Response
- Phenomenon
5 w1 x" A. U% k5 p( z
1 |* }# Y2 o# a3 \. A# c2 {手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：1 U) V! b+ Q2 H# a
- Why???
8 M: `5 \/ s( H6 W
- n9 s+ N8 Z$ b$ u, _
; g R' e4 i* G9 _: L
刚看到这条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' {+ w0 [1 d2 T# U// AC Change event2 h0 b j% Z8 P
7 O7 Y3 y5 u) B. W% I; u) H- z7 Y# pMethod(_QXX)
$ v$ f6 P: \4 Z7 j& q$ P" A& n$ ]$ h
- S- V" C8 b, U5 z1 H{
) g' }9 Q' g! N) r0 H8 N% k
5 V+ n* @& O6 G& {+ N! x( LStore(0x09, DBG8)
; [6 t: x! V6 a5 [5 L) z3 ^
, @, S: u; E' G- G( Z ~5 kNotify(\_SB. ADP,0x80)( K' a u* w1 D- G+ ]8 T
//Power Source status changed
+ u" t5 s+ n% ~# O) f9 U6 i* r. ~. D% \, C% u6 }
Store(0x0A, DBG8)+ F8 M; f6 G& v: a! W
9 C( ?5 h' \2 p" T! i; i0 P5 _4 \! g& ^$ F2 K( Q
}* p9 D G* R+ A1 @9 \
1 _$ |& c& [& }' U+ T' m: H) w' e
7 w) X8 P# p+ l" `: N/ s$ o$ y
8 B9 E$ U5 i2 ^Method(_PSR,0)
% ~* X2 F; ~% W6 f( x
X6 D d: T5 h5 Z6 i+ B6 p3 v5 n0 ?- `1 @" \5 [5 K P
{% `- n r. F/ g% ^, j" F
/ }' L# u: B) S: U
. C( A1 P1 w/ n& a0 f
Store(0x0B, DBG8)
) o+ z& t& [# t e
! m; {8 X: h1 l5 z0 K) @1 E* {. I6 e/ ~$ L
If(ACST)4 T& P5 \; ]. k" ~/ B3 @4 m% T; ?0 h
//check AC status9 l& u; {1 g- z6 L! M3 ?- A8 U
% e5 |/ W' m+ |$ M" h% i) e
{ }0 I R& M3 j
# t; u# r' L! q8 f. W& n
. Z: `" W) m& I; y8 {% @3 E
return(One)
; }8 T, y) u1 s7 e// AC Present$ ~5 Q9 D4 I ]) g
! z; y; l# {. X1 `7 L4 ~2 y' D
}' _1 Z$ x9 j; ^: M# o
2 j6 j8 |8 X1 h1 R4 L6 f5 Q" g* C8 i
else7 d- X' D* W- e' e9 i
( ~# V! q. |2 I, I% d! {4 ^{1 v( V+ ]+ H2 }1 W% v6 P$ a7 Z
1 H) h* s( Z$ w6 U3 [return(Zero)
$ |. Y" @' r7 V0 r// AC Not Present e1 z/ m- x6 h' F; h
2 Y% ]/ f3 A* L5 y. R6 y}9 N# G4 F; G0 S H$ O2 Q
. N% A5 l& D0 J V% }, Z3 |
Store(0x0C, DBG8)
& X$ e9 U* U9 m8 P: [* M. W
9 s* ^; a; }% _7 Q. W2 U7 k8 I}3 w. D# o6 A) }. X/ K1 I
2 `9 W% h. v2 R6 S2 j9 I$ Q3 |$ p" O$ t& `
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
G1 L( H5 ^- i* }- f: \9 k' K状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
4 c# q' h! [. T8 V* W2 b XMethod(_BST)( g- N* G8 M" u+ { e9 I& j
{$ l: \' _. f9 ^+ l. E
% V' X% ^0 J0 ?) T
Store(BSTS,Local0)! `) p7 { D: N, C) ]5 V1 h& b- q" _
9 E" A7 b; N9 G
% R- u0 K9 a2 D, f
If(LEqual(Local0,1)) //Check Battery Present Bit
( a: u7 Y+ F0 f5 V3 P, j; K: k+ Z- `% ~0 I( [" t) a
{6 g( ~) ]* Q. K9 m' O$ e2 c9 X- O& `/ i
% `# S \# i% I3 b3 L9 ]
, ~ K: B: i2 C* E& q3 r
5 ^* C3 X- q/ d" E$ J% ?) I1 U) P h
k& T- ]6 l' A9 O% u Q" D
//Read Battery information from EC
q! K# q8 u9 j$ g8 [: E6 ?+ V2 X J' I9 E- a6 h
… …; \( k# T7 D. K" L" w
) m# J( Y6 z) p2 \
! z# O' I# B; j
}' D. N) h$ \1 y0 I
# q8 c/ C2 H8 P% u0 z5 Q1 M
Store(0x0D, DBG8)7 D. y$ D! P& q/ t" |0 @1 Y2 C
} ; r4 u- N- E; J* 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所致。
& C" u7 ]# i# s那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
8 T5 r: I8 ?8 N p4 I; G$ D
4 e$ {2 z- ^* f2 X l4 w
7 g) J# j4 V @ N: T a而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.+ v; j! V1 H, B6 F% w& p
w2 e/ v, T2 Q8 U' ^2 M& G2 ?+ }& z
. _% z+ X) ~ C* z& A
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！' n: W$ i& O) l
( Z& P5 V. V Z8 E
$ M! b+ _' h+ T2 j4 Y9 x9 E( U& a
( W1 R7 \ g1 R3 t 1 g$ v4 ?+ Q) M) F0 o! h
That’s all!
& |5 o. i- M0 l* {: y: r * H) G0 F6 F$ I/ [' G8 N2 t
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
