diff --git a/handbook/authors.sgml b/handbook/authors.sgml index 6c3227e00a..1b59640df7 100644 --- a/handbook/authors.sgml +++ b/handbook/authors.sgml @@ -1,112 +1,112 @@ - + "> "> "> "> "> "> "> "> "> "> "> "> -"> "> "> "> "> "> "> "> "> "> "> "> "> "> diff --git a/handbook/basics.sgml b/handbook/basics.sgml index 990d08f208..d9d0f05061 100644 --- a/handbook/basics.sgml +++ b/handbook/basics.sgml @@ -1,78 +1,97 @@ - + Unix Basics The online manual

The most comprehensive documentation on FreeBSD is in the form of man pages. Nearly every program on the system comes with a short reference manual explaining the basic operation and various argument. These manuals can be view with the man command. Use of the man command is simple: man command where command is the name of the command you wish to learn about. For example, to learn more about ls command type: % man ls

The online manual is divided up into numbered sections: User commands System calls and error numbers Functions in the C libraries Device drivers File formats Games and other diversions Miscellaneous information System maintenance and operation commands in some cases, the same topic may appear in more than one section of the on-line manual. For example, there is a chmod user command and a chmod() system call. In this case, you can tell the man command which you want by specifying the section: % man 1 chmod which will display the manual page for the user command - chmod. + chmod. References to a particular + section of the on-line manual are traditionally placed + in paranthesis in written documentation; so + chmod(1) refers to the chmod + user command, while chmod(2) + means the system call.

