蜗窝科技

@misakamm20001：以Android为例，写state的位置在“system/core/libsuspend/”中，但具体到调用时机，和操作系统的电源管理机制有关，就比较复杂了，一时半会也说不清的。

arm64下gcc 4.9.2，编译汇编中@开始地方出现异常 ``` /tmp/ccd6iavd.s: Assembler messages: /tmp/ccd6iavd.s:26: Error: junk at end of line, first unrecognized character is `@' ``` gcc4.9不支持@注释符么？

@printk：感觉你这个要跟飞思卡尔的FAE联系吧，一般SOC厂商都会提供内核崩溃的调试机制。MTK就提供了类似KDUMP的机制可以得到core file + vlinux进行奔溃点调试，高通提供了类似的ramdump机制。这些都是向它们的FAE要datasheet看怎么做。

Hi wowo: 请教个问题 能介绍下这个autosleep的具体调用情景 谁来负责写这个state？

@printk：抱歉，我也不是很了解这一块的内容，因为一般情况下，内核崩溃用ksymoops也就足够了，不知道为什么一定需要kdump？另外，arm下应该也可以用kdump，只是要编译两个kernel image吧（因为ARM不支持重定向内核）。

@fire：1. 什么时候会使用PM resume唤醒Kernel呢？ ==================================== 我不太确定您这里的“PM resume”指的是什么，是指System sleep过程中的resume动作（和Runtime PM对应）吗？如果是的话，resume是和suspend成对出现的，只有suspend了，才会resume。 2. 一般情况下，唤醒源是那些没有被disable的中断，电源芯片应该也是其中的一种，和具体系统的设计有关。 3. 我们系统上的pm resume代码如下， 我想问下，系统挂起后，是不是只要PM resume之后，才能接收到runtime resume？ ====================================================== 这个问题的本质是Runtime PM和System sleep（suspend&resume etc.）之间的交互， 我一直没有来得及写。您可以先参考“Documentation/power/runtime_pm.txt”中的相关的内容，这里我们先简单的讨论一下。 a）就某个设备而言，suspend的过程中，RPM和System sleep之间的关系可以分为三种：一，先RPM suspend，后System sleep suspend；二，先System sleep suspend，后RPM suspend；三，RPM suspend和System sleep suspend之间互相交叉。 b）显然，kernel power managerment的同步机制应该会保证第三种情况不会发生，就先忽略。 c）第二种情况，由于先System sleep suspend，情况比较简单，PM core会在prepare阶段（suspend_devices_and_enter->dpm_suspend_start->dpm_prepare->device_prepare）,get一次RPM的引用计数（pm_runtime_get_noresume），以保证系统不会再RPM suspend，此后的过程，就是正常的suspend流程。因此这种情况也不会发生。 d）第一种情况有些复杂，如果设备已经RPM suspend了，那么System sleep suspend要怎么做？要强调的是，这种情况下，RPM suspend、System sleep suspend以及后续的resume行为，完全是由设备驱动决定的，例如，RPM suspend执行“浅睡眠（可以唤醒系统）”，System sleep suspend执行“深睡眠（不可以唤醒系统）”，等等。 e）因此，设备驱动对已经RPM suspend的设备，再执行System sleep suspend时，很有可能会先把设备从RPM suspend状态唤醒，然后再让它进入System sleep suspend状态，而这一切Runtime PM已经不知情了。 f）回到resume的过程，来探讨一下您提出的两个问题（主要针对第一种情况）。 g）首先，系统没有从suspend状态resume的时候，RPM机制肯定是没有激活的，因此，肯定是System sleep resume后，才可能有RPM resume。至于是否一定有RPM resume，这依赖于System sleep resume后，设备的实际状态。 h）如果设备在System sleep suspend之前，已经RPM suspend了，它的RPM status就是SUSPEND状态。但在System sleep resume之后，设备有可能直接变成full power on状态了（这和设备驱动的策略有关），因此就和RPM的实际status不符，怎么办呢？手动修改RPM状态，使其变成ACTIVE的（pm_runtime_set_active(dev) ），这就是那三句话的意思。 I）最后，如果设备已经是RPM ACTIVE了，在需要RPM resume的时候，就不会再真正执行resume操作；甚至，如果之后不需要再使用设备，有可能会执行RPM suspend。 有点长，希望能帮到您。

@wowo 大神 ，请教一个问题，关于kdump的，我们单位现在开发的基于arm V7平台的freescale IMX6 CPU的设备，现在由于内核不稳定，导致的死机问题增多，想问一下有没有什么类似于kdump的功能，能在内核freeze的时候提供一个core文件，定位到问题发生点。但是kdump不支持arm平台，使用ftrace跟踪，显示的特别乱，并且如果调用过多，无法跟踪到最后死机现场。 求教～～～～～

@wowo：O(∩_∩)O我也是接触不久一知半解、多多指教~~在这儿收获很多、谢谢~~

@fire：我们做唤醒测试时，总是先看到pm resume, 有时候会有run time resume， 有时候又没有。 万分感激！

版主你好， 你对Linux的管理流程很深入，请教个问题，最近碰到的critical bug都和PM有关。 什么时候会使用PM resume唤醒Kernel呢？ 只有电源芯片，外部IRQ之类的才能PM resume吗？ 我们系统上的pm resume代码如下， 我想问下，系统挂起后，是不是只要PM resume之后，才能接收到runtime resume？ atomic_set(&motg->pm_suspended, 0); if (motg->async_int || motg->sm_work_pending) { pm_runtime_get_noresume(dev); ret = msm_otg_resume(motg); /* Update runtime PM status */ pm_runtime_disable(dev); //不是很明白这三句的含义 pm_runtime_set_active(dev); pm_runtime_enable(dev); if (motg->sm_work_pending) { motg->sm_work_pending = false; msm_queue_sm_work(motg); } }