|
|
AC In/Out OS Slow Response
) L0 {8 Z. ?9 U- Phenomenon5 f$ z# m, P8 Y, x
$ v) |4 ?& M, Z1 S4 [- g手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
. D: A& y* Y! m6 | ~- Why???
( T" i$ R5 Q: ^' f: U2 ^
4 W8 L" Z; P. ^/ U$ k( {
# E: T9 ~. X% D' 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 如下述所示：
1 L, [* }% Q6 V6 q/ ^! l. y: P. Y// AC Change event
$ W6 `, \! F. l, r; ^, A) e! Z# o3 }0 R) e
Method(_QXX)% q3 P2 S" X5 b3 m
1 [$ |; J, ^! _( R{9 \, K- J) w" m* A7 O8 `$ i J
9 q0 s/ Y$ a6 w) y" s5 yStore(0x09, DBG8). }! A# C7 [, m+ u1 c
- {' n" ]. n& j: N5 n
Notify(\_SB. ADP,0x80)
9 f3 y) j% d: P: m//Power Source status changed) \8 T5 f) P. d+ d. H9 r
+ m% D: B+ A$ C$ i0 T
Store(0x0A, DBG8); @9 l$ _' X. P5 Q4 n l2 I
( n( _8 p& @5 g- W) G# i, c9 R
. w/ o# o. Y6 k9 q) Z# J1 g% r* D
}
+ H5 B7 ^! m( D4 ~- x
; E% V4 g6 l0 {9 t
% x6 v; H, V# H! j+ U
' u$ h# @3 J8 m: G7 K4 wMethod(_PSR,0)
" p2 C2 V$ b+ `! E1 v6 P( J6 |, ~* ~# Q
- ^; c2 F: w1 I5 j9 {
{. B' W' M) t* v$ H
& F* _- k# W8 G ?: H9 j! X
! T1 @9 O0 U" K' x& NStore(0x0B, DBG8)
( K1 j3 q1 a$ a/ H" R8 x4 I1 V) H. g0 v$ R1 X! j4 Y4 j3 i
; `! j" R. q1 j5 G% M3 }5 X
If(ACST)
' y! t& ^7 ^2 X* g4 C4 `//check AC status, S" L$ ]' _8 v
& k \* Q/ ?/ H
{% Y% ?6 B+ D8 y. u& t
6 s5 ~! L2 K( O' V
) q1 r5 ?0 B1 |return(One)& c: {2 o: S8 m, S" }5 G Q; A
// AC Present
9 e8 t/ q# T2 }4 u/ {) @2 L% y2 h6 K. h
}
4 a& C" [- C2 ]
: S! M$ v* |1 ?' P! ]7 Z' gelse
* c" X, u; ~7 ~( w6 c; ]3 t( o7 d" m% C
{ C! d+ Y4 U# M3 l! k
9 x& A% E7 R) e% ^& K, b! Dreturn(Zero)
) q8 j; K9 h( w% ]0 o& d$ u# h( X// AC Not Present+ M4 K6 l D: d3 e ?" S
* M9 e6 { f6 |}
# g" ]8 ~$ [1 l/ v) G# Y4 O, s! E% |- c
Store(0x0C, DBG8)! J6 S- P! G, p1 u- s$ P0 r
- q/ P$ q6 z6 A& {3 h6 ~ c3 S}# l! d! P+ M. T2 |9 h
/ E* T4 k& \: s0 B$ j6 h
% k; W6 k$ ^1 |2 O) j: d我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
& V, e" E: ?0 a- d状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
* y a, h7 u% vMethod(_BST). k7 _9 o) e9 g, P) w c% ]& l& s$ D
{
) G, r# x/ L# \, c) ]/ g
9 W% ]9 b0 W% G8 I, X4 R, PStore(BSTS,Local0)# h( g: }+ N' e4 _' p
* L& r6 V' }& t' W9 l. T- @2 \% ^3 [) t8 Y, {: D# U
If(LEqual(Local0,1)) //Check Battery Present Bit: p/ B, y/ u7 O6 a; |2 z* {% J
: a- @3 U! J3 U Y' h# p) S{2 [7 e# A7 k2 |% r+ f
. @5 x( n# G' L$ G$ K
& a; H. C* _) y+ W+ D4 L5 r/ B0 ?9 D/ D( d# X5 K |7 E) g: K3 w
) ~! P$ ?1 s/ h" S- ^
% C! x1 Q0 z0 B8 q//Read Battery information from EC7 U6 z% X- L" {% y/ p
: ]! X3 B7 ^; b! v0 h2 Z
… …
) K c0 k3 U8 \: j k0 x1 q @4 v
( f2 N: d& N \9 F- S/ n
* k9 \8 s4 A8 F) T}
0 y$ @$ w m: F2 r7 o: [
; ]7 v9 l* h6 \& L( L$ q8 FStore(0x0D, DBG8)
; p0 x6 f) i, g( |; S}
" s5 e$ m/ Y8 Z! \那么问题好像是由读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所致。
h( a: W/ c: g% q那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：8 O- H/ ^/ |4 f
7 z& B( P% ?7 c. f# k. z- J- i
/ U, d! l, P+ H2 F8 M# B而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.5 q/ T% t' w9 o0 p6 q. ?) T3 q; R
3 _. z) j- b3 ~' C
* \2 j1 K; c. D* s+ X. l6 n+ X7 e* Z. C/ h! i: v! x: F" n1 i2 P: h
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！5 a5 [ n! ^$ X; Y( v
3 a- `: g3 D: s& Y; M/ Y5 L$ Z
. m( u. A" F) e. o9 f L6 U: i7 g' _! D! B! f2 W' a4 \( ^
5 z7 R% C/ g! E: [% Q6 f1 d
That’s all!3 o& {* I2 G! \! ?1 h) X3 W
B; e2 }$ F3 K7 X
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
