|
|
AC In/Out OS Slow Response
- Phenomenon8 M* O: R, o0 W" q& i; W! C
1 g9 Z g0 P( p2 B5 m1 Y( N# Z手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
* N/ d7 Y0 ^; f$ W2 [: I( A- Why???- t3 a- F" {0 Z, h9 }% D
6 F) `; K+ e+ d/ G! R
( `5 T7 c+ u( n! Q$ M
刚看到这条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 如下述所示：5 J5 X: n( j0 Q H# E5 Q
// AC Change event
9 _! k8 m; L# Y% E9 O2 X# D7 M8 ]
1 c2 W& @& u' j! HMethod(_QXX)
+ W# j& F) s$ Y/ z! n* R& A4 g$ a3 [1 q3 \$ ]9 ~' |
{
; {8 j3 v. k$ q$ J" F$ I; ]1 H! b8 b' Q2 j. ?( Q$ e' Y' B$ D; l
Store(0x09, DBG8)4 S! K/ C# q) f% h$ b& o* f
4 R# n p" n* qNotify(\_SB. ADP,0x80)
9 C" F U- T% B1 s//Power Source status changed( z) Z$ [* D3 E: I
8 V, Q5 p7 I7 R1 l jStore(0x0A, DBG8)" g6 e, v1 z* C5 N* h
/ _9 ?! J$ r4 N; _8 s8 G6 h$ [/ c& w
1 H/ E/ M, o, U: I- B}- a" }9 F% E5 g8 T) ^
7 C4 u' {/ Y. k$ v, `
. z( K! {& ^! g3 I+ p
/ K$ U5 r& S: `( v. i9 m8 lMethod(_PSR,0)
+ o- g$ s p- t: H) y& u& R5 Y2 Q2 R6 K4 Z: J
* L) V6 H \; {! ` _{; I& \6 ], y9 x: T/ i$ b1 Q
' k+ v4 X. x/ @ N8 J9 j, P
5 K. ^: j/ E( g( {& e
Store(0x0B, DBG8)
8 F! c6 L$ n1 C# [9 Y; v; K K& r/ z) m: U5 p# E1 p1 M
0 g" C; W5 {( \% l9 F) [8 C+ v
If(ACST)
( t& M* i4 Z: F2 t( Q* _' m//check AC status* D0 ]5 W8 w6 M& M& `+ Q) y
: k' a( z; D/ p: N$ c" s
{
# L) @8 w& i2 y: h6 ]" D8 J; s" l, Z+ N
; T* G9 g2 E" Nreturn(One)
1 E) p5 V& I" g( x6 H// AC Present
/ i* _8 ]5 |, M* ^& E
# c4 a( {% Q5 t( U1 t* y$ i}# ?: v* w5 S* G4 H" U
' |5 r L9 m! O0 ]) y6 y1 S
else
( l' i+ i8 p- G: w+ S* Q
3 f" J: ^. r, t1 G{+ |' r' {/ D# s% {1 C
* A9 o! [9 r$ [# v6 o9 X
return(Zero)
p7 c% R; t, T// AC Not Present
. A }7 g" J+ C1 L
! Y+ d& h' U3 p6 l1 N}
' I D6 D) O) ^1 f$ X) r' A! h. F" `3 L P& @5 D# Q
Store(0x0C, DBG8)
! d, x+ v1 |: v& l0 I O
5 e2 a0 |0 u5 d, ?6 n- T# i- ~. h4 T}/ B' L3 R. Q6 |
# T3 ]% r/ A8 d4 Y; k: f" V" M
. w# A& i, D& y7 `. l" L3 Z) D我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。3 g. x. V- x+ ~0 K
状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
/ L& B [3 W# D$ [# mMethod(_BST)
) {- D0 h3 I6 @) w* {6 c% }: a6 e{
+ R5 B$ G5 [6 B* l9 l3 v! d) _5 n1 Q/ S6 F; J; L
Store(BSTS,Local0)" P8 k; x: R* p% ]: X9 L. k* \
% T* G4 O* B5 V+ B$ G
6 S3 Y+ k/ V& ], f( X
If(LEqual(Local0,1)) //Check Battery Present Bit
2 Y" W2 Y! M4 C; R, O5 u8 V# c. c, S+ w8 H* c) Y
{
" p7 m" ]& l2 u9 Y2 k/ u* [, L
8 I# I5 w) d- {, |) E+ j
( a: d: Z7 e8 ?8 E, Z5 d$ E. ~. k3 `; V7 d9 z, x
6 N( D" T, @1 R7 | w2 y
+ S0 j3 V I0 o
//Read Battery information from EC
5 v. `( z# r! @
% N& v3 `9 {) x* {2 x4 L… …
: t& B3 H" f; g8 o& H) P( z3 i. j8 b3 g- H$ h; T+ U
; O# b) U; ^9 F! ^3 Y}
" R( ^* ^8 N D0 \
) G! o1 L, T' f7 f' ~Store(0x0D, DBG8). A v) E2 R2 R
} , O" t! Z, h! C% W
那么问题好像是由读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所致。
}2 R1 \; ?- g% ~) v9 n( f那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：$ S% [7 R/ T6 H7 [- v
# d; V' m9 u0 M7 D4 W/ V n1 T
9 @, B' T E8 k& Y: L( D# w
而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# z4 q8 b: x7 I1 t: s + Z. e0 \6 X2 {: _& s" o7 K
0 A6 C8 _/ U! w0 E$ K6 _ A
D" B9 y n8 }$ f% g! ^- _经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！' A5 y5 G" j2 J& m& w
6 a* B$ h8 l1 x+ v
) U. G9 v( N7 U" i! r' T/ n- R" N) V; `+ I+ F6 R/ e
) z4 e: A" `6 i: ]/ {- z, Q
That’s all!3 c' m- j8 t$ q* O+ T. H" m' r j
0 Q' B6 X' g7 o, R7 w
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