This is fine if you know the name of the command and forgot how to use it, but what if you cannot recall the command name? You can use man to search for keywords in the command descriptions by using the -k switch: % man -k mail With this command you will be presented with a list of commands that have the keyword `mail' in their - descriptions. + descriptions. This is the same as the separate command + apropos. + +

You are seeing all those fancy commands in + /usr/bin, but don't even have the silliest idea + what most of the names do actually stand for? Simply + do a + + % cd /usr/bin; man -f * + + or + + % cd /usr/bin; whatis * + + which is the same. GNU Info files

FreeBSD includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to man pages, these programs come with more extensive hypertext documents called info files which can be viewed with the info command or, if you installed emacs, the info mode of emacs. To use the info(1) command, simply type: % info For a brief introduction, type h, and for a quick command reference, type ?. diff --git a/handbook/booting.sgml b/handbook/booting.sgml index fba9c2fd1f..c7e46b52f8 100644 --- a/handbook/booting.sgml +++ b/handbook/booting.sgml @@ -1,170 +1,173 @@ The FreeBSD Booting Process

Contributed by &a.phk;. v1.1, April 26th. Booting FreeBSD is essentially a three step: Load the kernel, determine the root filesystem and initialize user-land things. This leads to some interesting possibilities shown below. Loading a kernel

We presently have three basic mechanisms for loading the kernel as described below: They all pass some information to the kernel to help the kernel decide what to do next. Biosboot Biosboot is our ``bootblocks'', it consists of two files, which will be installed in the first 8Kbytes of the floppy or hard-disk slice to be booted from. Biosboot can load a kernel from a FreeBSD filesystem. Dosboot Dosboot was written by DI. Christian Gusenbauer, and is unfortunately at this time one of the few pieces of code that isn't compilable under FreeBSD itself because it is written for MicroSoft compilers. Dosboot will boot the kernel from a MS-DOS file or from a FreeBSD filesystem partition on the disk. It attempts to negotiate with the various and strange kinds of memory manglers that lurk in high memory on MS/DOS systems and usually wins them for it's case. Netboot Netboot will try to find a supported ethernet card, and use BOOTP, TFTP and NFS to find a kernel file to boot. Determine the root filesystem

Once the kernel is loaded and the boot-code jumps to it, the kernel will initialize itself, trying to determine what hardware is present and so on, and then it needs to find a root filesystem. Presently we support the following types of rootfilesystems: UFS This is the most normal type of root filesystem. It can reside on a floppy or on harddisk. MSDOS While this is technically possible, it isn't particular useful, because of ``FAT'' filesystems inability to make links, device nodes and such ``UNIXisms''. MFS This is actually a UFS filesystem which has been compiled into the kernel. That means that the kernel does not really need any disks/floppies or other HW to function. CD9660 This is for using a CD-ROM as root filesystem. NFS This is for using a fileserver as root filesystem, basically making it a diskless machine. Initialize user-land things

To get the user-land going, when the kernel has finished - initialization, it will create a with ``/sbin/init''. You can substitute any program for /sbin/init, as long as you keep in mind that: there is no stdin/out/err unless you open it yourself, if you exit, - the machine panics signal handling is special for ``/stand/sysinstall'' + program on the installation floppy. + Interesting combinations

Boot a kernel with a MFS in it with a special /sbin/init which... mounts your /C: Attaches C:/freebsd.fs on /dev/vn0 mounts /dev/vn0 as /rootfs makes symlinks /rootfs/bin -> /bin /rootfs/etc -> /etc /rootfs/sbin -> /sbin (etc...) Now you run FreeBSD without repartitioning your hard disk... server:˜you/FreeBSD as /nfs, chroots to /nfs and executes /sbin/init there Now you run FreeBSD diskless, even though you don't control the NFS server... /dev/rwd0 and writes it to a remote tape station or fileserver. Now you finally got that backup you should have made a year ago... E -- Acts as a firewall/web-server/what do I know... This is particular interesting since you can boot from a write- protected floppy, but still write to your root filesystem... diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml index 9b2c0bb6a4..fbaf98e566 100644 --- a/handbook/contrib.sgml +++ b/handbook/contrib.sgml @@ -1,313 +1,313 @@ - + FreeBSD contributor list Derived software contributors

This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially reimplemented from the 4.4 BSD Lite release provided by the Computer Science Research Group (CSRG) at the University of California, Berkeley and associated academic contributors. There are also portions of NetBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD for their work. Despite some occasionally rocky moments in relations between the two groups, we both want essentially the same thing: More BSD based operating systems on people's computers! We wish the NetBSD group every success in their endeavors. Hardware contributors

A special thank-you to Walnut Creek CDROM for providing the Pentium P5-90 and 486/DX2-66 EISA/VL systems that are being used for our development work, to say nothing of the network access and other donations of hardware resources. It would have been impossible to do this release without their support. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve ethernets, two routers and an ATM switch for debugging the diskless code. They also keep a couple of FreeBSD hackers alive and busy. Thanks! Thanks also to Dermot McDonnell for his donation of a Toshiba XM3401B CDROM drive. It's been most useful! Thanks to Chuck Robey <chuckr@eng.umd.edu> who's been contributing his floppy tape streamer for experimental work. The FreeBSD core team

(in alphabetical order by first name): Andrey A. Chernov <ache@FreeBSD.org> Bruce Evans <bde@FreeBSD.org> David Greenman <davidg@FreeBSD.org> Garrett A. Wollman <wollman@FreeBSD.org> Gary Palmer <gpalmer@FreeBSD.org> Jörg Wunsch <joerg@FreeBSD.org> John Dyson <dyson@FreeBSD.org> Jordan K. Hubbard <jkh@FreeBSD.org> Justin Gibbs <gibbs@FreeBSD.org> Poul-Henning Kamp <phk@FreeBSD.org> Rich Murphey <rich@FreeBSD.org> Satoshi Asami <asami@FreeBSD.org> Søren Schmidt <sos@FreeBSD.org> Who is responsible for what

Additional FreeBSD contributors

(in alphabetical order by first name): Adam David <adam@veda.is> Adam Glass <glass@postgres.berkeley.edu> Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu> Akito Fujita <fujita@zoo.ncl.omron.co.jp> Alain Kalker <A.C.P.M.Kalker@student.utwente.nl> Andras Olah <olah@cs.utwente.nl> Andreas Klemm <andreas@knobel.GUN.de> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@FreeBSD.org> Anthony Yee-Hang Chan <yeehang@netcom.com> Atsushi Murai <amurai@spec.co.jp> Bill Fenner <fenner@parc.xerox.com> Bill Paul <wpaul@FreeBSD.org> Bob Wilcox <bob@obiwan.uucp> Brian Tao <taob@gate.sinica.edu.tw> Charles Hannum <mycroft@ai.mit.edu> Chet Ramey <chet@odin.INS.CWRU.Edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Provenzano <proven@athena.mit.edu> Chris Stenton <jacs@gnome.co.uk> Chris Torek <torek@ee.lbl.gov> Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Chuck Hein <chein@cisco.com> Chuck Robey <chuckr@Glue.umd.edu> Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de> Craig Struble <cstruble@vt.edu> Cristian Ferretti <cfs@riemann.mat.puc.cl> Curt Mayer <curt@toad.com> Danny J. Zerkel <dzerkel@feephi.phofarm.com> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Chapeskie <dchapes@zeus.leitch.com> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> Dean Huxley <dean@fsa.ca> Dirk Froemberg <dirk@hal.in-berlin.de> Don Whiteside <dwhite@anshar.shadow.net> Eric L. Hernes <erich@lodgenet.com> Frank Bartels <knarf@camelot.de> Frank Durda IV <bsdmail@nemesis.lonestar.org> Frank Maclachlan <fpm@crash.cts.com> Frank Nobis <fn@trinity.radio-do.de> Gary A. Browning <gab10@griffcd.amdahl.com> Gary Clark II <gclarkii@FreeBSD.ORG> Gary Jennejohn <gj%pcs.dec.com@inet-gw-1.pa.dec.com> Gene Stark <stark@cs.sunysb.edu> Guido van Rooij <guido@gvr.win.tue.nl> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Hideaki Ohmon <ohmon@sfc.keio.ac.jp> Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@winsey.com> James Clark <jjc@jclark.com> James da Silva <jds@cs.umd.edu> et al Janusz Kokot <janek@gaja.ipan.lublin.pl> Javier Martin Rueda <jmrueda@diatel.upm.es> Jean-Marc Zucconi <jmz@FreeBSD.ORG> Jim Wilson <wilson@moria.cygnus.com> Jonathan Bresler < jmb@FreeBSD.ORG> Josh MacDonald <jmacd@uclink.berkeley.edu> Juergen Lock <nox@jelal.hb.north.de> Julian Elischer <julian@dialix.oz.au> Julian Stacey <stacey@guug.de> (fallback: <julian@meepmeep.pcs.com>) Keith Bostic <bostic@toe.CS.Berkeley.EDU> Keith Moore <?> Kirk McKusick <mckusick@mckusick.com> Kurt Olsen <kurto@tiny.mcs.usu.edu> L Jonas Olsson <ljo@po.cwru.edu> Lars Fredriksen <fredriks@mcs.com> Lucas James <Lucas.James@ldjpc.apana.org.au> Marc Frajola <marc@dev.com> Marc Ramirez <mrami@mramirez.sy.yale.edu Marc van Kempen <wmbfmk@urc.tue.nl> Mark Murray <mark@grondar.za> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Birgmeier Martin Renters <martin@innovus.com> Matt Thomas <thomas@lkg.dec.com> Michael Elbel <me@freebsd.org> Michael Smith <msmith@atrad.adelaide.edu.au> Mike Pritchard <mpp@mpp.minn.net> NIIMI Satoshi <sa2c@and.or.jp> Nate Williams <nate@FreeBSD.org> Nobuhiro Yasutomi <nobu@psrc.isac.co.jp> Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp> Ollivier Robert <roberto@FreeBSD.org> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Richards <paul@FreeBSD.org> Paul Traina <pst@cisco.com> Peter Dufault <dufault@hda.com> Peter Wemm <peter@haywire.DIALix.COM> Philippe Charnier <charnier@lirmm.fr> Richard Stallman <rms@gnu.ai.mit.edu> Rob Shady <rls@id.net> Rob Snow <rsnow@txdirect.net> Rodney W. Grimes <rgrimes@FreeBSD.org> Sascha Wildner <swildner@channelz.GUN.de> Scott Blachowicz <scott@sabami.seaslug.org> Scott Mace <smace@FreeBSD.org> Sean Eric Fagan <sef@kithrup.com> Serge V. Vakulenko <vak@zebub.msk.su> Stefan Esser <se@MI.Uni-Koeln.DE> Stephen McKay <syssgm@devetir.qld.gov.au> Steve Gerakines <steve2@genesis.tiac.net> Steve Passe <smp@csn.net> Steven Wallace <swallace@ece.uci.edu> Tatsumi Hosokawa <hosokawa@mt.cs.keio.ac.jp> Terry Lee <terry@uivlsi.csl.uiuc.edu> Theo Deraadt <deraadt@fsa.ca> Thomas Gellekum <thomas@ghpc8.ihf.rwth-aachen.de> Tom Samplonius <tom@misery.sdf.com> Torbjorn Granlund <tege@matematik.su.se> Torsten Blum <torstenb@FreeBSD.ORG> Ugen J.S.Antsilevich <ugen@latte.WorldBank.org> Werner Griessl <werner@btp1da.phy.uni-bayreuth.de> Wolfgang Stanglmeier <wolf@kintaro.cologne.de> Wolfram Schneider <wosch@cs.tu-berlin.de> Yuval Yarom <yval@cs.huji.ac.il> Yves Fonk <yves@cpcoup5.tn.tudelft.nl> 386BSD Patch kit patch contributors

(in alphabetical order by first name): Adam Glass <glass@postgres.berkeley.edu> Adrian Hall <adrian@ibmpcug.co.uk> Andrey A. Chernov <ache@astral.msk.su> Andrew Herbert <andrew@werple.apana.org.au> Andrew Moore <alm@netcom.com> Andy Valencia <ajv@csd.mot.com> <jtk@netcom.com> Arne Henrik Juul <arnej@Lise.Unit.NO> Bakul Shah <bvs@bitblocks.com> Barry Lustig <barry@ictv.com> Bob Wilcox <bob@obiwan.uucp> Branko Lankester Brett Lymn <blymn@mulga.awadi.com.AU> Charles Hannum <mycroft@ai.mit.edu> Chris G. Demetriou <cgd@postgres.berkeley.edu> Chris Torek <torek@ee.lbl.gov> Christoph Robitschko <chmr@edvz.tu-graz.ac.at> Daniel Poirot <poirot@aio.jsc.nasa.gov> Dave Burgess <burgess@hrd769.brooks.af.mil> Dave Rivers <rivers@ponds.uucp> David Dawes <dawes@physics.su.OZ.AU> David Greenman <davidg@Root.COM> Eric J. Haug <ejh@slustl.slu.edu> Felix Gaehtgens <felix@escape.vsse.in-berlin.de> Frank Maclachlan <fpm@crash.cts.com> Gary A. Browning <gab10@griffcd.amdahl.com> Geoff Rehmet <csgr@alpha.ru.ac.za> Goran Hammarback <goran@astro.uu.se> Guido van Rooij <guido@gvr.win.tue.nl> Guy Harris <guy@auspex.com> Havard Eidnes <Havard.Eidnes@runit.sintef.no> Herb Peyerl <hpeyerl@novatel.cuc.ab.ca Holger Veit <Holger.Veit@gmd.de> Ishii Masahiro, R. Kym Horsell J.T. Conklin <jtc@winsey.com> Jagane D Sundar < jagane@netcom.com > James Clark <jjc@jclark.com> James Jegers <jimj@miller.cs.uwm.edu> James W. Dolter James da Silva <jds@cs.umd.edu> et al Jay Fenlason <hack@datacube.com> Jim Wilson <wilson@moria.cygnus.com> - Joerg Lohse <lohse@tech7.informatik.uni-hamburg.de> + Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de> Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de> John Dyson - <formerly dyson@ref.tfs.com> John Polstra <jdp@polstra.com> John Woods <jfw@eddie.mit.edu> Jordan K. Hubbard <jkh@whisker.hubbard.ie> Julian Elischer <julian@dialix.oz.au> Julian Stacey <stacey@guug.de> (fallback: <julian@meepmeep.pcs.com>) Karl Lehenbauer <karl@NeoSoft.com> <karl@one.neosoft.com> Keith Bostic <bostic@toe.CS.Berkeley.EDU> Ken Hughes Kent Talarico <kent@shipwreck.tsoft.net> Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu> <kml@mosquito.cis.ufl.edu> Marc Frajola <marc@dev.com> Mark Tinguely <tinguely@plains.nodak.edu> <tinguely@hookie.cs.ndsu.NoDak.edu> Martin Renters <martin@innovus.com> Michael Galassi <nerd@percival.rain.com> Mike Durkin <mdurkin@tsoft.sf-bay.org> Nate Williams <nate@bsd.coe.montana.edu> Nick Handel <nhandel@NeoSoft.com> <nick@madhouse.neosoft.com> Pace Willisson <pace@blitz.com> Paul Kranenburg <pk@cs.few.eur.nl> Paul Mackerras <paulus@cs.anu.edu.au> Paul Popelka <paulp@uts.amdahl.com> Peter da Silva <peter@NeoSoft.com> Phil Sutherland <philsuth@mycroft.dialix.oz.au> Ralf Friedl <friedl@informatik.uni-kl.de> Rick Macklem <root@snowhite.cis.uoguelph.ca> Robert D. Thrush <rd@phoenix.aii.com> Rodney W. Grimes <rgrimes@cdrom.com> Rog Egge <?> Sascha Wildner <swildner@channelz.GUN.de> Scott Burris <scott@pita.cns.ucla.edu> Scott Reynolds <scott@clmqt.marquette.mi.us> Sean Eric Fagan <sef@kithrup.com> Simon J Gerraty <sjg@melb.bull.oz.au> <sjg@zen.void.oz.au> Stephen McKay <syssgm@devetir.qld.gov.au> Terry Lambert <terry@icarus.weber.edu> Terry Lee <terry@uivlsi.csl.uiuc.edu> Warren Toomey <wkt@csadfa.cs.adfa.oz.au> Wiljo Heinen <wiljo@freeside.ki.open.de> William Jolitz <withheld> Wolfgang Solfrank <ws@tools.de> Wolfgang Stanglmeier <wolf@dentaro.GUN.de> Yuval Yarom <yval@cs.huji.ac.il> Last, but not least, the release engineer would like to thank: His Wife, for chocolate chip cookies, and some other things. The DGB project @ TFS, for patience and tolerance. diff --git a/handbook/install.sgml b/handbook/install.sgml index 2ac1539564..a95e220b2c 100644 --- a/handbook/install.sgml +++ b/handbook/install.sgml @@ -1,790 +1,801 @@ - + Installing FreeBSD

So, you would like to try out FreeBSD on your system? This section is a quick-start guide for what you need to do. FreeBSD can be installed from a variety of media including CD-ROM, floppy disk, magnetic tape, an MS-DOS partition, and if you have a network connection, via anonymous ftp or NFS. Regardless of the installation media you choose, you can get started by downleading the installation disk as described below. Booting your computer with disk will provide important information about compatibility between FreeBSD and your hardware which could dictate which installation options are possible. It can also provide early clues to compatibilty problems that could prevent FreeBSD running on your system at all. If you plan on installing via anonymous FTP, then this installation disk is all you need to download. For more information on obtaining the FreeBSD distribution itself, please see in the Appendix. So, to get the show on the road, follow these steps: Review the section of this installation guide to be sure that your hardware is supported by FreeBSD. It may be helpful to make a list of any special cards you have installed, such as SCSI controllers, etherernet adapters or sound cards. This list should include relevant configuration parameters such as interrupts (IRQ) and IO port addresses. Download the file to your hard drive, and be sure to tell your browser to save rather than display. Note: This disk image can be used for both 1.44 megabyte 3.5 inch floppy disks and 1.2 megabyte 5.25 inch floppy disks. Make the installation boot disk from the image file: If you are using MS-DOS download (tell your browser to save rather than display!), then run it: C:\> rawrite The program will prompt you for the floppy drive containing the disk you want to write to (A: or B:) and the name of the file to put on disk (boot.flp). If you are using a UNIX system: % dd if=boot.flp of=disk_device bs=18k where disk_device is the /dev entry for the floppy drive. On FreeBSD systems, this is /dev/rfd0 for the A: drive and /dev/rfd1 for the B: drive. With the installation disk in the A: drive, reboot your computer. You should get a boot prompt something like this: >> FreeBSD BOOT ... Use hd(1,a)/kernel to boot sd0 when wd0 is also installed. Usage: [[hd(1,a)]/kernel][-abcCdhrsv] Use ? for file list or press Enter for defaults Boot: If you do not type anything, FreeBSD will automatically boot with its default configuration after a delay of about five seconds. As FreeBSD boots, it probes your computer to determine what hardware is installed. The results of this probing is displayed on the screen. When the booting process is finished, The main FreeBSD installation menu will be displayed.

If something goes wrong...

Due to limitations of the PC architecture, it is impossible for probing to be 100 percent reliable. In the event that your hardware is incorrectly identified, or that the probing causes your computer to lock up, first check the section of this installation guide to be sure that your hardware is indeed supported by FreeBSD.

If your hardware is supported, reset the computer and when the Boot: prompt comes up, type -c. This puts FreeBSD into a configuration mode where you can supply hints about your hardware. The FreeBSD kernel on the installation disk is configured assuming that most hardware devices are in their factory default configuration in terms of IRQs, IO addresses and DMA channels. If your hardware has been reconfigured, you will most likely need to use the -c option at boot to tell FreeBSD where things are.

It is also possible that a probe for a device not present will cause a later probe for another device that is present to fail. In that case, the probes for the conflicting driver(s) should be disabled.

In the configuration mode, you can: List the device drivers installed in the kernel. Disable device drivers for hardware not present in your system. Change the IRQ, DRQ, and IO port addresses used by a device driver.

While at the config> prompt, type help for more information on the available commands. After adjusting the kernel to match how you have your hardware configured, type quit at the config> prompt to continue booting with the new settings. After FreeBSD has been installed, changes made in the configuration mode will be permanent so you do not have to reconfigure every time you boot. Even so, it is likely that you will want to build a custom kernel to optimize the performance of your system. See for more information on creating custom kernels. MS-DOS user's Questions and Answers

Many FreeBSD users wish to install FreeBSD on PCs inhabited by MS-DOS. Here are some commonly asked questions about installing FreeBSD on such systems.

Help! I have no space! Do I need to delete everything first? If your machine is already running MS-DOS and has little or no free space available for FreeBSD's installation, all is not lost! You may find the FIPS utility, provided in the tools directory on the FreeBSD CDROM or on the various FreeBSD ftp sites, to be quite useful. FIPS allows you to split an existing MS-DOS partition into two pieces, preserving the original partition and allowing you to install onto the second free piece. You first defragment your MS-DOS partition, using the DOS 6.xx DEFRAG utility or the Norton Disk tools, then run FIPS. It will prompt you for the rest of the information it needs. Afterwards, you can reboot and install FreeBSD on the new free slice. See the Distributions menu for an estimation of how much free space you'll need for the kind of installation you want. Can I use compressed MS-DOS filesystems from FreeBSD? No. If you are using a utility such as Stacker(tm) or DoubleSpace(tm), FreeBSD will only be able to use whatever portion of the filesystem you leave uncompressed. The rest of the filesystem will show up as one large file (the stacked/dblspaced file!). Do not remove that file! You will probably regret it greatly! It is probably better to create another uncompressed MS-DOS primary partition and use this for communications between MS-DOS and FreeBSD. Can I mount my MS-DOS extended partitions? This feature isn't in FreeBSD 2.0.5 but should be in 2.1. We've laid all the groundwork for making this happen, now we just need to do the last 1 percent of the work involved. Can I run MS-DOS binaries under FreeBSD? Not yet! We'd like to add support for this someday, but are still lacking anyone to actually do the work. - Ongoing work with Linux's PCEMU utility may bring this + Ongoing work with Linux's DOSEMU utility may bring this much closer to being a reality sometime soon. Send mail to hackers@freebsd.org if you're interested in joining this effort! + However, there's a nice application available in the + called pcemu, + that allows you to run many basic MS-DOS text-mode binaries + by entirely emulating an 8088 CPU. + Supported Configurations

FreeBSD currently runs on a wide variety of ISA, VLB, EISA and PCI bus based PC's, ranging from 386sx to Pentium class machines (though the 386sx is not recommended). Support for generic IDE or ESDI drive configurations, various SCSI controller, network and serial cards is also provided. A minimum of four megabytes of RAM is required to run FreeBSD. To run the X-window system, eight megabytes of RAM is the recommended minimum. Following is a list of all disk controllers and ethernet cards currently known to work with FreeBSD. Other configurations may very well work, and we have simply not received any indication of this. Disk Controllers

WD1003 (any generic MFM/RLL) WD1007 (any generic IDE/ESDI) WD7000 IDE ATA Adaptec 152x series ISA SCSI controllers Adaptec 154x series ISA SCSI controllers Adaptec 174x series EISA SCSI controller in standard and enhanced mode. Adaptec 274X/284X/2940 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers - Adaptec AIC-6260 and AIC-6360 based boards, + Adaptec + + AIC-6360 based boards, which includes the AHA-152x and SoundBlaster SCSI cards. Note: You cannot boot from the SoundBlaster cards as they have no on-board BIOS, which is necessary for mapping the boot device into the system BIOS I/O vectors. They are perfectly usable for external tapes, CDROMs, etc, however. The same goes for any other AIC-6x60 based card without a boot ROM. Some systems DO have a boot ROM, which is generally indicated by some sort of message when the system is first powered up or reset. Check your system/board documentation for more details. Buslogic 545S & 545c Note: that Buslogic was formerly known as "Bustec". Buslogic 445S/445c VLB SCSI controller Buslogic 742A, 747S, 747c EISA SCSI controller. Buslogic 946c PCI SCSI controller Buslogic 956c PCI SCSI controller NCR 53C810 and 53C825 PCI SCSI controller. NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller. DTC 3290 EISA SCSI controller in 1542 emulation mode. UltraStor 14F, 24F and 34F SCSI controllers. Seagate ST01/02 SCSI controllers. Future Domain 8xx/950 series SCSI controllers. With all supported SCSI controllers, full support is provided for SCSI-I & SCSI-II peripherals, including Disks, tape drives (including DAT) and CD ROM drives. The following CD-ROM type systems are supported at this time: Soundblaster SCSI and ProAudio Spectrum SCSI (cd) Mitsumi (all models) proprietary interface (mcd) Matsushita/Panasonic (Creative) CR-562/CR-563 proprietary interface (matcd) Sony proprietary interface (scd) Note: CD-Drives with IDE interfaces are not supported at this time. Some controllers have limitations with the way they deal with >16MB of memory, due to the fact that the ISA bus only has a DMA address space of 24 bits. If you do your arithmetic, you'll see that this makes it impossible to do direct DMA to any address >16MB. This limitation is even true of some EISA controllers (which are normally 32 bit) when they're configured to emulate an ISA card, which they then do in *all* respects. This problem is avoided entirely by IDE controllers (which do not use DMA), true EISA controllers (like the UltraStor, Adaptec 1742A or Adaptec 2742) and most VLB (local bus) controllers. In the cases where it's necessary, the system will use "bounce buffers" to talk to the controller so that you can still use more than 16Mb of memory without difficulty. Ethernet cards

SMC Elite 16 WD8013 ethernet interface, and most other WD8003E, WD8003EBT, WD8003W, WD8013W, WD8003S, WD8003SBT and WD8013EBT based clones. SMC Elite Ultra is also supported. DEC EtherWORKS III NICs (DE203, DE204, and DE205) DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422) DEC DC21140 based NICs (SMC???? DE???) DEC FDDI (DEFPA/DEFEA) NICs Fujitsu MB86960A family of NICs Intel EtherExpress Isolan AT 4141-0 (16 bit) Isolink 4110 (8 bit) Novell NE1000, NE2000, and NE2100 ethernet interface. 3Com 3C501 cards 3Com 3C503 Etherlink II 3Com 3c505 Etherlink/+ 3Com 3C507 Etherlink 16/TP 3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III Toshiba ethernet cards PCMCIA ethernet cards from IBM and National Semiconductor are also supported. Miscellaneous devices

AST 4 port serial card using shared IRQ. ARNET 8 port serial card using shared IRQ. BOCA IOAT66 6 port serial card using shared IRQ. + BOCA 2016 16 port serial card using shared IRQ. + Cyclades Cyclom-y Serial Board. STB 4 port card using shared IRQ. SDL Communications Riscom/8 Serial Board. Adlib, SoundBlaster, SoundBlaster Pro, ProAudioSpectrum, Gravis UltraSound and Roland MPU-401 sound cards. FreeBSD currently does NOT support IBM's microchannel (MCA) bus, but support is apparently close to materializing. Details will be posted as the situation develops. Preparing for the installation

There are a number of different methods by which FreeBSD can be installed. The following describes what preparation needs to be done for each type. Before installing from CDROM

If your CDROM is of an unsupported type, such as an IDE CDROM, then please skip to section 2.3: MS-DOS Preparation. There is not a lot of preparatory work that needs to be done to successfully install from one of Walnut Creek's FreeBSD CDROMs (other CDROM distributions may work as well, but I can't say for sure as I have no hand or say in their creation). You can either boot into the CD installation directly from MS-DOS using Walnut Creek's supplied "install" batch file or you can make a boot floppy by writing the supplied image (floppies/boot.flp) onto a floppy with the "go" command, which invokes the rawrite.exe command found in the tools/ subdirectory. If you're creating the boot floppy from a UNIX machine, you may find that ``dd if=floppies/boot.flp of=/dev/rfd0'' or ``dd if=floppies/boot.flp of=/dev/floppy'' works well, depending on your hardware and operating system environment. Once you've booted from MS-DOS or floppy, you should be able to select CDROM as the media type in the Media menu and load the entire distribution from CDROM. No other types of installation media should be required. After your system is fully installed and you have rebooted from the hard disk, you should find the CD mounted on the directory /cdrom. A utility called `lndir' comes with the XFree86 distribution which you may also find useful: It allows you to create "link tree" directories to things on Read-Only media like CDROM. One example might be something like this: mkdir /usr/portslndir /cdrom/ports /usr/ports Which would allow you to then "cd /usr/ports; make" and get all the sources from the CD, but yet create all the intermediate files in /usr/ports, which is presumably on a more writable media! Before installing from Floppy

