|
|
AC In/Out OS Slow Response & e* P+ r8 F, X* Q, G
- Phenomenon( U3 ?0 N% N, s( j, i4 e
2 v0 E/ @3 E: J0 w+ `- L: a# Y手上一个超薄NB的案子DQA报了这样一条bug:频繁的插拔AC,vista右下角的power icon有时反应很慢,AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分:
- X/ {* |& n0 x6 V: @: W( d- Why???
. ^$ r( ~& |# Q7 t
& f7 ?) u) i" _/ ^7 }0 R8 M: s
% P) R0 y/ A6 A* |, O5 _/ 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 如下述所示:0 x7 K' V3 z S; Z- `
// AC Change event
9 E! F: r, Z2 |4 H; f: l6 i
A& z! p: B; ]0 dMethod(_QXX)8 A A1 M6 p# l. Y" S" ^ R
( |2 F) I+ L$ }1 n5 G9 @3 q) @ R{
2 J7 ^3 i2 y/ v, B
! c* T" F: c' D. ~7 VStore(0x09, DBG8)
! `( y3 t4 Y6 W9 R4 Q( Q: ]6 n" u* @% w9 j* {2 \
Notify(\_SB. ADP,0x80)$ f% r9 Z0 S7 J/ K+ t1 k
//Power Source status changed
# ~ K& X* C0 k* g, P
* L0 }3 r0 r! TStore(0x0A, DBG8)% [, d( ^) |- J7 I# x9 C- A
8 o0 E; j8 y" q% K- R! _) }+ e( l7 ^8 W* `9 T" h. o
}
8 R& L( V. d, ~0 q5 Y' [, g- V( b! Z. Y. T
# i8 O1 ~* [6 {" M
) i$ {1 u. ?* e- w6 JMethod(_PSR,0)
; [5 [! v" v3 a9 F, D. i# b, c& D8 A7 ?
9 D+ d+ Q, T i. T5 z4 _8 f
{
% s' @5 u% O. V: n" f }9 W3 J/ Y" [) r) i3 [% y i. Q
+ X& E) c" m4 x c& gStore(0x0B, DBG8)
5 M+ n: c0 n ]! S! z2 `0 X
0 ~. F; m2 `- D7 P! {& r# Z9 G
( n. P8 e6 m: ]If(ACST)
+ h7 Y5 ~- v; ? e! \//check AC status
5 J* x, m+ g9 ?3 |& A
% d& e) [2 j% ?+ { [4 k3 A{
" ]5 x0 j- L2 }. ^, ^- l4 j
& i+ o- @1 |8 E+ S4 c6 ?' [
6 g2 S# F+ t8 T! d- ^7 b! greturn(One)# f/ p3 J( p2 h; b2 m) v, L5 Z1 q
// AC Present2 R* c6 ?3 y( `2 A* b
+ [& N* Q: Z, z! _3 U& g0 ]5 Q6 F8 n
}) f. Q/ n7 d4 x5 w( H2 n, F1 s
. q! P0 G! X. j8 c9 ^+ f0 y: E; celse: w5 x( B% o6 `, |4 x7 f
0 [0 }; [4 i1 i) X
{
! W6 v8 q% f4 o2 E7 X3 b+ K2 D
7 |8 M7 p) L b$ V* Hreturn(Zero); U' F) t2 x' _; c
// AC Not Present
. r! I9 Q: F' [; u9 E/ G% D& i
8 ~, B n$ Y p2 u/ \0 i}
I9 f$ ]' O$ O( N! n: V7 \! O) w; P# R! L0 y
Store(0x0C, DBG8)" u+ o: q; g6 {; q& m7 t: N
2 E7 \0 l G7 x$ y
}6 \- {: ?# A- G) v7 G. ^+ ]
7 |6 H' p5 W0 _ R- I* @- ~
3 @0 {7 p( H8 o4 ~! H$ j我能猜到的大概的流程应该就是这样了。那我们就从头开始追,先在AC change qevent中抛点,可是发现AC change对应的_Q method反应很快,一旦AC in/out debug card马上就会有显示。那么说明什么呢?跟EC没有关系吗?接着抛,又发现有时停在’0x0A’比较久才会出现,有时’0x0C’比较久。
3 k! i1 r" v1 Z& f9 R+ C- J. D; P状况不太一致;没感觉就把网撒大点,在几乎所有的ACPI method中都抛上点然后再try,试了几个回合以后有感觉了,我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高,也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息,sample code如下所示:# G; q( ~6 b3 a2 i7 K, K9 W5 D: G
Method(_BST)
* S7 Z7 A& ^) v2 Y; B{
1 N; ~) o w! k7 p$ m `9 B' K) k! v" N. I8 V0 U8 X
Store(BSTS,Local0)
$ u+ G( {* T% o; |' l& x2 Z' p. b+ I, d9 k0 r+ A9 ^- w f
( r1 }' X( Y# O7 U5 F; ]' a
If(LEqual(Local0,1)) //Check Battery Present Bit
& K+ [0 b* C0 }. U8 c2 p' n8 s- K2 q; @. Q
{3 z* n3 @: g$ Y: A# C- O
- t& H( S3 z# k+ _8 s+ {& [7 x
1 L" u3 G8 s7 f. }: A* {. m5 d6 ~
4 R1 g! S j4 ?9 P/ a2 R
# q. @$ P- i0 {+ o- ^/ f# _' _, T8 a* x9 u1 h
//Read Battery information from EC
) N% t0 U `, s) v, p2 M2 r9 m/ \2 c/ H
… …
1 w2 t) R: A* ?7 G: y% ]8 I4 A& t' y% H
/ v6 ] b# x" z
}: i5 q. y. _* Z3 \7 h8 q4 W. f1 t
& s, N& C: O( U) u" j3 Y" R0 j0 qStore(0x0D, DBG8)
/ ]2 w. c5 }. `& y4 ?9 Z7 y} " P. E( A$ o/ Y$ O
那么问题好像是由读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所致。& Y4 \9 B: B: K- ~9 W& `$ K0 E
那么SCI中断机制是怎样的呢?EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger,而且L的时间通常设置成64us,如下图2所示:7 ~5 [- A8 }5 v5 u
6 |& _: }4 [1 J: [
3 D% [" C7 [ {; `2 {0 K3 f而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 o8 `# v: |* K
6 T1 X0 w0 C f4 W2 S, l2 x/ u& \) g0 F: p# [1 y
. _1 P4 a8 G, w" l
经过上面的分析,大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width,将保持低电平的时间调短,这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节,并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论,更不能想当然,正确的态度是不放过任何蛛丝马迹,大胆假设多方求证!2 w6 h1 z/ {8 X) B% h, w2 i+ l" }3 `' \
- |8 w: K) j! D) z
, h% y, \& W4 V. q/ V% N# d! @% S6 D* j& ?
1 @* Y/ o0 u, I% h3 g" B( v3 R$ _$ wThat’s all!4 a2 S0 _6 ^# K9 b: i% Z
8 f) }4 G" ^$ G2 `: L5 C4 r. B/ \" \, IPeter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?加入计匠网
×
|