[原创]AC In/Out OS Slow Response

peterhu

AC In/Out OS Slow Response

• Phenomenon
  

手上一个超薄NB的案子DQA报了这样一条bug：频繁的插拔AC，vista右下角的power icon有时反应很慢，AC插拔过后有时需要等几秒或十几秒才发现power icon有变化。Power icon指的是下图红色圆圈标出的部分：
1 W. B2 u' `4 e: v& X3 d0 ?; _( U* J

图 1

• Why???
  4 m0 H5 X) S2 \  C. G! W1 e

# r; ?. |( ]$ p
6 E7 R% W  X) h. v刚看到这条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 如下述所示：
, Y( g+ V# d( Z: ^6 m) K- O// AC Change event
" B5 d6 K+ m- k' B# ~" Z
Method(_QXX)
! F4 v. J* U8 Q7 W/ |0 q6 I3 G: i
5 k2 a" B/ Y5 j& q) B{

Store(0x09, DBG8)
2 d+ t5 h: P" R( x  Y3 Z% U
. d$ h* q8 @- }( N8 {! iNotify(\_SB. ADP,0x80)
7 {- w* W. K  l  v" |2 j2 N//Power Source status changed
' H( m- ?  ?" \& X# V2 s
Store(0x0A, DBG8)
0 f( U' ]$ H. ?- T' N6 ^

* V6 C! O1 w1 W}
& f, B5 E3 t8 _! V0 f8 G3 z$ C


7 W6 e, }4 \7 ^Method(_PSR,0)


0 _7 D9 B) I: x2 V0 ]- C* o{
1 C! A0 h  j0 c2 P% M: v
1 k! `. B. R/ g7 \& O5 f
( z- h8 _6 a/ r: }Store(0x0B, DBG8)


9 L1 C9 _" ], E: kIf(ACST)
7 W# a; X; E# s8 B3 @//check AC status

6 A2 r- j" z/ J# ~/ k* W. U{
6 v8 L- q  r. `! p& k

/ Q( A5 R* F( ^2 `6 [5 ireturn(One)
// AC Present

1 [; Q+ m# H7 z# l. ~* j! J}

else
3 q$ Z9 T1 ?4 w0 A
/ Q8 U$ d7 n6 O{
. c# {/ `- p, _' q/ N; d
return(Zero)
( E7 F) O9 s; O! B0 f5 U5 k. o// AC Not Present
$ O4 A- V  J% L7 V% t
9 M# w; m- H* K/ B& A}
/ M; z9 ^$ J" K" |8 F2 W
- O& {5 r; G9 _+ b7 D& r& H9 v) |/ N5 sStore(0x0C, DBG8)
3 ?9 Y( q& Z: @# o' l) o3 H; j( P
}


我能猜到的大概的流程应该就是这样了。那我们就从头开始追，先在AC change qevent中抛点，可是发现AC change对应的_Q method反应很快，一旦AC in/out debug card马上就会有显示。那么说明什么呢？跟EC没有关系吗？接着抛，又发现有时停在’0x0A’比较久才会出现，有时’0x0C’比较久。
( i. Q0 l" J4 j: v+ H( O$ I: P; G* G状况不太一致；没感觉就把网撒大点，在几乎所有的ACPI method中都抛上点然后再try，试了几个回合以后有感觉了，我们发现一旦现象出现在Device Battery _BST method中停的久的几率非常高，也就是说AC in/out OS还会更新battery的信息。这段代码最明显的特征就是它会从EC ram中获取非常多的电池信息，sample code如下所示：
1 E9 F& Y# ~2 b$ bMethod(_BST)
! l7 ~9 k3 {: v6 j  [{
! Q% b5 g) g! G$ H7 @6 [8 k+ r& S
& i/ Q" l4 f! Z  a7 UStore(BSTS,Local0)
; V: [! |* f' C5 i; k
1 D1 u* `7 [7 |2 _" |/ E& B+ s; e" {& F
If(LEqual(Local0,1)) //Check Battery Present Bit
* n/ c, h" E9 ?! x& j( h
{



+ m( O# W' g" b4 N( ?* F' L
8 E; r5 A; B1 j, k; @3 j( S/ o
0 O* q. q8 @9 Y, D//Read Battery information from EC
5 _: P) L# B; ?, j
# c4 y5 S6 A- J1 R3 N, c# X… …
+ t0 F* v' z4 D$ g) X' S! P

}
, P: ]" q) t) D. o
6 P1 `/ _$ v- T' b% [& s, ]2 OStore(0x0D, DBG8)
3 m6 Z2 ~% T& @% s}
+ y& x; L7 y! G, d, v5 U+ B; ^# }0 P那么问题好像是由读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所致。
; w9 D: q  p9 _% I( Q7 ?1 V3 z) H$ k+ X那么SCI中断机制是怎样的呢？EC SCICFG register通常将SCI IRQ配置成HLH的pulse trigger，而且L的时间通常设置成64us，如下图2所示：
% C. p5 p3 i  h9 Y! j+ u
' B/ O" U- i& G

而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.
; O( f# n/ I: k$ X* n; W9 s& V
( B( g2 J# w0 m# E

• Solution

; a. @  i/ Z, ~  ?经过上面的分析，大概的原因已经清楚了。所以解决问题的方法应该是调整SCI IRQ pulse width，将保持低电平的时间调短，这样就可以有效的避免这条bug。通过这条bug我发现在分析问题的过程中需要理清问题的各个环节，并且对各个环节所涉及到的细节也要深入分析。不能够看到现象就轻易的下结论，更不能想当然，正确的态度是不放过任何蛛丝马迹，大胆假设多方求证！
9 |8 u1 ^$ `2 B& o& t/ ^1 P
6 ^# t$ p) h; f! b) c

9 H/ _( q& t/ S  K2 T: o" H1 A
/ H9 c+ ?: _! S/ `& \That’s all!

/ }3 [, Q, j6 ~* n9 h3 N  LPeter

xtdumpling

原来如此！！！
2 Q) Y$ d$ b: |# k2 h
谢谢！

winbondowen

Bug起因为本

蓝色永恒

好帖，学习了 谢谢！！！！！

zhanghmjm

感谢分享！真的很有用，以前我也遇到这个问题，还以为是OS的问题呢！真的好贴啊！
我看了您的分析代码，好像不是EC的代码吧！我现在就是OS-BIOS-EC三者的关系有点迷糊，版主能否指点一下！谢谢

peterhu

hehe...
: h) V) H2 \3 F$ ~很高心这篇文章能够对你有帮助。
' ^* x: d1 ~1 x2 H/ Z0 r上述代码是BIOS中的ASL code，理清OS-BIOS-EC之间的关系的最好途径就是
ACPI spec，没事翻翻ACPI spec会有不少收获的。

zhanghmjm

感谢指导！谢谢！有时间经常关注你帖子。

zhanghmjm

您好！我现在手上有一个小本项目！用的是华邦的代码！我发现在oemmain.c中的几毫秒中断中是不是不能添加太多的代码啊！打个比方我就在一毫秒中断里加的代码，而这些代码是执行时间加入超过了一毫秒，是不是会造成EC死掉啊！因为在我修改后的代码发现有时很不稳定！我想了想是不是问题出现在这！请指教一下

peterhu

中断的处理通常分顶半部和底半部,很多driver都是这样处理的.
) U! _0 Y0 ?% b7 n简单来讲就是在中断到来时置flag,后续再处理(DPC).

zhanghmjm

谢谢了！刚才我又仔细的查看了一下我的代码！终于找到了！EC死掉的原因了，就是我在上电时序那加了一个类似看门狗的小程序！来保证开机的效率。结果硬件始终有一个S电没有上来才导致我EC死在那里。
, G4 N5 N, s# Z3 z对于您的解释我还是有点迷糊！对winbond的EC他的oemmain.c中的1MS，10MS，100MS，500MS，1000MS。它用的是中断还是轮询！！中断和轮询是不是没有什么太大的区别啊！我现在就是担心我在比如1MS的函数里加的代码太多，会不会出现在这段代码执行一半的时候，1MS的中断又来了。那代码不就不能完全执行了吗？

蓝色永恒

oemmain.c的是service，是具体的执行处理过程，而实际的中断呢，是由Timer 来触发的（有定时1ms），只要不在中断的Routine 里加太多东西，在 service 里加，应该没事。个人看法，呵呵

zhanghmjm

谢谢了！明天有时间我做个小的实验！我想就应该清楚了，到时与您分享！呵呵

amty.wang

为啥你们的是C，我的是汇编啊，

June

用汇编写才牛呢，呵呵

conolzhu

文章很精采,分析很透彻!

peterhu

conol你也來這里了
呵呵...

zhanghmjm

您好！
# D7 U# L6 M, @4 q     不好意思又打扰你了，我现在遇到一个问题就是在重启电脑时EC为什么会几率性的死掉！在重启的时候我们EC都做什么啊！现在真的有点头痛了！！！

peterhu

之前有追过reboot它的大致过程是这样的：
1.BIOS发FE给KBC,KBC pull low KBRST#一段时间，然后sb会将init# pin pull low 16个pci clock
chipset reset pci reset系统重启。
2.一旦重启后面的动作看上去正常开机没多少差别，对ec来讲无非是keyboard init、进出idle（update escd）
* ~; _% V+ D, @: H# J8 o等等一些琐碎的动作。
/ Q7 W1 u2 }$ }5 A; W/ H之前碰到问题比较多的地方就在idle这部分了。
5 Z% L- K9 O# e& K$ Y你所说的EC死掉指的是所有的function 都失效吗？keyboard能不能用，hot key能用吗，四秒关机呢...
3 l6 d- @5 @0 n8 N7 M# {+ |5 e5 O还有如果单台fail几率比较高，建议你接串口debug去看EC死在哪里。
以上希望对你有所帮助。

zhanghmjm

谢谢您的答复！
    我在做重启的时候EC是死掉的，四秒不能关机。键盘和热键无效！至于死机的原因真的很难找的。因为串口debug调试的功能我还没有弄呢！
' x0 u: t/ z6 o, f+ Y     对了您说的BIOS发ＦＥ给我们ＥＣ应该是通过SCI吧！请指教一下！

peterhu

to zhanghmjm:
BIOS发FE不是通过SCI,而是透过60h，64h port。
" c5 q+ V7 F, O% h9 @3 a9 ?BIOS应该没有办法发SCI给EC，而EC是可以发SCI给BIOS的。