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? |
Please see the article on Contributing to FreeBSD for specific advice on how to do this. Assistance is more than welcome! | |
17.3. | What are snapshots and releases? |
There are currently four active/semi-active branches in the FreeBSD Subversion Repository. (Earlier branches are only changed very rarely, which is why there are only four active branches of development):
Right now, -CURRENT is the
10. | |
17.4. | Can I follow -CURRENT with limited Internet access? |
Yes, you can do this without downloading the whole source tree by using the CTM facility. | |
17.5. | I have written a kernel extension, who do I send it to? |
Please take a look at the article on Contributing to FreeBSD to learn how to submit code. And thanks for the thought! | |
17.6. | 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 When you see a message like this, it is not enough to
just reproduce it and send it in. The instruction pointer
value is important;
unfortunately, it is also configuration dependent. In other
words, the value varies depending on the exact kernel image
that you are using. If you are using a
What you should do is this:
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 you do not use the The make(1) process will have built two kernels.
To make sure you capture a crash dump, you need edit
Note:FreeBSD crash dumps are usually the same size as the
physical RAM size of your machine. That is, if you have
512 MB of RAM, you will get a 512 MB crash dump.
Therefore you must make sure there is enough space in
Once you have recovered the crash dump, you can get a stack trace with kgdb(1) as follows: %
(kgdb) backtrace Note that there may be several screens worth of information; ideally you should 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. Usually you have to read the stack trace from the bottom up to trace the exact sequence of events that lead to the crash. You can also use kgdb(1) to print out the contents of various variables or structures to examine the system state at the time of the crash. Tip:Now, if you are really insane and have a second computer, you can also configure kgdb(1) to do remote debugging such that you can use kgdb(1) on one system to debug the kernel on another system, including setting breakpoints, single-stepping through the kernel code, just like you can do with a normal user-mode program. Note:If you have | |
17.7. | Why has |
The ELF toolchain does not, by default, make the symbols
defined in an executable visible to the dynamic linker.
Consequently If you want to search, using
| |
17.8. | 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. If you run a network-intensive server (e.g., a FTP or HTTP server), or you want to use ZFS, you might find that is not enough. Add the following line to your kernel configuration file to increase available space and rebuild your kernel: options KVA_PAGES= N To find the correct value of
|
This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/
For questions about FreeBSD, read the
documentation before
contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.