diff --git a/handbook/dialup.sgml b/handbook/dialup.sgml index 06980f2f44..7c54b179fe 100644 --- a/handbook/dialup.sgml +++ b/handbook/dialup.sgml @@ -1,810 +1,812 @@ Dialup access

Contributed by &a.ghelmer;. This document provides suggestions for configuring a FreeBSD system to handle dialup modems. This document is written based on the author's experience with FreeBSD versions 1.0, 1.1, and 1.1.5.1 (and experience with dialup modems on other UNIX-like operating systems); however, this document may not answer all of your questions or provide examples specific enough to your environment. The author cannot be responsible if you damage your system or lose data due to attempting to follow the suggestions here. Prerequisites

To begin with, the author assumes you have some basic knowledge of FreeBSD. You need to have FreeBSD installed, know how to edit files in a UNIX-like environment, and how to look up manual pages on the system. As discussed below, you'll need certain versions of FreeBSD, and knowledge of some terminology & modem and cabling. FreeBSD Version

First, it is assumed that you are using FreeBSD version 1.1 or higher (including versions 2.x). FreeBSD version 1.0 included two different serial drivers, which complicates the situation. Also, the serial device driver (Terminology

A quick rundown of terminology: If you need more information about these terms and data communications in general, the author remembers reading that External vs. Internal Modems

External modems seem to be more convenient for dialup, because external modems often can be semi-permanently configured via parameters stored in non-volatile RAM and they usually provide lighted indicators that display the state of important RS-232 signals. Blinking lights impress visitors, but lights are also very useful to see whether a modem is operating properly. Internal modems usually lack non-volatile RAM, so their configuration may be limited only to setting DIP switches. If your internal modem has any signal indicator lights, it is probably difficult to view the lights when the system's cover is in place. Modems and Cables

A background knowledge of these items is assumed You know how to connect your modem to your computer so that the two can communicate (unless you have an internal modem, which doesn't need such a cable) You are familiar with your modem's command set, or know where to look up needed commands You know how to configure your modem (probably via a terminal communications program) so you can set the non-volatile RAM parameters The first, connecting your modem, is usually simple - most straight-through serial cables work without any problems. You need to have a cable with appropriate connectors (DB-25 or DB-9, male or female) on each end, and the cable must be a DCE-to-DTE cable with these signals wired: Transmitted Data ( Received Data ( Request to Send ( Clear to Send ( Data Set Ready ( Data Terminal Ready ( Carrier Detect ( Signal Ground ( FreeBSD needs the Serial Interface Considerations

FreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based EIA RS-232C (CCITT V.24) communications interfaces. The 8250 and 16450 devices have single-character buffers. The 16550 device provides a 16-character buffer, which allows for better system performance. (Bugs in plain 16550's prevent the use of the 16-character buffer, so use 16550A's if possible). Because single-character-buffer devices require more work by the operating system than the 16-character-buffer devices, 16550A-based serial interface cards are much prefered. If the system has many active serial ports or will have a heavy load, 16550A-based cards are better for low-error-rate communications. Quick Overview

Here is the process that FreeBSD follows to accept dialup logins. A /dev/ttyd0, for our example). The command 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0 When a user dials the modem's line and the modems connect, the /usr/bin/login, which completes the login by asking for the user's password and then starting the user's shell. Let's dive into the configuration... Kernel Configuration

FreeBSD kernels typically come prepared to search for four serial ports, known in the PC-DOS world as /sbin/dmesg command to replay the kernel's boot messages. In particular, look for messages that start with the characters /sbin/dmesg | grep 'sio' For example, on a system with four serial ports, these are the serial-port specific kernel boot messages: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 9 on isa sio3: type 16550A If your kernel doesn't recognize all of your serial ports, you'll probably need to configure a custom FreeBSD kernel for your system. Please see the BSD System Manager's Manual chapter on ``Building Berkeley Kernels with Config'' [the source for which is in /usr/src/share/doc/smm] and ``FreeBSD Configuration -Options'' [in /sys/doc/options.doc] for more +Options'' [in /sys/conf/options and in +/sys/arch/conf/options.arch, with +arch for example being i386] for more information on configuring and building kernels. You may have to unpack the kernel source distribution if haven't installed the system sources already (srcdist/srcsys.?? in FreeBSD 1.1, srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire source distribution in FreeBSD 2.0) to be able to configure and build kernels. Create a kernel configuration file for your system (if you haven't already) by /sys/i386/conf. Then, if you are creating a new custom configuration file, copy the file GENERICAH (or GENERICBT, if you have a BusTek SCSI controller on FreeBSD 1.x) to device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr You can comment-out or completely remove lines for devices you don't have. If you have a multiport serial board, such as the Boca Board BB2016, please see the can't share interrupts on ISA-bus PCs (multiport boards have on-board electronics that allow all the 16550A's on the board to share one or two interrupt request lines). When you are finished adjusting the kernel configuration file, use the program Device Special Files

Most devices in the kernel are accessed through ``device special files'', which are located in the /dev directory. The /dev/ttyd? (dial-in) and /dev/cua0? (call-out) devices. On FreeBSD version 1.1.5 and higher, there are also initialization devices (/dev/ttyid? and /dev/cuai0?) and locking devices (/dev/ttyld? and /dev/cual0?). The initialization devices are used to initialize communications port parameters each time a port is opened, such as crtscts for modems which use CTS/RTS signaling for flow control. The locking devices are used to lock flags on ports to prevent users or programs changing certain parameters; see the manual pages Making Device Special Files

A shell script called /dev directory manages the device special files. (The manual page for /dev and issue the command /dev/ttyd? device special files, but also creates the /dev/cua0? (and all of the initializing and locking special files under FreeBSD 1.1.5 and up) and removes the hardwired terminal special file /dev/tty0?, if it exists. After making new device special files, be sure to check the permissions on the files (especially the /dev/cua* files) to make sure that only users who should have access to those device special files can read & write on them - you probably don't want to allow your average user to use your modems to dialout. The default permissions on the /dev/cua* files should be sufficient: crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01 crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01 crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01 These permissions allow the user Configuration Files

There are three system configuration files in the /etc directory that you'll probably need to edit to allow dialup access to your FreeBSD system. The first, /etc/gettytab, contains configuration information for the /usr/libexec/getty daemon. Second, /etc/ttys holds information that tells /sbin/init what /etc/rc.serial script if you have FreeBSD 1.1.5.1 or higher; otherwise, you can initialize ports in the /etc/rc.local script. There are two schools of thought regarding dialup modems on UNIX. One group likes to configure their modems and system so that no matter at what speed a remote user dials in, the local computer-to-modem RS-232 interface runs at a locked speed. The benefit of this configuration is that the remote user always sees a system login prompt immediately. The downside is that the system doesn't know what a user's true data rate is, so full-screen programs like Emacs won't adjust their screen-painting methods to make their response better for slower connections. The other school configures their modems' RS-232 interface to vary its speed based on the remote user's connection speed. For example, V.32bis (14.4 Kbps) connections to the modem might make the modem run its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the modem's RS-232 interface run at 2400 bps. Because <Enter> key until they see a recognizable prompt. If the data rates don't match, /etc/gettytab

/etc/gettytab is a Locked-Speed Config

If you are locking your modem's data communications rate at a particular speed, you probably won't need to make any changes to /etc/gettytab. Matching-Speed Config

You'll need to setup an entry in /etc/gettytab to give # # Fast dialup terminals, 2400/1200/300 rotary (can start either way) # D2400|d2400|Fast-Dial-2400:\ :nx=D1200:tc=2400-baud: 3|D1200|Fast-Dial-1200:\ :nx=D300:tc=1200-baud: 5|D300|Fast-Dial-300:\ :nx=D2400:tc=300-baud: If you have a higher speed modem, you'll probably need to add an entry in /etc/gettytab; here's an entry you could use for a 14.4 Kbps modem with a top interface speed of 19.2 Kpbs: # # Additions for a V.32bis Modem # um|V300|High Speed Modem at 300,8-bit:\ :nx=V19200:tc=std.300: un|V1200|High Speed Modem at 1200,8-bit:\ :nx=V300:tc=std.1200: uo|V2400|High Speed Modem at 2400,8-bit:\ :nx=V1200:tc=std.2400: up|V9600|High Speed Modem at 9600,8-bit:\ :nx=V2400:tc=std.9600: uq|V19200|High Speed Modem at 19200,8-bit:\ :nx=V9600:tc=std.19200: On FreeBSD 1.1.5 and later, this will result in 8-bit, no parity connections. Under FreeBSD 1.1, add std. entries at the top of the file for 8 bits, no parity; otherwise, the default is 7 bits, even parity. The example above starts the communications rate at 19.2 Kbps (for a V.32bis connection), then cycles through 9600 bps (for V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps. Communications rate cycling is implemented with the # # Additions for a V.32bis or V.34 Modem # Starting at 57.6 Kpbs # vm|VH300|Very High Speed Modem at 300,8-bit:\ :nx=VH57600:tc=std.300: vn|VH1200|Very High Speed Modem at 1200,8-bit:\ :nx=VH300:tc=std.1200: vo|VH2400|Very High Speed Modem at 2400,8-bit:\ :nx=VH1200:tc=std.2400: vp|VH9600|Very High Speed Modem at 9600,8-bit:\ :nx=VH2400:tc=std.9600: vq|VH57600|Very High Speed Modem at 57600,8-bit:\ :nx=VH9600:tc=std.57600: If you have a slow CPU or a heavily loaded system and you don't have 16550A-based serial ports, you may receive sio ``silo'' errors at 57.6 Kbps. /etc/ttys

/etc/ttys is the list of /etc/ttys also provides security information to /etc/ttys or add new lines to make ttyd0 "/usr/libexec/getty xxx" dialup on The first item in the above line is the device special file for this entry - /dev/ttyd0 is the file that this "/usr/libexec/getty (secure, but it should only be used for terminals which are physically secure (such as the system console). The default terminal type (/etc/ttys, you may send the kill -1 1 to send the signal. If this is your first time setting up the system, though, you may want to wait until your modem(s) are properly configured and connected before signaling Locked-Speed Config

For a locked-speed configuration, your ttyd0 "/usr/libexec/getty std.19200" dialup on If your modem is locked at a different data rate, substitute the appropriate name for the std. entry for /etc/gettytab for your modem's data rate. Matching-Speed Config

In a matching-speed configuration, your /etc/gettytab. For example, if you added the above suggested entry for a matching-speed modem that starts at 19.2 Kbps (the ttyd0 "/usr/libexec/getty V19200" dialup on /etc/rc.serial or /etc/rc.local

High-speed modems, like V.32, V.32bis, and V.34 modems, need to use hardware (RTS/CTS) flow control. You can add /etc/rc.serial on FreeBSD 1.1.5.1 and up, or /etc/rc.local on FreeBSD 1.1, to set the hardware flow control flag in the FreeBSD kernel for the modem ports. For example, on a sample FreeBSD 1.1.5.1 system, /etc/rc.serial reads: #!/bin/sh # # Serial port initial configuration stty -f /dev/ttyid1 crtscts stty -f /dev/cuai01 crtscts which sets the # Set serial ports to use RTS/CTS flow control stty -f /dev/ttyd0 crtscts stty -f /dev/ttyd1 crtscts stty -f /dev/ttyd2 crtscts stty -f /dev/ttyd3 crtscts Since there isn't an initialization device special file on FreeBSD 1.1, one has to just set the flags on the sole device special file and hope the flags aren't cleared by a miscreant. Modem Settings

If you have a modem whose parameters may be permanently set in non-volatile RAM, you'll need to use a terminal program (such as Telix under PC-DOS or Disable XON/XOFF flow control Quiet mode (no result codes) No command echo Please read the documentation for your modem to find out what commands and/or DIP switch settings you need to give it. For example, to set the above parameters on a USRobotics Sportster 14,400 external modem, one could give these commands to the modem: ATZ AT&C1&D2&H1&I0&R2&W You might also want to take this opportunity to adjust other settings in the modem, such as whether it will use V.42bis and/or MNP5 compression. The USR Sportster 14,400 external modem also has some DIP switches that need to be set; for other modems, perhaps you can use these settings as an example: Switch 1: UP - DTR Normal Switch 2: Don't care (Verbal Result Codes/Numeric Result Codes) Switch 3: UP - Suppress Result Codes Switch 4: DOWN - No echo, offline commands Switch 5: UP - Auto Answer Switch 6: UP - Carrier Detect Normal Switch 7: UP - Load NVRAM Defaults Switch 8: Don't care (Smart Mode/Dumb Mode) Result codes should be disabled/suppressed for dialup modems to avoid problems that can occur if Locked-speed Config

For a locked-speed configuration, you'll need to configure the modem to maintain a constant modem-to-computer data rate independent of the communications rate. On a USR Sportster 14,400 external modem, these commands will lock the modem-to-computer data rate at the speed used to issue the commands: ATZ AT&B1&W Matching-speed Config

For a variable-speed configuration, you'll need to configure your modem to adjust its serial port data rate to match the incoming call rate. On a USR Sportster 14,400 external modem, these commands will lock the modem's error-corrected data rate to the speed used to issue the commands, but allow the serial port rate to vary for non-error-corrected connections: ATZ AT&B2&W Checking the Modem's Configuration

Most high-speed modems provide commands to view the modem's current operating parameters in a somewhat human-readable fashion. On the USR Sportster 14,400 external modems, the command Troubleshooting

Here are a few steps you can follow to check out the dialup modem on your system. Checking out the FreeBSD system

Hook up your modem to your FreeBSD system, boot the system, and, if your modem has status indication lights, watch to see whether the modem's 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0 115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1 If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0 ^^ and the modem hasn't accepted a call yet, this means that /etc/ttys to see if there are any mistakes there. Also, check the log file /var/log/messages to see if there are any log messages from /etc/ttys and /etc/gettytab, as well as the appropriate device special files /dev/ttyd?, for any mistakes, missing entries, or missing device special files. Try Dialing In

Try dialing into the system; be sure to use 8 bits, no parity, 1 stop bit on the remote system. If you don't get a prompt right away, or get garbage, try pressing <Enter> about once per second. If you still don't see a BREAK. If you are using a high-speed modem to do the dialing, try dialing again after locking the dialing modem's interface speed (via AT&B1 on a USR Sportster, for example). If you still can't get a /etc/gettytab again and double-check that The initial capability name specified in /etc/ttys for the line matches a name of a capability in /etc/gettytab Each Each If you dial but the modem on the FreeBSD system won't answer, make sure that the modem is configured to answer the phone when describing your modem and your problem, and the good folks on the list will try to help. Acknowledgments

Thanks to these people for comments and advice: diff --git a/handbook/kernelconfig.sgml b/handbook/kernelconfig.sgml index bd9406ad38..6db11d8bf9 100644 --- a/handbook/kernelconfig.sgml +++ b/handbook/kernelconfig.sgml @@ -1,1243 +1,1260 @@ - + Configuring the FreeBSD Kernel

Contributed by &a.jehamby;.6 October 1995. This large section of the handbook discusses the basics of building your own custom kernel for FreeBSD. This section is appropriate for both novice system administrators and those with advanced Unix experience. Why build a custom kernel?

Building a custom kernel is one of the most important rites of passage every Unix system administrator must learn. This process, while time-consuming, will provide many benefits to your FreeBSD system. Unlike the GENERIC kernel, which must support every possible SCSI and network card, along with tons of other rarely used hardware support, a custom kernel only contains support for your PC's hardware. This has a number of benefits: It will take less time to boot because it does not have to spend time probing for hardware which you do not have. A custom kernel often uses less memory, which is important because the kernel is the one process which must always be present in memory, and so all of that unused code ties up pages of RAM that your programs would otherwise be able to use. Therefore, on a system with limited RAM, building a custom kernel is of critical importance. Finally, there are several kernel options which you can tune to fit your needs, and device driver support for things like sound cards which you can include in your kernel but are not present in the GENERIC kernel.

Building and Installing a Custom Kernel

First, let us take a quick tour of the kernel build directory. All directories mentioned will be relative to the main /usr/src/sys directory, which is also accessible through /sys. There are a number of subdirectories here representing different parts of the kernel, but the most important, for our purposes, are i386/conf, where you will edit your custom kernel configuration, and compile, which is the staging area where your kernel will be built. Notice the logical organization of the directory tree, with each supported device, filesystem, and option in its own subdirectory. Also, anything inside the i386 directory deals with PC hardware only, while everything outside the i386 directory is common to all platforms which FreeBSD could potentially be ported to. not a /usr/src/sys directory on your system, then the kernel source has not been been installed. Follow the instructions for installing packages to add this package to your system. Next, move to the i386/conf directory and copy the GENERIC configuration file to the name you want to give your kernel. For example: # cd /usr/src/sys/i386/conf # cp GENERIC MYKERNEL Traditionally, this name is in all capital letters and, if you are maintaining multiple FreeBSD machines with different hardware, it's a good idea to name it after your machine's hostname. We will call it MYKERNEL for the purpose of this example. Now, edit MYKERNEL with your favorite text editor. If you're just starting out, the only editor available will probably be vi, which is too complex to explain here, but is covered well in many books in the . Feel free to change the comment lines at the top to reflect your configuration or the changes you've made to differentiate it from GENERIC. If you've build a kernel under SunOS or some other BSD operating system, much of this file will be very familiar to you. If you're coming from some other operating system such as DOS, on the other hand, the GENERIC configuration file might seem overwhelming to you, so follow the descriptions in the section slowly and carefully. config(8) from the same place you got the new kernel sources. It is located in /usr/src/usr.sbin, so you'll need to download those sources as well. Re-build and install it before running the next commands. When you're finished, type the following to compile and install your kernel: # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # make depend # make # make install The new kernel will be copied to the root directory as /kernel and the old kernel will be moved to /kernel.old. Now, shutdown the system and reboot to use your kernel. In case something goes wrong, there are some instructions at the end of this document. Be sure to read the section which explains how to recover in case your new kernel . to your /dev directory before you can use them. The Configuration File

The general format of a configuration file is quite simple. Each line contains a keyword and one or more arguments. For simplicity, most lines only contain one argument. Anything following a # is considered a comment and ignored. The following sections describe each keyword, generally in the order they are listed in GENERIC, although some related keywords have been grouped together in a single section (such as Networking) even though they are actually scattered throughout the GENERIC file. An exhaustive list of options and more detailed explanations of the device lines is present in the LINT configuration file, located in the same directory as GENERIC. If you are in doubt as to the purpose or necessity of a line, check first in LINT. +

The kernel is currently being moved to a better organization + of the option handling. Traditionally, each option in the + config file was simply converted into a -D switch + for the CFLAGS line of the kernel Makefile. Naturally, + this caused a creaping optionism, with nobody really knowing + which option has been referenced in what files. + +

In the new scheme, every #ifdef that is intended to + be dependant upon an option gets this option out of an + opt_foo.h declaration file created in the + compile directory by config. The list of valid options + for config lives in two files: options that don't + depend on the architecture are listed in + /sys/conf/options, architecture-dependant ones + in /sys/arch/conf/options.arch, + with arch being for example i386. + Mandatory Keywords

These keywords are required in every kernel you build. machine ``i386''

The first keyword is machine, which, since FreeBSD only runs on Intel 386 and compatible chips, is i386. Note: that any keyword which contains numbers used as text must be enclosed in quotation marks, otherwise config gets confused and thinks you mean the actual number 386. cpu ``cpu_type''

The next keyword is cpu, which includes support for each CPU supported by FreeBSD. The possible values of cpu_type include: I386_CPU I486_CPU I586_CPU and multiple instances of the cpu line may be present with different values of cpu_type as are present in the GENERIC kernel. For a custom kernel, it is best to specify only the cpu you have. If, for example, you have an Intel Pentium, use I586_CPU for cpu_type. ident machine_name

Next, we have ident, which is the identification of the kernel. You should change this from GENERIC to whatever you named your kernel, in this example, MYKERNEL. The value you put in ident will print when you boot up the kernel, so it's useful to give a kernel a different name if you want to keep it separate from your usual kernel (if you want to build an experimental kernel, for example). Note that, as with machine and cpu, enclose your kernel's name in quotation marks if it contains any numbers. Since this name is passed to the C compiler as a -D switch, don't use names like DEBUG, or something that could be confused with another machine or CPU name, like vax. maxusers number

This file sets the size of a number of important system tables. This number is supposed to be roughly equal to the number of simultaneous users you expect to have on your machine. However, under normal circumstances, you will want to set maxusers to at least four, especially if you're using X Windows or compiling software. The reason is that the most important table set by maxusers is the maximum number of processes, which is set to 20 + 16 * maxusers, so if you set maxusers to one, then you can only have 36 simultaneous processes, including the 18 or so that the system starts up at boot time, and the 15 or so you will probably create when you start X Windows. Even a simple task like reading a man page will start up nine processes to filter, decompress, and view it. Setting maxusers to 4 will allow you to have up to 84 simultaneous processes, which should be enough for anyone. If, however, you see the dreaded ``proc table full'' error when trying to start another program, or are running a server with a large number of simultaneous users (like Walnut Creek CDROM's FTP site), you can always increase this number and rebuild. maxuser does not limit the number of users which can log into your machine. It simply sets various table sizes to reasonable values considering the maximum number of users you will likely have on your system and how many processes each of them will be running. One keyword which does limit the number of simultaneous remote logins is . config kernel_name root on root_device

This line specifies the location and name of the kernel. Traditionally the kernel is called vmunix but in FreeBSD, it is aptly named kernel. You should always use kernel for kernel_name because changing it will render numerous system utilities inoperative. The second part of the line specifies the disk and partition where the root filesystem and kernel can be found. Typically this will be wd0 for systems with non-SCSI drives, or sd0 for systems with SCSI drives. General Options

These lines provide kernel support for various filesystems and other options.

This line allows the kernel to simulate a math co-processor if your computer does not have one (386 or 486SX). If you have a Pentium, a 486DX, or a 386 or 486SX with a separate 387 or 487 chip, you can comment this line out. Note: The normal math co-processor emulation routines that come with FreeBSD are not very accurate. If you do not have a math co-processor, and you need the best accuracy, I recommend that you change this option to GPL_MATH_EMULATE to use the superior GNU math support, which is not included by default for licensing reasons. options ``COMPAT_43''

Compatibility with BSD 4.3. Leave this in; some programs will act strangely if you comment this out. options BOUNCE_BUFFERS

ISA devices and EISA devices operating in an ISA compatibility mode can only perform DMA (Direct Memory Access) to memory below 16 megabytes. This option enables such devices to work in systems with more than 16 megabytes of memory. options UCONSOLE

Allow users to grab the console, useful for X Windows. For example, you can create a console xterm by typing xterm -C, which will display any `write', `talk', and other messages you receive, as well as any console messages sent by the kernel. options SYSVSHM

This option provides for System V shared memory. The most common use of this is the XSHM extension in X Windows, which many graphics-intensive programs (such as the movie player XAnim, and Linux DOOM) will automatically take advantage of for extra speed. If you use X Windows, you'll definitely want to include this. options SYSVSEM

Support for System V semaphores. Less commonly used but only adds a few hundred bytes to the kernel. options SYSVMSG

Support for System V messages. Again, only adds a few hundred bytes to the kernel. ipcs(1) command will tell will list any processes using using each of these System V facilities. Filesystem Options

These options add support for various filesystems. You must include at least one of these to support the device you boot from; typically this will be FFS if you boot from a hard drive, or NFS if you are booting a diskless workstation from Ethernet. You can include other commonly-used filesystems in the kernel, but feel free to comment out support for filesystems you use less often (perhaps the MS-DOS filesystem?), since they will be dynamically loaded from the Loadable Kernel Module directory /lkm the first time you mount a partition of that type. options FFS

The basic hard drive filesystem; leave it in if you boot from the hard disk. options NFS

Network Filesystem. Unless you plan to mount partitions from a Unix file server over Ethernet, you can comment this out. options MSDOSFS

MS-DOS Filesystem. Unless you plan to mount a DOS formatted hard drive partition at boot time, you can safely comment this out. It will be automatically loaded the first time you mount a DOS partition, as described above. Also, the excellent mtools software (in the ports collection) allows you to access DOS floppies without having to mount and unmount them (and does not require MSDOSFS at all). options ``CD9660''

ISO 9660 filesystem for CD-ROMs. Comment it out if you do not have a CD-ROM drive or only mount data CD's occasionally (since it will be dynamically loaded the first time you mount a data CD). Audio CD's do not need this filesystem. options PROCFS

Process filesystem. This is a pretend filesystem mounted on /proc which allows programs like ps(1) to give you more information on what processes are running. options MFS

Memory-mapped file system. This is basically a RAM disk for fast storage of temporary files, useful if you have a lot of swap space that you want to take advantage of. A perfect place to mount an MFS partition is on the /tmp directory, since many programs store temporary data here. To mount an MFS RAM disk on /tmp, add the following line to /etc/fstab and then reboot or type mount /tmp: /dev/wd1s2b /tmp mfs rw 0 0 /dev/wd1s2b with the name of your swap partition, which will be listed in your /etc/fstab as follows: /dev/wd1s2b none swap sw 0 0 /tmp device simultaneously). As such, you may want to avoid it for now. --> Also, the MFS filesystem can not be dynamically loaded, so you must compile it into your kernel if you want to experiment with it. options QUOTA

Enable disk quotas. If you have a public access system, and do not want users to be able to overflow the /home partition, you can establish disk quotas for each user. This code is a little buggy, so do not enable it unless you have to. View the manual page for quota(1) to learn more about disk quotas. Basic Controllers and Devices

These sections describe the basic disk, tape, and CD-ROM controllers supported by FreeBSD. There are separate sections for controllers and cards. controller isa0

All PC's supported by FreeBSD have one of these. If you have an IBM PS/2 (Micro Channel Architecture), then you cannot run FreeBSD at this time. controller pci0

Include this if you have a PCI motherboard. This enables auto-detection of PCI cards and gatewaying from the PCI to the ISA bus. controller fdc0

Floppy drive controller: fd0 is the ``A:'' floppy drive, and fd1 is the ``B:'' drive. ft0 is a QIC-80 tape drive attached to the floppy controller. Comment out any lines corresponding to devices you do not have. ft(8), see the manual page for details. controller wdc0

This is the primary IDE controller. wd0 and wd1 are the master and slave hard drive, respectively. wdc1 is a secondary IDE controller where you might have a third or fourth hard drive, or an IDE CD-ROM. Comment out the lines which do not apply (if you have a SCSI hard drive, you'll probably want to comment out all six lines, for example). controller wcd0

This device provides IDE CD-ROM support. Be sure to leave wdc1 uncommented if your CD-ROM is on its own controller card. To use this, you must also include the line options ATAPI. device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr

npx0 is the interface to the floating point math unit in FreeBSD, either the hardware co-processor or the software math emulator. It is device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr

Wangtek and Archive QIC-02/QIC-36 tape drive support Proprietary CD-ROM support

The following drivers are for the so-called proprietary CD-ROM drives. These drives have their own controller card or might plug into a sound card such as the SoundBlaster 16. They are not IDE or SCSI. Most older single-speed and double-speed CD-ROMs use these interfaces, while newer quad-speeds are likely to be or . device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr

Mitsumi CD-ROM (LU002, LU005, FX001D). device scd0 at isa? port 0x230 bio

Sony CD-ROM (CDU31, CDU33A). controller matcd0 at isa? port ? bio

Matsushita/Panasonic CD-ROM (sold by Creative Labs for SoundBlaster). SCSI Device Support

This section describes the various SCSI controllers and devices supported by FreeBSD. SCSI Controllers

The next ten or so lines include support for different kinds of SCSI controllers. Comment out all except for the one(s) you have: controller bt0 at isa? port ``IO_BT0'' bio irq ? vector btintr

Most Buslogic controllers controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr

UltraStor 14F and 34F controller ahc0

Adaptec 274x/284x/294x controller ahb0 at isa? bio irq ? vector ahbintr

Adaptec 174x controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr

Adaptec 154x controller aic0 at isa? port 0x340 bio irq 11 vector aicintr

Adaptec 152x and sound cards using Adaptec AIC-6360 (slow!) controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr

ProAudioSpectrum cards using NCR 5380 or Trantor T130 controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr

Seagate ST01/02 8 bit controller (slow!) controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr

Western Digital WD7000 controller controller ncr0

NCR 53C810 and 53C825 PCI SCSI controller options ``SCSI_DELAY=15''

This causes the kernel to pause 15 seconds before probing each SCSI device in your system. If you only have IDE hard drives, you can ignore this, otherwise you'll probably want to lower this number, perhaps to 5 seconds, to speed up booting. Of course if you do this, and FreeBSD has trouble recognizing your SCSI devices, you'll have to raise it back up. controller scbus0

If you have any SCSI controllers, this line provides generic SCSI support. If you do not have SCSI, you can comment this, and the following three lines, out. device sd0

Support for SCSI hard drives. device st0

Support for SCSI tape drives. device cd0

Support for SCSI CD-ROM drives.

Note that the number 0 in the above entries is slightly misleading: all these devices are automatically configured as they are found, regardless of how many of them are hooked up to the SCSI bus(es), and which target IDs they have. If you want to ``wire down'' specific target IDs to particular devices, refer to the appropriate section of the LINT kernel config file. Console, Bus Mouse, and X Server Support

You must choose one of these two console types, and, if you plan to use X Windows, enable the XSERVER option and optionally, a bus mouse or PS/2 mouse device. device sc0 at isa? port ``IO_KBD' tty irq 1 vector scintr

sc0 is the default console driver, which resembles an SCO console. Since most full-screen programs access the console through a terminal database library like termcap, it should not matter much whether you use this or vt0, the VT220 compatible console driver. When you log in, set your TERM variable to ``scoansi'' if full-screen programs have trouble running under this console. device vt0 at isa? port ``IO_KBD'' tty irq 1 vector pcrint

This is a VT220-compatible console driver, backwards compatible to VT100/102. It works well on some laptops which have hardware incompatibilities with sc0. Also, set your TERM variable to ``vt100'' or ``vt220'' when you log in. This driver might also prove useful when connecting to a large number of different machines over the network, where the termcap or terminfo entries for the sc0 device are often not available -- ``vt100'' should be available on virtually any platform. options ``PCVT_FREEBSD=210''

Required with the vt0 console driver. options XSERVER

This includes code required to run the XFree86 X Window Server. device mse0 at isa? port 0x23c tty irq 5 vector ms

Use this device if you have a Logitech or ATI InPort bus mouse card. port is enabled (probably COM1). device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr

Use this device if your mouse plugs into the PS/2 mouse port. Serial and Parallel Ports

Nearly all systems have these. If you are attaching a printer to one of these ports, the section of the handbook is very useful. If you are using modem, provides extensive detail on serial port configuration for use with such devices. device sio0 at isa? port ``IO_COM1'' tty irq 4 vector siointr

sio0 through sio3 are the four serial ports referred to as COM1 through COM4 in the MS-DOS world. Note that if you have an internal modem on COM4 and a serial port at COM2 you will have to change the IRQ of the modem to 2 (for obscure technical reasons IRQ 2 = IRQ 9) in order to access it from FreeBSD. If you have a multiport serial card, check the manual page for sio(4) for more information on the proper values for these lines. Some video cards (notably those based on S3 chips) use IO addresses of the form 0x*2e8, and since many cheap serial cards do not fully decode the 16-bit IO address space, they clash with these cards, making the COM4 port practically unavailable. Each serial port is required to have a unique IRQ (unless you are using one of the multiport cards where shared interrupts are supported), so the default IRQs for COM3 and COM4 cannot be used. device lpt0 at isa? port? tty irq 7 vector lptintr

lpt0 through lpt2 are the three printer ports you could conceivably have. Most people just have one, though, so feel free to comment out the other two lines if you do not have them. Networking

FreeBSD, as with Unix in general, places a big emphasis on networking. Therefore, even if you do not have an Ethernet card, pay attention to the mandatory options and the dial-up networking support. options INET Networking support. Leave it in even if you do not plan to be connected to a network. Most programs require at least loopback networking (i.e. making network connections within your PC) so this is essentially mandatory. Ethernet cards

The next lines enable support for various Ethernet cards. If you do not have a network card, you can comment out all of these lines. Otherwise, you'll want to leave in support for your particular Ethernet card(s): device de0

Digital Equipment DC21040 PCI Ethernet adapter device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr

Cronyx/Sigma multiport sync/async (with Cisco or PPP framing) device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr

Western Digital and SMC 80xx; Novell NE1000 and NE2000; 3Com 3C503 device el0 at isa? port 0x300 net irq 9 vector elintr

3Com 3C501 (slow!) device eg0 at isa? port 0x310 net irq 5 vector egintr

3Com 3C505 device ep0 at isa? port 0x300 net irq 10 vector epintr

3Com 3C509 (buggy) device fe0 at isa? port 0x240 net irq ? vector feintr

Fujitsu MB86960A/MB86965A Ethernet device fea0 at isa? net irq ? vector feaintr

DEC DEFEA EISA FDDI adapter device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr

AT&T StarLAN 10 and EN100; 3Com 3C507; unknown NI5210 device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr

Intel EtherExpress 16 device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr

Digital Equipment EtherWorks 2 and EtherWorks 3 (DEPCA, DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422) device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr

Lance/PCnet cards (Isolan, Novell NE2100, NE32-VL) device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr

IBM/National Semiconductor PCMCIA ethernet controller. device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr

3Com PCMCIA Etherlink III pseudo-device loop

loop is the generic loopback device for TCP/IP. If you telnet or FTP to localhost (a.k.a. 127.0.0.1) it will come back at you through this pseudo-device. Mandatory. pseudo-device ether

ether is only needed if you have an Ethernet card and includes generic Ethernet protocol code. pseudo-device sl number

sl is for SLIP (Serial Line Internet Protocol) support. This has been almost entirely supplanted by PPP, which is easier to set up, better suited for modem-to-modem connections, as well as more powerful. The number after sl specifies how many simultaneous SLIP sessions to support. This handbook has more information on setting up a SLIP or . pseudo-device ppp number

ppp is for kernel-mode PPP (Point-to-Point Protocol) support for dial-up Internet connections. There is also version of PPP implemented as a user application that uses the tun and offers more flexibility and features such as demand dialing. If you still want to use this PPP driver, read the section of the handbook. As with the sl device, number specifies how many simultaneous PPP connections to support. pseudo-device tun number

tun is used by the user-mode PPP software. This program is easy to set up and very fast. It also has special features such as automatic dial-on-demand. The number after tun specifies the number of simultaneous PPP sessions to support. See the section of the handbook for more information. pseudo-device bpfilter number

Berkeley packet filter. This pseudo-device allows network interfaces to be placed in promiscuous mode, capturing every packet on a broadcast network (e.g. an ethernet). These packets can be captured to disk and/or examined with the tcpdump(1) program. Note that implementation of this capability can seriously compromise your overall network security. The number after bpfilter is the number of interfaces that can be examined simultaneously. Optional, not recommended except for those who are fully aware of the potential pitfalls. Not all network cards support this capability. Sound cards

This is the first section containing lines that are not in the GENERIC kernel. To include sound card support, you'll have to copy the appropriate lines from the LINT kernel (which contains support for every device) as follows: controller snd0

Generic sound driver code. Required for all of the following sound cards except pca. device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr

ProAudioSpectrum digital audio and MIDI. device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr

SoundBlaster digital audio. irq 7 to, for example, irq 5 and remove the conflicts keyword. Also, you must add the line: options ``SBC_IRQ=5'' device sbxvi0 at isa? drq 5

SoundBlaster 16 digital 16-bit audio. drq 5 keyword appropriately, and then add the line: options "SB16_DMA=6" device sbmidi0 at isa? port 0x330

SoundBlaster 16 MIDI interface. If you have a SoundBlaster 16, you must include this line, or the kernel will not compile. device gus0 at isa? port 0x220 irq 10 drq 1 vector gusintr

Gravis Ultrasound. device mss0 at isa? port 0x530 irq 10 drq 1 vector adintr

Microsoft Sound System. device opl0 at isa? port 0x388 conflicts

AdLib FM-synthesis audio. Include this line for AdLib, SoundBlaster, and ProAudioSpectrum users, if you want to play MIDI songs with a program such as playmidi (in the ports collection). device mpu0 at isa? port 0x330 irq 6 drq 0

Roland MPU-401 stand-alone card. device uart0 at isa? port 0x330 irq 5 vector ``m6850intr''

Stand-alone 6850 UART for MIDI. device pca0 at isa? port ``IO_TIMER1'' tty

Digital audio through PC speaker. This is going to be very poor sound quality and quite CPU-intensive, so you have been warned (but it does not require a sound card). /usr/src/sys/i386/isa/sound/sound.doc. Also, if you add any of these devices, be sure to create the sound . Pseudo-devices

Pseudo-device drivers are parts of the kernel that act like device drivers but do not correspond to any actual hardware in the machine. The pseudo-devices are in that section, while the remainder are here. pseudo-device gzip

gzip allows you to run FreeBSD programs that have been compressed with gzip. The programs in /stand are compressed so it is a good idea to have this option in your kernel.

pseudo-device log

log is used for logging of kernel error messages. Mandatory. pseudo-device pty number

pty is a ``pseudo-terminal'' or simulated login port. It's used by incoming telnet and rlogin sessions, xterm, and some other applications such as emacs. The number indicates the number of ptys to create. If you need more than GENERIC default of 16 simultaneous xterm windows and/or remote logins, be sure to increase this number accordingly, up to a maximum of 64. pseudo-device snp number

Snoop device. This pseudo-device allows one terminal session to watch another using the watch(8) command. Note that implementation of this capability has important security and privacy implications. The number after snp is the total number of simultaneous snoop sessions. Optional. pseudo-device vn

Vnode driver. Allows a file to be treated as a device after being set up with the vnconfig(8) command. This driver can be useful for manipulating floppy disk images and using a file as a swap device (e.g. an MS Windows swap file). Optional. Joystick, PC Speaker, Miscellaneous

This section describes some miscellaneous hardware devices supported by FreeBSD. Note that none of these lines are included in the GENERIC kernel, you'll have to copy them from this handbook or the LINT kernel (which contains support for every device): device joy0 at isa? port ``IO_GAME''

PC joystick device. pseudo-device speaker

Supports IBM BASIC-style noises through the PC speaker. Some fun programs which use this are /usr/sbin/spkrtest, which is a shell script that plays some simple songs, and /usr/games/piano which lets you play songs using the keyboard as a simple piano (this file only exists if you've installed the games package). Also, the excellent text role-playing game NetHack (in the ports collection) can be configured to use this device to play songs when you play musical instruments in the game.

See also the device. Making Device Nodes

Almost every device in the kernel has a corresponding ``node'' entry in the /dev directory. These nodes look like regular files, but are actually special entries into the kernel which programs use to access the device. The shell script /dev/MAKEDEV, which is executed when you first install the operating system, creates nearly all of the device nodes supported. However, it does not create all of them, so when you add support for a new device, it pays to make sure that the appropriate entries are in this directory, and if not, add them. Here is a simple example: Suppose you add the IDE CD-ROM support to the kernel. The line to add is: controller wcd0 This means that you should look for some entries that start with wcd0 in the /dev directory, possibly followed by a letter, such as `c', or preceded by the letter 'r', which means a `raw' device. It turns out that those files are not there, so I must change to the /dev directory and type: # sh MAKEDEV wcd0 When this script finishes, you will find that there are now wcd0c and rwcd0c entries in /dev so you know that it executed correctly. For sound cards, the command: # sh MAKEDEV snd0 creates the appropriate entries. Follow this simple procedure for any other non-GENERIC devices which do not have entries. /dev entries, so you do not need to create these. Also, network cards and SLIP/PPP pseudo-devices do not have entries in /dev at all, so you do not have to worry about these either. If Something Goes Wrong

There are four categories of trouble that can occur when building a custom kernel. They are: Config command fails

If the config command fails when you give it your kernel description, you've probably made a simple error somewhere. Fortunately, config will print the line number that it had trouble with, so you can quickly skip to it with vi. For example, if you see: config: line 17: syntax error you can skip to the problem in vi by typing ``17G'' in command mode. Make sure the keyword is typed correctly, by comparing it to the GENERIC kernel or another reference. Make command fails

If the make command fails, it usually signals an error in your kernel description, but not severe enough for config to catch it. Again, look over your configuration, and if you still cannot resolve the problem, send mail to with your kernel configuration, and it should be diagnosed very quickly. Kernel will not boot

If your new kernel does not boot, or fails to recognize your devices, do not panic! Fortunately, BSD has an excellent mechanism for recovering from incompatible kernels. Simply type the name of the kernel you want to boot from (i.e. ``kernel.old'') at the FreeBSD boot prompt instead of pressing return. When reconfiguring a kernel, it is always a good idea to keep a kernel that is known to work on hand. After booting with a good kernel you can check over your configuration file and try to build it again. One helpful resource is the /var/log/messages file which records, among other things, all of the kernel messages from every successful boot. Also, the dmesg(8) command will print the kernel messages from the current boot. kernel.old because when installing a new kernel, kernel.old is overwritten with the last installed kernel which may be non-functional. Also, as soon as possible, move the working kernel to the proper ``kernel'' location or commands such as ps(1) will not work properly. The proper command to ``unlock'' the kernel file that make installs (in order to move another kernel back permanently) is: # chflags noschg /kernel And, if you want to ``lock'' your new kernel into place, or any file for that matter, so that it cannot be moved or tampered with: # chflags schg /kernel Kernel works, but ps does not work any more!

If you've installed a different version of the kernel from the one that the system utilities have been built with, for example, an experimental ``2.2.0'' kernel on a 2.1.0-RELEASE system, many system-status commands like ps(1) and vmstat(8) will not work any more. You must recompile the libkvm library as well as these utilities. This is one reason it is not normally a good idea to use a different version of the kernel from the rest of the operating system.