If you must install from floppy disks, either due to unsupported hardware or just because you enjoy doing things the hard way, you must first prepare some floppies for the install. The first floppy you'll need is ``floppies/root.flp'', which is somewhat special in that it's not a MS-DOS filesystem floppy at all, but rather an "image" floppy (it's actually a gzip'd cpio file). You can use the rawrite.exe program to do this under DOS, or ``dd'' to do it on a UNIX Workstation (see notes in section 2.1 concerning the ``floppies/boot.flp'' image). Once this floppy is made, put it aside. You'll be asked for it later. You will also need, at minimum, as many 1.44MB or 1.2MB floppies as it takes to hold all files in the bin - (binary distribution) directory. THESE floppies *must* + (binary distribution) directory. THESE floppies must be formatted using MS-DOS, using with the FORMAT command in MS-DOS or the File Manager format command in Microsoft Windows(tm). Factory preformatted floppies will also work well, provided that they haven't been - previously used for something else. + previously used for something else. Note that only media + without any defects are usable for these floppies; there + is no kind of bad sector remapping available for them. Many problems reported by our users in the past have resulted from the use of improperly formatted media, so we simply take special care to mention it here! After you've MS-DOS formatted the floppies, you'll need to copy the files onto them. The distribution files are split into chunks conveniently sized so that 5 of them will fit on a conventional 1.44MB floppy. Go through all your floppies, packing as many files as will fit on each one, until you've got all the distributions you want packed up in this fashion. Select ``Floppy'' from the Media menu at installation time and you will be prompted for everything after that. Before installing from a MS-DOS partition

