17.1. | How can I learn more about FreeBSD's internals? |
See the FreeBSD Architecture Handbook. Additionally, much general UNIX® knowledge is directly applicable to FreeBSD. | |
17.2. | How can I contribute to FreeBSD? What can I do to help? |
We accept all types of contributions: documentation, code, and even art. See the article on Contributing to FreeBSD for specific advice on how to do this. And thanks for the thought! | |
17.3. | What are snapshots and releases? |
There are currently 3 active/semi-active branches in the FreeBSD Subversion Repository. (Earlier branches are only changed very rarely, which is why there are only 3 active branches of development):
Right now, -CURRENT is the
13. | |
17.4. | How can I make the most of the data I see when my kernel panics? |
Here is typical kernel panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x40 fault code = supervisor read, page not present instruction pointer = 0x8:0xf014a7e5 stack pointer = 0x10:0xf4ed6f24 frame pointer = 0x10:0xf4ed6f28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 80 (mount) interrupt mask = trap number = 12 panic: page fault This message is not enough. While the instruction
pointer value is important, it is also configuration
dependent as it varies depending on the kernel image.
If it is a To proceed:
However, the best way to track down the cause of a panic is by capturing a crash dump, then using kgdb(1) to generate a stack trace on the crash dump. In any case, the method is this:
Note:If The make(1) process will have built two kernels.
To capture a crash dump, edit
Note:FreeBSD crash dumps are usually the same size as
physical RAM. Therefore, make sure there is enough
space in Once the crash dump has been recovered , get a stack trace as follows:
Note that there may be several screens worth of information. Ideally, use script(1) to capture all of them. Using the unstripped kernel image with all the debug symbols should show the exact line of kernel source code where the panic occurred. The stack trace is usually read from the bottom up to trace the exact sequence of events that lead to the crash. kgdb(1) can also be used to print out the contents of various variables or structures to examine the system state at the time of the crash. Tip:If a second computer is available, kgdb(1) can be configured to do remote debugging, including setting breakpoints and single-stepping through the kernel code. Note:If | |
17.5. | Why has |
The ELF toolchain does not, by default, make the
symbols defined in an executable visible to the dynamic
linker. Consequently To search, using
| |
17.6. | How can I increase or reduce the kernel address space on i386? |
By default, the kernel address space is 1 GB (2 GB for PAE) for i386. When running a network-intensive server or using ZFS, this will probably not be enough. Add the following line to the kernel configuration file to increase available space and rebuild the kernel: options KVA_PAGES= To find the correct value of
|
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.