Kernel

em(4) MT5 patch

Available here.

AT YOUR OWN RISK!!

Still ULE+PREEMPTION

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.

Working on ULE

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.

keys of (j),(z), etc. in FreeBSD scheduler related stuff's comments

You can obtain latest list from sys/sys/proc.h:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

 * Below is a key of locks used to protect each member of struct proc.  The
 * lock is indicated by a reference to a specific character in parens in the
 * associated comment.
 *      * - not yet protected
 *      a - only touched by curproc or parent during fork/wait
 *      b - created at fork, never changes
 *              (exception aiods switch vmspaces, but they are also
 *              marked 'P_SYSTEM' so hopefully it will be left alone)
 *      c - locked by proc mtx
 *      d - locked by allproc_lock lock
 *      e - locked by proctree_lock lock
 *      f - session mtx
 *      g - process group mtx       
 *      h - callout_lock mtx
 *      i - by curproc or the master session mtx
 *      j - locked by sched_lock mtx
 *      k - only accessed by curthread
 *      l - the attaching proc or attaching proc parent
 *      m - Giant
 *      n - not locked, lazy
 *      o - ktrace lock
 *      p - select lock (sellock)
 *      q - td_contested lock
 *      r - p_peers lock
 *      x - created at fork, only changes during single threading in exec
 *      z - zombie threads/ksegroup lock

ULE: kseq_nice_rem is called too much!

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.

an(4) fixed

Today quakelee@ has reported that an(4) is broken with a recent -CURRENT. I have identified that that was related to our recent ifnet change and has fixed it under scottl@’s approval.

Final FreeBSD 6.0-STABLE Code Freeze call!

We are only 1 day to the great 6.0-STABLE code freeze, which will result in 7.0-CURRENT, 6.0-STABLE, and finally, 6.0-RELEASE!

Deploy FreeBSD on your spare boxes, g/f’s laptops, etc., to help us toward an excellent release!

Debian Linux 3.0 coming

Now they are at r6. I hope that FreeBSD will have dabian base for their 3.x series soon, which will provide better compatibility and ease the way of users to migrate to FreeBSD.

ReiserFS 3 ReadOnly support imported

So he has finally (after about six or more months) imported read-only ResierFS, congratulations, dumbbell, you have made a quite impressive change!

Since 6-ism VFS interface is quite different from 5-ism, so this change is not likely to be merged IMO. Read-write is also not likely to be available soon, but anyway, ReiserFS is a nice FS and supporting it is a good move.

Today another GPL kernel has problem with a 4TB RAID5 array, it thought that it is 2.1TB (on boot) and refuse to initialize it with its native file systems, including ReiserFS. On contrary, FreeBSD 5.4 and 6.0 works smoothly with a GENERIC kernel. Oh well…

听说……花了~~

在-CURRENT上发表那个patch之后果然有很多热心人帮助测试。有人说在X里面接USB键盘会花，现在还在找原因……

• ← 上一页
• 下一页 →