aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDoc Manager <doceng@FreeBSD.org>1995-09-08 19:40:05 +0000
committerDoc Manager <doceng@FreeBSD.org>1995-09-08 19:40:05 +0000
commit1e3d63db88bcd7862a9788e164577763ff3bea7e (patch)
treec8268aa99d77b7dca1e337039e1fd7d7818ed136
parent7a5f061be2bfee99b0b6f405a08067d412ce9c76 (diff)
downloaddoc-1e3d63db88bcd7862a9788e164577763ff3bea7e.tar.gz
doc-1e3d63db88bcd7862a9788e164577763ff3bea7e.zip
Create branch 'RELENG_2_1_0'.
Notes
Notes: svn path=/branches/RELENG_2_1_0/; revision=79
-rw-r--r--FAQ/Makefile6
-rw-r--r--handbook/Makefile12
-rw-r--r--handbook/boothelp.sgml50
-rw-r--r--handbook/contrib.sgml300
-rw-r--r--handbook/hw.sgml319
-rw-r--r--handbook/install.sgml652
-rw-r--r--handbook/kerneldebug.sgml425
-rw-r--r--handbook/mirrors.sgml410
-rw-r--r--handbook/relnotes.sgml503
-rw-r--r--handbook/sections.sgml38
-rw-r--r--handbook/userppp.sgml360
11 files changed, 3075 insertions, 0 deletions
diff --git a/FAQ/Makefile b/FAQ/Makefile
new file mode 100644
index 0000000000..bce89aa43f
--- /dev/null
+++ b/FAQ/Makefile
@@ -0,0 +1,6 @@
+# $Id: Makefile,v 1.1 1995-09-08 19:40:04 jfieber Exp $
+
+DOC= freebsd-faq
+SRCS= freebsd-faq.sgml
+
+.include <bsd.sgml.mk>
diff --git a/handbook/Makefile b/handbook/Makefile
new file mode 100644
index 0000000000..ef951720a0
--- /dev/null
+++ b/handbook/Makefile
@@ -0,0 +1,12 @@
+# $Id: Makefile,v 1.1 1995-09-08 19:34:26 jfieber Exp $
+
+SRCS= authors.sgml basics.sgml bibliography.sgml boothelp.sgml
+SRCS+= booting.sgml contrib.sgml ctm.sgml current.sgml dialup.sgml
+SRCS+= diskless.sgml eresources.sgml glossary.sgml handbook.sgml
+SRCS+= history.sgml hw.sgml install.sgml kerberos.sgml kerneldebug.sgml
+SRCS+= memoryuse.sgml mirrors.sgml nfs.sgml nutshell.sgml porting.sgml
+SRCS+= ports.sgml ppp.sgml relnotes.sgml scsi.sgml sections.sgml
+SRCS+= slipc.sgml slips.sgml submitters.sgml sup.sgml
+SRCS+= troubleshooting.sgml userppp.sgml
+
+.include <bsd.sgml.mk>
diff --git a/handbook/boothelp.sgml b/handbook/boothelp.sgml
new file mode 100644
index 0000000000..78db5f6c83
--- /dev/null
+++ b/handbook/boothelp.sgml
@@ -0,0 +1,50 @@
+<!-- $Id: boothelp.sgml,v 1.1 1995-09-03 21:12:24 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
+
+<!-- Conditional flags for this version of the document -->
+<!ENTITY % boothelp.only "INCLUDE">
+<!ENTITY % handbook.only "IGNORE">
+
+<!-- Entity shorthand for authors' names and email addresses -->
+<!ENTITY % authors SYSTEM "authors.sgml">
+%authors;
+
+<!-- Entity definitions for all the parts -->
+<!ENTITY % sections SYSTEM "sections.sgml">
+%sections;
+
+]>
+
+<linuxdoc>
+ <book>
+
+ <title>FreeBSD Installation
+ <author>
+ <name></name>
+ </author>
+
+ <abstract>Welcome to FreeBSD! This guide describes the
+ FreeBSD installation process. To navigate through the
+ sections in this guide using the <bf>up</bf> and
+ <bf>down</bf> arrow keys to select a section you wish to
+ read. Then use the <bf>right arrow</bf> or the <bf>enter
+ key</bf> to view the section. You can backtrack through
+ sections you have read by using the <bf>left arrow</bf>.
+ </abstract>
+
+ <chapt><heading>General information</heading>
+ &nutshell;
+ &history;
+ &relnotes;
+
+ &install;
+ &troubleshooting;
+ &bibliography;
+ &eresources;
+ &hw;
+ &contrib;
+
+ </book>
+</linuxdoc>
diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml
new file mode 100644
index 0000000000..8b80dbe0a2
--- /dev/null
+++ b/handbook/contrib.sgml
@@ -0,0 +1,300 @@
+<!-- $Id: contrib.sgml,v 1.15 1995-09-08 10:13:12 asami Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<chapt><heading>FreeBSD contributor list<label id="contrib"></heading>
+
+ <sect><heading>Derived software contributors</heading>
+
+ <p>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 endevors.
+
+ <sect><heading>Hardware contributors</heading>
+
+ <p>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 &lt;chuckr@eng.umd.edu&gt; who's been
+ contributing his floppy tape streamer for experimental
+ work.
+
+ <sect><heading>The FreeBSD core team<label id="contrib:core"></heading>
+
+ <p>(in alphabetical order by first name):
+
+ <itemize>
+ <item>Andrey A. Chernov &lt;ache@FreeBSD.org&gt;
+ <item>Bruce Evans &lt;bde@FreeBSD.org&gt;
+ <item>David Greenman &lt;davidg@FreeBSD.org&gt;
+ <item>Garrett A. Wollman &lt;wollman@FreeBSD.org&gt;
+ <item>Gary Palmer &lt;gpalmer@FreeBSD.org&gt;
+ <item>J&ouml;rg Wunsch &lt;joerg@FreeBSD.org&gt;
+ <item>John Dyson &lt;dyson@FreeBSD.org&gt;
+ <item>Jordan K. Hubbard &lt;jkh@FreeBSD.org&gt;
+ <item>Justin Gibbs &lt;gibbs@FreeBSD.org&gt;
+ <item>Poul-Henning Kamp &lt;phk@FreeBSD.org&gt;
+ <item>Rich Murphey &lt;rich@FreeBSD.org&gt;
+ <item>Rodney W. Grimes &lt;rgrimes@FreeBSD.org&gt;
+ <item>Satoshi Asami &lt;asami@FreeBSD.org&gt;
+ <item>S&oslash;ren Schmidt &lt;sos@FreeBSD.org&gt;
+ </itemize>
+
+ <sect><heading>Who is responsible for what</heading>
+
+ <p><descrip>
+ <tag/President/ Jordan K. Hubbard &lt;jkh@FreeBSD.org&gt;
+ <tag/Principle Architect/ David Greenman &lt;davidg@FreeBSD.org&gt;
+ <tag/Documentation/ John Fieber &lt;jfieber@FreeBSD.org&gt;
+ <tag/Internationalization/ Andrey A. Chernov &lt;ache@FreeBSD.org&gt;
+ <tag/Networking/ Garrett A. Wollman &lt;wollman@FreeBSD.org&gt;
+ <tag/Postmaster/ Jonathan M. Bresler &lt;jmb@FreeBSD.org&gt;
+ <tag/Public Relations/ Jordan Hubbard &lt;jkh@FreeBSD.org&gt;
+ <tag/Release Coordinator/ Jordan Hubbard &lt;jkh@FreeBSD.org&gt;
+ <tag/System Administration/ Gary Palmer &lt;gpalmer@FreeBSD.org&gt;
+ <tag/Webmasters/ John Fieber &lt;jfieber@FreeBSD.org&gt; and
+ James L. Robinson &lt;jlrobin@FreeBSD.org&gt;
+ <tag/XFree86 Project, Inc. Liason/ Rich Murphey
+ &lt;rich@FreeBSD.org&gt;
+ </descrip>
+
+ <sect><heading>Additional FreeBSD contributors</heading>
+
+ <p>(in alphabetical order by first name):
+
+ <itemize>
+ <item>Adam David &lt;adam@veda.is&gt;
+ <item>Adam Glass &lt;glass@postgres.berkeley.edu&gt;
+ <item>Akito Fujita &lt;fujita@zoo.ncl.omron.co.jp&gt;
+ <item>Alain Kalker &lt;alain@Wit401402.student.utwente.nl&gt;
+ <item>Andras Olah &lt;olah@cs.utwente.nl&gt;
+ <item>Andreas Klemm &lt;andreas@knobel.GUN.de&gt;
+ <item>Andrew Herbert &lt;andrew@werple.apana.org.au&gt;
+ <item>Andrew Moore &lt;alm@FreeBSD.org&gt;
+ <item>Anthony Yee-Hang Chan &lt;yeehang@netcom.com&gt;
+ <item>Atsushi Murai &lt;amurai@spec.co.jp&gt;
+ <item>Bill Fenner &lt;fenner@parc.xerox.com&gt;
+ <item>Bill Paul &lt;wpaul@FreeBSD.org&gt;
+ <item>Bob Wilcox &lt;bob@obiwan.uucp&gt;
+ <item>Brian Tao &lt;taob@gate.sinica.edu.tw&gt;
+ <item>Charles Hannum &lt;mycroft@ai.mit.edu&gt;
+ <item>Chris G. Demetriou &lt;cgd@postgres.berkeley.edu&gt;
+ <item>Chris Provenzano &lt;proven@athena.mit.edu&gt;
+ <item>Chris Stenton &lt;jacs@gnome.co.uk&gt;
+ <item>Chris Torek &lt;torek@ee.lbl.gov&gt;
+ <item>Christian Gusenbauer &lt;cg@fimp01.fim.uni-linz.ac.at&gt;
+ <item>Christoph Robitschko &lt;chmr@edvz.tu-graz.ac.at&gt;
+ <item>Chuck Robey &lt;chuckr@Glue.umd.edu&gt;
+ <item>Cornelis van der Laan &lt;nils@guru.ims.uni-stuttgart.de&gt;
+ <item>Craig Struble &lt;cstruble@vt.edu&gt;
+ <item>Curt Mayer &lt;curt@toad.com&gt;
+ <item>Danny J. Zerkel &lt;dzerkel@feephi.phofarm.com&gt;
+ <item>Dave Burgess &lt;burgess@hrd769.brooks.af.mil&gt;
+ <item>Dave Chapeskie &lt;dchapes@zeus.leitch.com&gt;
+ <item>Dave Rivers &lt;rivers@ponds.uucp&gt;
+ <item>David Dawes &lt;dawes@physics.su.OZ.AU&gt;
+ <item>Dean Huxley &lt;dean@fsa.ca&gt;
+ <item>Don Whiteside &lt;dwhite@anshar.shadow.net&gt;
+ <item>Eric L. Hernes &lt;erich@lodgenet.com&gt;
+ <item>Frank Durda IV &lt;bsdmail@nemesis.lonestar.org&gt;
+ <item>Frank Maclachlan &lt;fpm@crash.cts.com&gt;
+ <item>Frank Nobis &lt;fn@trinity.radio-do.de&gt;
+ <item>Gary A. Browning &lt;gab10@griffcd.amdahl.com&gt;
+ <item>Gary Clark II &lt;gclarkii@FreeBSD.ORG&gt;
+ <item>Gary Jennejohn &lt;gj%pcs.dec.com@inet-gw-1.pa.dec.com&gt;
+ <item>Gene Stark &lt;stark@cs.sunysb.edu&gt;
+ <item>Guido van Rooij &lt;guido@gvr.win.tue.nl&gt;
+ <item>Havard Eidnes &lt;Havard.Eidnes@runit.sintef.no&gt;
+ <item>Holger Veit &lt;Holger.Veit@gmd.de&gt;
+ <item>Ishii Masahiro, R. Kym Horsell
+ <item>J.T. Conklin &lt;jtc@winsey.com&gt;
+ <item>James Clark &lt;jjc@jclark.com&gt;
+ <item>James da Silva &lt;jds@cs.umd.edu&gt; et al
+ <item>Janusz Kokot &lt;janek@gaja.ipan.lublin.pl&gt;
+ <item>Javier Martin Rueda &lt;jmrueda@diatel.upm.es&gt;
+ <item>Jim Wilson &lt;wilson@moria.cygnus.com&gt;
+ <item>Jonathan Bresler &lt; jmb@FreeBSD.ORG&gt;
+ <item>Josh MacDonald &lt;jmacd@uclink.berkeley.edu&gt;
+ <item>Julian Elischer &lt;julian@dialix.oz.au&gt;
+ <item>Julian Stacey &lt;stacey@guug.de&gt;
+ (fallback: &lt;julian@meepmeep.pcs.com&gt)
+ <item>Keith Bostic &lt;bostic@toe.CS.Berkeley.EDU&gt;
+ <item>Keith Moore &lt;?&gt;
+ <item>Kirk McKusick &lt;mckusick@mckusick.com&gt;
+ <item>Kurt Olsen &lt;kurto@tiny.mcs.usu.edu&gt;
+ <item>L Jonas Olsson &lt;ljo@po.cwru.edu&gt;
+ <item>Lars Fredriksen &lt;fredriks@mcs.com&gt;
+ <item>Lucas James &lt;Lucas.James@ldjpc.apana.org.au&gt;
+ <item>Marc Frajola &lt;marc@dev.com&gt;
+ <item>Marc Ramirez &lt;mrami@mramirez.sy.yale.edu
+ <item>Marc van Kempen &lt;wmbfmk@urc.tue.nl&gt;
+ <item>Mark Murray &lt;mark@grondar.za&gt;
+ <item>Mark Tinguely &lt;tinguely@plains.nodak.edu&gt;
+ &lt;tinguely@hookie.cs.ndsu.NoDak.edu&gt;
+ <item>Martin Birgmeier
+ <item>Martin Renters &lt;martin@innovus.com&gt;
+ <item>Matt Thomas &lt;thomas@lkg.dec.com&gt;
+ <item>Michael Smith &lt;msmith@atrad.adelaide.edu.au&gt;
+ <item>Mike Pritchard &lt;mpp@mpp.minn.net&gt;
+ <item>NIIMI Satoshi &lt;sa2c@and.or.jp&gt;
+ <item>Nate Williams &lt;nate@FreeBSD.org&gt;
+ <item>Nobuhiro Yasutomi &lt;nobu@psrc.isac.co.jp&gt;
+ <item>Nobuyuki Koganemaru &lt;kogane@kces.koganemaru.co.jp&gt;
+ <item>Ollivier Robert &lt;roberto@FreeBSD.org&gt;
+ <item>Paul Kranenburg &lt;pk@cs.few.eur.nl&gt;
+ <item>Paul Mackerras &lt;paulus@cs.anu.edu.au&gt;
+ <item>Paul Richards &lt;paul@FreeBSD.org&gt;
+ <item>Paul Traina &lt;pst@cisco.com&gt;
+ <item>Peter Dufault &lt;dufault@hda.com&gt;
+ <item>Peter Wemm &lt;peter@haywire.DIALix.COM&gt;
+ <item>Philippe Charnier &lt;charnier@lirmm.fr&gt;
+ <item>Richard Stallman &lt;rms@gnu.ai.mit.edu&gt;
+ <item>Rob Shady &lt;rls@id.net&gt;
+ <item>Rob Snow &lt;rsnow@txdirect.net&gt;
+ <item>Sascha Wildner &lt;swildner@channelz.GUN.de&gt;
+ <item>Scott Mace &lt;smace@FreeBSD.org&gt;
+ <item>Sean Eric Fagan &lt;sef@kithrup.com&gt;
+ <item>Serge V. Vakulenko &lt;vak@zebub.msk.su&gt;
+ <item>Stefan Esser &lt;se@MI.Uni-Koeln.DE&gt;
+ <item>Stephen McKay &lt;syssgm@devetir.qld.gov.au&gt;
+ <item>Steve Gerakines &lt;steve2@genesis.tiac.net&gt;
+ <item>Steven Wallace &lt;swallace@ece.uci.edu&gt;
+ <item>Tatsumi Hosokawa &lt;hosokawa@mt.cs.keio.ac.jp&gt;
+ <item>Terry Lee &lt;terry@uivlsi.csl.uiuc.edu&gt;
+ <item>Theo Deraadt &lt;deraadt@fsa.ca&gt;
+ <item>Thomas Gellekum &lt;thomas@ghpc8.ihf.rwth-aachen.de&gt;
+ <item>Tom Samplonius &lt;tom@misery.sdf.com&gt;
+ <item>Torbjorn Granlund &lt;tege@matematik.su.se&gt;
+ <item>Torsten Blum &lt;torstenb@FreeBSD.ORG&gt;
+ <item>Ugen J.S.Antsilevich &lt;ugen@NetVision.net.il&gt;
+ <item>Werner Griessl &lt;werner@btp1da.phy.uni-bayreuth.de&gt;
+ <item>Wolfgang Stanglmeier &lt;wolf@kintaro.cologne.de&gt;
+ <item>Wolfram Schneider &lt;wosch@cs.tu-berlin.de&gt;
+ <item>Yuval Yarom &lt;yval@cs.huji.ac.il&gt;
+ <item>Yves Fonk &lt;yves@cpcoup5.tn.tudelft.nl&gt;
+ </itemize>
+
+ <sect><heading>386BSD Patch kit patch contributors</heading>
+
+ <p>(in alphabetical order by first name):
+
+ <itemize>
+ <item>Adam Glass &lt;glass@postgres.berkeley.edu&gt;
+ <item>Adrian Hall &lt;adrian@ibmpcug.co.uk&gt;
+ <item>Andrey A. Chernov &lt;ache@astral.msk.su&gt;
+ <item>Andrew Herbert &lt;andrew@werple.apana.org.au&gt;
+ <item>Andrew Moore &lt;alm@netcom.com&gt;
+ <item>Andy Valencia &lt;ajv@csd.mot.com&gt; &lt;jtk@netcom.com&gt;
+ <item>Arne Henrik Juul &lt;arnej@Lise.Unit.NO&gt;
+ <item>Bakul Shah &lt;bvs@bitblocks.com&gt;
+ <item>Barry Lustig &lt;barry@ictv.com&gt;
+ <item>Bob Wilcox &lt;bob@obiwan.uucp&gt;
+ <item>Branko Lankester
+ <item>Brett Lymn &lt;blymn@mulga.awadi.com.AU&gt;
+ <item>Charles Hannum &lt;mycroft@ai.mit.edu&gt;
+ <item>Chris G. Demetriou &lt;cgd@postgres.berkeley.edu&gt;
+ <item>Chris Torek &lt;torek@ee.lbl.gov&gt;
+ <item>Christoph Robitschko &lt;chmr@edvz.tu-graz.ac.at&gt;
+ <item>Daniel Poirot &lt;poirot@aio.jsc.nasa.gov&gt;
+ <item>Dave Burgess &lt;burgess@hrd769.brooks.af.mil&gt;
+ <item>Dave Rivers &lt;rivers@ponds.uucp&gt;
+ <item>David Dawes &lt;dawes@physics.su.OZ.AU&gt;
+ <item>David Greenman &lt;davidg@Root.COM&gt;
+ <item>Eric J. Haug &lt;ejh@slustl.slu.edu&gt;
+ <item>Felix Gaehtgens &lt;felix@escape.vsse.in-berlin.de&gt;
+ <item>Frank Maclachlan &lt;fpm@crash.cts.com&gt;
+ <item>Gary A. Browning &lt;gab10@griffcd.amdahl.com&gt;
+ <item>Geoff Rehmet &lt;csgr@alpha.ru.ac.za&gt;
+ <item>Goran Hammarback &lt;goran@astro.uu.se&gt;
+ <item>Guido van Rooij &lt;guido@gvr.win.tue.nl&gt;
+ <item>Guy Harris &lt;guy@auspex.com&gt;
+ <item>Havard Eidnes &lt;Havard.Eidnes@runit.sintef.no&gt;
+ <item>Herb Peyerl &lt;hpeyerl@novatel.cuc.ab.ca
+ <item>Holger Veit &lt;Holger.Veit@gmd.de&gt;
+ <item>Ishii Masahiro, R. Kym Horsell
+ <item>J.T. Conklin &lt;jtc@winsey.com&gt;
+ <item>Jagane D Sundar &lt; jagane@netcom.com &gt;
+ <item>James Clark &lt;jjc@jclark.com&gt;
+ <item>James Jegers &lt;jimj@miller.cs.uwm.edu&gt;
+ <item>James W. Dolter
+ <item>James da Silva &lt;jds@cs.umd.edu&gt; et al
+ <item>Jay Fenlason &lt;hack@datacube.com&gt;
+ <item>Jim Wilson &lt;wilson@moria.cygnus.com&gt;
+ <item>Joerg Lohse &lt;lohse@tech7.informatik.uni-hamburg.de&gt;
+ <item>J&ouml;rg Wunsch &lt;joerg_wunsch@uriah.heep.sax.de&gt;
+ <item>John Dyson - &lt;formerly dyson@ref.tfs.com&gt;
+ <item>John Woods &lt;jfw@eddie.mit.edu&gt;
+ <item>Jordan K. Hubbard &lt;jkh@whisker.hubbard.ie&gt;
+ <item>Julian Elischer &lt;julian@dialix.oz.au&gt;
+ <item>Julian Stacey &lt;stacey@guug.de&gt;
+ (fallback: &lt;julian@meepmeep.pcs.com&gt;)
+ <item>Karl Lehenbauer &lt;karl@NeoSoft.com&gt;
+ &lt;karl@one.neosoft.com&gt;
+ <item>Keith Bostic &lt;bostic@toe.CS.Berkeley.EDU&gt;
+ <item>Ken Hughes
+ <item>Kent Talarico &lt;kent@shipwreck.tsoft.net&gt;
+ <item>Kevin Lahey &lt;kml%rokkaku.UUCP@mathcs.emory.edu&gt;
+ &lt;kml@mosquito.cis.ufl.edu&gt;
+ <item>Marc Frajola &lt;marc@dev.com&gt;
+ <item>Mark Tinguely &lt;tinguely@plains.nodak.edu&gt;
+ &lt;tinguely@hookie.cs.ndsu.NoDak.edu&gt;
+ <item>Martin Renters &lt;martin@innovus.com&gt;
+ <item>Michael Galassi &lt;nerd@percival.rain.com&gt;
+ <item>Mike Durkin &lt;mdurkin@tsoft.sf-bay.org&gt;
+ <item>Nate Williams &lt;nate@bsd.coe.montana.edu&gt;
+ <item>Nick Handel &lt;nhandel@NeoSoft.com&gt;
+ &lt;nick@madhouse.neosoft.com&gt;
+ <item>Pace Willisson &lt;pace@blitz.com&gt;
+ <item>Paul Kranenburg &lt;pk@cs.few.eur.nl&gt;
+ <item>Paul Mackerras &lt;paulus@cs.anu.edu.au&gt;
+ <item>Paul Popelka &lt;paulp@uts.amdahl.com&gt;
+ <item>Peter da Silva &lt;peter@NeoSoft.com&gt;
+ <item>Phil Sutherland &lt;philsuth@mycroft.dialix.oz.au&gt;
+ <item>Ralf Friedl &lt;friedl@informatik.uni-kl.de&gt;
+ <item>Rick Macklem &lt;root@snowhite.cis.uoguelph.ca&gt;
+ <item>Robert D. Thrush &lt;rd@phoenix.aii.com&gt;
+ <item>Rodney W. Grimes &lt;rgrimes@cdrom.com&gt;
+ <item>Rog Egge &lt;?&gt;
+ <item>Sascha Wildner &lt;swildner@channelz.GUN.de&gt;
+ <item>Scott Burris &lt;scott@pita.cns.ucla.edu&gt;
+ <item>Scott Reynolds &lt;scott@clmqt.marquette.mi.us&gt;
+ <item>Sean Eric Fagan &lt;sef@kithrup.com&gt;
+ <item>Simon J Gerraty &lt;sjg@melb.bull.oz.au&gt;
+ &lt;sjg@zen.void.oz.au&gt;
+ <item>Stephen McKay &lt;syssgm@devetir.qld.gov.au&gt;
+ <item>Terry Lambert &lt;terry@icarus.weber.edu&gt;
+ <item>Terry Lee &lt;terry@uivlsi.csl.uiuc.edu&gt;
+ <item>Warren Toomey &lt;wkt@csadfa.cs.adfa.oz.au&gt;
+ <item>Wiljo Heinen &lt;wiljo@freeside.ki.open.de&gt;
+ <item>William Jolitz &lt;withheld&gt;
+ <item>Wolfgang Solfrank &lt;ws@tools.de&gt;
+ <item>Wolfgang Stanglmeier &lt;wolf@dentaro.GUN.de&gt;
+ <item>Yuval Yarom &lt;yval@cs.huji.ac.il&gt;
+ </itemize>
+
+ 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/hw.sgml b/handbook/hw.sgml
new file mode 100644
index 0000000000..dd49b55fae
--- /dev/null
+++ b/handbook/hw.sgml
@@ -0,0 +1,319 @@
+<!-- $Id: hw.sgml,v 1.6 1995-09-02 11:09:03 ats Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<!--
+<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN">
+-->
+
+<chapt><heading>PC Hardware compatibility<label id="hw"></heading>
+
+ <p>Issues of hardware compatibility are among the most
+ troublesome in the computer industry today and FreeBSD is by
+ no means immune to trouble. In this respect, FreeBSD's
+ advantage of being able to run on inexpensive commidity PC
+ hardware is also its liability when it comes to support for
+ the amazing variety of components on the market. While it
+ would be impossible to provide a exhaustive listing of
+ hardware that FreeBSD supports, this section serves as a
+ catalog of the device drivers included with FreeBSD and the
+ hardware each drivers supports. Where possible and
+ appropriate, notes about specific products are included.
+
+ As FreeBSD is a volunteer project without a funded testing
+ department, we depend on you, the user, for much of the
+ information contained in this catalog. If you have direct
+ experience of hardware that does or does not work with
+ FreeBSD, please let us know by sending email to
+ <tt>doc@freebsd.org</tt>. Questions about supported hardware
+ should be directed to <tt>questions@freebsd.org</tt> (see
+ <ref id="eresources:mail" name="Mailing Lists"> for more
+ information). When submitting information or asking a
+ question, please remember to specify exactly what version of
+ FreeBSD you are using and include as many details of your
+ hardware as possible.
+
+<sect><heading>Core/Processing<label id="hw:core"></heading>
+
+<sect1><heading>Motherboards, busses, and chipsets</heading>
+ <sect2><heading>* ISA</heading>
+ <sect2><heading>* EISA</heading>
+ <sect2><heading>* VLB</heading>
+ <sect2><heading>PCI</heading>
+
+ <p><em>Contributed by &a.rgrimes;.<newline>25 April 1995.</em></p>
+
+ <p>Of the Intel PCI chip sets the following is a list
+ of brokenness from worst to best and a short
+ description of brokenness.</p>
+
+ <p><descrip>
+
+ <tag>Mercury:</tag> Cache coherency problems,
+ especially if there are ISA bus masters behind
+ the ISA to PCI bridge chip. Hardware flaw, only
+ known work around is to turn the cache
+ off.
+
+ <tag>Saturn-I <em>(ie, 82424ZX at rev 0, 1 or
+ 2)</em>:</tag> write back cache coherency
+ problems. Hardware flaw, only known work around
+ is to set the external cache to write-through
+ mode. Upgrade to Saturn-II.
+
+ <tag>Saturn-II <em>(ie, 82424ZX at rev 3 or
+ 4)</em>:</tag> Works fine, but many MB
+ manufactures leave out the external dirty bit
+ SRAM needed for write back operation. Work
+ arounds are either run it in write through mode,
+ or get the dirty bit SRAM installed. (I have
+ these for the ASUS PCI/I-486SP3G rev 1.6 and
+ later boards).
+
+ <tag>Neptune:</tag> Can not run more than 2 bus
+ master devices. Admitted Intel design flaw.
+ Workarounds include do not run more than 2 bus
+ masters, special hardware design to replace the
+ PCI bus arbiter (appears on Intel Altair board
+ and several other Intel server group MB's). And
+ of course Intel's official answer, move to the
+ Triton chip set, we ``fixed it there''.
+
+ <tag>Triton:</tag> No known cache coherency or bus
+ master problems, chip set does not implement
+ parity checking. Workaround for parity issue.
+ Wait for Triton-II.
+
+ <tag>Triton-II:</tag> Unknown, not yet shipping.
+
+ </descrip>
+ </p>
+
+<sect1><heading>* CPUs/FPUs</heading>
+<sect1><heading>* Memory</heading>
+<sect1><heading>* BIOS</heading>
+
+<sect><heading>Input/Output Devices<label id="hw:io"></heading>
+
+<sect1><heading>* Video cards</heading>
+<sect1><heading>* Sound cards</heading>
+<sect1><heading>Serial ports and multiport cards</heading>
+
+ <p>The <tt>sio</tt> driver provides support for NS8250-,
+ NS16450-, NS16550 and NS16550A-based EIA RS-232C (CCITT
+ V.24) communications interfaces. Several multiport
+ cards are supported as well. See the <tt>sio(4)</tt>
+ manual page for detailed technical documentation.
+
+<sect2><heading>Digiboard PC/8</heading>
+
+ <p><em>Contributed by &a.awebster;.<newline>26 August
+ 1995.</em>
+
+ Here is a config snippet from a machine with
+ digiboard PC/8 with 16550. It has 8 modems connected
+ to these 8 lines, and they work just great. Do not
+ forget to add <tt>options "COM_MULTIPORT"</tt> or it
+ will not work very well!
+
+<tscreen><verb>
+device sio4 at isa? port 0x100 tty flags 0xb05
+device sio5 at isa? port 0x108 tty flags 0xb05
+device sio6 at isa? port 0x110 tty flags 0xb05
+device sio7 at isa? port 0x118 tty flags 0xb05
+device sio8 at isa? port 0x120 tty flags 0xb05
+device sio9 at isa? port 0x128 tty flags 0xb05
+device sio10 at isa? port 0x130 tty flags 0xb05
+device sio11 at isa? port 0x138 tty flags 0xb05 irq 9 vector siointr
+</verb></tscreen>
+
+ The trick in setting this up is that the MSB of the
+ flags represent the last SIO port, in this case 11 so
+ flags are 0xb05.
+
+<sect2><heading>Boca 16</heading>
+
+ <p><em>Contributed by &a.whiteside;.<newline>26 August
+ 1995.</em>
+
+ The procedures to make a Boca 16 pord board with
+ FreeBSD are pretty straighforward, but you will need
+ a couple things to make it work:
+
+ <enum>
+ <item>You either need the kernel sources installed
+ so you can recompile the necessary options or
+ you will need someone else to compile it for you.
+ The 2.0.5 default kernel does <bf>not</bf> come with
+ multiport support enabled and you will need to add
+ a device entry for each port anyways.
+ </item>
+ <item>Two, you will need to know the interrupt and IO
+ setting for your Boca Board so you can set these
+ options properly in the kernel.</item>
+ </enum>
+
+ One important note - the actual UART chips for the
+ Boca 16 are in the connector box, not on the internal
+ board itself. So if you have it unplugged, probes of
+ those ports will fail. I have never tested booting with
+ the box unplugged and plugging it back in, and I
+ suggest you do not either.
+
+ If you do not already have a custom kernel
+ configuration file set up, refer to <ref
+ id="kernelconfig" name="Kernel Configuration"> for
+ general procedurs. The following are the specifics
+ for the Boca 16 board and assume you are using the
+ kernel name MYKERNEL and editing with vi.
+
+ <enum>
+ <item>Add the line
+<tscreen><verb>
+options "COM_MULTIPORT"
+</verb></tscreen>
+to the config file.
+</item>
+
+ <item>Where the current <tt>device sio
+ <em>xxx</em></tt> lines are, you will need to add
+ 16 more devices. <em>Only the last device
+ includes the interrupt vector for the
+ board</em>. (See the <tt>sio(4)</tt> manual page
+ for detail as to why.)
+
+ The following example is for a Boca Board with an
+ interrupt of 3, and a base IO address 100h. The
+ IO address for Each port is +8 hexidecimal from
+ the previous port, thus the 100h, 108h, 110h...
+ addresses.
+
+<tscreen><verb>
+device sio1 at isa? port 0x100 tty flags 0x1005
+device sio2 at isa? port 0x108 tty flags 0x1005
+device sio3 at isa? port 0x110 tty flags 0x1005
+device sio4 at isa? port 0x118 tty flags 0x1005
+...
+device sio15 at isa? port 0x170 tty flags 0x1005
+device sio16 at isa? port 0x178 tty flags 0x1005 irq 3 vector siointr
+</verb></tscreen>
+
+ The flags entry <em>must</em> be changed from
+ this example unless you are using the exact same
+ sio assignments. Flags are set according to
+ 0x<em>MYY</em> where <em>M</em> indicates the
+ minor number of the master port (the last port on
+ a Boca 16) and <em>YY</em> indicates if FIFO is
+ enabled or disabled(enabled), IRQ sharing is
+ used(yes) and if there is an AST/4 compatible IRQ
+ control register(no).
+
+ In this example,
+<tscreen><verb>
+flags 0x1005
+</verb></tscreen>
+
+ indicates that the master port is sio16. If I
+ added another board and assigned sio17 through
+ sio28, the flags for all 16 ports on
+ <em>that</em> board would be 0x1C05, where 1C
+ indicates the minor number of the master port.
+ Do not change the 05 setting.</item>
+
+ <item>Save and complete the kernel configuration,
+ recompile, install and reboot.
+
+ Presuming you have successfully installed the
+ recompiled kernel and have it set to the correct
+ address and IRQ, your boot message should
+ indicate the successful probe of the Boca ports
+ as follows: (obviously the sio numbers, IO and
+ IRQ could be different)
+
+<tscreen><verb>
+sio1 at 0x100-0x107 flags 0x1005 on isa
+sio1: type 16550A (multiport)
+sio2 at 0x108-0x10f flags 0x1005 on isa
+sio2: type 16550A (multiport)
+sio3 at 0x110-0x117 flags 0x1005 on isa
+sio3: type 16550A (multiport)
+sio4 at 0x118-0x11f flags 0x1005 on isa
+sio4: type 16550A (multiport)
+sio5 at 0x120-0x127 flags 0x1005 on isa
+sio5: type 16550A (multiport)
+sio6 at 0x128-0x12f flags 0x1005 on isa
+sio6: type 16550A (multiport)
+sio7 at 0x130-0x137 flags 0x1005 on isa
+sio7: type 16550A (multiport)
+sio8 at 0x138-0x13f flags 0x1005 on isa
+sio8: type 16550A (multiport)
+sio9 at 0x140-0x147 flags 0x1005 on isa
+sio9: type 16550A (multiport)
+sio10 at 0x148-0x14f flags 0x1005 on isa
+sio10: type 16550A (multiport)
+sio11 at 0x150-0x157 flags 0x1005 on isa
+sio11: type 16550A (multiport)
+sio12 at 0x158-0x15f flags 0x1005 on isa
+sio12: type 16550A (multiport)
+sio13 at 0x160-0x167 flags 0x1005 on isa
+sio13: type 16550A (multiport)
+sio14 at 0x168-0x16f flags 0x1005 on isa
+sio14: type 16550A (multiport)
+sio15 at 0x170-0x177 flags 0x1005 on isa
+sio15: type 16550A (multiport)
+sio16 at 0x178-0x17f irq 3 flags 0x1005 on isa
+sio16: type 16550A (multiport master)
+</verb></tscreen>
+
+ If the messages go by too fast to see, <tt>dmesg
+ &gt; more</tt> will show you the boot
+ messages.</item>
+
+ <item>Next, apprepriate entries in <tt>/dev</tt> for the devices
+ must be made using the <tt>/dev/MAKEDEV</tt>
+ script. After becoming root:
+<tscreen>
+cd /dev<newline>
+./MAKEDEV tty1<newline>
+./MAKEDEV cua1<newline>
+<em>.. (everything inbetween)</em><newline>
+./MAKEDEV ttyg<newline>
+./MAKEDEV cuag
+</tscreen>
+
+ If you do not want or need callout devices for some
+ reason, you can dispense with making the <tt>cua*</tt>
+ devices.</item>
+
+ <item>If you want a quick and sloppy way to make
+ sure the devices are working, you can simply plug
+ a modem into each port and (as root) <tt>echo at
+ &gt; ttyd*</tt> for each device you have
+ made. You <em>should</em> see the RX lights flash
+ for each working port.</item>
+ </enum>
+
+
+<sect1><heading>* Parallel ports</heading>
+<sect1><heading>* Modems</heading>
+<sect1><heading>* Network cards</heading>
+<sect1><heading>* Keyboards</heading>
+<sect1><heading>* Mice</heading>
+<sect1><heading>* Other</heading>
+
+<sect><heading>* Storage Devices<label id="hw:storage"></heading>
+
+<sect1><heading>* Disk/tape controllers</heading>
+ <sect2><heading>* SCSI</heading>
+ <sect2><heading>* IDE</heading>
+ <sect2><heading>* Floppy</heading>
+<sect1><heading>* Hard drives</heading>
+<sect1><heading>* Tape drives</heading>
+<sect1><heading>* CD-ROM drives</heading>
+<sect1><heading>* Other</heading>
+
+<sect><heading>* Other<label id="hw:other"></heading>
+
+<sect1><heading>* PCMCIA</heading>
+
+
+
diff --git a/handbook/install.sgml b/handbook/install.sgml
new file mode 100644
index 0000000000..ba63835ca2
--- /dev/null
+++ b/handbook/install.sgml
@@ -0,0 +1,652 @@
+<!-- $Id: install.sgml,v 1.9 1995-08-29 01:42:39 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<!--
+<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
+-->
+<chapt><heading>Installing FreeBSD<label id="install"></heading>
+
+ <sect><heading>MS-DOS user's Questions and Answers</heading>
+
+ <p><bf>Help! I have no space! Do I need to delete
+ everything first?</bf>
+
+ 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 <tt>tools</tt> 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 <em>Distributions</em>
+ menu for an estimation of how much free space you'll need
+ for the kind of installation you want.
+
+
+ <bf>Can I use compressed MS-DOS filesystems from
+ FreeBSD?</bf>
+
+ 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!). <bf>Do not
+ remove that file!</bf> 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.
+
+
+ <bf>Can I mount my MS-DOS extended partitions?</bf>
+
+ 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.
+
+
+ <bf>Can I run MS-DOS binaries under FreeBSD?</bf>
+
+ 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
+ much closer to being a reality sometime soon. Send mail
+ to hackers@freebsd.org if you're interested in joining
+ this effort!
+
+
+
+ <sect><heading>Supported Configurations<label id="install:hw"></heading>
+
+ <p>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.
+
+ <sect1><heading>Disk Controllers</heading>
+
+ <p>
+ <itemize>
+ <item>WD1003 (any generic MFM/RLL)
+ <item>WD1007 (any generic IDE/ESDI)
+ <item>WD7000
+ <item>IDE
+ <item>ATA
+
+ <item>Adaptec 152x series ISA SCSI controllers
+ <item>Adaptec 154x series ISA SCSI controllers
+ <item>Adaptec 174x series EISA SCSI controller in
+ standard and enhanced mode.
+ <item>Adaptec 274X/284X/2940 <!-- 3940 (in 2.1) -->
+ (Narrow/Wide/Twin)
+ series EISA/VLB/PCI SCSI controllers
+ <item>Adaptec AIC-6260 and AIC-6360 based boards,
+ which includes the AHA-152x and SoundBlaster SCSI
+ cards.
+
+ <bf>Note:</bf> 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.
+
+ <item>Buslogic 545S &amp; 545c
+ <bf>Note:</bf> that Buslogic was formerly known as "Bustec".
+ <item>Buslogic 445S/445c VLB SCSI controller
+ <item>Buslogic 742A, 747S, 747c EISA SCSI controller.
+ <item>Buslogic 946c PCI SCSI controller
+ <item>Buslogic 956c PCI SCSI controller
+
+ <item>NCR 53C810 and 53C825 PCI SCSI controller.
+ <item>NCR5380/NCR53400 ("ProAudio Spectrum") SCSI controller.
+
+ <item>DTC 3290 EISA SCSI controller in 1542 emulation mode.
+
+ <item>UltraStor 14F, 24F and 34F SCSI controllers.
+
+ <item>Seagate ST01/02 SCSI controllers.
+
+ <item>Future Domain 8xx/950 series SCSI controllers.
+ </itemize>
+
+ With all supported SCSI controllers, full support is
+ provided for SCSI-I &amp; SCSI-II peripherals,
+ including Disks, tape drives (including DAT) and CD ROM
+ drives.
+
+ The following CD-ROM type systems are supported at this
+ time:
+
+ <itemize>
+ <item>SCSI (also includes ProAudio Spectrum and
+ SoundBlaster SCSI) (cd)
+ <item>Mitsumi proprietary interface (mcd)
+ <item>Matsushita/Panasonic (Creative) proprietary
+ interface (matcd)
+ <item>Sony proprietary interface (scd)
+ </itemize>
+
+ <bf>Note:</bf> CD-Drives with IDE interfaces are not
+ supported at this time.
+
+ Some controllers have limitations with the way they
+ deal with &gt;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 &gt;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.
+
+
+ <sect1><heading>Ethernet cards</heading>
+
+ <p>
+ <itemize>
+
+ <item>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.
+
+ <item>DEC EtherWORKS III NICs (DE203, DE204, and DE205)
+ <item>DEC EtherWORKS II NICs (DE200, DE201, DE202, and DE422)
+ <item>DEC DC21140 based NICs (SMC???? DE???)
+ <item>DEC FDDI (DEFPA/DEFEA) NICs
+
+ <item>Fujitsu MB86960A family of NICs
+
+ <item>Intel EtherExpress
+
+ <item>Isolan AT 4141-0 (16 bit)
+ <item>Isolink 4110 (8 bit)
+
+ <item>Novell NE1000, NE2000, and NE2100 ethernet interface.
+
+ <item>3Com 3C501 cards
+
+ <item>3Com 3C503 Etherlink II
+
+ <item>3Com 3c505 Etherlink/+
+
+ <item>3Com 3C507 Etherlink 16/TP
+
+ <item>3Com 3C509, 3C579, 3C589 (PCMCIA) Etherlink III
+
+ <item>Toshiba ethernet cards
+
+ <item>PCMCIA ethernet cards from IBM and National
+ Semiconductor are also supported.
+ </itemize>
+
+ <sect1><heading>Miscellaneous devices</heading>
+
+ <p>
+ <itemize>
+ <item>AST 4 port serial card using shared IRQ.
+
+ <item>ARNET 8 port serial card using shared IRQ.
+
+ <item>BOCA ATIO66 6 port serial card using shared IRQ.
+
+ <item>Cyclades Cyclom-y Serial Board.
+
+ <item>STB 4 port card using shared IRQ.
+
+ <item>Mitsumi (all models) CDROM interface and drive.
+
+ <item>SDL Communications Riscom/8 Serial Board.
+
+ <item>Soundblaster SCSI and ProAudio Spectrum SCSI
+ CDROM interface and drive.
+
+ <item>Matsushita/Panasonic (Creative SoundBlaster)
+ CDROM interface and drive.
+
+ <item>Adlib, SoundBlaster, SoundBlaster Pro,
+ ProAudioSpectrum, Gravis UltraSound and Roland
+ MPU-401 sound cards.
+
+ </itemize>
+
+ 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.
+
+ <sect><heading>Preparing for the installation</heading>
+
+ <p>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.
+
+ <sect1><heading>Before installing from CDROM</heading>
+
+ <p>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:
+ <tscreen>mkdir /usr/ports<newline>lndir /cdrom/ports
+ /usr/ports</tscreen>
+
+ 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!
+
+
+ <sect1><heading>Before installing from Floppy</heading>
+
+ <p>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*
+ 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.
+
+ 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.
+
+
+ <sect1><heading>Before installing from a MS-DOS partition</heading>
+
+ <p>To prepare for installation from an MS-DOS partition,
+ copy the files from the distribution into a directory
+ called <tt>C:&bsol;FREEBSD</tt>. The directory tree structure
+ of the CDROM must be partially reproduced within this directory
+ so we suggest using the DOS <tt>xcopy</tt>
+ command. For example, to prepare for a minimal installation of
+ FreeBSD:
+<tscreen><verb>
+C> MD C:\FREEBSD
+C> XCOPY /S E:\FLOPPIES C:\FREEBSD\FLOPPIES\
+C> XCOPY /S E:\DISTS\BIN C:\FREEBSD\BIN\
+</verb></tscreen>
+ asssuming that <tt>C:</tt> is where you have free space
+ and <tt>E:</tt> is where your CDROM is mounted. Note
+ that you need the <tt>FLOPPIES</tt> directory because
+ the <tt>root.flp</tt> 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
+ <tt>C:&bsol;FREEBSD</tt> - the <tt>BIN</tt> 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:
+<tscreen><verb>
+C> XCOPY /S E:\DISTS C:\FREEBSD\
+</verb></tscreen>
+ which would copy all the subdirectories of
+ <tt>E:&bsol;DISTS</tt> to <tt>C:&bsol;FREEBSD</tt>.
+
+ <sect1><heading>Before installing from QIC/SCSI Tape</heading>
+
+ <p>Installing from tape is probably the easiest method,
+ short of an on-line install using FTP or a CDROM
+ instal. 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:
+<tscreen>
+ cd /freebsd/distdir<newline>
+ tar cvf /dev/rwt0 (or /dev/rst0) dist1 .. dist2
+ </tscreen>
+ 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.
+
+
+<sect1><heading>Before installing over a network</heading>
+
+ <p>You can do network installations over 3 types of
+ communications links:
+ <descrip>
+ <tag>Serial port</tag> SLIP or PPP <tag>Parallel
+ port</tag> PLIP (laplink cable) <tag>Ethernet</tag> A
+ standard ethernet controller (includes some PCMCIA).
+ </descrip>
+
+ 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.
+
+ <sect2><heading>Preparing for NFS installation</heading>
+
+ <p>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!
+
+
+ <sect2><heading>Preparing for FTP Installation</heading>
+
+ <p>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: <tscreen>
+ ftp://192.216.222.4/pub/FreeBSD/2.0.5-RELEASE</tscreen>
+
+ <em><bf>NOTE:</bf> Substitute "ALPHA" for "RELEASE"
+ during the ALPHA test period!</em>
+
+ 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.
+
+
+ <sect><heading>Installing FreeBSD</heading>
+
+ <p>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:
+
+ <enum>
+
+ <item>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&amp;A section of the Hardware Guide
+ for possible causes.
+
+ <item>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!
+
+ <item>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.
+
+ <item>Select the Options item and set any special
+ preferences you may have.
+
+ <item>Select Proceed, bringing you to the Installation Menu.
+
+ </enum>
+
+ <sect1><heading>The installation menu</heading>
+
+ <p>You can do anything you like in this menu without
+ altering your system <em>except</em> 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.
+
+ <enum>
+
+ <item>The first step is generally `Partition', which
+ allows you to chose how your drives will be used
+ for FreeBSD.
+
+ <item>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).
+
+ <item>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.
+
+ <item>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.
+
+ <item>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.
+
+ <item>The Configure menu choice allows you to furthur
+ 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.
+
+ <item>Exit returns you to the top menu.
+
+ </enum>
+
+ 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&amp;A
+ section of the Hardware Guide for possible clues!
+
diff --git a/handbook/kerneldebug.sgml b/handbook/kerneldebug.sgml
new file mode 100644
index 0000000000..7208d09df9
--- /dev/null
+++ b/handbook/kerneldebug.sgml
@@ -0,0 +1,425 @@
+<!-- $Id: kerneldebug.sgml,v 1.3 1995-07-31 01:18:46 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<chapt><heading>Kernel Debugging<label id="kerneldebug"></heading>
+
+<p><em>Contributed by &a.paul; and &a.joerg;</em>
+
+<sect><heading>Debugging a kernel crash dump with kgdb</heading>
+
+ <p>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 <tt>config kernel</tt> 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 <tt>config -g</tt>.
+ See <ref id="kernelconfig" name="Kernel Configuration"> for
+ details on configuring the FreeBSD kernel.
+
+ Use the <tt>dumpon(8)</tt> 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 <tt>swapon(8)</tt>). This is
+ normally arranged via <tt>/etc/sysconfig</tt> and <tt>/etc/rc</tt>.
+ 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.
+
+ <em><bf>Note:</bf> In the following, the term `<tt>kgdb</tt>' refers
+ to <tt>gdb</tt> run in `kernel debug mode'. This can be accomplished by
+ either starting the <tt>gdb</tt> with the option <tt>-k</tt>, or by linking
+ and starting it under the name <tt>kgdb</tt>. This is not being
+ done by default, however.</em>
+
+ When the kernel has been built make a copy of it, say
+ <tt>kernel.debug</tt>, and then run <tt>strip -x</tt> 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 willl 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 <tt>-s</tt> flag at the
+ boot prompt, and then perform the following steps:
+<tscreen><verb>
+ 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
+</verb></tscreen>
+ This instructs <tt>savecore(8)</tt> to use another kernel for symbol name
+ extraction. It would otherwise default to the currently running kernel.
+
+ Now, after a crash dump, go to <tt>/sys/compile/WHATEVER</tt> and run
+ <tt>kgdb</tt>. From <tt>kgdb</tt> do:
+<tscreen><verb>
+ symbol-file kernel.debug
+ exec-file /var/crash/system.0
+ core-file /var/crash/ram.0
+</verb></tscreen>
+ 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 <tt>kgdb</tt>'s `where' command,
+ and look for the stack frame in the function <tt>trap()</tt>. Go `up'
+ to that frame, and then type:
+<tscreen><verb>
+ frame frame->tf_ebp frame->tf_eip
+</verb></tscreen>
+ This will tell <tt>kgdb</tt> 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 <tt>kgdb</tt> (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 <tt>kgdb</tt> session illustrating the above. 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.
+<tscreen><verb>
+ 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(&amp;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
+</verb></tscreen>
+ Comments to the above script:
+
+<descrip>
+<tag/line 6:/ This is a dump taken from within DDB (see below), hence the
+ panic comment ``because you said to!'', and a rather long
+ stack trace; the initial reason for going into DDB has been
+ a page fault trap though.
+<tag/line 20:/ This is the location of function <tt>trap()</tt>
+ in the stack trace.
+<tag/line 36:/ Force usage of a new stack frame, kgdb responds and displays
+ the source line where the trap happened; from looking at the
+ code, there's a high probability that either the pointer
+ access for ``tp'' was messed up, or the array access was
+ out of bounds.
+<tag/line 52:/ The pointer looks suspicious, but happens to be a valid
+ address.
+<tag/line 56:/ However, it obviously points to garbage, so we have found our
+ error! (For those unfamiliar with that particular piece
+ of code: <tt>tp-&gt;t_line</tt> refers to the line discipline
+ of the console device here, which must be a rather small integer
+ number.)
+</descrip>
+
+
+<sect><heading>Post-mortem analysis of a dump</heading>
+
+<p>What do you do if a kernel dumped core but you did not expect
+ it, and it's therefore not compiled using <tt>config -g</tt>?
+ 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.)
+
+ Go to your kernel compile directory, and edit the line
+ containing <tt>COPTFLAGS?=-O</tt>. Add the <tt>-g</tt> option
+ there (but <em>don't</em> 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 <tt>pcvt</tt>
+ 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 <tt>trap.o</tt>. With a bit of luck, the added
+ <tt>-g</tt> option won't change anything for the generated
+ code, so you'll finally get a new kernel with similiar code to
+ the faulting one but some debugging symbols. You should at
+ least verify the old and new sizes with the <tt>size(1)</tt> 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 <tt>kgdb</tt> session until you know enough.
+
+ All this is not guaranteed to work, but it will do it fine in
+ most cases.
+
+<sect><heading>On-line kernel debugging using DDB</heading>
+
+<p>While <tt>kgdb</tt> 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 changeing 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
+ <tt>kgdb</tt>.
+
+ To configure your kernel to include DDB, add the option line
+<tscreen><verb>
+ options DDB
+</verb></tscreen>
+ to your config file, and rebuild. (See <ref id="kernelconfig"
+ name="Kernel Configuration"> 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 <tt>-d</tt> 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'')
+ that allows the use of a serial line BREAK on the console line to
+ enter DDB.
+
+ 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 DDB commands roughly resemble some <tt>gdb</tt> commands. The first you
+ probably need is to set a breakpoint:
+<tscreen><verb>
+ b function-name
+ b address
+</verb></tscreen>
+
+ Numbers are taken hexadecimal by default, but to make them
+ distinct from symbol names, hexadecimal numbers starting with the
+ letters <tt>a</tt>-<tt>f</tt> need to be preceded with
+ <tt>0x</tt> (for other numbers, this is optional). Simple
+ expressions are allowed, for example: <tt>function-name + 0x103</tt>.
+
+ To continue the operation of an interrupted kernel, simply type
+<tscreen><verb>
+ c
+</verb></tscreen>
+ To get a stack trace, use
+<tscreen><verb>
+ trace
+</verb></tscreen>
+ 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
+<tscreen><verb>
+ del
+ del address-expression
+</verb></tscreen>
+ 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
+<tscreen><verb>
+ show b
+</verb></tscreen>
+ To single-step the kernel, try
+<tscreen><verb>
+ s
+</verb></tscreen>
+ This will step into functions, but you can make DDB trace them until
+ the matching return statement is reached by
+<tscreen><verb>
+ n
+</verb></tscreen>
+ Note: this is different from <tt>gdb</tt>'s `next' statement, it's like
+ <tt>gdb</tt>'s `finish'.
+
+ To examine data from memory, use (for example):
+<tscreen><verb>
+ x/wx 0xf0133fe0,40
+ x/hd db_symtab_space
+ x/bc termbuf,10
+ x/s stringbuf
+</verb></tscreen>
+ 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
+<tscreen><verb>
+ x ,10
+</verb></tscreen>
+ Similiarly, use
+<tscreen><verb>
+ x/ia foofunc,10
+</verb></tscreen>
+ to disassemble the first 0x10 instructions of <tt>foofunc</tt>, and display
+ them along with their offset from the beginning of <tt>foofunc</tt>.
+
+ To modify the memory, use the write command:
+<tscreen><verb>
+ w/b termbuf 0xa 0xb 0
+ w/w 0xf0010030 0 0
+</verb></tscreen>
+ The command modifier (<tt>b</tt>/<tt>h</tt>/<tt>w</tt>)
+ specifies the size of the data to be writtten, 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
+<tscreen><verb>
+ show reg
+</verb></tscreen>
+ Alternatively, you can display a single register value by e.g.
+<tscreen><verb>
+ print $eax
+</verb></tscreen>
+ and modify it by
+<tscreen><verb>
+ set $eax new-value
+</verb></tscreen>
+
+ Should you need to call some kernel functions from DDB, simply
+ say
+<tscreen><verb>
+ call func(arg1, arg2, ...)
+</verb></tscreen>
+ The return value will be printed.
+
+ For a <tt>ps(1)</tt> style summary of all running processes, use
+<tscreen><verb>
+ ps
+</verb></tscreen>
+
+ 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:
+<tscreen><verb>
+ call diediedie()
+</verb></tscreen>
+
+ 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
+ `<tt>continue</tt>' statement.
+ There is now an alias for this: `<tt>panic</tt>'.
+
+<tscreen><verb>
+ call boot(0)
+</verb></tscreen>
+ might be a good way to cleanly shut down the running system, <tt>sync()</tt>
+ 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.
+
+<tscreen><verb>
+ call cpu_reset()
+</verb></tscreen>
+ is the final way out of disaster and almost the same as hitting
+ the Big Red Button.
+
+
+
+<sect><heading>Debugging a console driver</heading>
+
+<p>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 <tt>options COMCONSOLE</tt> line, 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 <tt>COMCONSOLE</tt>.
+
+
diff --git a/handbook/mirrors.sgml b/handbook/mirrors.sgml
new file mode 100644
index 0000000000..02078b3d80
--- /dev/null
+++ b/handbook/mirrors.sgml
@@ -0,0 +1,410 @@
+<!-- $Id: mirrors.sgml,v 1.1 1995-09-01 04:54:13 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<!--
+<!doctype linuxdoc public "-//FreeBSD//DTD linuxdoc//EN">
+-->
+
+<chapt><heading>Obtaining FreeBSD<label id="mirrors"></heading>
+
+<p>The official sources for FreeBSD available via anonymous FTP from:
+<quote>
+<htmlurl url="ftp://ftp.freebsd.org/pub/FreeBSD"
+name="ftp://ftp.FreeBSD.org/pub/FreeBSD">
+</quote>
+and on CD-ROM from Walnut Creek CDROM:
+<quote>
+ Walnut Creek CDROM<newline>
+ 1547 Palos Verdes Mall, Suite 260<newline>
+ Walnut Creek CA 94596 USA<newline>
+ Phone: +1 510 647-0783<newline>
+ Fax: +1 510 647-0821<newline>
+ Email: <htmlurl url="mailto:info@cdrom.com" name="info@cdrom.com"><newline>
+ WWW: <htmlurl url="http://www.cdrom.com/" name="http://www.cdrom.com/">
+</quote>
+
+<p>Additionally, FreeBSD is available via anonymous FTP from the
+ following mirror sites. If you choose to obtain FreeBSD via
+ anonymous FTP, please try to use a site near you.
+
+<descrip>
+<tag>Australia</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.physics.usyd.edu.au/FreeBSD"
+ name="ftp://ftp.physics.usyd.edu.au/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:dawes@xfree86.org"
+ name="dawes@xfree86.org">.
+
+<item>
+<htmlurl url="ftp://minnie.cs.adfa.oz.au/FreeBSD"
+ name="ftp://minnie.cs.adfa.oz.au/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:wkt@dolphin.cs.adfa.oz.au"
+ name="wkt@dolphin.cs.adfa.oz.au">.
+
+</itemize>
+
+<tag>Canada</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.synapse.net/contrib/FreeBSD"
+ name="ftp://ftp.synapse.net/contrib/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:evanc@synapse.net"
+ name="evanc@synapse.net">.
+
+</itemize>
+
+<tag>Finland</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://nic.funet.fi/pub/unix/FreeBSD"
+ name="ftp://nic.funet.fi/pub/unix/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:count@nic.funet.fi"
+ name="count@nic.funet.fi">.
+
+</itemize>
+
+<tag>France</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.ibp.fr/pub/FreeBSD"
+ name="ftp://ftp.ibp.fr/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:Remy.Card@ibp.fr"
+ name="Remy.Card@ibp.fr">.
+
+</itemize>
+
+<tag>Germany</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD"
+ name="ftp://ftp.fb9dv.uni-duisburg.de/pub/unix/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp@ftp.fb9dv.uni-duisburg.de"
+ name="ftp@ftp.fb9dv.uni-duisburg.de">.
+
+<item>
+<htmlurl url="ftp://gil.physik.rwth-aachen.de/pub/FreeBSD"
+ name="ftp://gil.physik.rwth-aachen.de/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:kuku@gil.physik.rwth-aachen.de"
+ name="kuku@gil.physik.rwth-aachen.de">.
+
+<item>
+<htmlurl url="ftp://ftp.uni-paderborn.de/freebsd"
+ name="ftp://ftp.uni-paderborn.de/freebsd"><newline>
+ Contact: <htmlurl url="mailto:ftp@uni-paderborn.de"
+ name="ftp@uni-paderborn.de">.
+
+<item>
+<htmlurl url="ftp://ftp.leo.org/pub/comp/os/bsd/FreeBSD"
+ name="ftp://ftp.leo.org/pub/comp/os/bsd/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:bsd@leo.org"
+ name="bsd@leo.org">.
+
+<item>
+<htmlurl url="ftp://ftp.tu-dresden.de/pub/soft/unix/bsd/FreeBSD"
+ name="ftp://ftp.tu-dresden.de/pub/soft/unix/bsd/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:pdsowner@rcs1.urz.tu-dresden.de"
+ name="pdsowner@rcs1.urz.tu-dresden.de">.
+
+</itemize>
+
+<tag>Ireland</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.internet-eireann.ie/pub/FreeBSD"
+ name="ftp://ftp.internet-eireann.ie/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftpadmin@internet-eireann.ie"
+ name="ftpadmin@internet-eireann.ie">.
+
+</itemize>
+
+<tag>Israel</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://orgchem.weizmann.ac.il/pub/FreeBSD"
+ name="ftp://orgchem.weizmann.ac.il/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:serg@klara.weizmann.ac.il"
+ name="serg@klara.weizmann.ac.il">.
+
+</itemize>
+
+<tag>Hong Kong</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.hk.super.net/pub/FreeBSD"
+ name="g ftp://ftp.hk.super.net/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp-admin@HK.Super.NET"
+ name="ftp-admin@HK.Super.NET">.
+
+</itemize>
+
+<tag>Korea</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.cau.ac.kr/pub/FreeBSD"
+ name="ftp://ftp.cau.ac.kr/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftpadm@ftp.cau.ac.kr"
+ name="ftpadm@ftp.cau.ac.kr">.
+
+</itemize>
+
+<tag>Netherlands</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.nl.net/pub/os/FreeBSD"
+ name="ftp://ftp.nl.net/pub/os/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:archive@nl.net"
+ name="archive@nl.net">.
+
+</itemize>
+
+<tag>Russia</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.kiae.su/FreeBSD"
+ name="ftp://ftp.kiae.su/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp@ftp.kiae.su"
+ name="ftp@ftp.kiae.su">.
+
+</itemize>
+
+<tag>Sweden</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.luth.se/pub/FreeBSD"
+ name="ftp://ftp.luth.se/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ragge@ludd.luth.se"
+ name="ragge@ludd.luth.se">.
+
+</itemize>
+
+<tag>Taiwan</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://NCTUCCCA.edu.tw/Operating-Systems/FreeBSD"
+ name="ftp://NCTUCCCA.edu.tw/Operating-Systems/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:freebsd@NCTUCCCA.edu.tw"
+ name="freebsd@NCTUCCCA.edu.tw">.
+
+<item>
+<htmlurl url="ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD"
+ name="ftp://netbsd.csie.nctu.edu.tw/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp@netbsd.csie.nctu.edu.tw"
+ name="ftp@netbsd.csie.nctu.edu.tw">.
+
+</itemize>
+
+<tag>Thailand</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.nectec.or.th/pub/FreeBSD"
+ name="ftp://ftp.nectec.or.th/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftpadmin@ftp.nectec.or.th"
+ name="ftpadmin@ftp.nectec.or.th">.
+
+</itemize>
+
+<tag>USA</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://gatekeeper.dec.com/pub/BSD/FreeBSD"
+ name="ftp://gatekeeper.dec.com/pub/BSD/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:hubbard@gatekeeper.dec.com"
+ name="hubbard@gatekeeper.dec.com">.
+
+<item>
+<htmlurl url="ftp://ftp.cybernetics.net/pub/FreeBSD"
+ name="ftp://ftp.cybernetics.net/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:michael@Cybernetics.NET"
+ name="michael@Cybernetics.NET">.
+
+<item>
+<htmlurl url="ftp://ftp.neosoft.com/systems/FreeBSD"
+ name="ftp://ftp.neosoft.com/systems/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:smace@NeoSoft.COM"
+ name="smace@NeoSoft.COM">.
+
+<item>
+<htmlurl url="ftp://kryten.atinc.com/pub/FreeBSD"
+ name="ftp://kryten.atinc.com/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:jmb@kryten.atinc.com"
+ name="jmb@kryten.atinc.com">.
+
+<item>
+<htmlurl url="ftp://ftp.dataplex.net/pub/FreeBSD"
+ name="ftp://ftp.dataplex.net/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:rkw@dataplex.net"
+ name="rkw@dataplex.net">.
+
+<item>
+<htmlurl url="ftp://ftp.cps.cmich.edu/pub/ftp.freebsd.org"
+ name="ftp://ftp.cps.cmich.edu/pub/ftp.freebsd.org"><newline>
+ Contact: <htmlurl url="mailto:ftpadmin@cps.cmich.edu"
+ name="ftpadmin@cps.cmich.edu">.
+
+<item>
+<htmlurl url="ftp://ftp.cslab.vt.edu/pub/FreeBSD"
+ name="ftp://ftp.cslab.vt.edu/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp@ftp.cslab.vt.edu"
+ name="ftp@ftp.cslab.vt.edu">.
+
+</itemize>
+
+<tag>Japan</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.tokyonet.ad.jp/pub/FreeBSD"
+ name="ftp://ftp.tokyonet.ad.jp/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftpadmin@TokyoNet.AD.JP"
+ name="ftpadmin@TokyoNet.AD.JP">.
+
+<item>
+<htmlurl url="ftp://ftp.tut.ac.jp/FreeBSD"
+ name="ftp://ftp.tut.ac.jp/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:<ashida@ftp.tut.ac.jp"
+ name="ashida@ftp.tut.ac.jp">.
+
+<item>
+<htmlurl url="ftp://ftp.sra.co.jp/pub/os/FreeBSD"
+ name="ftp://ftp.sra.co.jp/pub/os/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp-admin@sra.co.jp"
+ name="ftp-admin@sra.co.jp">.
+
+<item>
+<htmlurl url="ftp://ftp.ee.uec.ac.jp/pub/os/mirror/ftp.freebsd.org"
+ name="ftp://ftp.ee.uec.ac.jp/pub/os/mirror/ftp.freebsd.org"><newline>
+ Contact: <htmlurl url="mailto:ftp-admin@ftp.ee.uec.ac.jp"
+ name="ftp-admin@ftp.ee.uec.ac.jp">.
+
+<item>
+<htmlurl url="ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD"
+ name="ftp://ftp.mei.co.jp/free/PC-UNIX/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:tanig@isl.mei.co.jp"
+ name="tanig@isl.mei.co.jp">.
+
+<item>
+<htmlurl url="ftp://ftp.waseda.ac.jp/pub/FreeBSD"
+ name="ftp://ftp.waseda.ac.jp/pub/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp-admin@waseda.ac.jp"
+ name="ftp-admin@waseda.ac.jp">.
+
+<item>
+<htmlurl url="ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD"
+ name="ftp://ftp.pu-toyama.ac.jp/pub/FreeBSD"><newline>
+ Contact: Yoshihiko USUI <htmlurl url="mailto:usui@pu-toyama.ac.jp"
+ name="usui@pu-toyama.ac.jp">.
+
+<item>
+<htmlurl url="ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD"
+ name="ftp://ftpsv1.u-aizu.ac.jp/pub/os/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:ftp-admin@u-aizu.ac.jp"
+ name="ftp-admin@u-aizu.ac.jp">.
+
+</itemize>
+
+<tag>UK</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD"
+ name="ftp://src.doc.ic.ac.uk/packages/unix/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:wizards@doc.ic.ac.uk"
+ name="wizards@doc.ic.ac.uk">.
+
+<item>
+<htmlurl url="ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD"
+ name="ftp://unix.hensa.ac.uk/pub/walnut.creek/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:archive-admin@unix.hensa.ac.uk"
+ name="archive-admin@unix.hensa.ac.uk">.
+
+<item>
+<htmlurl url="ftp://ftp.demon.co.uk/pub/BSD/FreeBSD"
+ name="ftp://ftp.demon.co.uk/pub/BSD/FreeBSD"><newline>
+ Contact: <htmlurl url="mailto:uploads@demon.net"
+ name="uploads@demon.net">.
+
+</itemize>
+</descrip>
+
+The latest versions of export-restricted code for FreeBSD (2.0C or later)
+(eBones and secure) are being made available at the following locations.
+If you are outside the U.S. or Canada, please get secure (DES) and
+eBones (Kerberos) from one of the following foreign distribution sites:
+
+<descrip>
+
+<tag>SouthAfrica</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://skeleton.mikom.csir.co.za/pub/FreeBSD"
+ name="ftp://skeleton.mikom.csir.co.za/pub/FreeBSD"><newline>
+ Contact: Mark Murray <htmlurl url="mailto:mark@grondar.za"
+ name="mark@grondar.za">.
+
+<item>
+<htmlurl url="ftp://storm.sea.uct.ac.za/pub/FreeBSD"
+ name="ftp://storm.sea.uct.ac.za/pub/FreeBSD"><newline>
+ Contact: Shaun Courtney <htmlurl url="mailto:ftp@storm.sea.uct.ac.za"
+ name="ftp@storm.sea.uct.ac.za">.
+
+</itemize>
+
+<tag>Brazil</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://ftp.iqm.unicamp.br/pub/FreeBSD"
+ name="ftp://ftp.iqm.unicamp.br/pub/FreeBSD"><newline>
+ Contact: Pedro A M Vazquez <htmlurl url="mailto:vazquez@iqm.unicamp.br"
+ name="vazquez@iqm.unicamp.br">.
+
+</itemize>
+
+<tag>Finland</tag>
+
+<itemize>
+
+<item>
+<htmlurl url="ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt"
+ name="ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt"><newline>
+ Contact: <htmlurl url="mailto:count@nic.funet.fi"
+ name="count@nic.funet.fi">.
+
+</itemize>
+</descrip> \ No newline at end of file
diff --git a/handbook/relnotes.sgml b/handbook/relnotes.sgml
new file mode 100644
index 0000000000..cdbf62a324
--- /dev/null
+++ b/handbook/relnotes.sgml
@@ -0,0 +1,503 @@
+<!-- $Id: relnotes.sgml,v 1.4 1995-08-29 01:42:43 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<!--
+<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
+<linuxdoc><book><chapt>foo
+-->
+ <sect><heading>About this release<label id="relnotes"></heading>
+
+ <p>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 <tt>pkg_add(1)</tt> command for those who do not
+ wish to compile their own ports from source. See <ref
+ id="ports" name="The Ports Collection"> for a more
+ complete description.
+
+<!-- XXX make xref
+ For a list of contributors and a general project
+ description, please see the file "CONTRIB.FreeBSD"
+ which should be bundled with your binary distribution.
+
+ Also see the "REGISTER.FreeBSD" file for information on
+ registering with the "Free BSD user counter". This
+ counter is for ALL freely available variants of BSD,
+ not just FreeBSD, and we urge you to register yourself
+ with it.
+-->
+
+ 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 <url
+ url="http://www.freebsd.org/How/faq" name="FreeBSD
+ FAQ">. 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!
+
+ <sect1><heading>New feature highlights</heading>
+
+ <p>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.
+
+ <sect2><heading>Kernel</heading>
+
+ <p>
+ <descrip>
+
+ <tag>Merged VM-File Buffer Cache</tag> 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)
+
+ <tag>Network PCB hash optimization</tag> 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)
+
+ <tag>Name cache optimization</tag> 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)
+
+ <tag>Less restrictive swap-spaces</tag> The need
+ to compile the names of the swap devices into
+ the kernel has been removed. Now
+ <tt>swapon(8)</tt> 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)
+
+ <tag>Hard Wired SCSI Devices</tag> 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 <tt>scsi(4)</tt> man
+ page or the LINT kernel config file.
+
+ Owner: Peter Dufault (dufault@hda.com)
+
+ Sources involved: <tt>sys/scsi/*</tt>
+ <tt>usr.sbin/config/*</tt>
+
+ <tag>Slice Support</tag> FreeBSD now supports a
+ <em>slice</em> 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: <tt>sys/disklabel.h</tt>
+ <tt>sys/diskslice.h</tt> <tt>sys/dkbad.h</tt>
+ <tt>kern/subr_diskslice.c</tt> <tt>kern/subr_dkbad.c</tt>
+ <tt>i386/isa/diskslice_machdep.c</tt> <tt>i386/isa/wd.c</tt>
+ <tt>scsi/sd.c</tt> <tt>dev/vn/vn.c</tt>
+
+ <tag>Support for Ontrack Disk Manager Version
+ 6.0</tag> Support has been added for disks
+ which use Ontrack Disk Manager. The fdisk
+ program does <em>not</em> 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)
+
+ <tag>Bad144 is back and working</tag> 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)
+
+ </descrip>
+
+ <sect2><heading>New device support</heading>
+
+ <sect3><heading>SCSI and CDROM devices</heading>
+
+ <p><descrip>
+
+ <tag>Matsushita/Panasonic (Creative) CD-ROM
+ driver</tag> 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: <tt>isa/matcd</tt>
+
+ <tag>Adaptec 2742/2842/2940 SCSI driver</tag> 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
+ <em>experimental</em> tagged queuing support has
+ been added (kernel option
+ <tt>AHC_TAGENABLE</tt>). 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: <tt>isa/aic7770.c</tt> <tt>pci/aic7870.c</tt>
+ <tt>i386/scsi/*</tt> <tt>sys/dev/aic7xxx/*</tt>
+
+ <tag>NCR5380/NCR53400 SCSI (ProAudio Spectrum)
+ driver</tag> Owner: core
+
+ Submitted by: Serge Vakulenko (vak@cronyx.ru)
+
+ Sources involved: <tt>isa/ncr5380.c</tt>
+
+ <tag>Sony CDROM driver</tag> Owner: core
+
+ Submitted by: Mikael Hybsch (micke@dynas.se)
+
+ Sources involved: <tt>isa/scd.c</tt>
+
+ </descrip>
+
+ <sect3><heading>Serial devices</heading>
+
+ <p><descrip>
+
+ <tag>SDL Communications Riscom/8 Serial Board
+ Driver</tag> Owner: Andrey Chernov
+ (ache@FreeBSD.org)
+
+ Sources involved: <tt>isa/rc.c</tt> <tt>isa/rcreg.h</tt>
+
+ <tag>Cyclades Cyclom-y Serial Board Driver</tag>
+ 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: <tt>isa/cy.c</tt>
+
+ <tag>Cronyx/Sigma sync/async serial driver</tag>
+ Owner: core
+
+ Submitted by: Serge Vakulenko
+
+ Sources involved: <tt>isa/cronyx.c</tt>
+
+ </descrip>
+
+ <sect2><heading>Networking</heading>
+
+ <p><descrip>
+
+ <tag>Diskless booting</tag> Diskless booting in 2.0.5
+ is much improved over previous releases. The boot
+ program is in <tt>src/sys/i386/boot/netboot</tt>,
+ 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.
+
+ <tag>DEC DC21140 Fast Ethernet driver</tag> 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: <tt>pci/if_de.c</tt> <tt>pci/dc21040.h</tt>
+
+
+ <tag>DEC FDDI (DEFPA/DEFEA) driver</tag> Owner: core
+
+ Submitted by: Matt Thomas (thomas@lkg.dec.com)
+
+ Sources involved: <tt>pci/if_pdq.c</tt> <tt>pci/pdq.c</tt>
+ <tt>pci/pdq_os.h</tt> <tt>pci/pdqreg.h</tt>
+
+
+ <tag>3Com 3c505 (Etherlink/+) NIC driver</tag> Owner:
+ core
+
+ Submitted by: Dean Huxley (dean@fsa.ca)
+
+ Obtained from: NetBSD
+
+ Sources involved: <tt>isa/if_eg.c</tt>
+
+
+ <tag>Fujitsu MB86960A family of NICs driver</tag>
+ Owner: core
+
+ Submitted by: M.S. (seki@sysrap.cs.fujitsu.co.jp)
+
+ Sources involved: <tt>isa/if_fe.c</tt>
+
+
+ <tag>Intel EtherExpress driver</tag> Owner: Rodney
+ W. Grimes (rgrimes@FreeBSD.org)
+
+ Sources involved: <tt>isa/if_ix.c</tt> <tt>isa/if_ixreg.h</tt>
+
+
+ <tag>3Com 3c589 driver</tag> 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: <tt>isa/if_zp.c</tt>
+
+
+ <tag>IBM Credit Card Adapter driver</tag> Owner: core
+
+ Submitted by: "HOSOKAWA Tatsumi"
+ (hosokawa@mt.cs.keio.ac.jp),
+
+ Sources involved: <tt>isa/pcic.c</tt> <tt>isa/pcic.h</tt>
+
+
+ <tag>EDSS1 and 1TR6 ISDN interface driver</tag>
+ Owner: core
+
+ Submitted by: Dietmar Friede
+ (dfriede@drnhh.neuhaus.de) and Juergen Krause
+ (jkr@saarlink.de)
+
+ Sources involved: <tt>gnu/isdn/*</tt>
+
+ </descrip>
+
+ <sect2><heading>Miscellaneous drivers</heading>
+
+ <p><descrip>
+
+ <tag>Joystick driver</tag> Owner: Jean-Marc Zucconi
+ (jmz@FreeBSD.org)
+
+ Sources involved: <tt>isa/joy.c</tt>
+
+ <tag>National Instruments "LabPC" driver</tag> Owner:
+ Peter Dufault (dufault@hda.com)
+
+ Sources involved: <tt>isa/labpc.c</tt>
+
+ <tag>WD7000 driver</tag> Owner: Olof Johansson
+ (offe@ludd.luth.se)
+
+ <tag>Pcvt Console driver</tag> Owner: Joerg Wunsch
+ (joerg@FreeBSD.org)
+
+ Submitted by: Hellmuth Michaelis
+ (hm@altona.hamburg.com)
+
+ Sources involved: <tt>isa/pcvt/*</tt>
+
+ <tag>BSD-audio emulator for VAT driver</tag> Owner:
+ Amancio Hasty (ahasty@FreeBSD.org) and
+ Paul Traina (pst@FreeBSD.org)
+
+ Sources involved: <tt>isa/sound/vat_audio.c</tt>
+ <tt>isa/sound/vat_audioio.h</tt>
+
+ <tag>National Instruments AT-GPIB and AT-GPIB/TNT
+ GPIB driver</tag> Owner: core
+
+ Submitted by: Fred Cawthorne
+ (fcawth@delphi.umd.edu)
+
+ Sources involved: <tt>isa/gpib.c</tt> <tt>isa/gpib.h</tt>
+ <tt>isa/gpibreg.h</tt>
+
+ <tag>Genius GS-4500 hand scanner driver</tag> Owner:
+ core
+
+ Submitted by: Gunther Schadow
+ (gusw@fub46.zedat.fu-berlin.de)
+
+ Sources involved: <tt>isa/gsc.c</tt> <tt>isa/gscreg.h</tt>
+
+ <tag>CORTEX-I Frame Grabber</tag> Owner: core
+
+ Submitted by: Paul S. LaFollette, Jr. (
+
+ Sources involved: <tt>isa/ctx.c</tt> <tt>isa/ctxreg.h</tt>
+
+
+ <tag>Video Spigot video capture card</tag> Owner: Jim
+ Lowe
+
+ </descrip>
+
+ <sect1><heading>Experimental features</heading>
+
+ <p><descrip>
+
+ <tag>UNIONFS and LFS</tag> 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.
+
+ <tag>iBCS2 Support</tag> 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: <tt>sys/i386/ibcs2/*</tt> and misc
+ kernel changes.
+
+ </descrip>
+<!--
+ <sect1><heading>Reporting problems, making suggestions, submitting code</heading>
+
+ <p>Your suggestions, bug reports and contributions of code
+ are always valued - please do not hesitate to report any
+ problems you may find (preferably with a fix attached if
+ you can!).
+
+ The preferred method to submit bug reports from a machine
+ with internet mail connectivity is to use the send-pr
+ command. Bug reports will be dutifully filed by our
+ faithful bugfiler program and you can be sure that we'll
+ do our best to respond to all reported bugs as soon as
+ possible.
+
+ If, for some reason, you are unable to use the send-pr
+ command to submit a bug report, you can try to send it
+ to: <tscreen>bugs@FreeBSD.org</tscreen> Otherwise, for
+ any questions or suggestions, please send mail to:
+ <tscreen>questions@FreeBSD.org</tscreen>
+
+ Additionally, being a volunteer effort, we are always
+ happy to have extra hands willing to help - there are
+ already far more enhancements to be done than we can ever
+ manage to do by ourselves! To contact us on technical
+ matters, or with offers of help, you may send mail to:
+ <tscreen>hackers@FreeBSD.org</tscreen>
+
+ Since these mailing lists can experience significant
+ amounts of traffic, if you have slow or expensive mail
+ access and you are only interested in keeping up with
+ significant FreeBSD events, you may find it preferable to
+ subscribe to: <tscreen>announce@FreeBSD.org</tscreen>
+
+ All but the freebsd-bugs groups can be freely joined by
+ anyone wishing to do so. Send mail to
+ MajorDomo@FreeBSD.org and include the keyword `help' on a
+ line by itself somewhere in the body of the message.
+ This will give you more information on joining the
+ various lists, accessing archives, etc. There are a
+ number of mailing lists targeted at special interest
+ groups not mentioned here, so send mail to majordomo and
+ ask about them!
+
+-->
diff --git a/handbook/sections.sgml b/handbook/sections.sgml
new file mode 100644
index 0000000000..a5f50d4078
--- /dev/null
+++ b/handbook/sections.sgml
@@ -0,0 +1,38 @@
+<!-- $Id: sections.sgml,v 1.1 1995-09-03 21:12:29 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<!-- Entities containing all the pieces of the handbook are -->
+<!-- defined here -->
+
+<!ENTITY bibliography SYSTEM "bibliography.sgml">
+<!ENTITY basics SYSTEM "basics.sgml">
+<!ENTITY booting SYSTEM "booting.sgml">
+<!ENTITY contrib SYSTEM "contrib.sgml">
+<!ENTITY ctm SYSTEM "ctm.sgml">
+<!ENTITY current SYSTEM "current.sgml">
+<!ENTITY dialup SYSTEM "dialup.sgml">
+<!ENTITY diskless SYSTEM "diskless.sgml">
+<!ENTITY eresources SYSTEM "eresources.sgml">
+<!ENTITY glossary SYSTEM "glossary.sgml">
+<!ENTITY history SYSTEM "history.sgml">
+<!ENTITY hw SYSTEM "hw.sgml">
+<!ENTITY install SYSTEM "install.sgml">
+<!ENTITY kerberos SYSTEM "kerberos.sgml">
+<!ENTITY kernelconfig SYSTEM "kernelconfig.sgml">
+<!ENTITY kerneldebug SYSTEM "kerneldebug.sgml">
+<!ENTITY memoryuse SYSTEM "memoryuse.sgml">
+<!ENTITY mirrors SYSTEM "mirrors.sgml">
+<!ENTITY nfs SYSTEM "nfs.sgml">
+<!ENTITY nutshell SYSTEM "nutshell.sgml">
+<!ENTITY porting SYSTEM "porting.sgml">
+<!ENTITY ports SYSTEM "ports.sgml">
+<!ENTITY ppp SYSTEM "ppp.sgml">
+<!ENTITY relnotes SYSTEM "relnotes.sgml">
+<!ENTITY scsi SYSTEM "scsi.sgml">
+<!ENTITY slipc SYSTEM "slipc.sgml">
+<!ENTITY slips SYSTEM "slips.sgml">
+<!ENTITY submitters SYSTEM "submitters.sgml">
+<!ENTITY sup SYSTEM "sup.sgml">
+<!ENTITY troubleshooting SYSTEM "troubleshooting.sgml">
+<!ENTITY userppp SYSTEM "userppp.sgml">
+
diff --git a/handbook/userppp.sgml b/handbook/userppp.sgml
new file mode 100644
index 0000000000..9265825b71
--- /dev/null
+++ b/handbook/userppp.sgml
@@ -0,0 +1,360 @@
+<!-- $Id: userppp.sgml,v 1.3 1995-08-29 01:42:52 jfieber Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+
+<sect>Setting up user PPP<label id="userppp">
+
+<p><em>Contributed by &a.nik;<newline>
+28 July 1995</em>.
+
+<!-- This FAQ/HowTo is intended to get you up and running with
+ iijppp, also known as the <em>user level ppp</em> for FreeBSD 2.0.5
+ (and above).
+
+ I hope this document turns into a collaborative effort, largely
+ because I am not really much of an authority on PPP. I've got
+ it working, and want to pass on details of what I did so that
+ other people can get it working. But I'm not 100% clear on some
+ details, so I hope that by writing this and haveing others
+ flesh out some of the information I'm going to learn something
+ as well.
+-->
+
+ <p>User PPP was intruduced to FreeBSD in release 2.0.5 as an
+ addition to the exisiting kernel implementation of PPP. So,
+ what is different about this new PPP that warrants its
+ addition? To quote from the manual page:
+
+<quote>
+ This is a user process PPP software package. Normally, PPP is
+ implemented as a part of the kernel (e.g. as managed by pppd) and
+ it's thus somewhat hard to debug and/or modify its behavior. However,
+ in this implementation PPP is done as a user process with the help of
+ the tunnel device driver (tun).
+</quote>
+
+ In essence, this means that rather than running a PPP daemon, the ppp
+ program can be run as and when desired. No PPP interface needs to be
+ compiled into the kernel, as the program can use the generic tunnel
+ device to to get data into and out of the kernel.
+
+ From here on out, user ppp will be referred to as simply as ppp unless a
+ distinction need to be made be it and any other PPP client/server software.
+ Unless otherwise stated, all commands in this section should be
+ executed as root.
+
+ Parts in this section marked with an asterisk (*) are
+ incomplete. Comments and suggestions are appreciated and
+ should be submitted to &a.nik;.
+ Thanks to Rob Snow &lt;rsnow@txdirect.net&gt; who proved to be a mine of
+ useful information when I was first experimenting with user ppp.
+
+<sect1><heading>Before you start</heading>
+
+<p>This document assumes you're in roughly this position:
+
+ You have an account with an Internet Service Provider (ISP) which lets you
+ use PPP. Further, you have a modem (or other device) connected and
+ configured correctly which allows you to connect to your ISP.
+
+ You are going to need the following information to hand:
+
+<itemize>
+ <item>IP address of your ISP's gateway
+
+ <item>Your ISP's netmask setting
+
+ <item>IP adresses of one or more nameservers
+
+ <item>If your ISP allocates you a static IP address and/or hostname then
+ you will need that as well. If not, you will need to know from what
+ range of IP addresses your allocated IP address will fall in.
+</itemize>
+
+ If you do not have any of this information then contact your ISP and make
+ sure they provide it to you.
+
+ As well as this, you may need the files required to recompile
+ your kernel. Check <ref id="kernelconfig" name="Kernel
+ Configuration"> for more information on how to acquire these.
+
+ In addition, I've assumed that because your connection to the Internet is
+ not full time you are not running a name server (<tt>named(8)</tt>).
+
+<sect1><heading>Building a ppp ready kernel</heading>
+
+<p>As the description states, ``ppp'' uses the kernel ``tun'' device. It is
+ necessary to make sure that your kernel has support for this device compiled
+ in.
+
+ To check this, go to your kernel compile directory (probably /sys/i386/conf)
+ and examine your kernel configuration file. It needs to have the line
+<tscreen><verb>
+pseudo-device tun 1
+</verb></tscreen>
+ in it somewhere. The stock GENERIC kernel has this as standard, so if you
+ have not installed a custom kernel you don't have to change anything.
+ If your kernel configuration file does not have this line in it then you
+ should add the line, re-compile and then re-install the kernel. Boot from
+ this new kernel.
+
+<sect1><heading>Check the tun device</heading>
+
+<p>My experiences with ppp have only been with one ``tun'' device (tun0). If
+ you have used more (i.e., a number other than `1' in the pseudo-device line
+ in the kernel configuration file) then alter all references to ``tun0''
+ below to reflect whichever device number you are using.
+
+ The easiest way to make sure that the tun0 device is configured correctly is
+ to re-make it. To this end, execute the following commands,
+<tscreen><verb>
+# cd /dev
+# ./MAKEDEV tun0
+</verb></tscreen>
+
+<sect1><heading>PPP Configuration</heading>
+
+<p>The meat of the problem.
+
+ Confusingly, it appears that both user ppp and pppd (the kernel level
+ implementation of PPP) both assume configuration files kept in
+ /etc/ppp. However, the sample configuration files provided are good for
+ user ppp, so keep them around for reference. The easiest way to do this is,
+<tscreen><verb>
+# cd /etc
+# mv ppp ppp.orig
+# mkdir ppp
+</verb></tscreen>
+ Configuring ppp requires that you edit somewhere between one and three
+ files, depending on your requirements. What you put in them depends to some
+ extent on whether your ISP allocates IP addresses statically (i.e., you get
+ given one IP address, and always use that one) or dynamically (i.e., your IP
+ address can be different during different PPP sessions).
+
+ However, there are a few things that you should do first, regardless of
+ whether you are using static or dynamic IP addresses.
+
+
+<sect2><heading>Configure the resolver(5)</heading>
+
+<p>The resolver is the part of the networking system that turns IP addresses
+ into hostnames. It can be configured to look for maps that describe IP to
+ hostname mappings in one of two places.
+
+ The first is a file called /etc/hosts (``hosts'' in section 5 of the
+ manual). The second is the Internet Domain Name Service, a distributed
+ data base, the discussion of which is beyond the realm of this document.
+
+ The resolver is a set of system calls that do the mappings,
+ and you have to tell them where to get their information
+ from. You do this by editing the file /etc/host.conf. Do
+ <bf>not</bf> call this file /etc/hosts.conf (note the extra
+ ``s'') as the results can be confusing.
+
+ This file should contain the following two lines,
+<tscreen><verb>
+hosts
+bind
+</verb></tscreen>
+ which instruct the resolver to look in the file /etc/hosts first, and
+ then to consult the DNS if the name was not found in the /etc/hosts file.
+
+ It's probably a good idea to make sure you are not running the ``named''
+ service. Check your /etc/sysconfig file for the line that refers to
+ ``namedflags'', and make sure the line reads
+<tscreen><verb>
+namedflags="NO"
+</verb></tscreen>
+
+<sect2><heading>Create the /etc/hosts(5) file</heading>
+
+<p>This file should contain the IP addresses and names of machines on your
+ network. At a bare minimum it should contain entries for the machine
+ which will be running ppp. Assuming that you're machine is called
+ foo.bar.com with the IP address 10.0.0.1, /etc/hosts should contain
+<tscreen><verb>
+127.0.0.0 localhost
+10.0.0.1 foo.bar.com foo
+</verb></tscreen>
+ The first line defines the alias ``localhost'' as a synonym for the
+ current machine. Regardless of your own IP address, the IP address for
+ this line should always be 127.0.0.1. The second line maps the name
+ ``foo.bar.com'' (and the shorthand ``foo'') to the IP address 10.0.0.1.
+
+ If your provider allocates you a static IP address then use this in place
+ of 10.0.0.1.
+
+ <!-- XXX <em>(* What should they do if they are
+ allocated an IP address dynamically?)</em> -->
+
+<sect2><heading>Create the /etc/resolv.conf file</heading>
+
+<p>/etc/resolv.conf contains some extra information required when you are
+ not running a nameserver. It points the resolver routines at real
+ nameservers, and specifies some other information.
+
+ At the very least, /etc/resolv.conf should contain one line with a
+ nameserver which can be queried. You should enter this as an IP
+ address. My /etc/resolv.conf contains
+<tscreen><verb>
+nameserver 158.152.1.193
+nameserver 158.152.1.65
+</verb></tscreen>
+ Which are Demon Internet's two nameservers. Add as many ``nameserver''
+ lines as your ISP provides nameservers.
+
+<sect1><heading>PPP and static IP addresses</heading>
+
+<p>Probably the easiest to configure for. You will need to create three files
+ in the /etc/ppp directory.
+
+ The first of these is ppp.conf. It should look similar to the example
+ below. Note that lines that end in a ``:'' start in column 1, all other
+ lines should be indented as shown.
+
+ /etc/ppp/ppp.conf
+<tscreen><verb>
+1 default:
+2 set device /dev/cuaa0
+3 set speed 9600
+4 disable lqr
+5 deny lqr
+6 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK
+\\dATDT\\T TIMEOUT 40 CONNECT"
+7 provider:
+8 set phone 01234567890
+9 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp"
+10 set timeout 120
+11 set ifaddr x.x.x.x y.y.y.y
+</verb></tscreen>
+ Don't include the line numbers, they're just for this discussion.
+
+<descrip>
+<tag/Line 1:/ Identifies the default entry. Commands in this entry are
+ executed automatically when ppp is run.
+
+<tag/Line 2:/ Identifies the device that has the modem hanging from it.
+ COM1: is /dev/cuaa0 and COM2: is /dev/cuaa1
+
+<tag/Line 3:/ Sets the speed you want to connect at.
+
+<tag/* Lines 4 and 5:/ Don't know exactly what effect these lines have
+
+<tag/Line 6:/ Dial string commands. user ppp uses the chat(8) language. Check
+ the manual page for information on the features of this
+ language.
+
+<tag/Line 7:/ Identifies an entry for a provider called ``provider''.
+
+<tag/Line 8:/ Sets the phone number for this provider. Don't include any
+ spaces in the phone number.
+
+<tag/Line 9:/ Set's the login string sequence. In this example, the string is
+ for a service who's login session looks like
+<tscreen><verb>
+J. Random Provider
+login: foo
+password: bar
+protocol: ppp
+</verb></tscreen>
+ You will need to alter this script to suit your own needs. It is
+ written in the chat(8) language.
+
+<tag/Line 10:/ Sets the default timeout (in seconds) for the connection. So
+ the connectioned will be closed automatically after 120 seconds
+ of inactivity.
+
+<tag/Line 11:/ Sets the interface addresses. The string x.x.x.x should be
+ replaced by the IP address that your provider allocates you. The
+ string y.y.y.y should be replaced by the IP address that your
+ ISP indicated for their gateway.
+</descrip>
+
+ Now you have to edit the file /etc/ppp/ppp.linkup:
+<tscreen><verb>
+x.x.x.x:
+ add 0 0 HISADDR
+</verb></tscreen>
+ Replace x.x.x.x with your IP address as before. This file is used to
+ automatically add a default route from your ISP (who's address is
+ automatically inserted with the HISADDR macro) to you.
+
+ Finally, you can create the file /etc/ppp/ppp.secret, which sets some
+ passwords to prevent people messing around with ppp on your system. You
+ may or may not want to do this, depending on how many people have access
+ to your ppp system.
+
+<sect1><heading>PPP and Dynamic IP configuration</heading>
+
+<!-- XXX -->
+ <p>If you service provider does not assign static IP numbers,
+ <tt>ppp</tt> can be configured to negotiate the local address. This is
+ done by specifying 0 as the local IP address:
+<tscreen><verb>
+set ifaddr 0 0
+</verb></tscreen>
+ See the <tt>ppp(8)</tt> manual page for more detailed information.
+
+<sect1><heading>Final system configuration</heading>
+
+<p>You now have PPP configured, but there's a few more things to do before
+ it's ready to work. They all involve editing the /etc/sysconfig file.
+
+ Working from the top down in this file, make sure the ``hostname='' line
+ is set, e.g.,
+<tscreen><verb>
+hostname=foo.bar.com
+</verb></tscreen>
+ Look for the network_interfaces variable, and make sure the tun0 device is
+ added to the list. My line looks like
+<tscreen><verb>
+network_interfaces="lo0 tun0 ep0"
+</verb></tscreen>
+ but I have an ethernet card (ep0) to configure as well.
+
+ Now add an ifconfig line for the tun0 device. It should look something
+ like
+<tscreen><verb>
+ifconfig_tun0="inet foo.bar.com y.y.y.y netmask 0xffffffff"
+</verb></tscreen>
+ as before, change ``foo.bar.com'' to be your hostname, y.y.y.y is the IP
+ address of your providers gateway, and 0xffffffff is the netmask they
+ provided you with (in hexadecimal). Two common values for the netmask are
+<tscreen><verb>
+255.255.255.255 = 0xffffffff
+255.255.255.0 = 0xffffff00
+</verb></tscreen>
+ Set the routed flags to ``-s'' with the line
+<tscreen><verb>
+routedflags=-s
+</verb></tscreen>
+ It's probably worth your while ensuring that the ``sendmail_flags'' line
+ does not include the ``-q'' option, otherwise sendmail will attempt to do
+ a network lookup every now and then, possibly causing your machine to dial
+ out. My sendmail line looks like
+<tscreen><verb>
+sendmail_flags="-bd"
+</verb></tscreen>
+ The upshot of this is that I must force sendmail to re-examine the
+ mailqueue whenever I have the PPP link up, by typing
+<tscreen><verb>
+# /usr/sbin/sendmail -q
+</verb></tscreen>
+ That should be about all you need to do to get PPP working with a static
+ IP address. All that's left is to reboot the machine. During startup the
+ tun0 device should be detected, and two lines like the following should be
+ printed,
+<tscreen><verb>
+tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 1500
+inet x.x.x.x --> y.y.y.y netmask 0xffffffff
+</verb></tscreen>
+ At this point, it should all be working. You can now either type
+<tscreen><verb>
+# ppp
+</verb></tscreen>
+ and then ``dial provider'' to start the PPP session, or, if you want ppp
+ to establish sessions automatically when there is outbound traffic, type
+<tscreen><verb>
+# ppp -auto provider
+</verb></tscreen>
+ This line could be added to your /etc/rc.local file.
+