aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDoc Manager <doceng@FreeBSD.org>1995-07-09 21:39:57 +0000
committerDoc Manager <doceng@FreeBSD.org>1995-07-09 21:39:57 +0000
commit608ba9dae8e83311d5d74398d40a9efe78e8a741 (patch)
tree4e9eadc9c3face478f56eca9a7b971b6e66fb496
parent35c9804bc5eb61cadc1ad96df02de589009a3e2c (diff)
downloaddoc-release/2.0.5.tar.gz
doc-release/2.0.5.zip
Create tag '2.0.5'.release/2.0.5
-rw-r--r--handbook/contrib.sgml266
-rw-r--r--handbook/hw.sgml70
-rw-r--r--handbook/install.sgml641
-rw-r--r--handbook/kerneldebug.sgml423
-rw-r--r--handbook/relnotes.sgml503
5 files changed, 0 insertions, 1903 deletions
diff --git a/handbook/contrib.sgml b/handbook/contrib.sgml
deleted file mode 100644
index 769078f710..0000000000
--- a/handbook/contrib.sgml
+++ /dev/null
@@ -1,266 +0,0 @@
-<!-- $Id: contrib.sgml,v 1.1 1995-07-09 21:39:55 jfieber Exp $ -->
-<!-- The FreeBSD Documentation Project -->
-
-<chapt>FreeBSD contributor list<label id="contrib">
-
- <sect>Derived software contributors
-
- <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>Hardware contributors
-
- <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>The FreeBSD core team<label id="contrib:core">
-
- <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>Paul Richards &lt;paul@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>Who is responsible for what
-
- <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>Additional FreeBSD contributors
-
- <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>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>Atsushi Murai &lt;amurai@spec.co.jp&gt;
- <item>Bill Paul &lt;wpaul@FreeBSD.org&gt;
- <item>Bob Wilcox &lt;bob@obiwan.uucp&gt;
- <item>Charles Hannum &lt;mycroft@ai.mit.edu&gt;
- <item>Chris G. Demetriou &lt;cgd@postgres.berkeley.edu&gt;
- <item>Christian Gusenbauer &lt;cg@fimp01.fim.uni-linz.ac.at&gt;
- <item>Chris Torek &lt;torek@ee.lbl.gov&gt;
- <item>Christoph Robitschko &lt;chmr@edvz.tu-graz.ac.at&gt;
- <item>Curt Mayer &lt;curt@toad.com&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>Dean Huxley &lt;dean@fsa.ca&gt;
- <item>Frank Durda IV &lt;bsdmail@nemesis.lonestar.org&gt;
- <item>Frank Maclachlan &lt;fpm@crash.cts.com&gt;
- <item>Gary A. Browning &lt;gab10@griffcd.amdahl.com&gt;
- <item>Gary Clark II &lt;gclarkii@radon.gbdata.com&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>Jim Wilson &lt;wilson@moria.cygnus.com&gt;
- <item>J&ouml;rg Wunsch &lt;joerg_wunsch@uriah.heep.sax.de&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>L Jonas Olsson &lt;ljo@po.cwru.edu&gt;
- <item>Lars Fredriksen &lt;fredriks@mcs.com&gt;
- <item>Marc Frajola &lt;marc@escargot.rain.com&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>Nate Williams &lt;nate@FreeBSD.org&gt;
- <item>Nobuhiro Yasutomi &lt;nobu@@psrc.isac.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 Traina &lt;pst@cisco.com&gt;
- <item>Peter Dufault &lt;dufault@hda.com&gt;
- <item>Chris Provenzano &lt;proven@athena.mit.edu&gt;
- <item>Rob Shady &lt;rls@id.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>Torsten Blum &lt;torstenb@FreeBSD.ORG&gt;
- <item>Ugen J.S.Antsilevich &lt;ugen@NetVision.net.il&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>386BSD Patch kit patch contributors
-
- <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@escargot.rain.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
deleted file mode 100644
index 64bfcc5e25..0000000000
--- a/handbook/hw.sgml
+++ /dev/null
@@ -1,70 +0,0 @@
-<!-- $Id: hw.sgml,v 1.2 1995-06-20 16:29:54 jfieber Exp $ -->
-<!-- The FreeBSD Documentation Project -->
-
-<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</heading>
- <sect2><heading>* ISA</heading>
- <sect2><heading>* EISA</heading>
- <sect2><heading>* VLB</heading>
- <sect2><heading>* PCI</heading>
-<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 (including multiport cards)</heading>
-<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
deleted file mode 100644
index 1cce366195..0000000000
--- a/handbook/install.sgml
+++ /dev/null
@@ -1,641 +0,0 @@
-<!-- $Id: install.sgml,v 1.3 1995-07-06 14:24:59 jfieber Exp $ -->
-<!-- The FreeBSD Documentation Project -->
-
-<!--
-<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
--->
-<chapt><heading>Installing FreeBSD<label id="install"></heading>
-
- <sect>MS-DOS user's Questions and Answers
-
- <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>Supported Configurations
-
- <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.
-
- 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>Disk Controllers
-
- <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 (Narrow/Wide/Twin)
- series ISA/EISA/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>Ethernet cards
-
- <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>Misc
-
- <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>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>Before installing from CDROM
-
- <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>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>Before installing from a MS-DOS partition</heading>
-
- <p>To prepare for installation from an MS-DOS partition,
- you should simply copy the files from the distribution
- into a directory called <tt>FREEBSD</tt>. For example, to do
- a minimal installation of FreeBSD from DOS using files
- copied from the CDROM, you might do something like
- this:
-<tscreen><verb>
-C> MD C:\FREEBSD
-C> XCOPY /S E:\DISTS\BIN C:\FREEBSD
-C> XCOPY /S E:\FLOPPIES C:\FREEBSD
-</verb></tscreen>
-
- Asssuming that <tt>C:</tt> was where you had free space and
- <tt>E:</tt> was where your CD was mounted. Note that you need
- the <tt>FLOPPIES</tt> directory because the <tt>root.flp</tt> image is
- automatically looked for there when you are doing a
- 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 BIN dist is only the minimal
- requirement.
-
-
- <sect1>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>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>Preparing for NFS installation
-
- <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>Preparing for FTP Installation
-
- <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>Installing FreeBSD
-
- <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>The installation menu
-
- <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
deleted file mode 100644
index a0d5f20394..0000000000
--- a/handbook/kerneldebug.sgml
+++ /dev/null
@@ -1,423 +0,0 @@
-<!-- $Id: kerneldebug.sgml,v 1.2 1995-06-30 17:37:41 jfieber Exp $ -->
-<!-- The FreeBSD Documentation Project -->
-
-<!--
-<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
-<!ENTITY % authors SYSTEM "authors.sgml">
-%authors;
-]>
--->
-
-<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 happen to have multiple swap
- partitions with the first one being too small to keep the dump,
- you can configure your kernel to use an alternate dump device
- (in the <tt>kernel</tt> line). Dumps to non-swap devices,
- tapes for example, are currently not supported. Config your
- kernel using <tt>config -g</tt>.
-<!-- XXX obsolete?
-Remember that you need to
- specify
-<tscreen><verb>
-options DODUMP
-</verb></tscreen>
- in your config file in order to get kernel core dumps.
--->
- See <ref id="kernelconfig" name="Kernel Configuration"> for
- details on configuring the FreeBSD kernel.
-
- <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 might drastically increase.
-
- 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!
-
-<!-- XXX obsolete?
- Of course, you still need to configure all your kernels with the
- DODUMP option being set, otherwise you won't get a core dump at all.
- (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. Patches for a
- COMCONSOLE kernel, are available from &a.joerg;.
-
- 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/relnotes.sgml b/handbook/relnotes.sgml
deleted file mode 100644
index ff74fbe4e8..0000000000
--- a/handbook/relnotes.sgml
+++ /dev/null
@@ -1,503 +0,0 @@
-<!-- $Id: relnotes.sgml,v 1.3 1995-06-30 17:37:47 jfieber Exp $ -->
-<!-- The FreeBSD Documentation Project -->
-
-<!--
-<!DOCTYPE linuxdoc PUBLIC '-//FreeBSD//DTD linuxdoc//EN'>
-<linuxdoc><book><chapt>foo
--->
- <sect>About this release<label id="relnotes">
-
- <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>New feature highlights
-
- <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>Kernel
-
- <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>New device support
-
- <sect3>SCSI and CDROM devices
-
- <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>Serial devices
-
- <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>Networking
-
- <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>Miscellaneous drivers
-
- <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>Experimental features
-
- <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>Reporting problems, making suggestions, submitting code
-
- <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!
-
--->