8.1. I would like to customize my
kernel. Is it difficult?
Not at all! Check out the kernel config section of the Handbook.
Note: We recommend that you make a dated snapshot of your new /kernel called /kernel.YYMMDD after you
get it working properly. Also back up your new /modules
directory to /modules.YYMMDD. That way, if you make a mistake
the next time you play with your configuration you can boot the backup kernel instead of
having to fall back to kernel.GENERIC. This is particularly
important if you are now booting from a controller that GENERIC does not support.
8.2. My kernel compiles
fail because _hw_float is missing. How do I solve this
problem?
Let me guess. You removed npx0 (see npx(4)) from your
kernel configuration file because you do not have a math co-processor, right? Wrong! :-)
The npx0 is MANDATORY. Even if you do not have a mathematic co-processor,
you must include the npx0 device.
8.3. Why is my kernel so big
(over 10MB)?
Chances are, you compiled your kernel in debug mode. Kernels built in debug mode contain many symbols
that are used for debugging, thus greatly increasing the size of the kernel. Note that if
you running a FreeBSD 3.0 or later system, there will be little or no performance
decrease from running a debug kernel, and it is useful to keep one around in case of a
system panic.
However, if you are running low on disk space, or you simply do not want to run a
debug kernel, make sure that both of the following are true:
Both of the above situations will cause your kernel to be built in debug mode. As long
as you make sure you follow the steps above, you can build your kernel normally, and you
should notice a fairly large size decrease; most kernels tend to be around 1.5MB to
2MB.
8.4.
Why do I get interrupt conflicts with multi-port serial code?
When I compile a kernel with multi-port serial code, it tells me that only the
first port is probed and the rest skipped due to interrupt conflicts. How do I fix
this?
The problem here is that FreeBSD has code built-in to keep the kernel from getting
trashed due to hardware or software conflicts. The way to fix this is to leave out the
IRQ settings on all but one port. Here is an example:
#
# Multiport high-speed serial line - 16550 UARTS
#
device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr
device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr
device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr
8.5. Why does every kernel I try to build
fail to compile, even GENERIC?
There are a number of possible causes for this problem. They are, in no
particular order:
-
You are not using the new make buildkernel and make installkernel targets, and your source tree is different from
the one used to build the currently running system (e.g., you are compiling 4.3-RELEASE
on a 4.0-RELEASE system). If you are attempting an upgrade, please read the /usr/src/UPDATING file, paying particular attention to the ``COMMON
ITEMS'' section at the end.
-
You are using the new make buildkernel and make installkernel targets, but you failed to assert the completion
of the make buildworld target. The make
buildkernel target relies on files generated by the make
buildworld target to complete its job correctly.
-
Even if you are trying to build FreeBSD-STABLE,
it is possible that you fetched the source tree at a time when it was either being
modified, or broken for other reasons; only releases are absolutely guaranteed to be
buildable, although FreeBSD-STABLE builds fine the
majority of the time. If you have not already done so, try re-fetching the source tree
and see if the problem goes away. Try using a different server in case the one you are
using is having problems.
8.6. How can I verify
which scheduler is in use on a running system?
Just type:
# sysctl kern.quantum
If you see
unknown oid 'kern.quantum'
it means that the current scheduler is ``SCHED_ULE'', however, if you see
kern.quantum: 100000
then the original scheduler ``SCHED_4BSD'' is the current selection.
8.7. What is
'kern.quantum'?
``kern.quantum'' is the maximum number of ticks a process can run without being
preempted. It is specific to the 4BSD scheduler, so you can use its presence or absence
to determine which scheduler is in use.