蜗窝科技

@linuxer：最后说明一下哪个函数是这两个的综合体

Hi 楼主， 两周前我遇到了一个关于suspend/resume的defect，主要表现为在执行echo > mem /sys/power/state的时候,进行usb格式化，就一直buffer i/o出错。 U-boot下一切正常，用uefi进行pm起来之后就有这个问题。前提是同一个linux kernel，同一个dts，同一个板子。 后来我将注意力转移到了PM上面，因为用uefi作为boot-loader的时候，休眠之前格式化u盘都是正常的，我们自己写了限定系统休眠醒来时间的驱动。但是之后就不正常了，所以我想是PM可能影响了什么。 我dump了在PM期间usb驱动的寄存器，没发现什么异常。 所以，还是云里雾里的...... 已经被这个问题卡了两周了...... 求帮助......

@薛文旺：clockevents_config和clockevents_register_device

@zhangyx：问题一：不会。sigwait仅仅是用来等待信号的，如果调用该函数的时候，指定的signal是pending的，那么该信号会从pending list中摘下，并直接返回。如果没有指定的pending的信号，那么该函数阻塞当前进程。这个函数不进行任何阻塞信号的操作。 问题二：在古老版本的unix中会存在信号丢失，linux中应该不存在信号丢失的问题。你在send_sigqueue函数增加了打印，已经确认了信号没有重复挂入pending list。我相信你的问题还是处在信号递交到进程的时间太长了。

@zyzii：vma和anon_vma是一对多的关系．多个anon_vma可以挂在vma->anon_vma_chain上．

“ 3、配置并注册clock event device 是上面两个接口函数的综合体，这里不再详细描述。 ”是指哪个函数？

@linuxer：首先多谢您答复！ 1，如果我没有注册signal handler ，只是用sigwait来等待信号的发生，是不是意味着 sigwait 返回后，信号就不阻塞了。 2、信号只提交给正在运行的进程，而信号要得到处理，进程必须要在运行，是不是意味着，不可能出现信号重复挂入队列的情况，也就不存在信号丢失。

@丈二和尚：如果是搞驱动的，可以考虑加入QQ群，里面有很多驱动高手，气氛也很热烈。 如果对内核感兴趣，愿意沉浸在“枯燥”的内核代码中，可以考虑加入微信群。如果觉得自己的确适合微信群，可以搜索Linuxer-at-wowo（这是我的微信号）申请加群。除了这个方法，也可以通过QQ群中的linuxer用户申请加入微信群。

@zhangyx：timer_getoverrun函数返回0，表示该POSIX interval timer没有overrun，大于0表示产生了overrun。例如一个POSIX timer每10ms触发一次，如果在10ms到期后发送了信号并递交到进程，那么说明没有overrun。如果在10ms到期后发送了信号，但是，由于种种原因，该信号在30ms后才递交到进程（即执行signal handler），那么你可以通过timer_getoverrun函数获取该POSIX timer的overrun的次数为2。 Siginfo中的si_overrun表示该信号的overrun次数 timer_getoverrun函数返回是POSIX timer的overrun次数 这两个overrun是不一样的。Siginfo中的si_overrun统计的是整个信号生命周期的overrun次数，包括signal generation到signal delivery。你在send_sigqueue函数中看到info.si_overrun++那是因为信号重复挂入signal pending list而造成的overrun。 timer_getoverrun函数返回是timer视角下的overrun，即interval timer已经触发，按理说应该及时rearm才能产生固定时间间隔的timer事件。对于POSIX timer，触发后发送信号，当完成signal delivery才会rearm timer。然而，信号可能pending很久，例如： 1、 信号只会被递交给正在运行的进程，如果进程阻塞，那么信号不会被递交。 2、 信号可能被阻塞 3、 响应信号（执行signal handler）的时候，往往会block该类型的signal 正因为如此，一个10ms的POSIX interval timer，在触发后会立刻产生信号，然而这个信号可能在30ms递交到进程（signal delivery），在这时候rearm timer已经完了，中间overrun了2次。 因此，timer_getoverrun函数返回非0值并不表示信号丢失，只是表示signal generation到signal delivery的时间太长，超过了POSIX timer的interval time。

@zhangyx：static void schedule_next_timer(struct k_itimer *timr) { struct hrtimer *timer = &timr->it.real.timer; if (timr->it.real.interval.tv64 == 0) return; ******************* timr->it_overrun += (unsigned int) hrtimer_forward(timer, timer->base->get_time(), timr->it.real.interval); timr->it_overrun_last = timr->it_overrun; ******************* timr->it_overrun = -1; ++timr->it_requeue_pending; hrtimer_restart(timer); } 也请跟踪一下上面的函数，实际上调用timer_getoverrun获取的是timr->it_overrun_last的值。