On Sun, May 6, 2012 at 3:38 AM, frantisek holop <min...@obiit.org> wrote: ... > however on the other notebook systat froze the system solid. > i have no idea how to reproduce this, obviously, running > systat now works fine.
Could you see the machine's console and see whether it paniced? For those that are interested in debugging from a kernel crash dump but that have Sandybridge video chipsets and similar that are unable to return to the console once they go into X, it's often still possible to type blindly into ddb and trigger a kernel core dump. Just type "boot crash". If it works, the system will pause a moment and then you'll see a pile of disk activity. You'll need your swap partition to be somewhat bigger than your total memory, and then you'll need somewhat more than that free on your /var partition. Check out the crash(8) manpage for some info on what you can do with a kernel crash dump. > could the reason be, that after the update both > libkvm.so.13.0 and libkvm.so.13.1 were still under /usr/lib? No. The libkvm changes there are mostly to permit analysis of kernel crash dumps, though some of netstat's options still involve reading structures directly from kernel memory and so may fail if libkvm isn't in sync with the running kernel. If out of sync, netstat may coredump or simply fail, but that won't crash the kernel. A process not running as root should never be able to crash the system. Philip Guenther
