Debug

The SMP case seems to have something wrong with it. My MARCH=p4 and -O optimized kernel often crashes when shutting down on beastieng.frontfree.net. Apparantly this is lock related (we can see the panic strings there not to be outputing atomically, and they just mixed with each other).

以前在网上看过一篇文章，作者说自己不用图形界面，只用vi云云。我觉得很可笑。

一直以为自己能够调试所有的程序，因为我一直以能够不依赖IDE调试，用一组assert，printf就能改掉别人花几个礼拜也没办法track down的东西，然而今天JDK让我折服了，用Java写的程序，如果没有IDE，简直就不具备可调试性！

Don Lewis (truckman@) has committed a fix for the sysctl spinning problem I mentioned here some days before. Currently, beastie.frontfree.net is running a workaround which made it possible to skip the deadlock, however, will not guarantee the correct result.

From Microsoft’s KB:

You can configure Microsoft Windows 2000, Microsoft Windows XP, and Microsoft Windows Server 2003 to write debugging information to three different file formats (also known as memory dump files) when your computer stops unexpectedly as a result of a Stop error (also known as a “blue screen”, system crash, or bug check). You can also configure Windows not to write debugging information to a memory dump file. Windows can generate any one of the following three memory dump file types:

1. Complete memory dump
2. Kernel memory dump
3. Small memory dump (64 KB)

Several servers I manage running FreeBSD 5-CURRENT as of 20040228 appears to bearing wierd deadlocks, which could be triggered by ps(1), top(1) and w(1).

It can be obtained here:
http://www.arbornet.org/~junsu/gcov.diff

I have sent a headsup to bugs list of DragonflyBSD, which mentions the recent bugfixes on FreeBSD-CURRENT committed by Dr. Alan Cox.

I have just tried to umount /usr on my test box in order to get all outstanding writes to be sync’ed to disk (as Kirk McKusick said, the umount system call will do true sync of a file system).

With help from clement@, I have finally addressed the problem I am encounting was caused by a mix of libkse(libpthread) and its older version.