To prepare for installation from an MS-DOS partition, copy the files from the distribution into a directory called C:\FREEBSD. The directory tree structure of the CDROM must be partially reproduced within this directory so we suggest using the DOS xcopy command. For example, to prepare for a minimal installation of FreeBSD: C> MD C:\FREEBSD C> XCOPY /S E:\FLOPPIES C:\FREEBSD\FLOPPIES\ C> XCOPY /S E:\DISTS\BIN C:\FREEBSD\BIN\ assuming that C: is where you have free space and E: is where your CDROM is mounted. Note that you need the FLOPPIES directory because the root.flp image is needed during an MS-DOS installation. For as many `DISTS' you wish to install from MS-DOS (and you have free space for), install each one under C:\FREEBSD - the BIN dist is only the minimal requirement. If you have room on your MS-DOS partition for all the distributions, you could replace the last line above with: C> XCOPY /S E:\DISTS C:\FREEBSD\ which would copy all the subdirectories of E:\DISTS to C:\FREEBSD. Before installing from QIC/SCSI Tape

Installing from tape is probably the easiest method, short of an on-line install using FTP or a CDROM install. The installation program expects the files to be simply tar'ed onto the tape, so after getting all of the files for distribution you're interested in, simply tar them onto the tape with a command like: cd /freebsd/distdir tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2 Make sure that the `floppies/' directory is one of the "dists" given above, since the installation will look for `floppies/root.flp' on the tape. When you go to do the installation, you should also make sure that you leave enough room in some temporary directory (which you'll be allowed to choose) to accommodate the FULL contents of the tape you've created. Due to the non-random access nature of tapes, this method of installation requires quite a bit of temporary storage! You should expect to require as much temporary storage as you have stuff written on tape. Before installing over a network

You can do network installations over 3 types of communications links: Serial port SLIP or PPP Parallel port PLIP (laplink cable) Ethernet A standard ethernet controller (includes some PCMCIA). SLIP support is rather primitive, and limited primarily to hard-wired links, such as a serial cable running between a laptop computer and another computer. The link should be hard-wired as the SLIP installation doesn't currently offer a dialing capability; that facility is provided with the PPP utility, which should be used in preference to SLIP whenever possible. If you're using a modem, then PPP is almost certainly your only choice. Make sure that you have your service provider's information handy as you'll need to know it fairly soon in the installation process. You will need to know, at the minimum, your service provider's IP address and possibly your own (though you can also leave it blank and allow PPP to negotiate it with your ISP). You also need to know how to use the various "AT commands" to dial the ISP with your particular modem as the PPP dialer provides only a very simple terminal emulator. If a hard-wired connection to another FreeBSD (2.0R or later) machine is available, you might also consider installing over a "laplink" parallel port cable. The data rate over the parallel port is much higher than is what's typically possible over a serial line (up to 50k/sec), thus resulting in a quicker installation. Finally, for the fastest possible network installation, an ethernet adaptor is always a good choice! FreeBSD supports most common PC ethernet cards, a table of supported cards (and their required settings) provided as part of the FreeBSD Hardware Guide - see the Documentation menu on the boot floppy. If you are using one of the supported PCMCIA ethernet cards, also be sure that it's plugged in _before_ the laptop is powered on! FreeBSD does not, unfortunately, currently support "hot insertion" of PCMCIA cards. You will also need to know your IP address on the network, the "netmask" value for your address class and the name of your machine. Your system administrator can tell you which values to use for your particular network setup. If you will be referring to other hosts by name rather than IP address, you'll also need a name server and possibly the address of a gateway (if you're using PPP, it's your provider's IP address) to use in talking to it. If you do not know the answers to all or most of these questions, then you should really probably talk to your system administrator _first_ before trying this type of installation! Once you have a network link of some sort working, the installation can continue over NFS or FTP. Preparing for NFS installation

NFS installation is fairly straight-forward: Simply copy the FreeBSD distribution files you're interested onto a server somewhere and then point the NFS media selection at it. If this server supports only "privileged port" access (as is generally the default for Sun workstations), you will need to set this option in the Options menu before installation can proceed. If you have a poor quality ethernet card which suffers from very slow transfer rates, you may also wish to toggle the appropriate Options flag. In order for NFS installation to work, the server must support "subdir mounts", e.g. if your FreeBSD 2.0.5 distribution directory lives on: ziggy:/usr/archive/stuff/FreeBSD Then ziggy will have to allow the direct mounting of /usr/archive/stuff/FreeBSD, not just /usr or /usr/archive/stuff. In FreeBSD's /etc/exports file, this is controlled by the ``-alldirs'' option. Other NFS servers may have different conventions. If you are getting `Permission Denied' messages from the server then it's likely that you don't have this enabled properly! Preparing for FTP Installation

FTP installation may be done from any mirror site containing a reasonably up-to-date version of FreeBSD 2.0.5, a full menu of reasonable choices from almost anywhere in the world being provided by the FTP site menu. If you are installing from some other FTP site not listed in this menu, or you are having troubles getting your name server configured properly, you can also specify your own URL by selecting the ``Other'' choice in that menu. A URL can also be a direct IP address, so the following would work in the absence of a name server: ftp://192.216.222.4/pub/FreeBSD/2.0.5-RELEASE NOTE: Substitute "ALPHA" for "RELEASE" during the ALPHA test period! If you are installing through a firewall then you should probably select ``Passive mode'' ftp, which is the default. If you are talking to a server which does not support passive mode for some reason, see the Options menu to select Active mode transfers. Installing FreeBSD

Once you've taken note of the appropriate preinstallation steps, you should be able to install FreeBSD without any further trouble. Should this not be true, then you may wish to go back and re-read the relevant preparation section (section 2.x) for the installation media type you're trying to use - perhaps there's a helpful hint there that you missed the first time? If you're having hardware trouble, or FreeBSD refuses to boot at all, read the Hardware Guide provided on the boot floppy for a list of possible solutions. The FreeBSD boot floppy contains all the on-line documentation you should need to be able to navigate through an installation and if it doesn't then I'd like to know what you found most confusing! It is the objective of the FreeBSD installation program (sysinstall) to be self-documenting enough that painful "step-by-step" guides are no longer necessary. It may take us a little while to reach that objective, but that's the objective! Meanwhile, you may also find the following "typical installation sequence" to be helpful: Boot the boot floppy. After a boot sequence which can take anywhere from from 30 seconds to 3 minutes, depending on your hardware, you should be presented with a menu of initial choices. If the floppy doesn't boot at all, or the boot hangs at some stage, go read the Q&A section of the Hardware Guide for possible causes. Press F1. You should see some basic usage instructions on the menu system and general navigation. If you haven't used this menu system before then PLEASE read this thoroughly! If English is not your native language, you may wish to proceed directly to the Language option and set your preferred language. This will bring up some of the documentation in that language instead of English. Select the Options item and set any special preferences you may have. Select Proceed, bringing you to the Installation Menu. The installation menu

You can do anything you like in this menu without altering your system except for "Commit", which will perform any requests to alter your system you may have made. If you're confused at any point, the F1 key usually pulls up the right information for the screen you're in. The first step is generally `Partition', which allows you to chose how your drives will be used for FreeBSD. Next, with the `Label' editor, you can specify how the space in any allocated FreeBSD partitions should be used by FreeBSD, or where to mount a non-FreeBSD partition (such as DOS). Next, the `Distributions' menu allows you to specify which parts of FreeBSD you wish to load. A good choice is "User" for a small system or "Developer" for someone wanting a bit more out of FreeBSD. If none of the existing collections sound applicable, select Custom. Next, the `Media' menu allows you to specify what kind of media you wish to install from. If a desired media choice is found and configured automatically then this menu will simply return, otherwise you'll be asked for additional details on the media device type. Finally, the Commit command will actually perform all the actions at once (nothing has been written to your disk so far, nor will it until you give the final confirmation). All new or changed partition information will be written out, file systems will be created and/or non-destructively labelled (depending on how you set their newfs flags in the Label editor) and all selected distributions will be extracted. The Configure menu choice allows you to further configure your FreeBSD installation by giving you menu-driven access to various system defaults. Some items, like networking, may be especially important if you did a CDROM/Tape/Floppy installation and have not yet configured your network interfaces (assuming you have some). Properly configuring your network here will allow FreeBSD to come up on the network when you first reboot from the hard disk. Exit returns you to the top menu. At this point, you're generally done with the sysinstall utility and can select the final `Quit'. If you're running it as an installer (e.g. before the system is all the way up) then the system will now reboot. If you selected the boot manager option, you will see a small boot menu with an `F?' prompt. Press the function key for BSD (it will be shown) and you should boot up into FreeBSD off the hard disk. If this fails to happen for some reason, see the Q&A section of the Hardware Guide for possible clues! diff --git a/handbook/kernelconfig.sgml b/handbook/kernelconfig.sgml index a565ee4957..1870f88b13 100644 --- a/handbook/kernelconfig.sgml +++ b/handbook/kernelconfig.sgml @@ -1,1206 +1,1240 @@ - + 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. When you're finished, type the following to compile and install your kernel: # /usr/sbin/config MYKERNEL # cd ../../compile/MYKERNEL # 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 is present in the LINT configuration file, located in the same directory as GENERIC. 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 + 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 coprocessor 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 coprocessor emulation routines that come with FreeBSD are not very accurate. If you do not have a math coprocessor, 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 compatibilty 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. + 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. + <-- XXX why? it's perfectly working as LKM. joerg --> Leave it in. 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 math coprocessor. If you have one then make sure you've commented out above. If you do not have a math coprocessor, you can comment this out. 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 ``vt220'' when you log in if - full-screen programs do not run correctly on this - console. + 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. + 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 + 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)! + 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. This is really only useful when you need to compress FreeBSD programs to fit on a boot floppy. You will probably never need to compress programs on your hard drive in this fashion, so you'll probably want to comment out this line. 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. diff --git a/handbook/kerneldebug.sgml b/handbook/kerneldebug.sgml index d3ad199dc0..b62837a289 100644 --- a/handbook/kerneldebug.sgml +++ b/handbook/kerneldebug.sgml @@ -1,425 +1,424 @@ - + Kernel Debugging

Contributed by &a.paul; and &a.joerg; Debugging a kernel crash dump with kgdb

Here are some instructions for getting kernel debugging working on a crash dump, it assumes that you have enough swap space for a crash dump. If you have multiple swap partitions and the first one is too small to hold the dump, you can configure your kernel to use an alternate dump device (in the config kernel line), or you can specify an alternate using the dumpon(8) command. Dumps to non-swap devices, tapes for example, are currently not supported. Config your kernel using config -g. See for details on configuring the FreeBSD kernel. Use the dumpon(8) command to tell the kernel where to dump to (note that this will have to be done after configuring the partition in question as swap space via swapon(8)). This is normally arranged via /etc/sysconfig and /etc/rc. Alternatively, you can hard-code the dump device via the `dump' clause in the `config' line - of your kernel config file. This is deprecated, but might be the - only chance to get a crash dump from a kernel that's not booting at - all, so that you didn't had the ability to run any command before it - used to crash. + of your kernel config file. This is deprecated, use only if you + want a crash dump from a kernel that crashes during booting. Note: In the following, the term `kgdb' refers to gdb run in `kernel debug mode'. This can be accomplished by either starting the gdb with the option -k, or by linking and starting it under the name kgdb. This is not being done by default, however. When the kernel has been built make a copy of it, say kernel.debug, and then run strip -x on the original. Install the original as normal. You may also install the unstripped kernel, but symbol table lookup time for some programs will drastically increase, and since the whole kernel is loaded entirely at boot time and cannot be swapped out later, several megabytes of - physical RAM will be wasted. + physical memory will be wasted. If you are testing a new kernel, for example by typing the new kernel's name at the boot prompt, but need to boot a different one in order to get your system up and running again, boot it only into single user state using the -s flag at the boot prompt, and then perform the following steps: fsck -p mount -a -t ufs # so your file system for /var/crash is writable savecore -N /kernel.panicked /var/crash exit # ...to multi-user This instructs savecore(8) to use another kernel for symbol name - extraction. It would otherwise default to the currently running kernel. + extraction. It would otherwise default to the currently running kernel + and most likely not do anything at all since the crash dump and the + kernel symbols differ. Now, after a crash dump, go to /sys/compile/WHATEVER and run kgdb. From kgdb do: symbol-file kernel.debug exec-file /var/crash/system.0 core-file /var/crash/ram.0 and voila, you can debug the crash dump using the kernel sources just like you can for any other program. - If your kernel panicked due to a trap, perhaps the most common - case for getting a core dump, the following trick might help - you. Examine the stack using kgdb's `where' command, - and look for the stack frame in the function trap(). Go `up' - to that frame, and then type: - - frame frame->tf_ebp frame->tf_eip - - This will tell kgdb to go to the stack frame explicitly named by a - frame pointer and instruction pointer, which is the location where - the trap occured. There are still some bugs in kgdb (you can go - `up' from there, but not `down'; the stack trace will still remain - as it was before going to here), but generally this method will lead - you much closer to the failing piece of code. - - Here's a script log of a kgdb session illustrating the above. Long + Here's a script log of a kgdb session illustrating the + procedure. Long lines have been folded to improve readability, and the lines are numbered for reference. Despite of this, it's a real-world error trace taken during the development of the pcvt console driver. 1:Script started on Fri Dec 30 23:15:22 1994 2:uriah # cd /sys/compile/URIAH 3:uriah # kgdb kernel /var/crash/vmcore.1 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36:(kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816 57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up 62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014 in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open () 67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74:(kgdb) up 75:Initial frame selected; you cannot go up. 76:(kgdb) quit 77:uriah # exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 Comments to the above script: trap() in the stack trace. -tp->t_line refers to the line discipline of the console device here, which must be a rather small integer number.) Post-mortem analysis of a dump

What do you do if a kernel dumped core but you did not expect it, and it's therefore not compiled using config -g? Not everything is lost here. Don't panic! Of course, you still need to enable crash dumps. See above - on the options you've got to do this. - (This is for safety reasons in the default kernels, to avoid them - trying to dump e.g. during system installation where there's no - FreeBSD partition at all and valuable data on the disk could be - destroyed.) + on the options you've got in order to do this. Go to your kernel compile directory, and edit the line containing COPTFLAGS?=-O. Add the -g option there (but don't change anything on the level of optimization). If you do already know roughly the probable location of the failing piece of code (e.g., the pcvt driver in the example above), remove all the object files for this code. Rebuild the kernel. Due to the time stamp change on the Makefile, there will be some other object files rebuild, for example trap.o. With a bit of luck, the added -g option won't change anything for the generated code, so you'll finally get a new kernel with similar code to the faulting one but some debugging symbols. You should at least verify the old and new sizes with the size(1) command. If there is a mismatch, you probably need to give up here. Go and examine the dump as described above. The debugging symbols might be incomplete for some places, as can be seen in the stack trace in the example above where some functions are displayed without line numbers and argument lists. If you need more debugging symbols, remove the appropriate object files and repeat the kgdb session until you know enough. All this is not guaranteed to work, but it will do it fine in most cases. On-line kernel debugging using DDB

While kgdb as an offline debugger provides a very high level of user interface, there are some things it cannot do. The most important ones being breakpointing and single-stepping kernel code. If you need to do low-level debugging on your kernel, there's an on- line debugger available called DDB. It allows to setting breakpoints, single-steping kernel functions, examining and changing kernel variables, etc. However, it cannot not access kernel source files, and only has access to the global and static symbols, not to the full debug information like kgdb. To configure your kernel to include DDB, add the option line options DDB to your config file, and rebuild. (See for details on configuring the FreeBSD kernel. Note that if you have an older version of the boot blocks, your debugger symbols might not be loaded at all. Update the boot blocks, the recent ones do load the DDB symbols automagically.) Once your DDB kernel is running, there are several ways to enter DDB. The first, and earliest way is to type the boot flag -d right at the boot prompt. The kernel will start up in debug mode and enter DDB prior to any device probing. Hence you are able to even debug the device probe/attach functions. The second scenario is a hot-key on the keyboard, usually Ctrl-Alt-ESC. For syscons, this can be remapped, and some of the distributed maps do this, so watch out. There's an option - available for a COMCONSOLE kernel (``options BREAK_TO_DEBUGGER'') + available for serial consoles that allows the use of a serial line BREAK on the console line to - enter DDB. + enter DDB (``options BREAK_TO_DEBUGGER'' + in the kernel config file). It is not the default since there are a lot of + crappy serial adapters around that gratuitously generate a + BREAK condition for example when pulling the cable. The third way is that any panic condition will branch to DDB if - the kernel is configured to use it. It is not wise to - configure a kernel with DDB for a machine running unattended - for this reason. + the kernel is configured to use it. + For this reason, it is not wise to + configure a kernel with DDB for a machine running unattended. The DDB commands roughly resemble some gdb commands. The first you probably need is to set a breakpoint: b function-name b address Numbers are taken hexadecimal by default, but to make them distinct from symbol names, hexadecimal numbers starting with the letters a-f need to be preceded with 0x (for other numbers, this is optional). Simple expressions are allowed, for example: function-name + 0x103. To continue the operation of an interrupted kernel, simply type c To get a stack trace, use trace Note that when entering DDB via a hot-key, the kernel is currently servicing an interrupt, so the stack trace might be not of much use for you. If you want to remove a breakpoint, use del del address-expression The first form will be accepted immediately after a breakpoint hit, and deletes the current breakpoint. The second form can remove any breakpoint, but you need to specify the exact address, as it can be obtained from show b To single-step the kernel, try s This will step into functions, but you can make DDB trace them until the matching return statement is reached by n - Note: this is different from gdb's `next' statement, it's like + Note: this is different from gdb's `next' statement, it's like gdb's `finish'. To examine data from memory, use (for example): x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10 x/s stringbuf for word/halfword/byte access, and hexadecimal/decimal/character/ string display. The number after the comma is the object count. To display the next 0x10 items, simply use x ,10 Similiarly, use x/ia foofunc,10 to disassemble the first 0x10 instructions of foofunc, and display them along with their offset from the beginning of foofunc. To modify the memory, use the write command: w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 The command modifier (b/h/w) specifies the size of the data to be written, the first following expression is the address to write to, the remainder is interpreted as data to write to successive memory locations. If you need to know the current registers, use show reg Alternatively, you can display a single register value by e.g. - print $eax + p $eax and modify it by set $eax new-value Should you need to call some kernel functions from DDB, simply say call func(arg1, arg2, ...) The return value will be printed. For a ps(1) style summary of all running processes, use ps Now you have now examined why your kernel failed, and you wish to reboot. Remember that, depending on the severity of previous malfunctioning, not all parts of the kernel might still be working as expected. Perform one of the following actions to shut down and reboot your system: call diediedie() will cause your kernel to dump core and reboot, so you can later analyze the core on a higher level with kgdb. This command usually must be followed by another `continue' statement. There is now an alias for this: `panic'. call boot(0) might be a good way to cleanly shut down the running system, sync() all disks, and finally reboot. As long as the disk and file system interfaces of the kernel are not damaged, this might be a good way for an almost clean shutdown. call cpu_reset() is the final way out of disaster and almost the same as hitting the Big Red Button. + If you nead a short command summary, simply type + + help + + However, it's highly recommended to have a printed copy of the + ddb(4) manual page ready for a debugging session. + Remember that it's hard to read the on-line manual while + single-stepping the kernel. Debugging a console driver

Since you need a console driver to run DDB on, things are more - complicated if the console driver itself is flakey. You might - remember the options COMCONSOLE line, and hook up a standard + complicated if the console driver itself is failing. You might + remember the use of a serial console (either with modified boot + blocks, or by specifying -h at the Boot: + prompt), and hook up a standard terminal onto your first serial port. DDB works on any configured - console driver, of course it also works on a COMCONSOLE. + console driver, of course also on a serial console. diff --git a/handbook/memoryuse.sgml b/handbook/memoryuse.sgml index 42aa2f7679..6dac2f1f9d 100644 --- a/handbook/memoryuse.sgml +++ b/handbook/memoryuse.sgml @@ -1,55 +1,52 @@ - + PC memory utilization

Contributed by &a.joerg;. 16 Apr 1995. Question: By the way, I have seen no description of how FreeBSD uses PC memory, ie what 0-640K gets used for, does the kernel load there or higher, is the kernel relocated, etc. Is there a paper on this? -The boot sector will be loaded at 0:0x7c00, and relocates itself -immediately to 0x7c0:0. (This is nothing magic, just an adjustment -for the %cs selector, done by an ljmp.) +The boot sector will be loaded at 0:0x7c00, and relocates itself +immediately to 0x7c0:0. (This is nothing magic, just an adjustment +for the %cs selector, done by an ljmp.) -It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the -biosboot Makefile), and sets up the stack to work below 0x1fff0. +It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the +biosboot Makefile), and sets up the stack to work below 0x1fff0. After this, it jumps to the entry of boot2 within that code. I.e., it jumps over itself and the (dummy) partition table, and it's going to adjust the %cs selector---we are still in 16-bit mode there. -boot2 asks for the boot file, and examines the a.out header. It masks -the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the -file there. Hence the usual load point is 1 MB (0x00100000). During +boot2 asks for the boot file, and examines the a.out header. It masks +the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the +file there. Hence the usual load point is 1 MB (0x00100000). During load, the boot code toggles back and forth between real and protected mode, to use the BIOS in real mode. -The boot code itself uses segment selectors 0x18 and 0x20 for %cs and -%ds/%es in protected mode, and 0x28 to jump back into real mode. The -kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which -refer to dummy descriptors covering the whole address space. +The boot code itself uses segment selectors 0x18 and 0x20 for %cs and +%ds/%es in protected mode, and 0x28 to jump back into real mode. The +kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which +refer to dummy descriptors covering the entire address space. The kernel will be started at its load point. Since it's been linked for another (high) address, it will have to execute PIC until the page table and page directory stuff is setup properly, at which point paging will be enabled and the kernel will finally run at the address for which it was linked. -The kernel still skips over the first 0x500 bytes of code, in the -assumption this were valuable BIOS data space (back from old days -where it has been loaded low). Contributed by &a.davidg;. 16 Apr 1995. The physical pages immediately following the kernel BSS contain proc0's page directory, page tables, and upages. Some time later when the VM system is initialized, the physical memory between -0x1000-0x9ffff and the physical memory after the kernel +0x1000-0x9ffff and the physical memory after the kernel (text+data+bss+proc0 stuff+other misc) is made available in the form of general VM pages and added to the global free page list. diff --git a/handbook/relnotes.sgml b/handbook/relnotes.sgml index 7ee06b8978..d2d778be24 100644 --- a/handbook/relnotes.sgml +++ b/handbook/relnotes.sgml @@ -1,503 +1,503 @@ - + About this release

Since our first release of FreeBSD 1.0 nearly two years ago, FreeBSD has changed dramatically. Since release 2.0, FreeBSD has been based on the Berkeley BSD 4.4-lite code rather than the Net2 code used for previous versions. In addition to clearing the legal issues that surrounded the Net2 code, the port to 4.4 has also brought in numerous new features, filesystems and enhanced driver support. Since our release of FreeBSD 2.0 in November of 1994, the performance, feature set, and stability of FreeBSD has improved dramatically. The largest change is a revamped Virtual Memory (VM) system with a merged virtual memory and file buffer cache. This increases performance while reducing FreeBSD's memory footprint, making a system with 4 megabytes of RAM a more acceptable minimum. Other enhancements include full NIS client and server support, transaction TCP support, dial on demand PPP, an improved SCSI subsystem, early support for ISDN, support for FDDI and 100Mbit Fast Ethernet adapters, improved support for the Adaptec 2940 and hundreds of bug fixes. We've also taken the comments and suggestions of many of our users to heart and have attempted to provide what we hope is a more sane and easily understood installation process. Your feedback on this constantly evolving process is especially welcome! In addition to the base distributions, FreeBSD offers a new ported software collection with some 270 commonly sought-after programs. The list of ports ranges from World Wide Web (http) servers, to games, languages, editors and almost everything in between. The entire ports collection requires only 10MB of storage because each port contains only the changes required for the source code to compile on FreeBSD and the information necessary to automatically retrieve the original sources. The original distribution for each port you build is automatically retrieved off of CD-ROM or a via anonymous ftp, so you need only enough disk space to build the ports you want. Each port is also provided as a pre-compiled package which can be installed with the pkg_add(1) command for those who do not wish to compile their own ports from source. See for a more complete description. The core of FreeBSD does not contain DES code which would inhibit its being exported outside the United States. An add-on package, for use only in the United States, contains the programs that normally use DES. The auxiliary packages provided separately can be used by anyone. A freely exportable European distribution of DES for our non-U.S. users also exists and is described in the . If password security for FreeBSD is all you need, and you have no requirement for copying encrypted passwords from other hosts using DES into FreeBSD password entries, then FreeBSD's MD5 based security may be all you require. We feel that our default security model is more than a match for DES, and without any messy export issues to deal with. FreeBSD 2.0.5 represents the culmination of 2 years of work and many thousands of man hours put in by an international development team. We hope you enjoy it! New feature highlights

The following features were added or substantially improved between the release of 2.0 and this 2.0.5 release. In order to facilitate better communication, the person, or persons, responsible for each enhancement is noted. Any questions regarding the new functionality should be directed to them first. Kernel

Merged VM-File Buffer Cache A merged VM/buffer cache design greatly enhances overall system performance and makes it possible to do a number of more optimal memory allocation strategies that were not possible before. Owner: David Greenman (davidg@FreeBSD.org) and John Dyson (dyson@implode.root.com) Network PCB hash optimization For systems with a great number of active TCP connections (WEB and ftp servers, for example), this greatly speeds up the lookup time required to match an incoming packet up to its associated connection. Owner: David Greenman (davidg@FreeBSD.org) Name cache optimization The name-cache would cache all files of the same name to the same bucket, which would put for instance all ".." entries in the same bucket. We added the parent directory version to frustrate the hash, and improved the management of the cache in various other ways while we were at it. Owner: Poul-Henning Kamp (phk@FreeBSD.org) David Greenman (davidg@FreeBSD.org) Less restrictive swap-spaces The need to compile the names of the swap devices into the kernel has been removed. Now swapon(8) will accept any block devices, up to the maximum number of swap devices configured in the kernel. Owner: Poul-Henning Kamp (phk@FreeBSD.org) David Greenman (davidg@FreeBSD.org) Hard Wired SCSI Devices Prior to 2.0.5, FreeBSD performed dynamic assignment of unit numbers to SCSI devices as they were probed, allowing a SCSI device failure to possibly change unit number assignment. This could cause filesystems other disks in the system to be incorrectly mounted, or not mounted at all. Hard wiring allows static allocation of unit numbers (and hence device names) to scsi devices based on SCSI ID and bus. SCSI configuration occurs in the kernel config file. Samples of the configuration syntax can be found in the scsi(4) man page or the LINT kernel config file. Owner: Peter Dufault (dufault@hda.com) Sources involved: sys/scsi/* usr.sbin/config/* Slice Support FreeBSD now supports a slice abstraction which enhances FreeBSD's ability to share disks with other operating systems. This support will allow FreeBSD to inhabit DOS extended partitions. Owner: Bruce Evans (bde@FreeBSD.org) Sources involved: sys/disklabel.h sys/diskslice.h sys/dkbad.h kern/subr_diskslice.c kern/subr_dkbad.c i386/isa/diskslice_machdep.c i386/isa/wd.c scsi/sd.c dev/vn/vn.c Support for Ontrack Disk Manager Version 6.0 Support has been added for disks which use Ontrack Disk Manager. The fdisk program does not know about it however, so make all changes using the install program on the boot.flp or the Ontrack Disk Manager tool under MS-DOS. Owner: Poul-Henning Kamp (phk@FreeBSD.org) Bad144 is back and working Bad144 works again, though the semantics are slightly different than before in that the bad-spots are kept relative to the slice rather than absolute on the disk. Owner: Bruce Evans (bde@FreeBSD.org) Poul-Henning Kamp (phk@FreeBSD.org) New device support SCSI and CDROM devices

Matsushita/Panasonic (Creative) CD-ROM driver The Matsushita/Panasonic CR-562 and CR-563 drives are now supported when connected to a Sound Blaster or 100% compatible host adapter. Up to four host adapters are supported for a total of 16 CD-ROM drives. The audio functions are supported with the Karoke variable speed playback. Owner: Frank Durda IV (bsdmail@nemesis.lonestar.org) Sources involved: isa/matcd Adaptec 2742/2842/2940 SCSI driver The original 274x/284x driver has evolved considerably since the 2.0 release of FreeBSD. We now offer full support for the 2940 series as well as the Wide models of these cards. The arbitration bug that caused problems with fast devices has been corrected and experimental tagged queuing support has been added (kernel option AHC_TAGENABLE). John Aycock has also released the sequencer code under a Berkeley style copyright making the driver entirely clean of the GPL. Owner: Justin Gibbs (gibbs@FreeBSD.org) Sources involved: isa/aic7770.c pci/aic7870.c i386/scsi/* sys/dev/aic7xxx/* NCR5380/NCR53400 SCSI (ProAudio Spectrum) driver Owner: core Submitted by: Serge Vakulenko (vak@cronyx.ru) Sources involved: isa/ncr5380.c Sony CDROM driver Owner: core Submitted by: Mikael Hybsch (micke@dynas.se) Sources involved: isa/scd.c Serial devices

SDL Communications Riscom/8 Serial Board Driver Owner: Andrey Chernov (ache@FreeBSD.org) Sources involved: isa/rc.c isa/rcreg.h Cyclades Cyclom-y Serial Board Driver Owner: Bruce Evans (bde@FreeBSD.org) Submitted by: Andrew Werple (andrew@werple.apana.org.au) and Heikki Suonsivu (hsu@cs.hut.fi) Obtained from: NetBSD Sources involved: isa/cy.c Cronyx/Sigma sync/async serial driver Owner: core Submitted by: Serge Vakulenko Sources involved: isa/cronyx.c Networking

Diskless booting Diskless booting in 2.0.5 is much improved over previous releases. The boot program is in src/sys/i386/boot/netboot, and can be run from an MS-DOS system or burned into an EPROM. WD, SMC, 3COM and Novell ethernet cards are currently supported. Local swapping is also supported. DEC DC21140 Fast Ethernet driver This driver supports any of the numerous NICs using the DC21140 chipset including the 100Mb DEC DE-500-XA and SMC 9332. Owner: core Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_de.c pci/dc21040.h DEC FDDI (DEFPA/DEFEA) driver Owner: core Submitted by: Matt Thomas (thomas@lkg.dec.com) Sources involved: pci/if_pdq.c pci/pdq.c pci/pdq_os.h pci/pdqreg.h 3Com 3c505 (Etherlink/+) NIC driver Owner: core Submitted by: Dean Huxley (dean@fsa.ca) Obtained from: NetBSD Sources involved: isa/if_eg.c Fujitsu MB86960A family of NICs driver Owner: core Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp) Sources involved: isa/if_fe.c Intel EtherExpress driver Owner: Rodney W. Grimes (rgrimes@FreeBSD.org) Sources involved: isa/if_ix.c isa/if_ixreg.h 3Com 3c589 driver Owner: core Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Seiji Murata (seiji@mt.cs.keio.ac.jp) and Noriyuki Takahashi (hor@aecl.ntt.jp) Sources involved: isa/if_zp.c IBM Credit Card Adapter driver Owner: core Submitted by: "HOSOKAWA Tatsumi" (hosokawa@mt.cs.keio.ac.jp), Sources involved: isa/pcic.c isa/pcic.h EDSS1 and 1TR6 ISDN interface driver Owner: core Submitted by: Dietmar Friede (dfriede@drnhh.neuhaus.de) and Juergen Krause (jkr@saarlink.de) Sources involved: gnu/isdn/* Miscellaneous drivers

Joystick driver Owner: Jean-Marc Zucconi (jmz@FreeBSD.org) Sources involved: isa/joy.c National Instruments ``LabPC'' driver Owner: Peter Dufault (dufault@hda.com) Sources involved: isa/labpc.c WD7000 driver Owner: Olof Johansson (offe@ludd.luth.se) - Pcvt Console driver Owner: Joerg Wunsch + Pcvt Console driver Owner: Jörg Wunsch (joerg@FreeBSD.org) Submitted by: Hellmuth Michaelis (hm@altona.hamburg.com) Sources involved: isa/pcvt/* BSD-audio emulator for VAT driver Owner: Amancio Hasty (ahasty@FreeBSD.org) and Paul Traina (pst@FreeBSD.org) Sources involved: isa/sound/vat_audio.c isa/sound/vat_audioio.h National Instruments AT-GPIB and AT-GPIB/TNT GPIB driver Owner: core Submitted by: Fred Cawthorne (fcawth@delphi.umd.edu) Sources involved: isa/gpib.c isa/gpib.h isa/gpibreg.h Genius GS-4500 hand scanner driver Owner: core Submitted by: Gunther Schadow (gusw@fub46.zedat.fu-berlin.de) Sources involved: isa/gsc.c isa/gscreg.h CORTEX-I Frame Grabber Owner: core Submitted by: Paul S. LaFollette, Jr. ( Sources involved: isa/ctx.c isa/ctxreg.h Video Spigot video capture card Owner: Jim Lowe Experimental features

UNIONFS and LFS The unionfs and LFS file systems are known to be severely broken in FreeBSD 2.0.5. This is in part due to old bugs that we haven't had time to resolve yet and the need to update these file systems to deal with the new VM system. We hope to address these issues in a later release of FreeBSD. iBCS2 Support FreeBSD now supports running iBCS2 compatible binaries. Currently SCO UNIX 3.2.2 and 3.2.4, and ISC 2.2 COFF are supported. The iBCS2 emulator is in its early stages and has not been extensively tested, but it is functional. Most of SCO's 3.2.2 binaries work, as does an old INFORMIX-2.10 for SCO. Further testing is nessesary to complete this project. There is also work under way for ELF and XOUT loaders, and most of the svr4 syscall wrappers are written. Owner: Soren Schmidt (sos) and Sean Eric Fagan (sef) Sources involved: sys/i386/ibcs2/* and misc kernel changes.