|
|
AC In/Out OS Slow Response
- Phenomenon, M% [$ C A6 P5 k/ K$ ?
$ O: I( k9 o$ `7 i
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
, k. G0 o' Z- U" e& f0 [- Why???
5 V/ t4 B7 M$ C# b- p, |" ~
" e8 A+ r; r5 W5 H, _0 Q+ R
9 i" {6 q+ { o* U8 J. |
刚看到这条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 如下述所示：
2 e% g& c( T8 S5 U8 F// AC Change event) C; \6 Q2 R! ?2 ^ P$ g( v
4 h+ m8 K8 s% [Method(_QXX)
! f, y3 a+ l' A$ o0 @$ x' R: A: |9 h$ \( v
v" m: v5 ?; E# b{- b( m% b6 A( v
5 W& X& r7 c* i7 k/ P d
Store(0x09, DBG8)( d* Y2 H8 b7 \6 t& P' d. R
6 R# b- h' ^) C2 m5 q! s. p: ?# h5 d
Notify(\_SB. ADP,0x80)* s: P0 {5 t' C K! H
//Power Source status changed
9 ~7 J# V3 W- v( _9 C! G) P$ W! u2 N! ]$ O) E* B
Store(0x0A, DBG8)
! r+ c( J# W/ w9 I! C+ ^ 8 ~; f7 K1 D2 {' h: P
& N2 s+ @6 [6 E7 ~1 O3 l* F3 L
}
# g, Y7 b1 J2 g. N+ o- d9 h% J" @$ K7 A& d: j$ m& {$ y1 j
( ^; n; A6 X/ i$ O4 ^$ h+ y0 Y; i( k1 @
Method(_PSR,0)+ g& P/ ^' Z7 O3 V: F' M- k
; o% ~7 n! Z, f8 O/ ]% i
: z# `0 q5 z( z0 j1 D{
9 U7 R( Z* K `
9 J5 H8 p8 E; @2 x" `8 N5 w
t* P/ o4 U6 J o* G$ DStore(0x0B, DBG8)9 P& Q( G; R6 n! W, G" J, `7 Z
3 U, l7 ~* V6 l' V/ l6 D
; d% A$ v0 }( \0 [If(ACST)! h# |! q& D* @; {( s
//check AC status
5 l. u$ W, z8 P+ _5 f; s) v t, M6 M
{2 z5 @! T6 M: r
5 w! q/ T4 f8 B" c
' h5 R) ~* p- Zreturn(One)# W; d& |: ?$ x/ g
// AC Present
8 ^9 q& T7 I. |& l0 F6 |
$ }! X, b( w2 @9 U3 i9 [% F}6 D0 |6 ]9 b) p. Q9 [0 \$ @
* L# x% O3 u" @9 D
else
2 L |( o) \: J$ d6 e, U4 d4 ~ v& D d
{
* I/ \3 r+ U- z' S) r2 C$ B& T; M* l$ S* l& @
return(Zero)
0 f& d* h+ }$ C1 B' a* Q! R// AC Not Present: x( n$ m a# p: b* @8 S3 f; p9 J6 K% J
~( [/ W0 f) l; X( Q2 i
}
( L) |2 A' l! a( ~4 T7 c# k$ g
& J: y' H3 f- R$ p" FStore(0x0C, DBG8)
# y1 \9 `' A4 U* j4 O
9 e6 @8 c8 X b6 Q3 L: _}. L; J2 K' O( L4 W8 W
& j* f0 L; F. w/ J3 i5 r) h: a; V# J" L3 N# Q$ B
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
0 s* X! w7 P) D3 x, f, A状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示： f/ c/ [0 v. Z7 n; ~) H0 K
Method(_BST) u& S5 L& J1 l6 k1 S( x: @0 y
{6 L# q6 C3 L9 e' ^: T$ x$ C& e
! K3 d$ g$ R6 @( @Store(BSTS,Local0)
6 k; E$ g2 m `) H1 V& N8 j# f
! M; a( R: U7 C5 a* M- }3 R. p- B1 G( X6 h
If(LEqual(Local0,1)) //Check Battery Present Bit' o# a+ x$ f! {
8 `" G2 T3 A& `. q
{
* R7 U! J. n' G% c9 c$ o( q, Q D! C4 O( s+ s" i% B! R8 L
' H& u: e/ {& u; U% x+ e% X
! q- ]& ^1 p7 F6 `" l- r" L5 z
0 H3 V3 Y* S. c8 X9 K$ ?- U* l$ R
3 B5 y1 R2 \' r: T//Read Battery information from EC
3 |7 k7 I) }8 @
: U7 a) j1 f, a2 \8 H) K' o* T( q… …4 j5 V7 X+ r2 }" w
Y+ E3 I3 t8 T9 l# A% N+ ?3 K
$ a0 J6 Z. N2 H/ E! T1 f}
& J% ]$ y/ q6 j9 F
1 G6 E% ?/ y! N% {) Z* N; K. b5 m) H' wStore(0x0D, DBG8)
2 k: g! x9 v L2 k+ q0 m" V}
, D9 b; ^+ I) ~, Y. d/ P那么问题好像是由读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所致。
* B5 U! a2 e) y4 z( B: g那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：8 c! o `6 L3 Q& C' @
6 A: P5 F2 J5 i% v: F5 F) a% ~ Q4 z' z7 _; h- h1 ~
而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.
' D. I I4 |% O% @
Q. U3 D6 K/ c* m/ H! Z- u1 c7 g& a$ b! H" {& x
+ w; q- H6 v% C" v
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
! K6 Y; t- H1 U# E* p
" L3 y! p, p- o& {# N
; Y$ H# U: C f4 D! Q8 c+ Z
, }+ ~5 G! e+ m) U m Z; i- |4 N+ p8 e S9 U3 z# v- p
That’s all!; g9 {! g t8 U0 }# T9 W/ ]1 F5 _# j
+ o9 F" N3 d9 z5 `4 M
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
