蜗窝科技

对于中断处理而言，linux将其分成了两个部分，一个叫做中断handler（top half），是全程关闭中断的，另外一部分是deferable task（bottom half），属于不那么紧急需要处理的事情。 //---------------------------- 请教一下，这里“全程关闭中断”在哪里操作的，我怎么么没有找到对应代码

@Loongson：过奖了，形式不同而已，本质都是一样的。大家互相学习~~~

LOU 楼主很厉害，看到你写的文章 很深入，虽然做嵌入式相关工作，但是都接触的是VxWorks、WinCE等 EOS，对Linux 不是很熟悉，楼主的博客不错， 以后多向楼主学习！

@koala：请参考“kernel/power/autosleep.c”中的注释： /* * Note: it is only safe to mutex_lock(&autosleep_lock) if a wakeup_source * is active, otherwise a deadlock with try_to_suspend() is possible. * Alternatively mutex_lock_interruptible() can be used. This will then fail * if an auto_sleep cycle tries to freeze processes. */ 就是说，mutex_lock(&autosleep_lock)的调用，必须在有active状态的wakeup_source才安全，否则在 try_to_suspend()时可能发生死锁，我的理解是： 例如，pm_autosleep_set_state中，需要更改autosleep_state（一个全局变量），因而需要使用mutex_lock保护临界区。如果调用时序如下： 1. 系统具备suspend的条件，调用try_to_suspend试图suspend系统，该接口调用mutex_lock(&autosleep_lock);，持有锁。 2. 发生调度，执行pm_autosleep_set_state所在的进程，在该接口中调用mutex_lock(&autosleep_lock)。因为此时锁已经被try_to_suspend占用，进程sleep，且状态为TASK_UNINTERRUPTIBLE（这个状态会导致task freezing失败）。 3. 发生调度，继续执行try_to_suspend，直到执行freeze操作（suspend_freeze_processes）。由于有进程处于TASK_UNINTERRUPTIBLE状态，freeze失败，suspend失败。 因此，出现了“具备suspend条件，却suspend失败了”，就是上面注释中所说的deadlock问题。所以在mutex_lock(&autosleep_lock)调用前，保持系统不会suspend，就可以解决这种问题。

@wowo：wowo，还是没有搞明白，再请教一下。 1.加个互斥锁就可以了，为啥还要__pm_stay_awake和__pm_relax？先"确保系统不会休眠",然后“允许系统休眠”。 2.为什么保护这个共享资源(autosleep_state)，就可以避免产生同步问题了？ 谢谢！

@linuxer：博主现在写的东西比很多嵌入式方面书里面写的更好了，等以后博主将写的东西系统整理下，我觉得肯定是一本很好的书。

@Daniel Shieh：不敢当，不敢当，虽有动笔写书的想法，不过现在时机还不成熟，我们自己还没有达到融会贯通的程度。套用我之前回复Daniel网友的话:写书是这样的过程,你自己首先是一个装满水的水库,但是准备了一桶水,给读者倒了一杯。但现在,我们只是建好了水库,还在蓄水阶段...

@SleepDeXiang：欢迎，欢迎，不论什么工作性质，只要保持一颗对linux kernel的热爱之心就OK了，把这个网站办成一个喜欢钻研linux kernel代码的集中营就是我们最大的心愿

@passerby：好的，我马上就有时间了，可以考虑一下这个主题

@wowo：linuxer有空的时候可以分析下armv8的异常向量表建立过程吗?刚看了他分析32位的时候的情况，但是现在armv8有了很大变化，汇编指令也变了很多。坐等大神授道解惑。