|
|
AC In/Out OS Slow Response
- Phenomenon/ K; A& V9 I( }/ ], v2 Q$ |% O
3 s% ]' F, A% y3 R! B
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
0 h$ T4 [3 U4 b0 D0 T' o8 l- Why???
' y! H. a ?- |& r1 O+ b$ }
) ?9 k+ l) G, g0 n `
* {5 A) D s2 I& u2 [: Y3 r刚看到这条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 如下述所示：" {, L5 i# o; \
// AC Change event
: N: \% X: g6 [8 f: _4 n1 }6 k
6 w# m G; O9 oMethod(_QXX)! C8 d: u% }. m V
) P |# B8 }5 S{7 `: |& y: j ~( v
# p2 x. T2 }* H1 q2 D% TStore(0x09, DBG8)
2 M/ d0 J" z: {3 I( N: k$ [, u1 Q
Notify(\_SB. ADP,0x80)
, A2 Q+ j" z& r, U: O//Power Source status changed5 S& h/ e& w4 {8 W# Q8 I! }0 b9 h1 ?
/ o" r" I' ]" }, [" t$ cStore(0x0A, DBG8)# O; r" ^- G" j( G- m& w8 I
|# H: P! }% r! J, P/ O( U
' F" ~1 ~- ?! ~" h; G# x}6 p. P; H8 H- p1 l) Q# }5 K
) U( [; M. L: e
+ ~! ^ D8 \# `# d1 S' V P1 o. T0 y
Method(_PSR,0)
* B4 ^+ M( W$ d, [
^2 E7 q* V+ ~" |% m3 i$ \+ V( R# a( v$ h' D" Z5 y5 r1 H% S* |
{
0 j, L6 l! ~/ }$ }, ^. `; M6 f0 r6 V( U- {2 t" Z. g- K2 c
0 u/ N9 ^4 Y7 q; GStore(0x0B, DBG8)9 L0 T9 a. E0 f x7 C
) T, k( H3 I1 m0 E' I
$ y; H# Z/ ^$ L- V$ K" q lIf(ACST)2 [+ F4 Z( C( R; z' [/ V
//check AC status3 f k* g3 h% T# N1 r* [/ p. c
3 o4 {, Y8 [7 y% o( A$ x$ h& ?{* V" c& g; f4 M& n$ O$ i
5 M5 X3 }# o8 }& j' P1 T: B- Z
return(One)
. E4 a# |- G: F4 E// AC Present; x+ O5 Y% C# b; e& T
8 l/ i5 c9 r" L0 \}/ ]! N* e( b$ _2 D( e2 y4 K
5 [' {) `' T1 [! o# [else
; }) a& N8 B# P9 R7 @/ c& E, G/ d! w" C1 j3 t, c
{0 r" _! k7 S: A
" O" H0 r# W2 K3 B6 o9 P% i ?return(Zero)
: n9 G1 t! u5 r: B// AC Not Present
8 @# W# f8 ^& V( \. H1 \; Q% w; a
}1 `% W) }% I& L
' H9 W R: E! X+ r: IStore(0x0C, DBG8)8 U# l8 K: U8 S: u# g8 Y
* g7 ~7 k/ u. s/ R
}
" P ~+ P) Z7 p
# J5 W! T" j& ` a/ u2 l# H- k
- L P1 l- `; y2 J. ]* g我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
+ L: P0 X" {3 [. ^- x& e( z6 c状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：2 i$ ^/ l4 o. z$ B/ _
Method(_BST), D. d4 e) u6 C
{
; O% \# L* d) A% x5 M% K$ \7 u3 p0 o/ d& }
Store(BSTS,Local0)' y b4 n; V0 ^9 O
! W, T0 H" j# P, q6 P: E6 ?' C* t p) F" C! \. A( V6 I
If(LEqual(Local0,1)) //Check Battery Present Bit4 D3 `4 _+ K+ e2 _
: V: z& G, o( ^{
, v5 v9 D8 y; e
1 b K2 }, r; ~
% c8 A1 ^ h4 y! S2 z* V( R/ v' z! W" g$ c$ F7 j
2 ^. b" i4 P, w" b: V
, @$ J; Y4 t4 j3 Y; U5 R
//Read Battery information from EC
: p7 R5 Q7 C K0 y! R7 |
4 G, @, R' Y( C… …
4 W/ Q+ R) r4 W! [$ w; W1 c; i% O3 l" ]
+ ]6 Z V. R! K: r6 }+ k
}; N0 |/ V- Q; T/ H1 i7 h( W
, |+ K' r1 R7 @ r; H7 m$ YStore(0x0D, DBG8)( D& N3 t7 L; |6 T' `
}
8 d, f1 I/ s- t+ k那么问题好像是由读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所致。
7 V+ f3 K- }; p$ l* ]( k0 [那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
/ o" e9 j* ^% [& E" U; K+ d
- w+ ?- b/ d/ W+ ?4 O% K
4 S8 \5 `8 a. j2 I( ^+ S, _2 j. N; t/ \而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.6 ~% Y3 _# m3 y. m2 U5 V1 u
4 y! c4 L1 G* r' C& j5 M2 Y8 j+ Q
4 U- u9 S9 t9 }# w W6 o
! ^6 c* t$ N) v ~5 V2 K t2 B
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
! w3 w/ k1 X, L& R2 }
5 m4 N b, }1 h
+ s9 V9 X/ ]% f* n( G) h( T" M/ Z3 h1 |; G: a% v& z
: j) }: q4 q4 O1 y+ k* A d x4 _& CThat’s all!9 B+ Y2 ~; a0 C2 @: @
( Q) p0 C, ]4 u9 F6 L5 e# `' T) bPeter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
