|
|
AC In/Out OS Slow Response
2 u8 O& Z" w' M5 x4 @- Phenomenon+ W! ]) k0 x ]7 F {- F
1 W! }% P; g4 N% v手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
$ q4 l, f8 }: B% T! {6 q. F6 H- Why???7 |0 ?: T6 K/ D) I$ w, b
% ]. h/ F2 O: X |: M: l* Z0 _! Z- @: N% i- k6 w, I! Q
刚看到这条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 j, c7 J; [- x1 l5 Y
// AC Change event
6 H' A4 a6 L4 R+ v1 C2 W2 O3 o6 Z/ O5 a6 b( S
Method(_QXX)/ a( M, _( e, _: w
' W A6 Z8 }4 q. |/ \{5 l7 ?3 `' ~. c6 p( W# f. A& D, d
9 h) U$ |0 K1 u9 H! cStore(0x09, DBG8)
9 f4 ?( b3 _6 b) O+ A6 ]
8 q8 ?2 S& i5 p: A8 U6 P9 ZNotify(\_SB. ADP,0x80)5 m& F/ Q w V9 T$ v8 `0 j3 S
//Power Source status changed
3 O7 {% S3 Q/ _# V6 p8 E) G
o0 K, e Y8 c. V6 N6 L' O1 dStore(0x0A, DBG8)0 L3 C2 G; N' o9 }! ]7 h
: F# b. b; f4 s: E8 e6 \) E# g& r6 J6 |7 u' }& K
}$ t/ u( u5 T9 ]# h( O( _3 G' C
7 R" U" H- b4 \0 U" f7 N; S
; A0 [, y# h. x3 @# i. _
* q; W: l9 b U2 o& w+ pMethod(_PSR,0)3 d2 y q6 ^, m b2 m: |+ C
1 `- P/ t3 D( ], }% x& p1 }
. v6 G) x9 C2 D! a. [; ~
{
/ U; l$ T @1 C# A6 ^$ {' }7 M: H6 _; P% P1 e. G
2 h3 C0 @; v0 I) p2 F$ A" u" L
Store(0x0B, DBG8)1 W6 T: H; n. [9 t3 F+ p5 C0 M
) a6 _4 n: N) O4 _& b. P9 }5 Q7 Y, ]" Q- g4 N5 v; H
If(ACST)( L1 `) Q9 j# v4 i
//check AC status
/ M" y# a+ f' ?5 G$ U; m) h2 L% f0 {; ~! `" A! q1 O, C6 J
{. S4 A# u9 ], _- e; q* {( y5 v, R/ q' q( M
# p* ^" D- Q4 }) H, l
f; }8 }. _; }
return(One)
( F4 N3 A5 ^$ f$ S2 w// AC Present
% D+ [& ^: X; z) M
; u9 Q. f, C- s/ i: L) I7 a+ a; t}
$ ?+ e, a, o+ ]- c+ Y) n/ L! a) T( i3 K" \
else
2 \4 S. Y; u, ^* Y ]; ^4 s9 K+ L" b2 H5 T- Q1 f5 [
{
% O, w9 `7 _) B3 [) C0 b$ @7 u- P7 p3 q
return(Zero)
. ^" g$ N) ^: G& o& ?// AC Not Present
% z" v/ h( }/ w ]" t1 p6 ~) B1 n8 \- V5 }! W
}( W7 ]3 K2 L8 \9 W5 Y
, h: U+ j& I7 f8 B
Store(0x0C, DBG8)' K" G8 p; r u/ u; n m: b+ ]: O
( G# v8 G: `( Y: H$ C4 E
}
* Y H3 Q, Q* n# ~3 B. c- p7 g# e4 N3 `# ^0 j& v# B
+ `4 J6 J |* [, m我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
) R+ ?: y7 o" G2 s* u; q状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
. }" H1 N& m3 Q; F0 H3 i: V4 MMethod(_BST)5 W" P: v$ j( r
{2 e5 Z7 c( M% U0 F& \0 f+ x
8 N- k, U9 n T e& F$ M. B
Store(BSTS,Local0)
* S! P v1 Y5 |5 _; P8 f
! \. e& O/ x2 d4 L4 @! D1 \1 B) k3 m2 A
If(LEqual(Local0,1)) //Check Battery Present Bit
l$ G; }6 R3 ^% w- V' y0 B' A* [4 ]+ a0 _# |) B4 _6 l
{
8 l0 e3 D$ j2 y5 Q* G3 i0 ~3 e! U8 n' l) V! P
4 q9 @. c4 h* d2 V) |, R
! Z% u' y. C5 ^1 L9 ?1 _0 g9 V
' w# J8 z" R2 ?2 q: `" K, T3 }3 L$ X+ |3 ?- _3 m' b
//Read Battery information from EC
( f( `2 x& t7 l( F0 Q) S
9 m6 V; u3 p) M4 b2 p2 \1 l… …
: t3 q: h* D) n+ F6 b
, h; T; U" q6 q7 s. y3 |
/ x( v! n5 O( G( q& o}
3 E$ e* R, _4 F2 l. L5 C
: I5 f1 Q1 y( GStore(0x0D, DBG8)
+ f% @' r' P. J! P$ u# F0 ?} 4 f7 K, D, }6 @5 B3 `4 ?
那么问题好像是由读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所致。
% v0 e; Q+ g& p9 v那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：" u0 l1 T$ i" \- F1 T' A
4 y3 B4 S9 \- j% |/ Q% [- a; o- @5 O& K4 y+ M
而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. p6 h4 s) E# R: b$ t$ ]; V
2 t% U1 [9 k% _* a" l
$ D( ]7 B2 u% G8 w9 D1 p* O. ?# Z+ Y8 s* E5 }) S9 C
经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！0 V7 U, Z! ?1 G5 K0 r
% @1 z5 Z( \1 Q" I4 ]
4 C7 `, B. m8 ~
2 k |& R2 q, M2 }4 @3 D; E2 [7 Y
4 f9 p. y# P7 R5 H+ j* m! ^1 tThat’s all!1 ]6 t1 |9 N" C- y' g. G1 T
# d" k3 T/ T- k+ i+ M( B- `Peter |
本帖子中包含更多资源
您需要 登录 才可以下载或查看，没有账号？加入计匠网
×
|
IP卡
狗仔卡
发表于 2009-5-19 08:11:52
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2009-5-19 18:31:57
