|
|
AC In/Out OS Slow Response
; y& F4 C# d+ G- Phenomenon, I v1 o- T! t$ \$ S) H/ A. O/ d
" E6 _4 Z, m5 |0 B+ z- o5 C' l
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：3 y/ E( o+ J, Z$ l
- Why???' g. K3 {2 r4 S( \$ V& U
; ]: a- N; T% A$ L9 S1 }8 o# V- `# H5 g1 q6 [) g. n; H, 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 如下述所示：
( z$ H z8 Y8 Q// AC Change event4 ]- L- d! b0 i7 c
9 h( N" k# q, k- e- u, [. k
Method(_QXX)
5 x4 u. ~: g# [0 D: Q( @
8 C) `3 s8 C8 J" U2 i" Q* ~{2 q; g+ W; |# u( Z
2 R1 \7 u2 q, x/ ], R% @$ {9 }Store(0x09, DBG8)6 D1 |$ [2 D. ^- M. e
k/ z) @& m0 [' h) h* _
Notify(\_SB. ADP,0x80)
0 n/ h. x7 }/ _5 f! o; [& h//Power Source status changed& w% e# W% U5 o& r& n( r) r
' h8 r0 s$ L* G% m5 |9 EStore(0x0A, DBG8)
1 @/ u9 X. Y1 D' e, E3 o
: N. M# x# ?& i9 o/ a" q" k- N+ U( f( w1 V2 F
}% [9 E' O3 V7 M$ h
0 l; g# [; B# P; @) e1 G8 ~
1 q# ~5 M$ h) H$ @# U7 G/ A9 g+ n6 w+ z1 h
Method(_PSR,0)
3 Q0 F$ m1 F6 W- Y8 D. S! G. R5 T8 |/ l9 a
3 E% \9 S( e6 z" F: r{
( m8 J/ t! |+ y+ p
( C9 n z; J9 V0 V2 n) R0 G I' J/ Q6 c* S' y$ {. `% }3 e
Store(0x0B, DBG8)% @" o( e1 m* ]( r6 L. f
' ^% Y# K6 m1 i$ e5 s
' P! r* E, j% a ?6 T* ZIf(ACST)
8 M3 o; ~6 l9 x- R C//check AC status3 w2 \7 g2 o1 b1 e( W; r2 @
: b: n8 r- L6 s{; e; V- A; R# T! N% S
8 d3 e, Y2 e, I! b' L+ C; X
& b, s* B5 d" T) m, @' Zreturn(One)
; \" R' [, L, I8 K4 H// AC Present2 N5 N6 p0 A2 q2 q
- h+ [) u! e' P}
, _& Y( o: c( v1 v& N ^: e( [ y. h# E% D
else: I8 O: C6 V# c
4 m# i& y8 i% g, R. s0 e" b
{3 e; |* X2 r0 g i
$ S' e7 L& H2 k. Q* U( k& Z- p
return(Zero)
, S z' _( |9 P6 L// AC Not Present
# E8 I: a6 c! Z/ U0 f+ h5 s! W4 M, g' I- y" @
}2 }$ z- K/ M- Z- U) m
( _3 N2 l/ u; k
Store(0x0C, DBG8)" f( U7 e5 P4 w! C- ]% M% v! I
1 A) N4 m a* r# q
}3 }3 B# p# ~+ p& p3 n& E8 `
; C9 N K, U, I' H
, L" A6 c4 p. l/ w' {8 O, j" R E我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
& X, ?! z5 d4 ^: \( M# l# j状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
6 R' B4 c* H6 i& w/ RMethod(_BST)
* s [3 {: L9 n: u{
9 S9 s' g5 u/ G9 M7 C& n) E6 n3 d+ ], k+ e# K) a
Store(BSTS,Local0) ]+ {8 P! L2 `1 h& s# A
6 w C7 B, l f* g9 X) n* I9 T
) |' Z% e1 c) i' S- F+ O
If(LEqual(Local0,1)) //Check Battery Present Bit
8 S4 k U% s1 `" |' x$ [1 J8 Y5 A& X8 v) P
{
% X- k, @* f0 X5 @+ k2 Q( R' D$ B3 P* l, e( s3 V+ o9 [) T3 ^) j
3 n; u9 l1 V9 H
/ t! o) o' Z+ v! }9 k) G% d. C# K& n k X
9 i. i2 F; M7 k9 `
//Read Battery information from EC0 \% F& O' S8 p: `$ o+ {
' V" h' U+ @9 _! l5 a
… …
2 @6 j, b- J) X- T1 D- u% {5 f/ k) X' j5 H
2 D9 E! h5 {1 s2 } y8 i X}
6 S' e1 k" G' I! ?- \! h; Q# w% w% S C7 O) U4 z
Store(0x0D, DBG8)- c5 M4 B3 ?' n* z1 f
}
. y. s0 z# U9 F; G& h) 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所致。
# O. M# q0 t) z- L3 U7 f: c0 f那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：1 m$ R6 A' } J2 b9 @1 b: e; K5 ^! {/ L
3 O6 E' j- |2 B
$ K$ y9 K4 t8 l' s4 l' r8 m/ 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.
- [+ a( v9 V. t; D* j) k0 O" I
7 `* u7 N5 a5 }, y" W* o3 Z
% ?0 N3 j: d/ v, r$ c; r5 e
0 [& }, n# O" v2 q% m2 C经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！; h1 i, a( Y$ H0 Q) x( M. j
8 ~+ z, P7 |' l) U5 k9 d
- [1 b; K# d7 a& O" P$ f
8 D5 j+ N! ^3 I* g0 f/ M7 t8 l
4 |7 J" M. n$ p" D; e- qThat’s all!5 t x& _: n" [4 S+ f
' J: r5 t( G0 g& [3 wPeter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
