|
|
AC In/Out OS Slow Response
- Phenomenon. |* v4 p3 z5 ?, W, v
- |7 @ i0 k& Y. E* s6 ]
手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
( w p k8 O. k' F9 Z: [. Q- Why???9 [8 y* D# P A% S% Q: x5 c7 g4 z
2 j, W( A) u) D( s g
! O# e' ^) J# B4 U
刚看到这条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 如下述所示：, k+ i4 C$ ~! q- ]- T4 d
// AC Change event6 O: ^: I% d# x0 j
# j/ o: c6 z* S6 a
Method(_QXX)
3 J/ T- o$ V, u( G% |- `3 Z5 @: e3 l9 c" r- d+ U1 I
{
3 j4 J, Y6 H3 {* ]4 D; @4 h/ o+ P# I4 ], ^2 y2 s! ^/ C. y
Store(0x09, DBG8)* ?4 z: H# s* `5 O9 e) ~$ A
6 ]8 E5 Q. e" F% J
Notify(\_SB. ADP,0x80)
9 ~- L; W3 `( g* v//Power Source status changed8 \& u! `2 t8 P9 Z' ?
' s0 B& Y4 u* c" Y) ]' cStore(0x0A, DBG8)
: D# L) P1 h2 u, q
1 t1 H# s9 ?0 g5 x4 J: Q+ \( Q6 d, ]9 I) T0 i* c/ F! x" }4 t
}9 Q+ b# s* \, |! w/ R6 }. K+ v' e
4 O# Q0 \4 S% u* F% ~$ W3 S; R1 j9 ?
& `. G3 U6 J$ Z1 y. Z8 v
Method(_PSR,0)
6 {+ ^( \. t2 J+ d+ K; c! W- e' z3 U% [0 f- g5 W
( F4 A4 |& N3 }% u+ x
{0 N/ T% E! n! }4 `/ c) _
3 _ l1 I9 W( z1 m9 B7 |( K* a$ u4 H# `# x3 p9 [/ n
Store(0x0B, DBG8)+ H3 L1 X4 J2 x) ~' f
~2 ]/ F( L2 G3 b3 A+ _2 b
0 @, u3 B/ M9 `
If(ACST)
9 z" ?/ y' G6 L4 }//check AC status
9 z4 A. u6 V( Y, [1 _7 |' r% k" f, E/ m$ ]! Z/ `3 n" f
{. [2 @* k @ t% n
, Y/ i: q/ J. _5 K. I3 p/ j( o, i8 H5 j8 F5 s, h
return(One)3 W: H, }8 e* F6 [
// AC Present
1 q4 L+ B/ j- y7 T/ m
' q/ a; W7 r. x& R}
) o" {' @' F8 q& {+ J1 G* F9 n D! q
9 o- E# h. H2 @8 Selse- \- d( @* Z+ O5 N+ r( `
3 D8 d0 W: f8 f0 A
{) l/ |8 A9 h8 @! W& v2 E) d& _6 ?
$ G7 e, C+ N% M. E
return(Zero) `: m4 \, S+ j$ I7 M
// AC Not Present; h( @6 R: a. k
, I8 r; O& Y7 s X \+ ~}6 R# e: |- W% m8 n" ?6 i
0 K% p8 Y Y6 Y0 J2 Q9 B; V6 _6 ]Store(0x0C, DBG8)
; |& }) a3 [# L' s0 ]+ B$ q2 Q1 W0 d: u9 P
}# w- i4 F' G( x( z8 ~
0 Y5 l. I1 ]) l( s, J* h- i& b8 [) C' C* h
我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。7 `# m9 T) d; q% m5 Z4 y
状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：1 n) h/ o; l, h; @3 }7 m* E7 \! F
Method(_BST)! f0 X0 g! c4 S2 T5 p' k
{. g9 w) \9 E. j; V* b r
8 d! y# z! v) [0 bStore(BSTS,Local0)
U1 h: |: A& `2 C& k- s- m
: ?0 E, g' G, w' Q3 U3 U u& i: Z2 v2 b L
If(LEqual(Local0,1)) //Check Battery Present Bit' {' [1 I7 v$ R# I8 \6 B
8 a5 L" L5 f) A) `& D{
8 d- ]/ D1 A5 K0 n: W1 _/ K+ u, d" z' z2 g* }- z- f
# [7 k( Y' | d4 h/ d, a7 Z2 X0 P; Z2 v. }2 j; a' g3 M O$ O
* ?* z: r& C/ m# O9 K
( F5 m$ L+ D7 m//Read Battery information from EC3 f( c5 c) I- }
; p& {% M: a9 [; w
… …: [& m- U N7 F& a/ D
5 k$ y" L6 W7 B; ^% M
; o+ E8 D, }" z6 s}0 H' z5 }, o# I8 b' L! k/ O. t; u
) J1 s! }3 _! k! _8 B. _Store(0x0D, DBG8)& v' f- @ i# {2 ?* n
}
0 L6 ^+ I$ X# x. ]那么问题好像是由读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所致。: ~+ I/ d* ^6 G7 R+ r# D# }
那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
) {! S5 @6 N9 W D. T* B3 ]) ?5 |* d g6 J& d% G) c7 n9 m4 i
5 ^& B$ E9 J( M7 ]5 s. v0 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.7 }4 }0 A+ Z& w$ O
2 v3 f. `$ C4 Z- h5 V" h \, L3 l9 q0 J# k: }6 F
+ _/ L! h/ e/ M2 F/ ~& B% _经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！0 Y4 A1 g5 f- b
2 I6 B3 T" _% j, I/ d1 K, p! Y9 V! x* s. a5 f2 u- C" h
$ a) |: [, [6 X# i; P * d. S( \1 i0 c' ~3 c6 S/ l* ? b
That’s all!
" S5 Z* T2 @* J, P9 C & E. e( z, N+ [1 t
Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
