|
|
AC In/Out OS Slow Response
! m V; i% z `" b- Phenomenon
4 F$ n* s8 T v9 |5 j
8 D* C2 I; A, Z2 G0 _! W4 X
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：" k$ r0 h% P/ B; G
- Why???7 Q' c$ k% D+ e7 N; W- }$ a' V
: o5 }, A) `2 O+ V6 \$ ^& E
; N% {9 r0 q) Q7 z( r. X3 k
刚看到这条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 如下述所示：, b4 B* y# K0 t% b% T( I3 N" v
// AC Change event3 Y% E2 t; s' s5 I1 S# }
, O1 _3 \* A B- T( H7 PMethod(_QXX)
7 y' O8 r5 {* W" B9 m) i) K3 u1 ?0 p) V# l( z- |
{
, M8 z! \/ z& U- Q, o. I- L% p$ ~8 U! {7 p2 ?+ v
Store(0x09, DBG8)$ M, r. D+ r# x& {: Z9 {0 t
! k% \# ~0 r# V4 ]9 p I3 q% CNotify(\_SB. ADP,0x80)3 y6 l$ {4 M: l% m0 m7 F& i( Z
//Power Source status changed& J5 d& l6 a; Z
: t+ w2 v2 A8 t. n! k
Store(0x0A, DBG8)$ Z. W2 f. G3 |( I4 g- N
7 a- k9 M. Y. F& Z4 e: t0 ~
1 |2 V- A. b- o/ p) _# o5 ?8 t" ~} n. r7 S2 ~% Y" ]) T4 j- F Z) c
5 ~* [$ w, Y4 S& U0 J
, s9 R: ~' W7 {9 m1 h1 f- C- P3 W2 B0 z8 D3 m4 c
Method(_PSR,0)
% n+ |. V1 }; O* @/ y" J) e1 C: q+ _7 | ]
9 B$ P% c' m" E! q) ~{
& y7 g& U/ ~6 L$ G) g: }6 J' v W6 l
3 G- _" r3 G" L5 b$ ~, X: L1 A, O
Store(0x0B, DBG8)
% `$ i* n" E7 D% \# Q: f2 ?8 F6 t$ J# l. H3 E: \
% }, |0 L; O) f; E( n7 p! [If(ACST)
- ^" F+ G$ s0 B% }" v8 m. j% Y//check AC status. i- l3 ^' x; l' z1 [8 @8 M: L
, g; \% ]9 Z. `
{
$ a; |# \% w( \4 z1 v* ~* w$ f9 S) I2 N' r w4 `! F
7 g& g8 y7 M7 a1 U- g* Y
return(One)
) P! u$ a% x# @0 U// AC Present
" U; E7 ?( `( m, C( S
& G. D- s: o+ ^0 \6 A}
t) t# V0 ?, q5 d9 x `3 n
" ^: t, G5 d" A8 D9 Ielse4 G6 i9 n# t- v) p
! n- x/ c0 \9 T" i7 r/ z1 {! O# g{
, G$ { i. ]6 {& f9 D5 R2 P" p u- x. i: \+ S1 [5 S
return(Zero)& `' {/ C8 X3 [, b; e9 D$ i1 N
// AC Not Present1 \( |% A' U( j
- B+ k h4 V O; N6 o} D, b" O- J, i% O
( @: P7 D8 {4 ]* v: a
Store(0x0C, DBG8)8 A4 ^- X- x" [3 ~9 g, I3 M
7 A6 y) W8 ?4 G$ o: X- j* _}; T. Q6 y- ^' L: r& m" C4 h+ K8 r1 u
/ |, ^& P' v* l: v; Z. x% k2 J0 h# f# K% a6 Z. ?
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。( N! z# p+ `3 ?- M- D
状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
% F! Z& I* {+ o i- ]" j/ F' \Method(_BST)
8 S5 v# T8 c3 w4 }2 E6 M/ @3 z{. j. D$ d+ b% b2 z6 H" h# C
' m' h7 [7 [: h; b1 n
Store(BSTS,Local0)
+ m# H' d" o6 F; ^ D x9 R/ u1 }* s E
3 Y0 ^. O3 v5 {/ g. B+ |+ R
# |' F, e! X; J9 p1 RIf(LEqual(Local0,1)) //Check Battery Present Bit" b7 d+ x$ _" @
/ ^" b# F8 S$ C5 n# M2 V+ s
{
U T7 E6 K; S" y' \& U, L5 s9 C; e6 B' }/ R
; q& a9 K' l' L( k5 p! Y7 w0 Y& |) \: C% q& h' [
- L+ S4 Q; N! L, D/ @1 ^ ?9 t9 |: O) }) k2 Z7 @
//Read Battery information from EC2 u) S: r, R3 m" W3 `5 Y# B
& {( g! d: b, A
… …
X8 d1 z* m0 O; P6 P7 i. T
! M) M# m3 H6 z% Y n4 e* w* S! l- X8 t
}
- H2 [9 M Z/ S0 y. ]& Q! i. a6 l0 _4 W0 W$ q+ E
Store(0x0D, DBG8)
+ h$ m! M! b/ R8 e0 C3 Y/ x}
* O$ J7 ^3 G; \* s那么问题好像是由读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所致。
E4 L& u# o+ J W- m3 w那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
c, M8 ?# F3 M* T4 B
- L, w, d3 w$ W9 u. h5 R* ?5 h& r& @& Z
而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.
/ \* Z! V4 p5 M - [ \0 P$ F' g: N$ f7 `& R
9 \ n) S: L, ?- Y* A
& U, L4 h' K" b2 T; d: a4 n经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
; |& M7 v2 G& W3 L3 m! J: e/ D: R; i, k2 {* T6 I
2 o5 M) _7 |1 H. v: G4 F7 H# K8 ^; j4 B. F1 v
6 K. K i9 i) W# A" s" l
That’s all!
5 @- U; P" g r0 \
1 a) }0 M2 \5 |3 ^Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
