My (*-RELEASE) kernel doesn't crash ?
The closest I've seen to a crash was a deadlock in the vfs which forced me to reboot the machine...
Deadlocks are worse than panics. At least with a panic the box reboots without having to go downstairs to punch the reset button. Panics also provide register dumps which are much easier to debug, because we're walking the stack through a backtrace. The source of the deadlock could have occurred seconds, minutes or even hours previously. While with a deadlock (or as we in the IBM mainframe world called them deadly embrace) leave you with little or no information.
When I was an MVS systems programmer, a subsidiary of ours did development on a production mainframe -- company made that decision because they didn't want to spend the millions on another mainframe. The developers had a small bug in their kernel code -- they were writing software to support a hardware vendor's to be announced tape robot. The IBM mainfame has no stack so the standard was to dynamically allocate (GETMAIN, aka malloc()) a 72 byte save area to save registers. Just prior to return() the function would restore the callers registers and free (using FREEMAIN, aka free()) the 72 byte save area. Save areas are a linked list giving you something like a stack without aa stack (no such thing as a stack exploit on the IBM mainframe) and save areas are stored on what we in the UNIX world call the heap. Well, with this bug their code freed 144 bytes or two save areas worth of memory while in kernel state. The problem didn't bite us until the next morning when people started to log in. The kernel would GETMAIN (malloc()) free memory, which was in fact still in use but considered freed by memory management in the kernel because 144 bytes were freed instead of the intended 72 bytes. This caused a deadlock because the memory freed were linked lists used to manage page tables (DAT - google dynamic address translation). The affected control blocks maintained a lock which would be used to lock the control block using a spin loop (compare and swap instruction -- we have those same instructions in Intel and ARM). To make a long story short, the CPU went into a tight loop (a compare and swap spin loop) waiting for a resource that no longer existed because it was overwritten by something else because memory management believed the memory was free beause the memory had been erroneously freed (144 bytes instead of 72 bytes) many (up to 8) hours before by the kernel modules the developers were testing.
In UNIX when we issue free() all we need to pass to free() is an address because the length is stored with the address by malloc(3) in userspace and malloc(9) because the mallocs keep track of not just the address but the length malloc()ed so when free() frees the memory all that is needed is an address and memory management does all the rest. On the mainframe the programmer passes not only the address of the memory to be freed to FREEMAIN but also the length to be freed. This is significantly more dangerous because one little mistake like above can lead to a deadlock. The programmer must keep all this minutiae in mind while programming (in assembler), especially when doing work in kernel.
This deadlock took weeks to sift through the kernel dumps to find the root cause. Fortunately the subsidiary's code contained some eye catchers when they wrote their data memory. Eventually we had to simply ask. They looked through their code and embarrassingly, they fixed the bug. But only after the company had lost a significant amount of money due to performance penalties.
Deadlocks are hard to diagnose, debug, and fix. I'd rather have a panic with a register dump telling me, "there's the problem, go fix it."
Ever since my ports bit was upgraded to include src, I run -CURRENT everywhere. Each of my machines has an alternate boot partition, a FreeBSD-CURRENT I can fall back to in case anything goes horribly wrong, plus an external USB boot disk for the extremely rare circumstance when nothing else will work. -CURRENT has been stable for me and any time I've never needed the alternate boot partitions for recovery, except when I've shot myself in the foot, my self and my fault. The last time my -CURRENT panicked was, again, my fault, playing around with some half baked thing.
My uptimes are generally low since I installworld/installkernel quite regularly.
FreeBSD is simply rock solid and stable. Even -CURRENT.
johnknifton.com
11-CURRENT panicked a few times on me, newer -CURRENT versions indeed only when I messed up something myself.
