|
|
AC In/Out OS Slow Response
- Phenomenon. S6 d( T% Q* F {
5 c, t5 a5 _- j: v3 l
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分： U% n3 U9 ~, E) W0 `
- Why???2 _ d) P$ a9 Y7 v3 ?% W
, k0 S m. D+ I. \$ E, n
/ R2 A1 s, z; S/ {" U: 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 如下述所示：
4 g" u0 m& L8 N// AC Change event, C8 ]- I9 q0 g6 }) P5 _- b0 D2 }
. }% @- Z( R/ U; @/ }, ZMethod(_QXX)
! K; w. ^. [/ e& o
% V, G9 |( j6 T, m3 p" @' P{+ Y- p$ b+ z# P, Z. e& ^7 U1 l
$ r0 R, y6 s; ]1 s6 E& cStore(0x09, DBG8)7 b: x* x; G% [# C8 A5 ?8 j! S, u
1 W7 M% c8 A1 o- ^Notify(\_SB. ADP,0x80)! w) I/ e8 [% ?
//Power Source status changed
! ^9 a+ r3 ]3 @% g& K( j' c! B! ^
" d: }" z1 T; y0 ~3 eStore(0x0A, DBG8): }1 ~2 J6 k& g# N+ f0 h: c# |' p( R
$ u6 M' k Y! q5 m
; ]- g. d+ [0 C}; w U' s: W5 x- b+ G; j+ ~/ G! J# ?
( Z+ Y6 ^& {' u, T+ [7 P: ?- t, T
# R9 {0 ?9 B% c: ]+ K
) o, E5 b! D/ k( p% Y
Method(_PSR,0)
9 ]* @' k, f' S, x
9 ]) {) ?" i G# {! S4 j+ A' B7 m, B$ G
{
& _ S5 U7 w2 w A& m! e: A, R5 Z% e
4 C- B8 ?( [& a! w0 I" g( @3 O7 W8 _) `% C: g2 ]
Store(0x0B, DBG8)( S+ O! z- k2 |8 u+ r" r
' J( O! }# Q$ y7 V9 h. f
# g' t% |( g- W+ k" Z# ^2 a
If(ACST)
( d! J3 I3 }7 S7 ~. e+ |8 v& ]/ o; e//check AC status) t N' q% q' @9 a o5 G- j
9 p9 w. J. Z% f# n
{. i8 Z* ~: T* S
5 z% f/ O' b) f+ m
+ m A/ V- ^9 K( V0 D qreturn(One)
# Q$ Q9 p ^! c0 @8 h. v8 a* j& z// AC Present
# Z9 R0 I- D$ j% ?" @2 W% ]" |$ ?1 p2 T/ @. ~
}4 D# ]1 @4 W5 H2 @' i4 k" Q
, }" B \) Q8 |2 c+ q
else/ N# }( _! U/ T1 |2 m
4 d! u/ O: T z1 n3 A5 _7 c- C{" X- d8 @& E6 d
0 c3 J, U9 L g
return(Zero)
3 h% H9 {0 E- u; M, `! C# o// AC Not Present/ F1 F6 P1 h' S/ V, x3 A
+ e2 r+ `- G% C- v2 r
}
* K( V6 }+ J0 a7 H4 d }; R& _7 I5 r* F% |8 B4 S
Store(0x0C, DBG8)
8 Y8 Z5 L' q) M/ n, S- d) C
" u4 p% x$ y$ x+ s, b9 h}
a8 M6 {; u- A4 t* Y# a: I# j* @" H- R' F* ?
; n( U# ]0 ^, h/ g- X' }我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
3 w+ W6 N6 x( L状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：- y& M" Y+ a7 p5 P& v
Method(_BST)
; `! v) P5 O& X3 {; a; V1 o7 T: ]{ c! ~" O9 k% _( L2 h( H8 n1 v& h
* D" @6 r G! |: ~# aStore(BSTS,Local0)
+ }0 |# a+ u, c5 M) D" y9 X% S( L
" v. B1 l7 c/ z. M9 W; f% {4 n `+ k( ?& A% `% Q
If(LEqual(Local0,1)) //Check Battery Present Bit
* i4 w# ~5 G2 H; H, m# Q" S/ X! W- h O1 @; x3 X9 U
{
" i6 _% s" t- P) v6 n+ _: l7 \3 u" k* ^9 K, o7 N8 s
$ e$ s6 w! u% {+ I
2 C4 D* v* S( |# Q: v7 Z4 x; p4 m6 C( [+ ?2 Z1 I
# H) @" k+ U% }
//Read Battery information from EC
, V9 M+ N' v* k+ J. Z: O& F$ o
5 f8 s" c, L, C' q% \" C7 C… …
" d9 u7 t3 b% r. J" U, K5 ?7 v) V4 A; B
" N6 ]6 g( Y2 R8 e' s _5 ?}
! M7 o& W. C; m! ?' a% F6 h7 F
, A- ?: C: ?- [% uStore(0x0D, DBG8)5 a( b4 b$ l7 ^7 p
}
! Q! ], b" ~" e2 P" w6 N3 t那么问题好像是由读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所致。5 X0 K. w' t; }
那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：/ n1 P& U& a( z2 l& A
/ ~4 t0 A0 [8 n5 _2 ~. s
- M' }1 T2 `& W) [( z! K
而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.4 G) }5 k0 T J3 o$ e
+ u/ u: _7 S" q/ @) N3 k' B& F8 s/ O2 ]3 L1 Q
7 X" {! d. ]# G6 X6 K经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
" [3 p6 |8 v) }8 M) E+ @' e5 d7 P9 V( ?+ N9 v1 F1 ^
" l9 e# `( c; }7 e4 l: q( @
) \( h% q. y3 j 9 n( Z3 A) M0 Z# B+ ^5 Y" [4 y
That’s all!; E9 p* t# A3 _3 @2 `% K9 y9 v
- B9 G4 P/ a$ ^& F$ k
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
