Frequently Asked Questions for FreeBSD 7.`X`, 8.`X`, and 9.`X`
Prev |  | Next

# Chapter 8 Kernel Configuration

8.1. I would like to customize my kernel. Is it difficult?
8.2. My kernel compiles fail because `_hw_float` is missing. How do I solve this problem?
8.3. Why is my kernel so big (over 10 MB)?
8.4. Why do I get interrupt conflicts with multi-port serial code?
8.5. Why does every kernel I try to build fail to compile, even `GENERIC`?
8.6. How can I verify which scheduler is in use on a running system?
8.7. What is `kern.sched.quantum`?

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: The new `kernel` will be installed to the `/boot/kernel` directory along with its modules, while the old kernel and its modules will be moved to the `/boot/kernel.old` directory, so if you make a mistake the next time you play with your configuration you can boot the previous version of your kernel.

8.2. My kernel compiles fail because `_hw_float` is missing. How do I solve this problem?

You probably removed `npx0` (see npx(4)) from your kernel configuration file because you do not have a math co-processor. The `npx0` device is MANDATORY. Somewhere inside your hardware lies a device that provides hardware floating-point support, even if it is no longer a separate device as used in the good old 386 days. You must include the `npx0` device. Even if you manage to build a kernel without `npx0` support, it will not boot anyway.

8.3. Why is my kernel so big (over 10 MB)?

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 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:

- You do not have a line in your kernel configuration file that reads:

      makeoptions DEBUG=-g

- You are not running config(8) with the `-g` option.

Either of the above settings 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.5 MB to 2 MB.

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 `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 9.0-RELEASE on a 8.3-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 `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?

Check for the existence of the `kern.sched.quantum` sysctl. If you have it, you should see something like this:

    % sysctl kern.sched.quantum
    kern.sched.quantum: 99960

If the `kern.sched.quantum` sysctl exists, you are using the 4BSD scheduler (sched_4bsd(4)). If not, you will get an error printed by sysctl(8) (which you can safely ignore):

    % sysctl kern.sched.quantum
    sysctl: unknown oid 'kern.sched.quantum'

The name of the scheduler currently being used is directly available as the value of the `kern.sched.name` sysctl:

    % sysctl kern.sched.name
    kern.sched.name: 4BSD

8.7. What is `kern.sched.quantum`?

`kern.sched.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.

Prev | Home | Next
User Applications |  | Disks, File Systems, and Boot Loaders