ULE

I have done several experiments/asserts to ensure that the panic is related to ULE+PREEMPTION case only.

ULE: no panic
4BSD: no panic
4BSD+PREEMPTION: no panic

My latest progress is that I found that sched_switch in ULE for the threaded case, can decide whether subsequent call would panic. Investigating.

My company has offered me some test equipment (namely, a HP 360 with ILO, which is *great* for debugging at home!), and I has started to trip over the ULE code and find for bugs.

It seems that I have hit a bug, where kseq_nice_rem is being called too much. Have read the code and added some KASSERT/MPASS’es.

I have enabled PREEMPTION, FULL_PREEMPTION with ULE. Now I get strange result here:

• propagate_priority gets a TD_ON_LOCK(td)
• It tries to panic(), unfortunatelly, ts->ts_lockobj here is NULL
• A fatal trap 12 happens.

It seems that ts->ts_lockobj was touched by sched_lend_prio, for unknown reasons. Maybe there is some lock releases?

·毕业设计翻译
·周一、四游泳
·完整的调度队列实现(本地)、远程调度队列的接口部分
·调度器设计文档
·本地调度的实现细节设计(参考ULE的一些思想)、队列的threadsafe处理
·软件学院的事情
·开始撰写毕业论文

Scott Long today announced the release. This is a point release over 5.2-RELEASE which addresses many critical bugs.

The -CURRENT have already differentiated from the RELENG_5_2 branch, say, 5.2.1-RELEASE by this time. The most significant differences are:

As planned, Jeff Roberson has made ULE scheduler the default for FreeBSD’s CVS -HEAD. This is an important step going forward to 5-STABLE.