diff --git a/en_US.ISO8859-1/articles/contributing/article.sgml b/en_US.ISO8859-1/articles/contributing/article.sgml index da26d06487..41322bc613 100644 --- a/en_US.ISO8859-1/articles/contributing/article.sgml +++ b/en_US.ISO8859-1/articles/contributing/article.sgml @@ -1,6011 +1,6011 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and - subservices to allow the use of ODI card drivers supplied with + sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting - internal vs. external display and picking a different screen + internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks Most of the tasks listed in the previous sections require either a considerable investment of time or an in-depth knowledge of the FreeBSD kernel (or both). However, there are also many useful tasks which are suitable for "weekend hackers", or people without programming skills. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. - If you know of any bugfixes which have been successfully + If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as FreeBSD-current which is made available in a variety of ways for the convenience of developers working actively on the system. See Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the rare case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it - becomes almost always necessary to either send changes as uuencode'd + becomes almost always necessary to either send changes as uuencoded tar files or upload them to our ftp site ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. <anchor id="donations">Donating funds While the FreeBSD Project is not a 501(c)(3) (charitable) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the Walnut Creek CDROM address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would - like to publically thank them here! + like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD - CD-ROMs). + CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: 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. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: Walnut Creek CDROM has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting - &a.joerg; who has often preferred FreeBSD work over paywork, and + &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or - flakey to work with it... + flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni The following people were members of the FreeBSD core team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Derived Software Contributors This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-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 and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com - Adrian Chadd adrian@freebsd.org + Adrian Chadd adrian@FreeBSD.org Adrian Colley aecolley@ois.ie Adrian Hall adrian@ibmpcug.co.uk Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex garbanzo@hooked.net Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex G. Bulushev bag@demos.su Alex Le Heux alexlh@funk.org Alex Perel veers@disturbed.net Alex Varju varju@webct.com Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Assar Westerlund assar@sics.se Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Smithurst ben@scientia.demon.co.uk Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Benno Rice benno@netizen.com.au Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce A. Mah bmah@ca.sandia.gov Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Choi Jun Ho junker@jazz.snu.ac.kr Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Clive Lin clive@CiRX.ORG Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@neosoft.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Harris dannyboy@dannyboy.eyep.net Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@umiacs.umd.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Malone dwmalone@maths.tcd.ie David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dima Sivachenko dima@Chg.RU Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Dominik Brettnacher domi@saargate.de Dominik Rother dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Doug Barton Doug@gorean.org Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Duncan Barclay dmlb@ragnet.demon.co.uk Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@lab321.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp G. Adam Stanislavadam@whizkidtech.net Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Garance A Drosehn gad@eclipse.its.rpi.edu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Dowse iedowse@maths.tcd.ie Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Issei Suzuki issei@jp.FreeBSD.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com J.T. Jang keith@email.gcn.net.tw Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer jeff@isni.net Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart unknown Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jua@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp Kazuo Horikawa horikawa@jp.FreeBSD.org Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Kelly Yancey kbyanc@posi.net Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Lokevlo@hello.com.tw Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mario Sergio Fujikawa Ferreira lioux@gns.com.br Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Ovens mark@dogma.freebsd-uk.eu.org Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Markus Holmberg saska@acc.umu.se Martin Birgmeier Martin Blapp blapp@attic.ch Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Mas.TAKEMURA unknown Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Micha Class michael_class@hpbbse.bbn.hp.com Michael Lucas mwlucas@blackhelicopters.org Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar MIHIRA Sanpei Yoshiro sanpei@sanpei.org Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@shiva.the-park.com Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.ziplink.net Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW MITA Yoshio mita@jp.FreeBSD.org MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Hausen unknown Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Rajesh Vaidheeswarran rv@fore.com Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@drmemory.fnal.gov Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge A. Babkin babkin@hq.icb.chel.su Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Shunsuke Akiyama akiyama@jp.FreeBSD.org Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko ARAI toshi@tenchi.ne.jp Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com Trevor Johnson trevor@jpj.net Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko OHTA yohta@bres.tsukuba.ac.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall adrian@ibmpcug.co.uk Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rod Taylor rod@idiotswitch.org Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index 2268cea7d6..0070cb3e44 100644 --- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,1813 +1,1813 @@ Advanced Networking Synopsis The following chapter will cover some of the more frequently used network services on UNIX systems. This, of course, will pertain to configuring said services on your FreeBSD system. Gateways and Routes Contributed by &a.gryphon;. 6 October 1995. For one machine to be able to find another, there must be a mechanism in place to describe how to get from one to the other. This is called Routing. A route is a defined pair of addresses: a destination and a gateway. The pair indicates that if you are trying to get to this destination, send along through this gateway. There are three types of destinations: individual hosts, subnets, and default. The default route is used if none of the other routes apply. We will talk a little bit more about default routes later on. There are also three types of gateways: individual hosts, interfaces (also called links), and ethernet hardware addresses. An example To illustrate different aspects of routing, we will use the following example which is the output of the command netstat -r: Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 The first two lines specify the default route (which we will cover in the next section) and the localhost route. The interface (Netif column) that it specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it out over the LAN, since it will only end up back where it started anyway. The next thing that stands out are the 0:e0:... addresses. These are ethernet hardware addresses. FreeBSD will automatically identify any hosts (test0 in the example) on the local ethernet and add a route for that host, directly to it over the ethernet interface, ed0. There is also a timeout (Expire column) associated with this type of route, which is used if we fail to hear from the host in a specific amount of time. In this case the route will be automatically deleted. These hosts are identified using a mechanism known as RIP (Routing Information Protocol), which figures out routes to local hosts based upon a shortest path determination. FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the subnet 10.20.30, and foobar.com is the domain name associated with that subnet). The designation link#1 refers to the first ethernet card in the machine. You will notice no additional interface is specified for those. Both of these groups (local network hosts and local subnets) have their routes automatically configured by a daemon called routed. If this is not run, then only routes which are statically defined (ie. entered explicitly) will exist. The host1 line refers to our host, which it knows by ethernet address. Since we are the sending host, FreeBSD knows to use the loopback interface (lo0) rather than sending it out over the ethernet interface. The two host2 lines are an example of what happens when we use an ifconfig alias (see the section of ethernet for reasons why we would do this). The => symbol after the lo0 interface says that not only are we using the loopback (since this is address also refers to the local host), but specifically it is an alias. Such routes only show up on the host that supports the alias; all other hosts on the local network will simply have a link#1 line for such. The final line (destination subnet 224) deals with MultiCasting, which will be covered in a another section. The other column that we should talk about are the Flags. Each route has different attributes that are described in the column. Below is a short table of some of these flags and their meanings: U Up: The route is active. H Host: The route destination is a single host. G Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. S Static: This route was configured manually, not automatically generated by the system. C Clone: Generates a new route based upon this route for machines we connect to. This type of route is normally used for local networks. W WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. L Link: Route involves references to ethernet hardware. Default routes When the local system needs to make a connection to remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet that we know how to reach (Cloned routes), then the system checks to see if it can connect along that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this gateway is set to whatever machine has a direct connection to the outside world (whether via PPP link, or your hardware device attached to a dedicated data line). If you are configuring the default route for a machine which itself is functioning as the gateway to the outside world, then the default route will be the gateway machine at your Internet Service Provider's (ISP) site. Let us look at an example of default routes. This is a common configuration: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] The hosts Local1 and Local2 are at your site, with the formed being your PPP connection to your ISP's Terminal Server. Your ISP has a local network at their site, which has, among other things, the server where you connect and a hardware device (T1-GW) attached to the ISP's Internet feed. The default routes for each of your machines will be: host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP A common question is Why (or how) would we set the T1-GW to be the default gateway for Local1, rather than the ISP server it is connected to?. Remember, since the PPP interface is using an address on the ISP's local network for your side of the connection, routes for any other machines on the ISP's local network will be automatically generated. Hence, you will already know how to reach the T1-GW machine, so there is no need for the intermediate step of sending traffic to the ISP server. As a final note, it is common to use the address ...1 as the gateway address for your local network. So (using the same example), if your local class-C address space was 10.20.30 and your ISP was using 10.9.9 then the default routes would be: Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) Dual homed hosts There is one other type of configuration that we should cover, and that is a host that sits on two different networks. Technically, any machine functioning as a gateway (in the example above, using a PPP connection) counts as a dual-homed host. But the term is really only used to refer to a machine that sits on two local-area networks. In one case, the machine as two ethernet cards, each having an address on the separate subnets. Alternately, the machine may only have one ethernet card, and be using ifconfig aliasing. The former is used if two physically separate ethernet networks are in use, the latter if there is one physical network segment, but two logically separate subnets. Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine acting as a Bridge between the two subnets, is often used when we need to implement packet filtering or firewall security in either or both directions. Routing propagation We have already talked about how we define our routes to the outside world, but not about how the outside world finds us. We already know that routing tables can be set up so that all traffic for a particular address space (in our examples, a class-C subnet) can be sent to a particular host on that network, which will forward the packets inbound. When you get an address space assigned to your site, your service provider will set up their routing tables so that all traffic for your subnet will be sent down your PPP link to your site. But how do sites across the country know to send to your ISP? There is a system (much like the distributed DNS information) that keeps track of all assigned address-spaces, and defines their point of connection to the Internet Backbone. The Backbone are the main trunk lines that carry Internet traffic across the country, and around the world. Each backbone machine has a copy of a master set of tables, which direct traffic for a particular network to a specific backbone carrier, and from there down the chain of service providers until it reaches your network. It is the task of your service provider to advertise to the backbone sites that they are the point of connection (and thus the path inward) for your site. This is known as route propagation. Troubleshooting Sometimes, there is a problem with routing propagation, and some sites are unable to connect to you. Perhaps the most useful command for trying to figure out where a routing is breaking down is the &man.traceroute.8; command. It is equally useful if you cannot seem to make a connection to a remote machine (i.e. &man.ping.8; fails). The &man.traceroute.8; command is run with the name of the remote host you are trying to connect to. It will show the gateway hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. For more information, see the manual page for &man.traceroute.8;. NFS Written by &a.unfurl;, 4 March 2000. Among the many different file systems that FreeBSD supports is a very unique type, the Network File System or NFS. NFS allows you to share directories and files on one machine with one or more other machines via the network they are attached to. Using NFS, users and programs can access files on remote systems as if they were local files. NFS has several benefits: Local workstations dont need as much disk space because commonly used data can be stored on a single machine and still remain accessible to everyone on the network. There is no need for users to have unique home directories on every machine on your network. Once they have an established directory that is available via NFS it can be accessed from anywhere. Storage devices such as floppies and CD-ROM drives can be used by other machines on the network eliminating the need for extra hardware. How It Works NFS is composed of two sides – a client side and a server side. Think of it as a want/have relationship. The client wants the data that the server side has. The server shares its data with the client. In order for this system to function properly a few processes have to be configured and running properly. The server has to be running the following daemons: nfsd - The NFS Daemon which services requests from NFS clients. mountd - The NFS Mount Daemon which actually carries out requests that nfsd passes on to it. The client side only needs to run a single daemon: nfsiod - The NFS async I/O Daemon which services requests from its NFS server. Configuring NFS Luckily for us, on a FreeBSD system this setup is a snap. The processes that need to be running can all be run at boot time with - a few modificationss to your /etc/rc.conf + a few modifications to your /etc/rc.conf file. On the NFS server make sure you have: nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd is automatically run whenever the NFS server is enabled. The and flags to nfsd tell it to serve UDP and TCP clients. The flag tells nfsd to start 4 copies of itself. On the client, make sure you have: nfs_client_enable="YES" nfs_client_flags="-n 4" Like nfsd, the tells nfsiod to start 4 copies of itself. The last configuration step requires that you create a file called /etc/exports. The exports file specifies which file systems on your server will be shared (a.k.a., exported) and with what clients they will be shared. Each line in the file specifies a file system to be shared. There are a handful of options that can be used in this file but I will only touch on a few of them. You can find out about the rest in the &man.exports.5; man page. Here are a few example /etc/exports entries: The following line exports /cdrom to three silly machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in your /etc/hosts file. The flag makes the shared file system read-only. With this flag, the remote system will not be able to make any changes to the the shared file system. /cdrom -ro moe larry curly The following line exports /home to three hosts by IP address. This is a useful setup if you have a private network but do not have DNS running. The flag allows all the directories below the specified file system to be exported as well. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 The following line exports /a to two machines that have different domain names than the server. The flag allows the root user on the remote system to write to the shared file system as root. Without the -maproot=0 flag even if someone has root access on the remote system they won't be able to modify files on the shared file system. /a -maproot=0 host.domain.com box.example.com In order for a client to share an exported file system it must have permission to do so. Make sure your client is listed in your /etc/exports file. Now that you have made all these changes you can just reboot and let FreeBSD start everything for you at boot time or you can run the following commands as root: On the NFS server: &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r On the NFS client: &prompt.root; nfsiod -n 4 Now you should be ready to actually mount a remote file system. This can be done one of two ways. In these examples the server's name will be server and the client's name will be client. If you just want to temporarily mount a remote file system or just want to test out your config you can run a command like this as root on the client: &prompt.root; mount server:/home /mnt This will mount /home on the server on /mnt on the client. If everything is setup correctly you should be able to go into /mnt on the client and see all the files that are on the server. If you want to permanently (each time you reboot) mount a remote file system you need to add it to your /etc/fstab file. Here is an example line: server:/home /mnt nfs rw 0 0 Read the &man.fstab.5; man page for more options. Practical Uses There are many very cool uses for NFS. I use it quite a bit on the LAN I admin. Here are a few ways I have found it to be useful. I have several machines on my network but only one of them has a CD-ROM drive. Why? Because I have that one CD-ROM drive shared with all the others via NFS. The same can be done with floppy drives. With so many machines on the network it gets old having your personal files strewn all over the place. I have a central NFS server that houses all user home directories and shares them with the rest of the machines on the LAN, so no matter where I login I have the same home directory. When you get to reinstalling FreeBSD on one of your machines, NFS is the way to go. Just pop your distribution CD into your file server and away you go. I have a common /usr/ports/distfiles directory that all my machines share. That way when I go to install a port that I already installed on a different machine I do not have to download the source all over again. Problems integrating with other systems Contributed by &a.jlind;. Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it. The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved. Though the correct solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option . These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the parameter of the mount command for manual mounts. It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that your routers are routing the necessary UDP information, or you will not get anywhere, no matter what else you are doing. In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS filesystem (see man exports), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as or and may be desirable in your application. Examples for the FreeBSD system (freebox) as the client: in /etc/fstab on freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 As a manual mount command on freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Examples for the FreeBSD system as the server: in /etc/fstab on fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 As a manual mount command on fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size. For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a block size of 8k (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS block gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8K unit, and the process will be repeated, ad infinitum. By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation. Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS units. When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged. Diskless Operation Contributed by &a.martin;. netboot.com/netboot.rom allow you to boot your FreeBSD machine over the network and run FreeBSD without having a disk on your client. Under 2.0 it is now possible to have local swap. Swapping over NFS is also still supported. Supported Ethernet cards include: Western Digital/SMC 8003, 8013, 8216 and compatibles; NE1000/NE2000 and compatibles (requires recompile) Setup Instructions Find a machine that will be your server. This machine will require enough disk space to hold the FreeBSD 2.0 binaries and have bootp, tftp and NFS services available. Tested machines: HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't work) Sun/Solaris 2.3. (you may need to get bootp) Set up a bootp server to provide the client with IP, gateway, netmask. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: Set up a TFTP server (on same machine as bootp server) to provide booting information to client. The name of this file is cfg.X.X.X.X (or /tftpboot/cfg.X.X.X.X, it will try both) where X.X.X.X is the IP address of the client. The contents of this file can be any valid netboot commands. Under 2.0, netboot has the following commands: help print help list ip print/set client's IP address server print/set bootp/tftp server address netmask print/set netmask hostname name print/set hostname kernel print/set kernel name rootfs print/set root filesystem swapfs print/set swap filesystem swapsize - set diskless swapsize in Kbytes + set diskless swapsize in KBytes diskboot boot from disk autoboot continue boot process trans | turn transceiver on|off flags set boot flags A typical completely diskless cfg file might contain: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain A cfg file for a machine with local swap might contain: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain Ensure that your NFS server has exported the root (and swap if applicable) filesystems to your client, and that the client has root access to these filesystems A typical /etc/exports file on FreeBSD might look like: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain And on HP-UX: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain If you are swapping over NFS (completely diskless configuration) create a swap file for your client using dd. If your swapfs command has the arguments /swapfs and the size 20000 as in the example above, the swapfile for myclient will be called /swapfs/swap.X.X.X.X where X.X.X.X is the client's IP addr, - eg: + e.g.: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 Also, the client's swap space might contain sensitive information once swapping starts, so make sure to restrict read and write access to this file to prevent unauthorized access: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 Unpack the root filesystem in the directory the client will use for its root filesystem (/rootfs/myclient in the example above). On HP-UX systems: The server should be running HP-UX 9.04 or later for HP9000/800 series machines. Prior versions do not allow the creation of device files over NFS. When extracting /dev in /rootfs/myclient, beware that some systems (HPUX) will not create device files that FreeBSD is happy with. You may have to go to single user mode on the first bootup (press control-c during the bootup phase), cd /dev and do a sh ./MAKEDEV all from the client to fix this. Run netboot.com on the client or make an EPROM from the netboot.rom file Using Shared <filename>/</filename> and <filename>/usr</filename> filesystems At present there isn't an officially sanctioned way of doing this, although I have been using a shared /usr filesystem and individual / filesystems for each client. If anyone has any suggestions on how to do this cleanly, please let me and/or the &a.core; know. Compiling netboot for specific setups Netboot can be compiled to support NE1000/2000 cards by changing the configuration in /sys/i386/boot/netboot/Makefile. See the comments at the top of this file. ISDN Last modified by &a.wlloyd;. A good resource for information on ISDN technology and hardware is Dan Kegel's ISDN Page. - A quick simple roadmap to ISDN follows: + A quick simple road map to ISDN follows: If you live in Europe I suggest you investigate the ISDN card section. If you are planning to use ISDN primarily to connect to the - Internet with an Internet Provider on a dialup non-dedicated basis, + Internet with an Internet Provider on a dial-up non-dedicated basis, I suggest you look into Terminal Adapters. This will give you the most flexibility, with the fewest problems, if you change providers. - If you are connecting two lans together, or connecting to the + If you are connecting two LANs together, or connecting to the Internet with a dedicated ISDN connection, I suggest you consider the stand alone router/bridge option. Cost is a significant factor in determining what solution you will choose. The following options are listed from least expensive to most expensive. ISDN Cards Contributed by &a.hm;. This section is really only relevant to ISDN users in countries where the DSS1/Q.931 ISDN standard is supported. Some growing number of PC ISDN cards are supported under FreeBSD 2.2.x and up by the isdn4bsd driver package. It is still under development but the reports show that it is successfully used all over Europe. The latest isdn4bsd version is available from ftp://isdn4bsd@ftp.consol.de/pub/, the main isdn4bsd ftp site (you have to log in as user isdn4bsd , give your mail address as the password and change to the pub directory. Anonymous ftp as user ftp or anonymous will not give the desired result). Isdn4bsd allows you to connect to other ISDN routers using either IP over raw HDLC or by using synchronous PPP. A telephone answering machine application is also available. Many ISDN PC cards are supported, mostly the ones with a Siemens ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola, Cologne Chip Designs) is currently under development. For an up-to-date list of supported cards, please have a look at the README file. In case you are interested in adding support for a different ISDN protocol, a currently unsupported ISDN PC card or otherwise enhancing isdn4bsd, please get in touch with hm@kts.org. A majordomo maintained mailing list is available. To join the list, send mail to &a.majordomo; and specify: subscribe freebsd-isdn in the body of your message. ISDN Terminal Adapters Terminal adapters(TA), are to ISDN what modems are to regular phone lines. Most TA's use the standard hayes modem AT command set, and can be used as a drop in replacement for a modem. A TA will operate basically the same as a modem except connection and throughput speeds will be much faster than your old modem. You will need to configure PPP exactly the same as for a modem setup. Make sure you set your serial speed as high as possible. The main advantage of using a TA to connect to an Internet Provider is that you can do Dynamic PPP. As IP address space becomes more and more scarce, most providers are not willing to provide you - with a static IP anymore. Most standalone routers are not able to + with a static IP anymore. Most stand-alone routers are not able to accommodate dynamic IP allocation. TA's completely rely on the PPP daemon that you are running for their features and stability of connection. This allows you to upgrade easily from using a modem to ISDN on a FreeBSD machine, if you already have PPP setup. However, at the same time any problems you experienced with the PPP program and are going to persist. If you want maximum stability, use the kernel PPP option, not the user-land iijPPP. The following TA's are know to work with FreeBSD. Motorola BitSurfer and Bitsurfer Pro Adtran Most other TA's will probably work as well, TA vendors try to make sure their product can accept most of the standard modem AT command set. The real problem with external TA's is like modems you need a good serial card in your computer. You should read the serial ports section in the handbook for a detailed understanding of serial devices, and the differences between asynchronous and synchronous serial ports. A TA running off a standard PC serial port (asynchronous) limits you to 115.2Kbs, even though you have a 128Kbs connection. To fully utilize the 128Kbs that ISDN is capable of, you must move the TA to a synchronous serial card. Do not be fooled into buying an internal TA and thinking you have avoided the synchronous/asynchronous issue. Internal TA's simply have a standard PC serial port chip built into them. All this will do, is save you having to buy another serial cable, and find another empty electrical socket. - A synchronous card with a TA is at least as fast as a standalone + A synchronous card with a TA is at least as fast as a stand-alone router, and with a simple 386 FreeBSD box driving it, probably more flexible. - The choice of sync/TA vs standalone router is largely a religious + The choice of sync/TA v.s. stand-alone router is largely a religious issue. There has been some discussion of this in the mailing lists. I suggest you search the archives for the complete discussion. - Standalone ISDN Bridges/Routers + Stand-alone ISDN Bridges/Routers ISDN bridges or routers are not at all specific to FreeBSD or any other operating system. For a more complete description of routing and bridging technology, please refer to a Networking reference book. In the context of this page, I will use router and bridge interchangeably. As the cost of low end ISDN routers/bridges comes down, it will likely become a more and more popular choice. An ISDN router is a small box that plugs directly into your local Ethernet network(or card), and manages its own connection to the other bridge/router. It has all the software to do PPP and other protocols built in. A router will allow you much faster throughput that a standard TA, since it will be using a full synchronous ISDN connection. The main problem with ISDN routers and bridges is that interoperability between manufacturers can still be a problem. If you are planning to connect to an Internet provider, I recommend that you discuss your needs with them. If you are planning to connect two lan segments together, ie: home lan to the office lan, this is the simplest lowest maintenance solution. Since you are buying the equipment for both sides of the connection you can be assured that the link will work. For example to connect a home computer or branch office network to a head office network the following setup could be used. Branch office or Home network Network is 10 Base T Ethernet. Connect router to network cable with AUI/10BT transceiver, if necessary. ---Sun workstation | ---FreeBSD box | ---Windows 95 (Do not admit to owning it) | -Standalone router +Stand-alone router | ISDN BRI line If your home/branch office is only one computer you can use a - twisted pair crossover cable to connect to the standalone router + twisted pair crossover cable to connect to the stand-alone router directly. Head office or other lan Network is Twisted Pair Ethernet. -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | - |___---Standalone router + |___---Stand-alone router | ISDN BRI line One large advantage of most routers/bridges is that they allow you to have 2 separate independent PPP connections to 2 separate sites at the same time. This is not supported on most TA's, except for specific(expensive) models that have two serial ports. Do not confuse this with channel bonding, MPP etc. This can be very useful feature, for example if you have an - dedicated internet ISDN connection at your office and would like to + dedicated ISDN connection at your office and would like to tap into it, but don't want to get another ISDN line at work. A router at the office location can manage a dedicated B channel connection (64Kbs) to the internet, as well as a use the other B channel for a separate data connection. The second B channel can be used for - dialin, dialout or dynamically bond(MPP etc.) with the first B channel + dial-in, dial-out or dynamically bond(MPP etc.) with the first B channel for more bandwidth. An Ethernet bridge will also allow you to transmit more than just IP traffic, you can also send IPX/SPX or whatever other protocols you use. NIS/YP Written by &a.unfurl;, 21 January 2000. What is it? NIS is an RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location. How does it work? - There are 3 types of hosts in an NIS enviornment; master + There are 3 types of hosts in an NIS environment; master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers - hold the authoritatve copy of this information, while slave + hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them. Information in many files can be shared in this manner. The master.passwd, group, and hosts files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the server it is bound to, to get this information. Using NIS/YP Planning If you are setting up a NIS scheme for the first time, it is a good idea to think through how you want to go about it. No matter what the size of your network, there are a few decisions that need to be made. Choosing a NIS Domain Name This might not be the domainname that you are used to. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in someway way. Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique within your network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the "acme-art" NIS domain. Physical Server Requirements - There are several things to keep in mind when chosing a + There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind you should make sure to choose a machine that won't be prone to being rebooted regularly, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an NIS server. If you have a network that is not very heavily used, it is acceptable to put the NIS server on a machine running other services, just keep in mind that if the NIS server becomes unavailable, it will affect all of your NIS clients adversely. NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps. NIS master and slave servers handle all NIS requests with the ypserv daemon. Ypserv is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file and transmitting data from the database back to the client. Setting up a NIS master server - Setting up a master NIS server can be relativly straight + Setting up a master NIS server can be relatively straight forward, depending on your needs. FreeBSD comes with a handy script called ypinit that makes the initial setup procedure very easy. A few steps are needed ahead of time to make the setup process go smoothly. Make sure your NIS domainname is set, using the domainname command. You can run ypinit for domains other than the one your host is in but if domainname is not set, now is a good time to do so. Make sure a copy of the master.passwd file is in /var/yp. This where NIS will get the password entries it will share with it's clients. ypinit runs with errors if this file is not present. You can either start a new master.passwd or copy the existing one from /etc/master.passwd. If you do the latter, make sure the permissions are set properly to disallow world/group reading of the file. Start the ypserv daemon. ypinit requires ypserv to be running to answer some RPC calls it makes. In its basic configuration ypserv does not need to be run with any flags. Once you've done the above steps, run ypinit with the flag. You might want to specify the domain you are building a master server for if it is different than what the domainname is set to. In this example, test-domain will be our NIS domainname. # ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. master.example.com is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <Control D>. master server : master.example.com next host to add: ^D The current list of NIS servers looks like this: master.example.com Is this correct? [y/n: y] y Building /var/yp/test-domain/ypservers... Running /var/yp/Makefile... NIS Map update started on Fri Dec 3 16:54:12 PST 1999 for domain test-domain Updating hosts.byname... Creating new /var/yp/passwd file from /var/yp/master.passwd... Updating netid.byname... Updating hosts.byaddr... Updating networks.byaddr... Updating networks.byname... Updating protocols.bynumber... Updating protocols.byname... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating group.byname... Updating group.bygid... Updating passwd.byname... Updating passwd.byuid... Updating master.passwd.byname... Updating master.passwd.byuid... NIS Map update completed. master.example.com has been setup as an YP master server without any errors. There are a few crucial lines that need to be added to your /etc/rc.conf in order for the NIS server to start properly. Make sure that these lines are included: nis_server_enable="YES" nis_server_flags="" nis_yppasswdd_enable="YES" nis_yppasswdd_flags="" You will most likely want to run yppasswd on the NIS server. This allows users on NIS client machines to change their passwords and other user information remotely. Setting up a NIS slave server Setting up an NIS slave server is even more simple than setting up the master. Again the ypinit command helps out a great deal. As in the previous example we'll use test-domain as our target NIS domainname. # ypinit -s master.example.com test-domain Server Type: SLAVE Domain: test-domain Master: master.example.com Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from master.example.com. -Transfering netgroup... -ypxfr: Exiting: Map successfully transfered -Transfering netgroup.byuser... -ypxfr: Exiting: Map successfully transfered -Transfering netgroup.byhost... -ypxfr: Exiting: Map successfully transfered -Transfering master.passwd.byuid... -ypxfr: Exiting: Map successfully transfered -Transfering passwd.byuid... -ypxfr: Exiting: Map successfully transfered -Transfering passwd.byname... -ypxfr: Exiting: Map successfully transfered -Transfering group.bygid... -ypxfr: Exiting: Map successfully transfered -Transfering group.byname... -ypxfr: Exiting: Map successfully transfered -Transfering services.byname... -ypxfr: Exiting: Map successfully transfered -Transfering rpc.bynumber... -ypxfr: Exiting: Map successfully transfered -Transfering rpc.byname... -ypxfr: Exiting: Map successfully transfered -Transfering protocols.byname... -ypxfr: Exiting: Map successfully transfered -Transfering master.passwd.byname... -ypxfr: Exiting: Map successfully transfered -Transfering networks.byname... -ypxfr: Exiting: Map successfully transfered -Transfering networks.byaddr... -ypxfr: Exiting: Map successfully transfered -Transfering netid.byname... -ypxfr: Exiting: Map successfully transfered -Transfering hosts.byaddr... -ypxfr: Exiting: Map successfully transfered -Transfering protocols.bynumber... -ypxfr: Exiting: Map successfully transfered -Transfering ypservers... -ypxfr: Exiting: Map successfully transfered -Transfering hosts.byname... -ypxfr: Exiting: Map successfully transfered +Transferring netgroup... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byuser... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byhost... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring group.bygid... +ypxfr: Exiting: Map successfully transferred +Transferring group.byname... +ypxfr: Exiting: Map successfully transferred +Transferring services.byname... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.byname... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.byname... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring netid.byname... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring ypservers... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byname... +ypxfr: Exiting: Map successfully transferred slave.example.com has been setup as an YP slave server without any errors. Don't forget to update map ypservers on master.example.com. You should now have a directory called /var/yp/test-domain. Copies of the NIS master server's maps should be in this directory. You will need to make sure that these stay updated. The following /etc/crontab entries on your slave servers should do the job: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid These two lines force the slave to sync its maps with the maps on the master server. Although this is not mandatory, because the master server tries to make sure any changes to it's NIS maps are communicated to it's slaves, the password information is so vital to systems that depend on the server, that it is a good idea to force the updates. This is more important on busy networks where map updates might not always complete. NIS Clients An NIS client establishes what is called a binding to a particular NIS server using the ypbind daemon. Ypbind checks the system's default domain (as set by the domainname command), and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind, which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. Ypbind will occasionally ping the server to make sure it is still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. Setting up an NIS client Setting up a FreeBSD machine to be a NIS client is fairly straight forward. Set the host's NIS domainname with the domainname command, or at boot time with this entry in /etc/rc.conf: nisdomainname="test-domain" To import all possible password entries from the NIS server, add this line to your /etc/master.passwd file, using vipw: +::::::::: This line will afford anyone with a valid account in the NIS server's password maps an account. There are many ways to configure your NIS client by changing this line. For more detailed reading see O'Reilly's book on Managing NFS and NIS. To import all possible group entries from the NIS server, add this line to your /etc/group file: +:*:: After completing these steps, you should be able to run ypcat passwd and see the NIS server's passwd map. NIS Security In general, any remote user can issue an RPC to ypserv and retrieve the contents of your NIS maps, provided the remote user knows your domainname. To prevent such unauthorized transactions, ypserv supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, ypserv will attempt to load the securenets information from a file called /var/yp/securenets. This path varies depending on the path specified with the option. This file contains entries that consist of a network specification and a network mask separated by white space. Lines starting with # are considered to be comments. A sample securenets file might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 If ypserv receives a request from an address that matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow connections from any host. The ypserv program also has support for Wietse Venema's tcpwrapper package. This allows the administrator to use the tcpwrapper configuration files for access control instead of /var/yp/securenets. While both of these access control mechanisms provide some security, they, like the privileged port test, are both vulnerable to IP spoofing attacks. NIS v1 compatibility FreeBSD's ypserv has some support for serving NIS v1 clients. FreeBSD's NIS implementation only uses the NIS v2 protocol, however other implementations include support for the v1 protocol for backwards compatibility with older systems. The ypbind daemons supplied with these systems will try to establish a binding to an NIS v1 server even though they may never actually need it (and they may persist in broadcasting in search of one even after they receive a response from a v2 server). Note that while support for normal client calls is provided, this version of ypserv does not handle v1 map transfer requests; consequently, it can not be used as a master or slave in conjunction with older NIS servers that only support the v1 protocol. Fortunately, there probably are not any such servers still in use today. NIS servers that are also NIS clients Care must be taken when running ypserv in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon on it. Eventually all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again. You can force a host to bind to a particular server by running ypbind with the flag. - libscrypt vs. libdescrypt + libscrypt v.s. libdescrypt One of the most common issues that people run into when trying to implement NIS is crypt library compatibility. If your NIS server is using the DES crypt libraries, it will only support clients that are using DES as well. To check which one your server and clients are using look at the symlinks in /usr/lib. If the machine is configured to use the DES libraries, it will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a If the machine is configured to use the standard FreeBSD MD5 - crypt libraries they will look somethine like this: + crypt libraries they will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a If you have trouble authenticating on an NIS client, this is a pretty good place to start looking for possible problems. DHCP Written by &a.gsutter;, March 2000. What is DHCP? DHCP, the Dynamic Host Configuration Protocol, describes the means by which a system can connect to a network and obtain the necessary information for communication upon that network. FreeBSD uses the ISC (Internet Software Consortium) DHCP implementation, so all implementation-specific information here is for use with the ISC distribution. What This Section Covers This handbook section attempts to describe only the parts of the DHCP system that are integrated with FreeBSD; consequently, the server portions are not described. The DHCP manual pages, in addition to the references below, are useful resources. How it Works When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these requests are on UDP port 68. The server replies on UDP 67, giving the client an IP address and other relevant network information such as netmask, router, and DNS servers. All of this information comes in the form of a DHCP "lease" and is only valid for a certain time (configured by the DHCP server maintainer). In this manner, stale IP addresses for clients no longer connected to the network can be automatically reclaimed. DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in &man.dhcp-options.5;. FreeBSD Integration FreeBSD fully integrates the ISC DHCP client, dhclient. DHCP client support is provided within both the installer and the base system, obviating the need for detailed knowledge of network configurations on any network that runs a DHCP server. dhclient has been included in all FreeBSD distributions since 3.2. DHCP is supported by sysinstall. When configuring a network interface within sysinstall, the first question asked is, "Do you want to try dhcp configuration of this interface?" Answering affirmatively will execute dhclient, and if successful, will fill in the network configuration information automatically. To have your system use DHCP to obtain network information upon startup, edit your /etc/rc.conf to include the following: ifconfig_fxp0="DHCP" Be sure to replace fxp0 with the designation for the interface that you wish to dynamically configure. If you are using a different location for dhclient, or if you wish to pass additional flags to dhclient, also include the following (editing as necessary): dhcp_program="/sbin/dhclient" dhcp_flags="" The DHCP server, dhcpd, is included as part of the isc-dhcp2 port in the ports collection. This port contains the full ISC DHCP distribution, consisting of client, server, relay agent and documentation. Files /etc/dhclient.conf dhclient requires a configuration file, /etc/dhclient.conf. Typically the file contains only comments, the defaults being reasonably sane. This configuration file is described by the &man.dhclient.conf.5; man page. /sbin/dhclient dhclient is statically linked and resides in /sbin. The &man.dhclient.8; manual page gives more information about dhclient. /sbin/dhclient-script dhclient-script is the FreeBSD-specific DHCP client configuration script. It is described in &man.dhclient-script.8;, but should not need any user modification to function properly. /var/db/dhclient.leases The DHCP client keeps a database of valid leases in this file, which is written as a log. &man.dhclient.leases.5; gives a slightly longer description. Further Reading The DHCP protocol is fully described in RFC 2131. An informational resource has also been set up at dhcp.org. diff --git a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml index b6c5c3c292..12de057851 100644 --- a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml @@ -1,732 +1,732 @@ Backups Synopsis The following chapter will cover methods of backing up data, and the programs used to create those backups. If you would like to contribute something to this section, send it to the &a.doc;. Tape Media The major tape media are the 4mm, 8mm, QIC, mini-cartridge and DLT. 4mm (DDS: Digital Data Storage) 4mm tapes are replacing QIC as the workstation backup media of choice. This trend accelerated greatly when Conner purchased Archive, a leading manufacturer of QIC drives, and then stopped production of QIC drives. 4mm drives are small and quiet but do not have the reputation for reliability that is enjoyed by 8mm drives. The cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short head life for the same reason, both use helical scan. - Data thruput on these drives starts ~150kB/s, peaking at ~500kB/s. + Data throughput on these drives starts ~150kB/s, peaking at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. Multi-drive tape library units can have 6 drives in a single cabinet with automatic tape changing. Library capacities reach 240 GB. The DDS-3 standard now supports tape capacities up to 12GB (or 24GB compressed). 4mm drives, like 8mm drives, use helical-scan. All the benefits and drawbacks of helical-scan apply to both 4mm and 8mm drives. Tapes should be retired from use after 2,000 passes or 100 full backups. 8mm (Exabyte) 8mm tapes are the most common SCSI tape drives; they are the best choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm tape drive. 8mm drives are reliable, convenient and quiet. Cartridges are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is relatively short head and tape life due to the high rate of relative motion of the tape across the heads. - Data thruput ranges from ~250kB/s to ~500kB/s. Data sizes start + Data throughput ranges from ~250kB/s to ~500kB/s. Data sizes start at 300 MB and go up to 7 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. These drives are available as single units or multi-drive tape libraries with 6 drives and 120 tapes in a single cabinet. Tapes are changed automatically by the unit. Library capacities reach 840+ GB. The Exabyte Mammoth model supports 12GB on one tape (24MB with compression) and costs approximately twice as much as conventional tape drives. Data is recorded onto the tape using helical-scan, the heads are positioned at an angle to the media (approximately 6 degrees). The tape wraps around 270 degrees of the spool that holds the heads. The spool spins while the tape slides over the spool. The result is a high density of data and closely packed tracks that angle across the tape from one edge to the other. QIC QIC-150 tapes and drives are, perhaps, the most common tape drive and media around. QIC tape drives are the least expensive "serious" backup drives. The downside is the cost of media. QIC tapes are expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB data storage. But, if your needs can be satisfied with a half-dozen tapes, QIC may be the correct choice. QIC is the most common tape drive. Every site has a QIC drive of some density or another. Therein lies the rub, QIC has a large number of densities on physically similar (sometimes identical) tapes. QIC drives are not quiet. These drives audibly seek before they begin to record data and are clearly audible whenever reading, writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x 10.2 x 1.7 mm). Mini-cartridges, which also use 1/4" wide tape are discussed separately. Tape libraries and changers are not available. - Data thruput ranges from ~150kB/s to ~500kB/s. Data capacity + Data throughput ranges from ~150kB/s to ~500kB/s. Data capacity ranges from 40 MB to 15 GB. Hardware compression is available on many of the newer QIC drives. QIC drives are less frequently installed; they are being supplanted by DAT drives. Data is recorded onto the tape in tracks. The tracks run along the long axis of the tape media from one end to the other. The number of tracks, and therefore the width of a track, varies with the tape's capacity. Most if not all newer drives provide backward-compatibility at least for reading (but often also for writing). QIC has a good reputation regarding the safety of the data (the mechanics are simpler and more robust than for helical scan drives). Tapes should be retired from use after 5,000 backups. * Mini-Cartridge ]]> DLT DLT has the fastest data transfer rate of all the drive types listed here. The 1/2" (12.5mm) tape is contained in a single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging gate along one entire side of the cartridge. The drive mechanism opens this gate to extract the tape leader. The tape leader has an oval hole in it which the drive uses to "hook" the tape. The take-up spool is located inside the tape drive. All the other tape cartridges listed here (9 track tapes are the only exception) have both the supply and take-up spools located inside the tape cartridge itself. - Data thruput is approximately 1.5MB/s, three times the thruput of + Data throughput is approximately 1.5MB/s, three times the throughput of 4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB for a single drive. Drives are available in both multi-tape changers and multi-tape, multi-drive tape libraries containing from 5 to 900 tapes over 1 to 20 drives, providing from 50GB to 9TB of storage. With compression, DLT Type IV format supports up to 70GB capacity. Data is recorded onto the tape in tracks parallel to the direction of travel (just like QIC tapes). Two tracks are written at once. Read/write head lifetimes are relatively long; once the tape stops moving, there is no relative motion between the heads and the tape. AIT AIT is a new format from Sony, and can hold up to 50GB (with compression) per tape. The tapes contain memory chips which retain an index of the tape's contents. This index can be rapidly read by the tape drive to determine the position of files on the tape, instead of the several minutes that would be required for other tapes. Software such as SAMS:Alexandria can operate forty or more AIT tape libraries, communicating directly with the tape's memory chip to display the contents on screen, determine what files where backed up to which tape, locate the correct tape, load it, and restore the data from the tape. Libraries like this cost in the region of $20,000, pricing them a little out of the hobbyist market. Using a New Tape for the First Time The first time that you try to read or write a new, completely blank tape, the operation will fail. The console messages should be similar to: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready The tape does not contain an Identifier Block (block number 0). All QIC tape drives since the adoption of QIC-525 standard write an Identifier Block to the tape. There are two solutions: mt fsf 1 causes the tape drive to write an Identifier Block to the tape. Use the front panel button to eject the tape. Re-insert the tape and &man.dump.8; data to the tape. &man.dump.8; will report DUMP: End of tape detected and the console will show: HARDWARE FAILURE info:280 asc:80,96 rewind the tape using: mt rewind Subsequent tape operations are successful. Backup Programs The three major programs are &man.dump.8;, &man.tar.1;, and &man.cpio.1;. Dump and Restore &man.dump.8; and &man.restore.8; are the traditional Unix backup programs. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the filesystems. &man.dump.8; backs up devices, entire filesystems, not parts of a filesystem and not directory trees that span more than one filesystem, using either soft links &man.ln.1; or mounting one filesystem onto another. &man.dump.8; does not write files and directories to tape, but rather writes the data blocks that are the building blocks of files and directories. &man.dump.8; has quirks that remain from its early days in Version 6 of ATT Unix (circa 1975). The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. &man.rdump.8; and &man.rrestore.8; backup data across the network to a tape drive attached to another computer. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must have rhosts access to the remote computer. The arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use on the remote computer. (e.g. When rdump'ing from a FreeBSD computer to an Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there are security implications to allowing rhosts commands. Evaluate your situation carefully. Tar &man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975). &man.tar.1; operates in cooperation with the filesystem; &man.tar.1; writes files and directories to tape. &man.tar.1; does not support the full range of options that are available from &man.cpio.1;, but &man.tar.1; does not require the unusual command pipeline that &man.cpio.1; uses. Most versions of &man.tar.1; do not support backups across the network. The GNU version of &man.tar.1;, which FreeBSD utilizes, supports remote devices using the same syntax as &man.rdump.8;. To &man.tar.1; to an Exabyte tape drive connected to a Sun called komodo, use: /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1. For versions without remote device support, you can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b If you're worried about the security of backing over a network you should use the &man.ssh.1; command instead of &man.rsh.1;. Cpio &man.cpio.1; is the original Unix file interchange tape program for magnetic media. &man.cpio.1; has options (among many others) to perform byte-swapping, write a number of different archives format, and pipe the data to other programs. This last feature makes &man.cpio.1; and excellent choice for installation media. &man.cpio.1; does not know how to walk the directory tree and a list of files must be provided through stdin. &man.cpio.1; does not support backups across the network. You can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. (XXX add an example command) Pax &man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and &man.cpio.1;. Over the years the various versions of &man.tar.1; and &man.cpio.1; have gotten slightly incompatible. So rather than fight it out to fully standardize them, POSIX created a new archive utility. &man.pax.1; attempts to read and write many of the various &man.cpio.1; and &man.tar.1; formats, plus new formats of its own. Its command set more resembles &man.cpio.1; than &man.tar.1;. Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and network communications with the Amanda server. A common problem at locations with a number of large disks is the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem. Amanda can use a "holding disk" to backup several filesystems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the filesystems listed in Amanda's configuration file. The "archive set" also contains nightly incremental (or differential) backups of all the filesystems. Restoring a damaged filesystem requires the most recent full backup and the incremental backups. The configuration file provides fine control backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is available as either a port or a package, it is not installed by default. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and your data is worth little to nothing, then Do nothing is the most suitable backup program for your computer. But beware, Unix is a useful tool, you may find that within six months you have a collection of files that are valuable to you. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by your computer. An example is the files that comprise these handbook pages-they have been generated from SGML input files. Creating backups of these HTML files is not necessary. The SGML source files are backed up regularly. Which Backup Program is Best? &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of Unix filesystems is &man.dump.8;. Elizabeth created filesystems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by do a backup and restore of that filesystems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are only four steps that you need to perform in preparation for any disaster that may occur. First, print the disklabel from each of your disks (e.g. disklabel da0 | lpr), your filesystem table (/etc/fstab) and all boot messages, two copies of each. - Second, determine that the boot and fixit floppies + Second, determine that the boot and fix-it floppies (boot.flp and fixit.flp) have all your devices. The easiest way to check is to reboot your machine with the boot floppy in the floppy drive and check the boot messages. If all your devices are listed and functional, skip on to step three. Otherwise, you have to create two custom bootable floppies which has a kernel that can mount your all of your disks and access your tape drive. These floppies must contain: &man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and whichever backup program you use. These programs must be statically linked. If you use &man.dump.8;, the floppy must contain &man.restore.8;. Third, create backup tapes regularly. Any changes that you make after your last backup may be irretrievably lost. Write-protect the backup tapes. Fourth, test the floppies (either boot.flp and fixit.flp or the two custom bootable floppies you made in step two.) and backup tapes. Make notes of the procedure. Store these notes with the bootable floppy, the printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you might accidently type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two backup tapes each time. Store one of each at a remote location. A remote location is NOT the basement of the same office building. A number of firms in the World Trade Center learned this lesson the hard way. A remote location should be physically separated from your computers and disk drives by a significant distance. An example script for creating a bootable floppy: /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum filesystem table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < After the Disaster The key question is: did your hardware survive? You have been doing regular backups so there is no need to worry about the software. If the hardware has been damaged. First, replace those parts that have been damaged. If your hardware is okay, check your floppies. If you are using a custom boot floppy, boot single-user (type -s at the boot: prompt). Skip the following paragraph. If you are using the boot.flp and fixit.flp floppies, keep reading. Insert the boot.flp floppy in the first floppy drive and boot the computer. The original install menu will be displayed on the screen. Select the Fixit--Repair mode with CDROM or floppy. option. Insert the fixit.flp when prompted. restore and the other programs that you need are located in /mnt2/stand. Recover each filesystem separately. Try to &man.mount.8; (e.g. mount /dev/da0a /mnt) the root partition of your first disk. If the disklabel was damaged, use &man.disklabel.8; to re-partition and label the disk to match the label that your printed and saved. Use &man.newfs.8; to re-create the filesystems. Re-mount the root partition of the floppy read-write (mount -u -o rw /mnt). Use your backup program and backup tapes to recover the data for this filesystem (e.g. restore vrf /dev/sa0). Unmount the filesystem (e.g. umount /mnt) Repeat for each filesystem that was damaged. Once your system is running, backup your data onto new tapes. Whatever caused the crash or data loss may strike again. An another hour spent now, may save you from further distress later. * I did not prepare for the Disaster, What Now? ]]> What about Backups to Floppies? Can I use floppies for backing up my data? Floppy disks are not really a suitable media for making backups as: The media is unreliable, especially over long periods of time Backing up and restoring is very slow They have a very limited capacity (the days of backing up an entire hard disk onto a dozen or so floppies has long since passed). However, if you have no other method of backing up your data then floppy disks are better than no backup at all. If you do have to use floppy disks then ensure that you use good quality ones. Floppies that have been lying around the office for a couple of years are a bad choice. Ideally use new ones from a reputable manufacturer. So how do I backup my data to floppies? The best way to backup to floppy disk is to use &man.tar.1; with the (multi volume) option, which allows backups to span multiple floppies. To backup all the files in the current directory and sub-directory use this (as root): &prompt.root; tar Mcvf /dev/rfd0 * When the first floppy is full &man.tar.1; will prompt you to insert the next volume (because &man.tar.1; is media independent it refers to volumes. In this context it means floppy disk) Prepare volume #2 for /dev/rfd0 and hit return: This is repeated (with the volume number incrementing) until all the specified files have been archived. Can I compress my backups? Unfortunately, &man.tar.1; will not allow the option to be used for multi-volume archives. You could, of course, &man.gzip.1; all the files, &man.tar.1; them to the floppies, then &man.gunzip.1; the files again! How do I restore my backups? To restore the entire archive use: &prompt.root; tar Mxvf /dev/rfd0 To restore only specific files you can either start with the first floppy and use: &prompt.root; tar Mxvf /dev/rfd0 filename &man.tar.1; will prompt you to insert subsequent floppies until it finds the required file. Alternatively, if you know which floppy the file is on then you can simply insert that floppy and use the same command as above. Note that if the first file on the floppy is a continuation from the previous one then &man.tar.1; will warn you that it cannot restore it, even if you have not asked it to! diff --git a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml index da26d06487..41322bc613 100644 --- a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml @@ -1,6011 +1,6011 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and - subservices to allow the use of ODI card drivers supplied with + sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting - internal vs. external display and picking a different screen + internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks Most of the tasks listed in the previous sections require either a considerable investment of time or an in-depth knowledge of the FreeBSD kernel (or both). However, there are also many useful tasks which are suitable for "weekend hackers", or people without programming skills. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. - If you know of any bugfixes which have been successfully + If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as FreeBSD-current which is made available in a variety of ways for the convenience of developers working actively on the system. See Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the rare case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it - becomes almost always necessary to either send changes as uuencode'd + becomes almost always necessary to either send changes as uuencoded tar files or upload them to our ftp site ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. <anchor id="donations">Donating funds While the FreeBSD Project is not a 501(c)(3) (charitable) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the Walnut Creek CDROM address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would - like to publically thank them here! + like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD - CD-ROMs). + CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: 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. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: Walnut Creek CDROM has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting - &a.joerg; who has often preferred FreeBSD work over paywork, and + &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or - flakey to work with it... + flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni The following people were members of the FreeBSD core team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Derived Software Contributors This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-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 and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com - Adrian Chadd adrian@freebsd.org + Adrian Chadd adrian@FreeBSD.org Adrian Colley aecolley@ois.ie Adrian Hall adrian@ibmpcug.co.uk Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex garbanzo@hooked.net Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex G. Bulushev bag@demos.su Alex Le Heux alexlh@funk.org Alex Perel veers@disturbed.net Alex Varju varju@webct.com Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Assar Westerlund assar@sics.se Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Smithurst ben@scientia.demon.co.uk Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Benno Rice benno@netizen.com.au Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce A. Mah bmah@ca.sandia.gov Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Choi Jun Ho junker@jazz.snu.ac.kr Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Clive Lin clive@CiRX.ORG Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@neosoft.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Harris dannyboy@dannyboy.eyep.net Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@umiacs.umd.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Malone dwmalone@maths.tcd.ie David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dima Sivachenko dima@Chg.RU Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Dominik Brettnacher domi@saargate.de Dominik Rother dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Doug Barton Doug@gorean.org Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Duncan Barclay dmlb@ragnet.demon.co.uk Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@lab321.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp G. Adam Stanislavadam@whizkidtech.net Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Garance A Drosehn gad@eclipse.its.rpi.edu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Dowse iedowse@maths.tcd.ie Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Issei Suzuki issei@jp.FreeBSD.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com J.T. Jang keith@email.gcn.net.tw Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer jeff@isni.net Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart unknown Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jua@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp Kazuo Horikawa horikawa@jp.FreeBSD.org Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Kelly Yancey kbyanc@posi.net Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Lokevlo@hello.com.tw Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mario Sergio Fujikawa Ferreira lioux@gns.com.br Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Ovens mark@dogma.freebsd-uk.eu.org Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Markus Holmberg saska@acc.umu.se Martin Birgmeier Martin Blapp blapp@attic.ch Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Mas.TAKEMURA unknown Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Micha Class michael_class@hpbbse.bbn.hp.com Michael Lucas mwlucas@blackhelicopters.org Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar MIHIRA Sanpei Yoshiro sanpei@sanpei.org Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@shiva.the-park.com Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.ziplink.net Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW MITA Yoshio mita@jp.FreeBSD.org MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Hausen unknown Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Rajesh Vaidheeswarran rv@fore.com Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@drmemory.fnal.gov Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge A. Babkin babkin@hq.icb.chel.su Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Shunsuke Akiyama akiyama@jp.FreeBSD.org Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko ARAI toshi@tenchi.ne.jp Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com Trevor Johnson trevor@jpj.net Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko OHTA yohta@bres.tsukuba.ac.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall adrian@ibmpcug.co.uk Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rod Taylor rod@idiotswitch.org Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index 35bf891f54..6d56021fa1 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,1860 +1,1860 @@ The Cutting Edge Restructured, reorganized, and parts updated by &a.jim; March 2000. Original work by &a.jkh;, &a.phk;, &a.jdp;, and &a.nik; with feedback from various others. Synopsis FreeBSD is under constant development between releases. For people who want to be on the cutting edge, there are several easy mechanisms for keeping your system in sync with the latest developments. Be warned—the cutting edge is not for everyone! This chapter will help you decide if you want to track the development system, or stick with one of the released versions. - -CURRENT vs. -STABLE + -CURRENT v.s.. -STABLE There are two development branches to FreeBSD; -CURRENT and -STABLE. This section will explain a bit about each and describe how to keep your system up-to-date with each respective tree. -CURRENT will be discussed first, then -STABLE. Staying Current with FreeBSD As you are reading this, keep in mind that -CURRENT is the bleeding edge of FreeBSD development and that if you are new to FreeBSD, you are most likely going to want to think twice about running it. What is FreeBSD-CURRENT? FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD. These include work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. While many of us compile almost daily from FreeBSD-CURRENT sources, there are periods of time when the sources are literally un-compilable. These problems are generally resolved as expeditiously as possible, but whether or not FreeBSD-CURRENT sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in! Who needs FreeBSD-CURRENT? FreeBSD-CURRENT is made generally available for 3 primary interest groups: Members of the FreeBSD group who are actively working on some part of the source tree and for whom keeping current is an absolute requirement. Members of the FreeBSD group who are active testers, willing to spend time working through problems in order to ensure that FreeBSD-CURRENT remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of FreeBSD. Peripheral members of the FreeBSD (or some other) group who merely wish to keep an eye on things and use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code. What is FreeBSD-CURRENT <emphasis>not</emphasis>? A fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it. A quick way of getting bug fixes. In any way officially supported by us. We do our best to help people genuinely in one of the 3 legitimate FreeBSD-CURRENT categories, but we simply do not have the time to provide tech support for it. This is not because we are mean and nasty people who do not like helping people out (we would not even be doing FreeBSD if we were), it is literally because we cannot answer 400 messages a day and actually work on FreeBSD! I am sure that, if given the choice between having us answer lots of questions or continuing to improve FreeBSD, most of you would vote for us improving it. Using FreeBSD-CURRENT Join the &a.current; and the &a.cvsall; . This is not just a good idea, it is essential. If you are not on the FreeBSD-CURRENT mailing list, you will not see the comments that people are making about the current state of the system and thus will probably end up stumbling over a lot of problems that others have already found and solved. Even more importantly, you will miss out on important bulletins which may be critical to your system's continued health. The &a.cvsall; mailing list will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-current subscribe cvs-all Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. Grab the sources from ftp.FreeBSD.org. You can do this in one of three ways: Use the CTM facility. Unless you have a good TCP/IP connection at a flat rate, this is the way to do it. Use the cvsup program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 Use ftp. The source tree for FreeBSD-CURRENT is always exported on: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/. We also use wu-ftpd which allows - compressed/tar'd grabbing of whole trees. e.g. you + compressed/tarred grabbing of whole trees. e.g. you see: usr.bin/lex You can do the following to get the whole directory as a tar file: ftp> cd usr.bin ftp> get lex.tar Essentially, if you need rapid on-demand access to the source and communications bandwidth is not a consideration, use cvsup or ftp. Otherwise, use CTM. If you are grabbing the sources to run, and not just look at, then grab all of current, not just selected portions. The reason for this is that various parts of the source depend on updates elsewhere, and trying to compile just a subset is almost guaranteed to get you into trouble. Before compiling current, read the Makefilein /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.current; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. Be active! If you are running FreeBSD-CURRENT, we want to know what you have to say about it, especially if you have suggestions for enhancements or bug fixes. Suggestions with accompanying code are received most enthusiastically! Staying Stable with FreeBSD If you are using FreeBSD in a production environment and want to make sure you have the latest fixes from the -CURRENT branch, you want to be running -STABLE. This is the tree that -RELEASEs are branched from when we are putting together a new release. For example, if you have a copy of 3.4-RELEASE, that is really just a snapshot from the -STABLE branch that we put on CDROM. In order to get any changes merged into -STABLE after the -RELEASE, you need to track the -STABLE branch. What is FreeBSD-STABLE? FreeBSD-STABLE is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Changes of an experimental or untested nature do not go into this branch (see FreeBSD-CURRENT). Who needs FreeBSD-STABLE? If you are a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking stable. This is especially true if you have installed the most recent release (&rel.current;-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release. The stable tree endeavors, above all, to be fully compilable and stable at all times, but we do occasionally make mistakes (these are still active sources with quickly-transmitted updates, after all). We also do our best to thoroughly test fixes in current before bringing them into stable, but sometimes our tests fail to catch every case. If something breaks for you in stable, please let us know immediately! (see next section). Using FreeBSD-STABLE Join the &a.stable;. This will keep you informed of build-dependencies that may appear in stable or any other issues requiring special attention. Developers will also make announcements in this mailing list when they are contemplating some controversial fix or update, giving the users a chance to respond if they have any issues to raise concerning the proposed change. The &a.cvsall; mailing list will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-stable subscribe cvs-all Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. If you are installing a new system and want it to be as stable as possible, you can simply grab the latest dated branch snapshot from ftp://releng4.FreeBSD.org/pub/FreeBSD/ and install it like any other release. If you are already running a previous release of FreeBSD and wish to upgrade via sources then you can easily do so from ftp.FreeBSD.org. This can be done in one of three ways: Use the CTM facility. Unless you have a good TCP/IP connection at a flat rate, this is the way to do it. Use the cvsup program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron to keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 Use ftp. The source tree for FreeBSD-STABLE is always exported on: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ We also use wu-ftpd which allows - compressed/tar'd grabbing of whole trees. e.g. you + compressed/tarred grabbing of whole trees. e.g. you see: usr.bin/lex You can do the following to get the whole directory for you as a tar file: ftp> cd usr.bin ftp> get lex.tar Essentially, if you need rapid on-demand access to the source and communications bandwidth is not a consideration, use cvsup or ftp. Otherwise, use CTM. Before compiling stable, read the Makefile in /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.stable; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. Synchronizing Your Source There are various ways of using an Internet (or email) connection to stay up-to-date with any given area of the FreeBSD project sources, or all areas, depending on what interests you. The primary services we offer are Anonymous CVS, CVSup, and CTM. Anonymous CVS and CVSup use the pull model of updating sources. In the case of CVSup the user (or a cron script) invokes the cvsup program, and it interacts with a cvsupd server somewhere to bring your files up-to-date. The updates you receive are up-to-the-minute and you get them when, and only when, you want them. You can easily restrict your updates to the specific files or directories that are of interest to you. Updates are generated on the fly by the server, according to what you have and what you want to have. Anonymous CVS is quite a bit more simplistic than CVSup in that it's just an extension to CVS which allows it to pull changes directly from a remote CVS repository. CVSup can do this far more efficiently, but Anonymous CVS is easier to use. CTM, on the other hand, does not interactively compare the sources you have with those on the master archive or otherwise pull them across.. Instead, a script which identifies changes in files since its previous run is executed several times a day on the master CTM machine, any detected changes being compressed, stamped with a sequence-number and encoded for transmission over email (in printable ASCII only). Once received, these CTM deltas can then be handed to the &man.ctm.rmail.1; utility which will automatically decode, verify and apply the changes to the user's copy of the sources. This process is far more efficient than CVSup, and places less strain on our server resources since it is a push rather than a pull model. There are other trade-offs, of course. If you inadvertently wipe out portions of your archive, CVSup will detect and rebuild the damaged portions for you. CTM won't do this, and if you wipe some portion of your source tree out (and don't have it backed up) then you will have to start from scratch (from the most recent CVS base delta) and rebuild it all with CTM or, with anoncvs, simply delete the bad bits and resync. More information about Anonymous CVS, CTM, and CVSup is available further down in this section. Anonymous CVS <anchor id="anoncvs-intro">Introduction Anonymous CVS (or, as it is otherwise known, anoncvs) is a feature provided by the CVS utilities bundled with FreeBSD for synchronizing with a remote CVS repository. Among other things, it allows users of FreeBSD to perform, with no special privileges, read-only CVS operations against one of the FreeBSD project's official anoncvs servers. To use it, one simply sets the CVSROOT environment variable to point at the appropriate anoncvs server, provides the well-known password anoncvs with the cvs login command, and then uses the &man.cvs.1; command to access it like any local repository. While it can also be said that the CVSup and anoncvs services both perform essentially the same function, there are various trade-offs which can influence the user's choice of synchronization methods. In a nutshell, CVSup is much more efficient in its usage of network resources and is by far the most technically sophisticated of the two, but at a price. To use CVSup, a special client must first be installed and configured before any bits can be grabbed, and then only in the fairly large chunks which CVSup calls collections. Anoncvs, by contrast, can be used to examine anything from an individual file to a specific program (like ls or grep) by referencing the CVS module name. Of course, anoncvs is also only good for read-only operations on the CVS repository, so if it's your intention to support local development in one repository shared with the FreeBSD project bits then CVSup is really your only option. <anchor id="anoncvs-usage">Using Anonymous CVS Configuring &man.cvs.1; to use an Anonymous CVS repository is a simple matter of setting the CVSROOT environment variable to point to one of the FreeBSD project's anoncvs servers. At the time of this writing, the following servers are available: USA: :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs (Use cvs login and enter the password anoncvs when prompted.) Since CVS allows one to check out virtually any version of the FreeBSD sources that ever existed (or, in some cases, will exist :-), you need to be familiar with the revision () flag to &man.cvs.1; and what some of the permissible values for it in the FreeBSD Project repository are. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. Here are the branch tags that users might be interested in (keep in mind that the only tags valid for the ports collection is HEAD). HEAD Symbolic name for the main line, or FreeBSD-CURRENT. Also the default when no revision is specified. RELENG_3 The line of development for FreeBSD-3.X, also known as FreeBSD-STABLE. RELENG_2_2 The line of development for FreeBSD-2.2.X, also known as 2.2-STABLE. This branch is mostly obsolete. Here are the revision tags that users might be interested in. Again, none of these are valid for the ports collection since the ports collection does not have multiple revisions. RELENG_3_4_0_RELEASE FreeBSD-3.4. RELENG_3_3_0_RELEASE FreeBSD-3.3. RELENG_3_2_0_RELEASE FreeBSD-3.2. RELENG_3_1_0_RELEASE FreeBSD-3.1. RELENG_3_0_0_RELEASE FreeBSD-3.0. RELENG_2_2_8_RELEASE FreeBSD-2.2.8. RELENG_2_2_7_RELEASE FreeBSD-2.2.7. RELENG_2_2_6_RELEASE FreeBSD-2.2.6. RELENG_2_2_5_RELEASE FreeBSD-2.2.5. RELENG_2_2_2_RELEASE FreeBSD-2.2.2. RELENG_2_2_1_RELEASE FreeBSD-2.2.1. RELENG_2_2_0_RELEASE FreeBSD-2.2.0. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the flag. See the &man.cvs.1; man page for more details. Examples While it really is recommended that you read the manual page for &man.cvs.1; thoroughly before doing anything, here are some quick examples which essentially show how to use Anonymous CVS: Checking out something from -CURRENT (&man.ls.1;) and deleting it again: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co ls &prompt.user; cvs release -d ls &prompt.user; cvs logout Checking out the version of &man.ls.1; in the 2.2-STABLE branch: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co -rRELENG_2_2 ls &prompt.user; cvs release -d ls &prompt.user; cvs logout - Creating a list of changes (as unidiffs) to &man.ls.1; + Creating a list of changes (as unified diffs) to &man.ls.1; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE ls &prompt.user; cvs logout Finding out what other module names can be used: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co modules &prompt.user; more modules/modules &prompt.user; cvs release -d modules &prompt.user; cvs logout Other Resources The following additional resources may be helpful in learning CVS: CVS Tutorial from Cal Poly. Cyclic Software, commercial maintainers of CVS. CVSWeb is the FreeBSD Project web interface for CVS. Using <command>make world</command> - Once you have synchronised your local source tree against a + Once you have synchronized your local source tree against a particular version of FreeBSD (stable, current and so on) you must then use the source tree to rebuild the system. Take a backup I cannot stress highly enough how important it is to take a backup of your system before you do this. While remaking the world is (as long as you follow these instructions) an easy task to do, there will inevitably be times when you make mistakes, or when mistakes made by others in the source tree render your system unbootable. - Make sure you have taken a backup. And have a fixit floppy to + Make sure you have taken a backup. And have a fix-it floppy to hand. I have never needed to use them, and, touch wood, I never will, but it is always better to be safe than sorry. Subscribe to the right mailing list The -STABLE and -CURRENT FreeBSD code branches are, by their nature, in development. People that contribute to FreeBSD are human, and mistakes occasionally happen. Sometimes these mistakes can be quite harmless, just causing your system to print a new diagnostic warning. Or the change may be catastrophic, and render your system unbootable or destroy your filesystems (or worse). If problems like these occur, a heads up is posted to the appropriate mailing list, explaining the nature of the problem and which systems it affects. And an all clear announcement is posted when the problem has been solved. If you try and track -STABLE or -CURRENT and do not read the stable@FreeBSD.org or current@FreeBSD.org mailing lists then you are asking for trouble. Read <filename>/usr/src/UPDATING</filename> Before you do anything else, read /usr/src/UPDATING (or the equivalent file wherever you have a copy of the source code). This file should contain important information about problems you might encounter, or specify the order in which you might have to run certain commands. If UPDATING contradicts something you read here, UPDATING takes precedence. Reading UPDATING is not an acceptable substitute for subscribing to the correct mailing list, as described previously. The two requirements are complementary, not exclusive. Check <filename>/etc/make.conf</filename> Examine the file /etc/make.conf. This contains some default defines for Everything is, by default, commented out. Uncomment those entries that look useful. For a typical user (not a developer), you will probably want to uncomment the CFLAGS and NOPROFILE definitions. If your machine has a floating point unit (386DX, 486DX, Pentium and up class machines) then you can also uncomment the HAVE_FPU line.</para> <para>This definition was removed for version 2.2.2 and up of FreeBSD.</para> </note> <para>Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you.</para> </sect2> <sect2> <title>Update <filename>/etc/group</filename> The /etc directory contains a large part of your system's configuration information, as well as scripts that are run at system startup. Some of these scripts change from version to version of FreeBSD. Some of the configuration files are also used in the day to day running of the system. In particular, /etc/group. There have been occasions when the installation part of make world has expected certain usernames or groups to exist. When performing an upgrade it is likely that these groups did not exist. This caused problems when upgrading. The most recent example of this is when the ppp subsystem were installed using a non-existent (for them) group name. The solution is to examine /usr/src/etc/group and compare its list of groups with your own. If they are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in /etc/group which have the same GID but a different name to those in /usr/src/etc/group. If you are feeling particularly paranoid, you can check your system to see which files are owned by the group you are renaming or deleting. &prompt.root; find / -group GID -print will show all files owned by group GID (which can be either a group name or a numeric group ID). You may want to compile the system in single user mode. Apart from the obvious benefit of making things go slightly faster, reinstalling the system will touch a lot of important system files, all the standard system binaries, libraries, include files and so on. Changing these on a running system (particularly if you have active users on their at the time) is asking for trouble.</para> <para>That said, if you are confident, you can omit this step.</para> <note> <title>Version 2.2.5 and above As described in more detail below, versions 2.2.5 and above of FreeBSD have separated the building process from the installing process. You can therefore build the new system in multi-user mode, and then drop to single user mode to do the installation. As the superuser, you can execute &prompt.root; from a running system, which will drop it to single user mode. Alternatively, reboot the system, and at the boot prompt, enter the flag. The system will then boot single user. At the shell prompt you should then run: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a This checks the filesystems, remounts / read/write, mounts all the other UFS filesystems referenced in /etc/fstab and then turns swapping on. Remove <filename>/usr/obj</filename> As parts of the system are rebuilt they are placed in directories which (by default) go under /usr/obj. The directories shadow those under /usr/src. You can speed up the make world process, and possibly save yourself some dependency headaches by removing this directory as well. Some files below /usr/obj will have the immutable flag set (see &man.chflags.1; for more information) which must be removed first. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * <title>All versions You must be in the /usr/src directory... &prompt.root; cd /usr/src (unless, of course, your source code is elsewhere, in which case change to that directory instead). To rebuild the world you use the &man.make.1; command. This command reads instructions from the Makefile which describes how the programs that comprise FreeBSD should be rebuilt, the order they should be built in, and so on. The general format of the command line you will type is as follows: &prompt.root; make In this example, is an option that you would pass to &man.make.1;. See the &man.make.1; manual page for an example of the options you can pass. passes a variable to the Makefile. The behavior of the Makefile is controlled by these variables. These are the same variables as are set in /etc/make.conf, and this provides another way of setting them. &prompt.root; make -DNOPROFILE=true target - is another way of specifying that profiled libaries should + is another way of specifying that profiled libraries should not be built, and corresponds with the NOPROFILE= true # Avoid compiling profiled libraries lines in /etc/make.conf. target tells &man.make.1; what you want to do. Each Makefile defines a number of different targets, and your choice of target determines what happens. Some targets are listed in the Makefile, but are not meant for you to run. Instead, they are used by the build process to break out the steps necessary to rebuild the system into a number of sub-steps. Most of the time you won't need to pass any parameters to &man.make.1;, and so your command like will look like this: &prompt.root; make target Saving the output It's a good idea to save the output you get from running &man.make.1; to another file. If something goes wrong you will have a copy of the error message, and a complete list of where the process had got to. While this might not help you in diagnosing what has gone wrong, it can help others if you post your problem to one of the FreeBSD mailing lists. The easiest way to do this is to use the &man.script.1; command, with a parameter that specifies the name of the file to save all output to. You would do this immediately before remaking the world, and then type exit when the process has finished. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make world … compile, compile, compile … &prompt.root; exit Script done, … If you do this, do not save the output in /tmp. This directory may be cleared next time you reboot. A better place to store it is in /var/tmp (as in the previous example) or in root's home directory. Version 2.2.2 and below /usr/src/Makefile contains the world target, which will rebuild the entire system and then install it. Use it like this: &prompt.root; make world Version 2.2.5 and above Beginning with version 2.2.5 of FreeBSD (actually, it was first created on the -CURRENT branch, and then retrofitted to -STABLE midway between 2.2.2 and 2.2.5) the world target has been split in two. buildworld and installworld. As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld installs this tree on the current machine. This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is self hosted. Because of this, you can safely run buildworld on a machine running in multi-user mode with no fear of ill-effects. I still recommend you run the installworld part in single user mode though. Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run make buildworld and make installworld on A. B and C should then NFS mount /usr/src and /usr/obj from A, and you can then run make installworld to install the results of the build on B and C. The world target still exists, and you can use it exactly as shown for version 2.2.2. make world runs make buildworld followed by make installworld. If you do the make buildworld and make installworld commands separately, you must pass the same parameters to &man.make.1; each time. If you run: &prompt.root; make -DNOPROFILE=true buildworld you must install the results with: &prompt.root; make -DNOPROFILE=true installworld otherwise it would try and install profiled libraries that had not been built during the make buildworld phase. -CURRENT and above If you are tracking -CURRENT you can also pass the option to make. This lets make spawn several simultaneous processes. This is most useful on true multi-CPU machines. However, since much of the compiling process is IO bound rather than CPU bound it is also useful on single CPU machines. On a typical single-CPU machine you would run: &prompt.root; make -j4 target &man.make.1; will then have up to 4 processes running at any one time. Empirical evidence posted to the mailing lists shows this generally gives the best performance benefit. If you have a multi-CPU machine and you are using an SMP configured kernel try values between 6 and 10 and see how they speed things up. Be aware that (at the time of writing) this is still experimental, and commits to the source tree may occasionally break this feature. If the world fails to compile using this parameter try again without it before you report any problems. Timings Assuming everything goes well you have anywhere between an hour and a half and a day or so to wait. As a general rule of thumb, a 200MHz P6 with more than 32MB of RAM and reasonable SCSI disks will complete make world in about an hour and a half. A 32MB P133 will take 5 or 6 hours. Revise these figures down if your machines are slower… Update <filename>/etc</filename> Remaking the world will not update certain directories (in particular, /etc, /var and /usr) with new or changed configuration files. This is something you have to do by hand, eyeball, and judicious use of &man.diff.1;. You cannot just copy over the files from /usr/src/etc to /etc and have it work. Some of these files must be installed first. This is because the /usr/src/etc directory is not a copy of what your /etc directory should look like. In addition, there are files that should be in /etc that are not in /usr/src/etc. The simplest way to do this is to install the files into a new directory, and then work through them looking for differences. Backup your existing <filename>/etc</filename> Although, in theory, nothing is going to touch this directory automatically, it is always better to be sure. So copy your existing /etc directory somewhere safe. Something like: &prompt.root; cp -Rp /etc /etc.old does a recursive copy, preserves times, ownerships on files and suchlike. You need to build a dummy set of directories to install the new /etc and other files into. I generally choose to put this dummy directory in /var/tmp/root, and there are a number of subdirectories required under this as well. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution This will build the necessary directory structure and install the files. A lot of the subdirectories that have been created under /var/tmp/root are empty and should be deleted. The simplest way to do this is to: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | /usr/bin/perl -lne \ 'opendir(D,$_);@f=readdir(D);rmdir if $#f == 1;closedir(D);' This does a depth first search, examines each directory, and if the number of files in that directory is 2 ( /var/tmp/root now contains all the files that should be placed in appropriate locations below /. You now have to go through each of these files, determining how they differ with your existing files. Note that some of the files that will have been installed in /var/tmp/root have a leading /var/tmp/root/ and /var/tmp/root/root/, although there may be others (depending on when you are reading this. Make sure you use The simplest way to do this is to use &man.diff.1; to compare the two files. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells This will show you the differences between your /etc/shells file and the new /etc/shells file. Use these to decide whether to merge in changes that you have made or whether to copy over your old file. Name the new root directory - (<filename>/var/tmp/root</filename>)with a timestamp, so you can + (<filename>/var/tmp/root</filename>)with a time stamp, so you can easily compare differences between versions Frequently remaking the world means that you have to update /etc frequently as well, which can be a bit of a chore. You can speed this process up by keeping a copy of the last set of changed files that you merged into /etc. The following procedure gives one idea of how to do this. Make the world as normal. When you want to update /etc and the other directories, give the target directory a name based on the current date. If you were doing this on the 14th of February 1998 you could do the following. &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Merge in the changes from this directory as outlined above. Do not remove the /var/tmp/root-19980214 directory when you have finished. When you have downloaded the latest version of the source and remade it, follow step 1. This will give you a new directory, which might be called /var/tmp/root-19980221 (if you wait a week between doing updates). You can now see the differences that have been made in the intervening week using &man.diff.1; to create a recursive diff between the two directories. &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Typically, this will be a much smaller set of differences than those between /var/tmp/root-19980221/etc and /etc. Because the set of differences is smaller, it is easier to migrate those changes across into your /etc directory. You can now remove the older of the two /var/tmp/root-* directories. &prompt.root; rm -rf /var/tmp/root-19980214 Repeat this process every time you need to merge in changes to /etc. You can use &man.date.1; to automate the generation of the directory names. &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Update <filename>/dev</filename> DEVFS If you are using DEVFS then this is probably unnecessary. - For safety's sake, this is a multistep process. + For safety's sake, this is a multi-step process. Copy /var/tmp/root/dev/MAKEDEV to /dev. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev Now, take a snapshot of your current /dev. This snapshot needs to contain the permissions, ownerships, major and minor numbers of each filename, - but it should not contain the timestamps. The easiest way to do + but it should not contain the time stamps. The easiest way to do this is to use &man.awk.1; to strip out some of the information. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Remake all the devices. &prompt.root; Write another snapshot of the directory, this time to /var/tmp/dev2.out. Now look through these two files for any devices that you missed creating. There should not be any, but it is better to be safe than sorry. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out You are most likely to notice disk slice discrepancies which will involve commands such as &prompt.root; sh MAKEDEV sd0s1 to recreate the slice entries. Your precise circumstances may vary. Update <filename>/stand</filename> - This step is included only for completeness, it can safely be + This step is included only for completeness. It can safely be omitted. - For completenesses sake you may want to update the files in + For the sake of completeness, you may want to update the files in /stand as well. These files consist of hard links to the /stand/sysinstall binary. This binary should be statically linked, so that it can work when no other filesystems (and in particular /usr) have been mounted. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install Source older than 2 April 1998 If your source code is older than 2nd April 1998, or the Makefile version is not 1.68 or higher (for FreeBSD current and 3.X systems) or 1.48.2.21 or higher (for 2.2.X systems) you will need to add the NOSHARED=yes option, like so; &prompt.root; make NOSHARED=yes all install Compile and install a new kernel To take full advantage of your new system you should recompile the kernel. This is practically a necessity, as certain memory structures may have changed, and programs like &man.ps.1; and &man.top.1; will fail to work until the kernel and source code versions are the same. Follow the handbook instructions for compiling a new kernel. If you have previously built a custom kernel then carefully examine the LINT config file to see if there are any new options which you should take advantage of. A previous version of this document suggested rebooting before rebuilding the kernel. This is wrong because: Commands like &man.ps.1;, &man.ifconfig.8;, and &man.sysctl.8; may fail. This could leave your machine unable to connect to the network. Basic utilities like &man.mount.8; could fail, making it impossible to mount /, /usr and so on. This is unlikely if you are tracking a -STABLE candidate, but more likely if you are tracking -CURRENT during a large merge. Loadable kernel modules (LKMs on pre-3.X systems, KLDs on 3.X systems and above) built as part of the world may crash an older kernel. For these reasons, it is always best to rebuild and install a new kernel before rebooting. You should build your new kernel after you have completed make world (or make installworld). If you do not want to do this (perhaps you want to confirm that the kernel builds before updating your system) you may have problems. These may be because your &man.config.8; command is out of date with respect to your kernel sources. In this case you could build your kernel with the new version of &man.config.8; &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME This may not work in all cases. It is recommended that you complete make world (or make installworld) before compiling a new kernel. You are now done. After you have verified that everything appears to be in the right place you can reboot the system. A simple &man.fastboot.8; should do it.</para> <screen>&prompt.root; <userinput>fastboot</userinput></screen> </sect2> <sect2> <title>Finished You should now have successfully upgraded your FreeBSD system. Congratulations. You may notice small problems due to things that you have missed. For example, I once deleted /etc/magic as part of the upgrade and merge to /etc, and the file command stopped working. A moment's thought meant that &prompt.root; cd /usr/src/usr.bin/file &prompt.root; was sufficient to fix that one. <qandaentry> <question> <para>Do I need to re-make the world for every change?</para> </question> <answer> <para>There is no easy answer to this one, as it depends on the nature of the change. For example, I have just run CVSup, and it has shown the following files as being updated since I last ran it;</para> <screen><filename>src/games/cribbage/instr.c</filename> <filename>src/games/sail/pl_main.c</filename> <filename>src/release/sysinstall/config.c</filename> <filename>src/release/sysinstall/media.c</filename> <filename>src/share/mk/bsd.port.mk</filename></screen> <para>There is nothing in there that I would re-make the world for. I would go to the appropriate sub-directories and <command>make all install</command>, and that's about it. But if something major changed, for example <filename>src/lib/libc/stdlib</filename> then I would either re-make the world, or at least those parts of it that are statically linked (as well as anything else I might have added that is statically linked).</para> <para>At the end of the day, it is your call. You might be happy re-making the world every fortnight say, and let changes accumulate over that fortnight. Or you might want to re-make just those things that have changed, and are confident you can spot all the dependencies.</para> <para>And, of course, this all depends on how often you want to upgrade, and whether you are tracking -STABLE or -CURRENT.</para> </answer> </qandaentry> <qandaentry> <question> <para>My compile failed with lots of signal 12 (or other signal number) errors. What has happened?</para> </question> <answer> <para>This is normally indicative of hardware problems. (Re)making the world is an effective way to stress test your hardware, and will frequently throw up memory problems. These normally manifest themselves as the compiler mysteriously dying on receipt of strange signals.</para> <para>A sure indicator of this is if you can restart the make and it dies at a different point in the process.</para> <para>In this instance there is little you can do except start swapping around the components in your machine to determine which one is failing.</para> </answer> </qandaentry> <qandaentry> <question> <para>Can I remove <filename>/usr/obj</filename> when I have finished?</para> </question> <answer> <para>That depends on how you want to make the world on future occasions.</para> <para><filename>/usr/obj</filename> contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the <quote/make world/ process is to remove this directory and start afresh. In this case, keeping <filename>/usr/obj</filename> around after you have finished makes little sense, and will free up a large chunk of disk space (currently about 150MB).</para> <para>However, if you know what you are doing you can have <quote/make world/ skip this step. This will make subsequent builds run much faster, since most of sources will not need to be recompiled. The flip side of this is that subtle dependency problems can creep in, causing your build to fail in odd ways. This frequently generates noise on the FreeBSD mailing lists, when one person complains that their build has failed, not realising that it is because they have tried to cut corners.</para> <para>If you want to live dangerously then make the world, passing the <makevar>NOCLEAN</makevar> definition to make, like this:</para> <screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen> </answer> </qandaentry> <qandaentry> <question> <para>Can interrupted builds be resumed?</para> </question> <answer> <para>This depends on how far through the process you got before you found a problem.</para> <para><emphasis>In general</emphasis> (and this is not a hard and fast rule) the <quote>make world</quote> process builds new copies of essential tools (such as &man.gcc.1;, and &man.make.1;>) and the system libraries. These tools and libraries are then installed. The new tools and libraries are then used to rebuild themselves, and are installed again. The entire system (now including regular user programs, such as &man.ls.1; or &man.grep.1;) is then rebuilt with the new system files.</para> <para>If you are at the last state, and you know it (because you have looked through the output that you were storing) then you can (fairly safely) do</para> <screen><emphasis>… fix the problem …</emphasis> &prompt.root; <userinput>cd /usr/src</userinput> &prompt.root; <userinput>make -DNOCLEAN all</userinput></screen> <para>This will not undo the work of the previous <quote>make world</quote>.</para> <para>If you see the message <screen>-------------------------------------------------------------- Building everything.. --------------------------------------------------------------</screen> in the <quote>make world</quote> output then it is probably fairly safe to do so.</para> <para>If you do not see that message, or you are not sure, then it is always better to be safe than sorry, and restart the build from scratch.</para> </answer> </qandaentry> <qandaentry> <question> <para>Can I use one machine as a <emphasis/master/ to upgrade lots of machines (NFS)?</para> </question> <answer> <para>People often ask on the FreeBSD mailing lists whether they can do all the compiling on one machine, and then use the results of that compile to <command>make install</command> on to other machines around the network.</para> <para>This is not something I have done, so the suggestions below are either from other people, or deduced from the Makefiles.</para> <para>The precise approach to take depends on your version of FreeBSD</para> <para>You must still upgrade <filename>/etc</filename> and <filename>/dev</filename> on the target machines after doing this.</para> <para>For 2.1.7 and below, Antonio Bemfica suggested the following approach:</para> <screen>Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST) From: Antonio Bemfica <bemfica@militzer.me.tuns.ca> To: freebsd-questions@FreeBSD.org Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca> Josef Karthauser asked: > Has anybody got a good method for upgrading machines on a network First make world, etc. on your main machine Second, mount / and /usr from the remote machine: main_machine% mount remote_machine:/ /mnt main_machine% mount remote_machine:/usr /mnt/usr Third, do a 'make install' with /mnt as the destination: main_machine% make install DESTDIR=/mnt Repeat for every other remote machine on your network. It works fine for me. Antonio</screen> <para>This mechanism will only work (to the best of my knowledge) if you can write to <filename>/usr/src</filename> on the NFS server, as the <maketarget>install</maketarget> target in 2.1.7 and below needed to do this.</para> <para>Midway between 2.1.7 and 2.2.0 the <quote>reinstall</quote> target was committed. You can use the approach exactly as outlined above for 2.1.7, but use <quote>reinstall</quote> instead of <quote>install</quote>.</para> <para>This approach <emphasis>does not</emphasis> require write access to the <filename>/usr/src</filename> directory on the NFS server.</para> <para>There was a bug introduced in this target between versions 1.68 and 1.107 of the Makefile, which meant that write access to the NFS server <emphasis>was</emphasis> required. This bug was fixed before version 2.2.0 of FreeBSD was released, but may be an issue of you have an old server still running -STABLE from this era.</para> <para>For version 2.2.5 and above, you can use the <quote>buildworld</quote> and <quote>installworld</quote> targets. Use them to build a source tree on one machine, and then NFS mount <filename>/usr/src</filename> and <filename>/usr/obj</filename> on the remote machine and install it there.</para> </answer> </qandaentry> <qandaentry> <question> <para>How can I speed up making the world?</para> <itemizedlist> <listitem> <para>Run in single user mode.</para> </listitem> <listitem> <para>Put the <filename>/usr/src</filename> and <filename>/usr/obj</filename> directories on separate filesystems held on separate disks. If possible, put these disks on separate disk controllers.</para> </listitem> <listitem> <para>Better still, put these filesystems across separate disks using the <quote>ccd</quote> (concatenated disk driver) device.</para> </listitem> <listitem> <para>Turn off profiling (set <quote>NOPROFILE=true</quote> in <filename>/etc/make.conf</filename>). You almost certainly do not need it.</para> </listitem> <listitem> <para>Also in <filename>/etc/make.conf</filename>, set <quote>CFLAGS</quote> to something like <quote>-O - -pipe</quote>. The optimisation <quote>-O2</quote> is much - slower, and the optimisation difference between + -pipe</quote>. The optimization <quote>-O2</quote> is much + slower, and the optimization difference between <quote>-O</quote> and <quote>-O2</quote> is normally negligible. <quote>-pipe</quote> lets the compiler use pipes rather than temporary files for communication, which saves disk access (at the expense of memory).</para> </listitem> <listitem> <para>Pass the <option>-j<n></option> option to make (if you are running a sufficiently recent version of FreeBSD) to run multiple processes in parallel. This helps regardless of whether you have a single or a multi processor machine.</para> </listitem> <listitem><para>The filesystem holding <filename>/usr/src</filename> can be mounted (or remounted) with the <quote>noatime</quote> option. This stops the time files in the filesystem were last accessed from being written to the disk. You probably do not need this information anyway. <note> <para><quote>noatime</quote> is in version 2.2.0 and above.</para> </note> <screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen> <warning> <para>The example assumes <filename>/usr/src</filename> is on its own filesystem. If it is not (if it is a part of <filename>/usr</filename> for example) then you will need to use that filesystem mount point, and not <filename>/usr/src</filename>.</para> </warning> </para> </listitem> <listitem> <para>The filesystem holding <filename>/usr/obj</filename> can be mounted (or remounted) with the <quote>async</quote> option. This causes disk writes to happen asynchronously. In other words, the write completes immediately, and the data is written to the disk a few seconds later. This allows writes to be clustered together, and can be a dramatic performance boost.</para> <warning> <para>Keep in mind that this option makes your filesystem more fragile. With this option there is an increased chance that, should power fail, the filesystem will be in an unrecoverable state when the machine restarts.</para> <para>If <filename>/usr/obj</filename> is the only thing on this filesystem then it is not a problem. If you have other, valuable data on the same filesystem then ensure your backups are fresh before you enable this option.</para> </warning> <screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen> <warning> <para>As above, if <filename>/usr/obj</filename> is not on its own filesystem, replace it in the example with the name of the appropriate mount point.</para> </warning> </listitem> </itemizedlist> </question> </qandaentry> </qandaset> </sect2> </sect1> </chapter> <!-- Local Variables: mode: sgml sgml-declaration: "../chapter.decl" sgml-indent-data: t sgml-omittag: nil sgml-always-quote-attributes: t sgml-parent-document: ("../book.sgml" "part" "chapter") End: --> diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml index 24c97212b4..bca1791fdd 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml @@ -1,882 +1,882 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml,v 1.18 2000/04/30 22:10:06 nik Exp $ + $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml,v 1.19 2000/06/08 01:56:07 jim Exp $ --> <chapter id="disks"> <title>Disks Synopsis This chapter covers how to use disks, whether physical, memory, or networked, on FreeBSD. BIOS Drive Numbering Before you install and configure FreeBSD on your system, there is an important subject that you should be aware of if, especially if you have multiple hard drives. In a PC running DOS or any of the BIOS-dependent operating systems (WINxxx), the BIOS is able to abstract the normal disk drive order, and the operating system goes along with the change. This allows the user to boot from a disk drive other than the so-called primary master. This is especially convenient for some users who have found that the simplest and cheapest way to keep a system backup is to buy an identical second hard drive, and perform routine copies of the first drive to the second drive using Ghost or XCOPY. Then, if the first drive fails, or is attacked by a virus, or is scribbled upon by an operating system defect, he can easily recover by instructing the BIOS to logically swap the drives. It's like switching the cables on the drives, but without having to open the case. More expensive systems with SCSI controllers often include BIOS extensions which allow the SCSI drives to be re-ordered in a similar fashion for up to seven drives. A user who is accustomed to taking advantage of these features may become surprised when the results with FreeBSD are not as expected. FreeBSD does not use the BIOS, and does not know the logical BIOS drive mapping. This can lead to very perplexing situations, especially when drives are physically identical in geometry, and have also been made as data clones of one another. When using FreeBSD, always restore the BIOS to natural drive numbering before installing FreeBSD, and then leave it that way. If you need to switch drives around, then do so, but do it the hard way, and open the case and move the jumpers and cables. An illustration from the files of Bill and Fred's Exceptional Adventures: - Bill breaks-down an older WIntel box to make another FreeBSD box + Bill breaks-down an older Wintel box to make another FreeBSD box for Fred. Bill installs a single SCSI drive as SCSI unit zero, and installs FreeBSD on it. Fred begins using the system, but after several days notices that the older SCSI drive is reporting numerous soft errors, and reports this fact to Bill. After several more days, Bill decides it's time to address the situation, so he grabs an identical SCSI drive from the disk drive "archive" in the back room. An initial surface scan indicates that this drive is functioning well, so Bill installs this drive as SCSI unit four, and makes an image copy from drive zero to drive four. Now that the new drive is installed and functioning nicely, Bill decides that it's a good idea to start using it, so he uses features in the SCSI BIOS to re-order the disk drives so that the system boots from SCSI unit four. FreeBSD boots and runs just fine. Fred continues his work for several days, and soon Bill and Fred decide that it's time for a new adventure -- time to upgrade to a newer version of FreeBSD. Bill removes SCSI unit zero because it was - a bit flakey, and replaces it with another identical disk drive from + a bit flaky, and replaces it with another identical disk drive from the "archive." Bill then installs the new version of FreeBSD onto the new SCSI unit zero using Fred's magic internet FTP floppies. The installation goes well. Fred uses the new version of FreeBSD for a few days, and certifies that it is good enough for use in the engineering department...it's time to copy all of his work from the old version. So Fred mounts SCSI unit four (the latest copy of the older FreeBSD version). Fred is dismayed to find that none of his precious work is present on SCSI unit four. Where did the data go? When Bill made an image copy of the original SCSI unit zero onto SCSI unit four, unit four became the "new clone," When Bill re-ordered the SCSI BIOS so that he could boot from SCSI unit four, he was only fooling himself. FreeBSD was still running on SCSI unit zero. Making this kind of BIOS change will cause some or all of the Boot and Loader code to be fetched from the selected BIOS drive, but when the FreeBSD kernel drivers take-over, the BIOS drive numbering will be ignored, and FreeBSD will transition back to normal drive numbering. In the illustration at hand, the system continued to operate on the original SCSI unit zero, and all of Fred's data was there, not on SCSI unit four. The fact that the system appeared to be running on SCSI unit four was simply an artifact of human expectations. We are delighted to mention that no data bytes were killed or harmed in any way by our discovery of this phenomenon. The older SCSI - unit zero was retrieved from the bonepile, and all of Fred's work was + unit zero was retrieved from the bone pile, and all of Fred's work was returned to him, (and now Bill knows that he can count as high as zero). Although SCSI drives were used in this illustration, the concepts apply equally to IDE drives. Disk Naming - Physical drives come in two main flavours, + Physical drives come in two main flavors, IDE, or SCSI; but there are also drives backed by RAID controllers, flash memory, and so forth. Since these behave quite differently, they have their own drivers and devices. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad in 4.0-RELEASE, wd before 4.0-RELEASE. IDE CDROM drives acd in 3.1-RELEASE, wcd before 4.0-RELEASE. SCSI hard drives da from 3.0-RELEASE, sd before 3.0-RELEASE. SCSI CDROM drives cd Assorted non-standard CDROM drives mcd for Mitsumi CD-ROM, scd for Sony CD-ROM, matcd for Matsushita/Panasonic CD-ROM Floppy drives fd SCSI tape drives sa from 3.0-RELEASE, st before 3.0-RELEASE. IDE tape drives ast from 4.0-RELEASE, wst before 4.0-RELEASE. Flash drives fla for DiskOnChip Flash device from 3.3-RELEASE. RAID drives myxd for Mylex, and amrd for AMI MegaRAID, idad for Compaq Smart RAID. from 4.0-RELEASE. id between 3.2-RELEASE and 4.0-RELEASE.
Slices and Partitions Physical disks usually contain slices, unless they are dangerously dedicated. Slice numbers follow the device name, prefixed with an s: da0s1. Slices, dangerously dedicated physical drives, and other drives contain partitions, which represented as letters from a to h. b is reserved for swap partitions, and c is an unused partition the size of the entire slice or drive. This is explained in . Mounting and Unmounting Filesystems The filesystem is best visualized as a tree, rooted, as it were, at /. /dev, /usr, and the other directories in the root directory are branches, which may have their own branches, such as /usr/local, and so on. There are various reasons to house certain of these directories on separate filesystems. /var contains log, spool, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem isn't a good idea, so splitting /var from / is often a good idea. Another common reason to contain certain directory trees on other filesystems is if they are to be housed on separate physical disks, or are separate virtual disks, such as Network File System mounts, or CDROM drives. The fstab File During the boot process, filesystems listed in /etc/fstab are automatically mounted (unless they are listed with ). The /etc/fstab file contains a list of lines of the following format: device /mount-point fstype options dumpfreq passno device is a device name (which should exist), as explained in the Disk naming conventions above. mount-point is a directory (which should exist), on which to mount the filesystem. fstype is the filesystem type to pass to &man.mount.8;. The default FreeBSD filesystem is ufs. options is either for read-write filesystems, or for read-only filesystems, followed by any other options that may be needed. A common option is for filesystems not normally mounted during the boot sequence. Other options in the &man.mount.8; manual page. dumpfreq is the number of days the filesystem should be dumped, and passno is the pass number during which the filesystem is mounted during the boot sequence. The mount Command The &man.mount.8; command is what is ultimately used to mount filesystems. In its most basic form, you use: &prompt.root; mount device mountpoint There are plenty of options, as mentioned in the &man.mount.8; manual page, but the most common are: mount options Mount all filesystems in /etc/fstab, as modified by , if given. Do everything but actually mount the filesystem. Force the mounting the filesystem. Mount the filesystem read-only. fstype Mount the given filesystem as the given filesystem type, or mount only filesystems of the given type, if given the option. ufs is the default filesystem type. Update mount options on the filesystem. Be verbose. Mount the filesystem read-write. The takes a comma-separated list of the options, including the following: nodev Do not interpret special devices on the filesystem. Useful security option. noexec Do not allow execution of binaries on this filesystem. Useful security option. nosuid Do not interpret setuid or setgid flags on the filesystem. Useful security option. The umount Command The umount command takes, as a parameter, one of a mountpoint, a device name, or the or option. All forms take to force unmounting, and for verbosity. and are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after . , however, doesn't attempt to unmount the root filesystem. Adding Disks Originally contributed by &a.obrien; 26 April 1998 Lets say we want to add a new SCSI disk to a machine that currently only has a single drive. First turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturer. Due the wide variations of procedures to do this, the details are beyond the scope of this document. Login as user root. After you've installed the drive, inspect /var/run/dmesg.boot to ensure the new disk was found. Continuing with our example, the newly added drive will be da1 and we want to mount it on /1. (if you are adding an IDE drive substitute wd for da) Because FreeBSD runs on IBM-PC compatible computers, it must take into account the PC BIOS partitions. These are different from the traditional BSD partitions. A PC disk has up to four BIOS partition entries. If the disk is going to be truly dedicated to FreeBSD, you can use the dedicated mode. Otherwise, FreeBSD will have to live with in one of the PC BIOS partitions. FreeBSD calls the PC BIOS partitions, slices so as not to confuse them with traditional BSD partitions. You may also use slices on a disk that is dedicated to FreeBSD, but used in a computer that also has another operating system installed. This is to not confuse the fdisk utility of the other operating system. In the slice case the drive will be added as /dev/da1s1e. This is read as: SCSI disk, unit number 1 (second SCSI disk), slice 1 (PC BIOS partition 1), and e BSD partition. In the dedicated case, the drive will be added simply as /dev/da1e. Using sysinstall You may use /stand/sysinstall to partition and label a new disk using its easy to use menus. Either login as user root or use the su command. Run /stand/sysinstall and enter the Configure menu. With in the FreeBSD Configuration Menu, scroll down and select the Partition item. Next you should be presented with a list of hard drives installed in your system. If you do not see da1 listed, you need to recheck your physical installation and dmesg output in the file /var/run/dmesg.boot. Select da1 to enter the FDISK Partition Editor. Choose A to use the entire disk for FreeBSD. When asked if you want to remain cooperative with any future possible operating systems, answer YES. Write the changes to the disk using W. Now exit the FDISK editor using q. Next you will be asked about the Master Boot Record. Since you are adding a disk to an already running system, choose None. Next enter the Disk Label Editor. This is where you will create the traditional BSD partitions. A disk can have up to eight partitions, labeled a-h. A few of the partition labels have special uses. The a partition is used for the root partition (/). Thus only your system disk (e.g, the disk you boot from) should have an a partition. The b partition is used for swap partitions, and you may have many disks with swap partitions. The c partition addresses the entire disk in dedicated mode, or the entire FreeBSD slice in slice mode. The other partitions are for general use. Sysinstall's Label editor favors the e partition for non-root, non-swap partitions. With in the Label editor, create a single file system using C. When prompted if this will be a FS (file system) or swap, choose FS and give a mount point (e.g, /mnt). When adding a disk in post-install mode, Sysinstall will not create entries in /etc/fstab for you, so the mount point you specify isn't important. You are now ready to write the new label to the disk and create a file system on it. Do this by hitting W. Ignore any errors from Sysinstall that it could not mount the new partition. Exit the Label Editor and Sysinstall completely. The last step is to edit /etc/fstab to add an entry for your new disk. Using Command Line Utilities * Using Slices Dedicated If you will not be sharing the new drive with another operating system, you may use the dedicated mode. Remember this mode can confuse Microsoft operating systems; however, no damage will be done by them. IBM's OS/2 however, will appropriate any partition it finds which it doesn't understand. &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; disklabel -Brw da1 auto &prompt.root; disklabel -e da1 # create the `e' partition &prompt.root; newfs -d0 /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 An alternate method is: &prompt.root; dd if=/dev/zero of=/dev/rda1 count=2 &prompt.root; disklabel /dev/rda1 | disklabel -BrR da1 /dev/stdin &prompt.root; newfs /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 Virtual Disks: Network, Memory, and File-Based Filesystems Besides the disks you physically insert into your computer; floppies, CDs, hard drives, and so forth, other forms of disks are understood by FreeBSD - the virtual disks. These include network filesystems such as the Network Filesystem and Coda, memory-based filesystems such as md and file-backed filesystems created by vnconfig. vnconfig: file-backed filesystem &man.vnconfig.8; configures and enables vnode pseudo disk devices. A vnode is a representation of a file, and is the focus of file activity. This means that &man.vnconfig.8; uses files to create and operate a filesystem. One possible use is the mounting of floppy or CD images kept in files. To mount an existing filesystem image: Using vnconfig to mount an existing filesystem image &prompt.root; vnconfig vn0 diskimage &prompt.root; mount /dev/vn0c /mnt To create a new filesystem image with vnconfig: Creating a New File-Backed Disk with vnconfig &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; vnconfig -s labels -c vn0 newimage &prompt.root; disklabel -r -w vn0 auto &prompt.root; newfs vn0c Warning: 2048 sector(s) in last cylinder unallocated /dev/rvn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors 5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g) super-block backups (for fsck -b #) at: 32 &prompt.root; mount /dev/vn0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 4927 1 4532 0% /mnt md: Memory Filesystem md is a simple, efficient means to do memory filesystems. Simply take a filesystem you've prepared with, for example, &man.vnconfig.8;, and: md memory disk &prompt.root; dd if=newimage of=/dev/md0 5120+0 records in 5120+0 records out &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4927 1 4532 0% /mnt Disk Quotas Quotas are an optional feature of the operating system that allow you to limit the amount of disk space and/or the number of files a user, or members of a group, may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This will prevent one user from consuming all of the available disk space. Configuring Your System to Enable Disk Quotas Before attempting to use disk quotas it is necessary to make sure that quotas are configured in your kernel. This is done by adding the following line to your kernel configuration file: options QUOTA The stock GENERIC kernel does not have this enabled by default, so you will have to configure, build and install a custom kernel in order to use disk quotas. Please refer to the Configuring the FreeBSD Kernel section for more information on kernel configuration. Next you will need to enable disk quotas in /etc/rc.conf. This is done by adding the line: enable_quotas=YES For finer control over your quota startup, there is an additional configuration variable available. Normally on bootup, the quota integrity of each file system is checked by the quotacheck program. The quotacheck facility insures that the data in the quota database properly reflects the data on the file system. This is a very time consuming process that will significantly affect the time your system takes to boot. If you would like to skip this step, a variable is made available for the purpose: check_quotas=NO If you are running FreeBSD prior to 3.2-RELEASE, the configuration is simpler, and consists of only one variable. Set the following in your /etc/rc.conf: check_quotas=YES Finally you will need to edit /etc/fstab to enable disk quotas on a per-file system basis. This is where you can either enable user or group quotas or both for all of your file systems. To enable per-user quotas on a file system, add the userquota option to the options field in the /etc/fstab entry for the file system you want to to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 Similarly, to enable group quotas, use the groupquota option instead of the userquota keyword. To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default the quota files are stored in the root directory of the file system with the names quota.user and quota.group for user and group quotas respectively. See man fstab for more information. Even though that man page says that you can specify an alternate location for the quota files, this is not recommended because the various quota utilities do not seem to handle this properly. At this point you should reboot your system with your new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas you enabled in /etc/fstab, so there is no need to manually create any zero length quota files. In the normal course of operations you should not be required to run the quotacheck, quotaon, or quotaoff commands manually. However, you may want to read their man pages just to be familiar with their operation. Setting Quota Limits Once you have configured your system to enable quotas, verify that they really are enabled. An easy way to do this is to run: &prompt.root; quota -v You should see a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. You are now ready to start assigning quota limits with the edquota command. You have several options on how to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. You may limit allocations based on disk space (block quotas) or number of files (inode quotas) or a combination of both. Each of these limits are further broken down into two categories; hard and soft limits. A hard limit may not be exceeded. Once a user reaches their hard limit they may not make any further allocations on the file system in question. For example, if the user has a hard limit of 500 blocks on a file system and is currently using 490 blocks, the user can only allocate an additional 10 blocks. Attempting to allocate an additional 11 blocks will fail. Soft limits on the other hand can be exceeded for a limited amount of time. This period of time is known as the grace period, which is one week by default. If a user stays over his or her soft limit longer than their grace period, the soft limit will turn into a hard limit and no further allocations will be allowed. When the user drops back below the soft limit, the grace period will be reset. The following is an example of what you might see when you run the edquota command. When the edquota command is invoked, you are placed into the editor specified by the EDITOR environment variable, or in the vi editor if the EDITOR variable is not set, to allow you to edit the quota limits. &prompt.root; edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) You will normally see two lines for each file system that has quotas enabled. One line for the block limits, and one line for inode limits. Simply change the value you want updated to modify the quota limit. For example, to raise this users block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: blocks in use: 65, limits (soft = 50, hard = 75) to: /usr: blocks in use: 65, limits (soft = 500, hard = 600) The new quota limits will be in place when you exit the editor. Sometimes it is desirable to set quota limits on a range of uids. This can be done by use of the option on the edquota command. First, assign the desired quota limit to a user, and then run edquota -p protouser startuid-enduid. For example, if user test has the desired quota limits, the following command can be used to duplicate those quota limits for uids 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 See man edquota for more detailed information. Checking Quota Limits and Disk Usage You can use either the quota or the repquota commands to check quota limits and disk usage. The quota command can be used to check individual user and group quotas and disk usage. Only the super-user may examine quotas and usage for other users, or for groups that they are not a member of. The repquota command can be used to get a summary of all quotas and disk usage for file systems with quotas enabled. The following is some sample output from the quota -v command for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 On the /usr file system in the above example this user is currently 15 blocks over their soft limit of 50 blocks and has 5 days of their grace period left. Note the asterisk * which indicates that the user is currently over their quota limit. Normally file systems that the user is not using any disk space on will not show up in the output from the quota command, even if they have a quota limit assigned for that file system. The option will display those file systems, such as the /usr/var file system in the above example. Quotas over NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to the &man.quota.1; command on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; kill -HUP `cat /var/run/inetd.pid` diff --git a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml index 4a90d4b5d9..739d6adc18 100644 --- a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,1454 +1,1454 @@ Resources on the Internet Contributed by &a.jkh;. The rapid pace of FreeBSD progress makes print media impractical as a means of following the latest developments. Electronic resources are the best, if not often the only, way stay informed of the latest advances. Since FreeBSD is a volunteer effort, the user community itself also generally serves as a technical support department of sorts, with electronic mail and USENET news being the most effective way of reaching that community. The most important points of contact with the FreeBSD user community are outlined below. If you are aware of other resources not mentioned here, please send them to the &a.doc;so that they may also be included. Mailing Lists Though many of the FreeBSD development members read USENET, we cannot always guarantee that we will get to your questions in a timely fashion (or at all) if you post them only to one of the comp.unix.bsd.freebsd.* groups. By addressing your questions to the appropriate mailing list you will reach both us and a concentrated FreeBSD audience, invariably assuring a better (or at least faster) response. The charters for the various lists are given at the bottom of this document. Please read the charter before joining or sending mail to any list. Most of our list subscribers now receive many hundreds of FreeBSD related messages every day, and by setting down charters and rules for proper use we are striving to keep the signal-to-noise ratio of the lists high. To do less would see the mailing lists ultimately fail as an effective communications medium for the project. Archives are kept for all of the mailing lists and can be searched using the FreeBSD World Wide Web server. The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question. List Summary General lists: The following are general lists which anyone is free (and encouraged) to join: List Purpose freebsd-advocacy FreeBSD Evangelism freebsd-announce Important events and project milestones freebsd-arch Architecture and design discussions freebsd-bugs Bug reports freebsd-chat Non-technical items related to the FreeBSD community freebsd-current Discussion concerning the use of FreeBSD-current freebsd-isp Issues for Internet Service Providers using FreeBSD freebsd-jobs FreeBSD employment and consulting opportunities freebsd-newbies New FreeBSD users activities and discussions freebsd-policy FreeBSD Core team policy decisions. Low volume, and read-only freebsd-questions User questions and technical support freebsd-stable Discussion concerning the use of FreeBSD-stable Technical lists: The following lists are for technical discussion. You should read the charter for each list carefully before joining or sending mail to one as there are firm guidelines for their use and content. List Purpose freebsd-afs Porting AFS to FreeBSD freebsd-alpha Porting FreeBSD to the Alpha freebsd-database Discussing database use and development under FreeBSD freebsd-doc Creating FreeBSD related documents freebsd-emulation Emulation of other systems such as Linux/DOS/Windows freebsd-fs Filesystems freebsd-hackers General technical discussion freebsd-hardware General discussion of hardware for running FreeBSD freebsd-i18n FreeBSD Internationalization freebsd-ipfw Technical discussion concerning the redesign of the IP firewall code freebsd-isdn ISDN developers freebsd-java Java developers and people porting JDKs to FreeBSD freebsd-mobile Discussions about mobile computing freebsd-mozilla Porting mozilla to FreeBSD freebsd-net Networking discussion and TCP/IP/source code freebsd-platforms Concerning ports to non-Intel architecture platforms freebsd-ports Discussion of the ports collection freebsd-ppc Porting FreeBSD to the PowerPC freebsd-scsi The SCSI subsystem freebsd-security Security issues freebsd-security-notifications Security notifications freebsd-small Using FreeBSD in embedded applications freebsd-smp Design discussions for [A]Symmetric MultiProcessing freebsd-sparc Porting FreeBSD to Sparc systems freebsd-tokenring Support Token Ring in FreeBSD Limited lists: The following lists are for more specialized (and demanding) audiences and are probably not of interest to the general public. It is also a good idea to establish a presence in the technical lists before joining one of these limited lists so that you'll understand the communications etiquette involved. List Purpose freebsd-core FreeBSD core team freebsd-hubs People running mirror sites (infrastructural support) freebsd-install Installation development freebsd-user-groups User group coordination freebsd-www Maintainers of www.freebsd.org CVS lists: The following lists are for people interested in seeing the log messages for changes to various areas of the source tree. They are Read-Only lists and should not have mail sent to them. List Source area Area Description (source for) cvs-all /usr/src All changes to the tree (superset) How to Subscribe All mailing lists live on FreeBSD.org, so to post to a given list you simply mail to <listname@FreeBSD.org>. It will then be redistributed to mailing list members world-wide. To subscribe to a list, send mail to &a.majordomo; and include subscribe <listname> [<optional address>] in the body of your message. For example, to subscribe yourself to freebsd-announce, you'd do: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D If you want to subscribe yourself under a different name, or submit a subscription request for a local mailing list (this is more efficient if you have several interested parties at one site, and highly appreciated by us!), you would do something like: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@somesite.com ^D Finally, it is also possible to unsubscribe yourself from a list, get a list of other list members or see the list of mailing lists again by sending other types of control messages to majordomo. For a complete list of available commands, do this: &prompt.user; mail majordomo@FreeBSD.org help ^D Again, we would like to request that you keep discussion in the technical mailing lists on a technical track. If you are only interested in important announcements then it is suggested that you join freebsd-announce, which is intended only for infrequent traffic. List Charters All FreeBSD mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result in two (2) written warnings from the FreeBSD Postmaster postmaster@FreeBSD.org, after which, on a third offense, the poster will removed from all FreeBSD mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: The topic of any posting should adhere to the basic charter of the list it is posted to, e.g. if the list is about technical issues then your posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the freebsd-chat freebsd-chat@FreeBSD.org mailing list is freely available and should be used instead. No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say "-stable & -scsi"), there really is no reason to post to more than one list at a time. If a message is sent to you in such a - way that multiple mailing lists appear on the Cc line then the cc + way that multiple mailing lists appear on the Cc line then the Cc line should also be trimmed before sending it out again. You are still responsible for your own cross-postings, no matter who the originator might have been. Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. Advertising of non-FreeBSD related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. Individual list charters: FREEBSD-AFS Andrew File System This list is for discussion on porting and using AFS from CMU/Transarc FREEBSD-ANNOUNCE Important events / milestones This is the mailing list for people interested only in occasional announcements of significant FreeBSD events. This includes announcements about snapshots and other releases. It contains announcements of new FreeBSD capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. FREEBSD-ARCH Architecture and design discussions This is a moderated list for discussion of FreeBSD architecture. Messages will mostly be kept technical in nature, with (rare) exceptions for other messages the moderator deems need to reach all the subscribers of the list. Examples of suitable topics; How to re-vamp the build system to have several customized builds running at the same time. What needs to be fixed with VFS to make Heidemann layers work. How do we change the device driver interface to be able to use the ame drivers cleanly on many buses and architectures? How do I write a network driver? The moderator reserves the right to do minor editing (spell-checking, grammar correction, trimming) of messages that are posted to the list. The volume of the list will be kept low, which may involve having to delay topics until an active discussion has been resolved. FREEBSD-BUGS Bug reports This is the mailing list for reporting bugs in FreeBSD Whenever possible, bugs should be submitted using the &man.send-pr.1; command or the WEB interface to it. FREEBSD-CHAT Non technical items related to the FreeBSD community This list contains the overflow from the other lists about non-technical, social information. It includes discussion about whether Jordan looks like a toon ferret or not, whether or not to type in capitals, who is drinking too much coffee, where the best beer is brewed, who is brewing beer in their basement, and so on. Occasional announcements of important events (such as upcoming parties, weddings, births, new jobs, etc) can be made to the technical lists, but the follow ups should be directed to this -chat list. FREEBSD-CORE FreeBSD core team This is an internal mailing list for use by the core members. Messages can be sent to it when a serious FreeBSD-related matter requires arbitration or high-level scrutiny. FREEBSD-CURRENT Discussions about the use of FreeBSD-current This is the mailing list for users of freebsd-current. It includes warnings about new features coming out in -current that will affect the users, and instructions on steps that must be taken to remain -current. Anyone running current must subscribe to this list. This is a technical mailing list for which strictly technical content is expected. FREEBSD-CURRENT-DIGEST Discussions about the use of FreeBSD-current This is the digest version of the freebsd-current mailing list. The digest consists of all messages sent to freebsd-current bundled together and mailed out as a single message. The average digest size is about 40kB. This list is Read-Only and should not be posted to. FREEBSD-DOC Documentation project This mailing list is for the discussion of issues and projects related to the creation of documentation for FreeBSD. The members of this mailing list are collectively referred to as The FreeBSD Documentation Project. It is an open list; feel free to join and contribute! FREEBSD-FS Filesystems Discussions concerning FreeBSD filesystems. This is a technical mailing list for which strictly technical content is expected. FREEBSD-IPFW IP Firewall This is the forum for technical discussions concerning the redesign of the IP firewall code in FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-ISDN ISDN Communications This is the mailing list for people discussing the development of ISDN support for FreeBSD. FREEBSD-JAVA Java Development This is the mailing list for people discussing the development of significant Java applications for FreeBSD and the porting and maintenance of JDKs. FREEBSD-HACKERS Technical discussions This is a forum for technical discussions related to FreeBSD. This is the primary technical mailing list. It is for individuals actively working on FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. This is a technical mailing list for which strictly technical content is expected. FREEBSD-HACKERS-DIGEST Technical discussions This is the digest version of the freebsd-hackers mailing list. The digest consists of all messages sent to freebsd-hackers bundled together and mailed out as a single message. The average digest size is about 40kB. This list is Read-Only and should not be posted to. FREEBSD-HARDWARE General discussion of FreeBSD hardware General discussion about the types of hardware that FreeBSD runs on, various problems and suggestions concerning what to buy or avoid. FREEBSD-HUBS Mirror sites Announcements and discussion for people who run FreeBSD mirror sites. FREEBSD-INSTALL Installation discussion This mailing list is for discussing FreeBSD installation development for the future releases. FREEBSD-ISP Issues for Internet Service Providers This mailing list is for discussing topics relevant to Internet Service Providers (ISPs) using FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-NEWBIES Newbies activities discussion We cover any of the activities of newbies that are not already dealt with elsewhere, including: independent learning and problem solving techniques, finding and using resources and asking for help elsewhere, how to use mailing lists and which lists to use, general chat, making mistakes, boasting, sharing ideas, stories, moral (but not technical) support, and taking an active part in the FreeBSD community. We take our problems and support questions to freebsd-questions, and use freebsd-newbies to meet others who are doing the same things that we do as newbies. FREEBSD-PLATFORMS Porting to Non-Intel platforms Cross-platform FreeBSD issues, general discussion and proposals for non-Intel FreeBSD ports. This is a technical mailing list for which strictly technical content is expected. FREEBSD-POLICY Core team policy decisions This is a low volume, read-only mailing list for FreeBSD Core Team Policy decisions. FREEBSD-PORTS Discussion of ports Discussions concerning FreeBSD's ports collection (/usr/ports), proposed ports, modifications to ports collection infrastructure and general coordination efforts. This is a technical mailing list for which strictly technical content is expected. FREEBSD-QUESTIONS User questions This is the mailing list for questions about FreeBSD. You should not send how to questions to the technical lists unless you consider the question to be pretty technical. FREEBSD-QUESTIONS-DIGEST User questions This is the digest version of the freebsd-questions mailing list. The digest consists of all messages sent to freebsd-questions bundled together and mailed out as a single message. The average digest size is about 40kB. FREEBSD-SCSI SCSI subsystem This is the mailing list for people working on the scsi subsystem for FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-SECURITY Security issues FreeBSD computer security issues (DES, Kerberos, known security holes and fixes, etc). This is a technical mailing list for which strictly technical content is expected. FREEBSD-SECURITY-NOTIFICATIONS Security Notifications Notifications of FreeBSD security problems and fixes. This is not a discussion list. The discussion list is FreeBSD-security. FREEBSD-SMALL This list discusses topics related to unusually small and embedded FreeBSD installations. This is a technical mailing list for which strictly technical content is expected. FREEBSD-STABLE Discussions about the use of FreeBSD-stable This is the mailing list for users of freebsd-stable. It includes warnings about new features coming out in -stable that will affect the users, and instructions on steps that must be taken to remain -stable. Anyone running stable should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. FREEBSD-USER-GROUPS User Group Coordination List This is the mailing list for the coordinators from each of the local area Users Groups to discuss matters with each other and a designated individual from the Core Team. This mail list should be limited to meeting synopsis and coordination of projects that span User Groups. Usenet Newsgroups In addition to two FreeBSD specific newsgroups, there are many others in which FreeBSD is discussed or are otherwise relevant to FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.edu.au. BSD Specific Newsgroups comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc Other Unix Newsgroups of Interest comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Servers http://www.FreeBSD.org/ — Central Server. http://www.au.FreeBSD.org/ — Australia/1. http://www2.au.FreeBSD.org/ — Australia/2. http://www3.au.FreeBSD.org/ — Australia/3. http://freebsd.itworks.com.au/ — Australia/4. http://www.br.FreeBSD.org/www.freebsd.org/ — Brazil/1. http://www2.br.FreeBSD.org/www.freebsd.org/ — Brazil/2. http://www3.br.FreeBSD.org/ — Brazil/3. http://www.bg.FreeBSD.org/ — Bulgaria. http://www.ca.FreeBSD.org/ — Canada/1. http://www2.ca.FreeBSD.org/ — Canada/2. http://www3.ca.FreeBSD.org/ — Canada/3. http://www.cn.FreeBSD.org/ — China. http://www.cz.FreeBSD.org/ — Czech Republic/1. http://www2.cz.FreeBSD.org/ — Czech Republic/2. http://www.dk.FreeBSD.org/ — Denmark. http://www.ee.FreeBSD.org/ — Estonia. http://www.fi.FreeBSD.org/ — Finland. http://www.fr.FreeBSD.org/ — France. http://www.de.FreeBSD.org/ — Germany/1. http://www1.de.FreeBSD.org/ — Germany/2. http://www2.de.FreeBSD.org/ — Germany/3. http://www.gr.FreeBSD.org/ — Greece. http://www.hu.FreeBSD.org/ — Hungary. http://www.is.FreeBSD.org/ — Iceland. http://www.ie.FreeBSD.org/ — Ireland. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Japan. http://www.kr.FreeBSD.org/ — Korea/1. http://www2.kr.FreeBSD.org/ — Korea/2. http://www.lv.FreeBSD.org/ — Latvia. http://rama.asiapac.net/freebsd/ — Malaysia. http://www.nl.FreeBSD.org/ — Netherlands/1. http://www2.nl.FreeBSD.org/ — Netherlands/2. http://www.no.FreeBSD.org/ — Norway. http://www.nz.FreeBSD.org/ — New Zeland. + url="http://www.nz.FreeBSD.org/">http://www.nz.FreeBSD.org/ — New Zealand. http://www.pl.FreeBSD.org/ — Poland/1. http://www2.pl.FreeBSD.org/ — Poland/2. http://www.pt.FreeBSD.org/ — Portugal/1. http://www2.pt.FreeBSD.org/ — Portugal/2. http://www3.pt.FreeBSD.org/ — Portugal/3. http://www.ro.FreeBSD.org/ — Romania. http://www.ru.FreeBSD.org/ — Russia/1. http://www2.ru.FreeBSD.org/ — Russia/2. http://www3.ru.FreeBSD.org/ — Russia/3. http://www4.ru.FreeBSD.org/ — Russia/4. http://freebsd.s1web.com/ — Singapore. http://www.sk.FreeBSD.org/ — Slovak Republic. http://www.si.FreeBSD.org/ — Slovenia. http://www.es.FreeBSD.org/ — Spain. http://www.za.FreeBSD.org/ — South Africa/1. http://www2.za.FreeBSD.org/ — South Africa/2. http://www.se.FreeBSD.org/ — Sweden. http://www.ch.FreeBSD.org/ — Switzerland. http://www.tw.FreeBSD.org/www.freebsd.org/data/ — Taiwan. http://www.tr.FreeBSD.org/ — Turkey. http://www.ua.FreeBSD.org/www.freebsd.org/ — Ukraine/1. http://www2.ua.FreeBSD.org/ — Ukraine/2. http://www4.ua.FreeBSD.org/ — Ukraine/Crimea. http://www.uk.FreeBSD.org/ — United Kingdom. http://www6.FreeBSD.org/ — USA/Oregon. http://www2.FreeBSD.org/ — USA/Texas. Email Addresses The following user groups provide FreeBSD related email addresses for their members. The listed administrator reserves the right to revoke the address if it is abused in any way. Domain Facilities User Group Administrator ukug.uk.FreeBSD.org Forwarding only freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Shell Accounts The following user groups provide shell accounts for people who are actively supporting the FreeBSD project. The listed administrator reserves the right to cancel the account if it is abused in any way. Host Access Facilities Administrator storm.uk.FreeBSD.org - ssh only - Read-only cvs, personal webspace, email + SSH only + Read-only cvs, personal web space, email &a.brian dogma.freebsd-uk.eu.org Telnet/FTP/SSH - E-Mail, Webspace, Anonymous FTP + E-Mail, Web space, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/en_US.ISO8859-1/books/handbook/hw/chapter.sgml b/en_US.ISO8859-1/books/handbook/hw/chapter.sgml index b2f9347a91..06c7ea9e2e 100644 --- a/en_US.ISO8859-1/books/handbook/hw/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/hw/chapter.sgml @@ -1,5874 +1,5872 @@ PC Hardware compatibility 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 commodity 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. You may also want to refer to the kernel configuration file section in this handbook for a list of supported devices. 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 e-mail to the &a.doc;. Questions about supported hardware should be directed to the &a.questions; (see 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. Resources on the Internet The following links have proven useful in selecting hardware. Though some of what you see won't necessarily be specific (or even applicable) to FreeBSD, most of the hardware information out there is OS independent. Please check with the FreeBSD hardware guide to make sure that your chosen configuration is supported before making any purchases. The Pentium Systems Hardware Performance Guide Sample Configurations The following list of sample hardware configurations by no means constitutes an endorsement of a given hardware vendor or product by The FreeBSD Project. This information is provided only as a public service and merely catalogs some of the experiences that various individuals have had with different hardware combinations. Your mileage may vary. Slippery when wet. Beware of dog. Jordan's Picks I have had fairly good luck building workstation and server configurations with the following components. I can't guarantee that you will too, nor that any of the companies here will remain best buys forever. I will try, when I can, to keep this list up-to-date but cannot obviously guarantee that it will be at any given time. Motherboards For Pentium Pro (P6) systems, I'm quite fond of the Tyan S1668 dual-processor motherboard as well as the Intel PR440FX motherboard - with on-board SCSI WIDE and 100/10MB Intel Etherexpress NIC. You + with on-board SCSI WIDE and 100/10MB Intel EtherExpress NIC. You can build a dandy little single or dual processor system (which is supported in FreeBSD 3.0) for very little cost now that the Pentium Pro 180/256K chips have fallen so greatly in price, but no telling how much longer this will last. For the Pentium II, I'm rather partial to the ASUS P2l97-S motherboard with the on-board Adaptec SCSI WIDE controller. For Pentium machines, the ASUS P55T2P4 motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems. Those wishing to build more fault-tolerant systems should also be sure to use Parity memory or, for truly 24/7 applications, ECC memory. ECC memory does involve a slight performance trade-off (which may or may not be noticeable depending on your application) but buys you significantly increased fault-tolerance to memory errors. Disk Controllers This one is a bit trickier, and while I used to recommend the Buslogic controllers unilaterally for everything from ISA to PCI, now I tend to lean towards the Adaptec 1542CF for ISA, Buslogic Bt747c for EISA and Adaptec 2940UW for PCI. The NCR/Symbios cards for PCI have also worked well for me, though you need to make sure that your motherboard supports the BIOS-less model if you're using one of those (if your card has nothing which looks even vaguely like a ROM chip on it, you've probably got one which expects its BIOS to be on your motherboard). If you should find that you need more than one SCSI controller in a PCI machine, you may wish to consider conserving your scarce PCI bus resources by buying the Adaptec 3940 card, which puts two SCSI controllers (and internal busses) in a single slot. There are two types of 3940 on the market—the older model with AIC 7880 chips on it, and the newer one with AIC 7895 chips. The newer model requires CAM support which is not yet part of FreeBSD—you have to add it, or install from one of the CAM binary snapshot release. Disk drives In this particular game of Russian roulette, I'll make few specific recommendations except to say SCSI over IDE whenever you can afford it. Even in small desktop configurations, SCSI often makes more sense since it allows you to easily migrate drives from server to desktop as falling drive prices make it economical to do so. If you have more than one machine to administer then think of it not simply as storage, think of it as a food chain! For a serious server configuration, there's not even any argument—use SCSI equipment and good cables. CDROM drives My SCSI preferences extend to SCSI CDROM drives as well, and while the Toshiba drives - have always been favourites of mine (in whatever speed is hot that + have always been favorites of mine (in whatever speed is hot that week), I'm still fond of my good old Plextor PX-12CS drive. It's only a 12 speed, but it's offered excellent performance and reliability. Generally speaking, most SCSI CDROM drives I've seen have been of pretty solid construction and you probably won't go wrong with an HP or NEC SCSI CDROM drive either. SCSI CDROM prices also appear to have dropped considerably in the last few months and are now quite competitive with IDE CDROMs while remaining a technically superior solution. I now see no reason whatsoever to settle for an IDE CDROM drive if given a choice between the two. CD Recordable (WORM) drives At the time of this writing, FreeBSD supports 3 types of CDR drives (though I believe they all ultimately come from Phillips anyway): The Phillips CDD 522 (Acts like a Plasmon), the PLASMON RF4100 and the HP 6020i. I myself use the HP 6020i for burning CDROMs (in 2.2 and alter releases—it does not work with earlier releases of the SCSI code) and it works very well. See /usr/share/examples/worm on your 2.2 system for example scripts used to created ISO9660 filesystem images (with RockRidge extensions) and burn them onto an HP6020i CDR. Tape drives I've had pretty good luck with both 8mm drives from Exabyte and 4mm (DAT) drives from HP. For backup purposes, I'd have to give the higher recommendation to the Exabyte due to the more robust nature (and higher storage capacity) of 8mm tape. Video Cards If you can also afford to buy a commercial X server for US$99 from Xi Graphics, Inc. (formerly X Inside, Inc) then I can heartily recommend the Matrox Millenium II card. Note that support for this card is also excellent with the XFree86 server, which is now at version 3.3.2. You also certainly can't go wrong with one of Number 9's cards — their S3 Vision 868 and 968 based cards (the 9FX series) also being quite fast and very well supported by XFree86's S3 server. You can also pick up their Revolution 3D cards very cheaply these days, especially if you require a lot of video memory. Monitors I have had very good luck with the Sony Multiscan 17seII monitors, as have I with the Viewsonic offering in the same (Trinitron) tube. For larger than 17", all I can recommend at the time of this writing is to not spend any less than U.S. $2,000 for a 21" monitor or $1,700 for a 20" monitor if that's what you really need. There are good monitors available in the >=20" range and there are also cheap monitors in the >=20" range. Unfortunately, very few are both cheap and good! Networking I can recommend the Intel EtherExpress Pro/100B card first and foremost, followed by the SMC Ultra 16 controller for any ISA application and the SMC EtherPower or Compex ENET32 cards for slightly cheaper PCI based networking. In general, any PCI NIC based around DEC's DC21041 Ethernet controller chip, such as the Znyx ZX342 or DEC DE435/450, will generally work quite well and can frequently be found in 2-port and 4-port version (useful for firewalls and routers), though the Pro/100MB card has the edge when it comes to providing the best performance with lower overhead. If what you're looking for is the cheapest possible solution then almost any NE2000 clone will do a fine job for very little cost. Serial If you're looking for high-speed serial networking solutions, then Digi International makes the SYNC/570 - series, with drivers now in FreeBSD-current. Emerging Technologies also manufactures a board with T1/E1 capabilities, using software they provide. I have no direct experience using either product, however. - Multiport card options are somewhat more numerous, though it has + multiport card options are somewhat more numerous, though it has to be said that FreeBSD's support for Cyclades's products is probably the tightest, primarily as a result of that company's commitment to making sure that we are adequately supplied with evaluation boards and technical specs. I've heard that the Cyclom-16Ye offers the best price/performance, though I've not checked the prices lately. Other multiport cards I've heard good things about are the BOCA and AST cards, and Stallion Technologies apparently offers an unofficial driver for their cards at this location. Audio I currently use a Creative Labs AWE32 though just about anything from Creative Labs will generally work these days. This is not to say that other types of sound cards don't also work, simply that I have little experience - with them (I was a former GUS fan, but Gravis's soundcard situation + with them (I was a former GUS fan, but Gravis's sound card situation has been dire for some time). Video For video capture, there are two good choices — any card based on the Brooktree BT848 chip, such as the Hauppage or WinTV boards, will work very nicely with FreeBSD. Another board which works for me is the Matrox Meteor card. FreeBSD also supports the older video spigot card from Creative Labs, but those are getting somewhat difficult to find. Note that the Meteor frame grabber card will not work with motherboards based on the 440FX chipset! See the motherboard reference section for details. In such cases, it's better to go with a BT848 based board. Core/Processing Motherboards, busses, and chipsets * ISA * EISA * VLB PCI Contributed by &a.obrien; from postings by &a.rgrimes;. 25 April 1995. Continuing updates by &a.jkh;. Last update on 26 August 1996. Of the Intel PCI chip sets, the following list describes various types of known-brokenness and the degree of breakage, listed from worst to best. Mercury: 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. Saturn-I (ie, 82424ZX at rev 0, 1 or 2): 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. Saturn-II (ie, 82424ZX at rev 3 or 4): 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). + external dirty bit SRAM needed for write back operation. + You can work around this either by running 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). Neptune: 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. Triton (ie, 430FX): No known cache coherency or bus master problems, chip set does not implement parity checking. Workaround for parity issue. Use Triton-II based motherboards if you have the choice. Triton-II (ie, 430HX): All reports on motherboards using this chipset have been favorable so far. No known problems. Orion: Early versions of this chipset suffered from a PCI write-posting bug which can cause noticeable performance degradation in applications where large amounts of PCI bus traffic is involved. B0 stepping or later revisions of the chipset fixed this problem. 440FX: This Pentium Pro support chipset seems to work well, and does not suffer from any of the early Orion chipset problems. It also supports a wider variety of memory, including ECC and parity. The only known problem with it is that the Matrox Meteor frame grabber card doesn't like it. CPUs/FPUs Contributed by &a.asami;. 26 December 1997. P6 class (Pentium Pro/Pentium II) Both the Pentium Pro and Pentium II work fine with FreeBSD. In - fact, our main ftp site ftp.FreeBSD.org (also known as "ftp.cdrom.com", world's largest ftp site) runs FreeBSD on a Pentium Pro. Configurations details are available for interested parties. Pentium class The Intel Pentium (P54C), Pentium MMX (P55C), AMD K6 and Cyrix/IBM 6x86MX processors are all reported to work with FreeBSD. I will not go into details of which processor is faster than what, - there are zillions of web sites on the Internet that tells you one + there are millions of web sites on the Internet that tells you one way or another. :) Various CPUs have different voltage/cooling requirements. Make sure your motherboard can supply the exact voltage needed by the CPU. For instance, many recent MMX chips require split voltage (e.g., 2.9V core, 3.3V I/O). Also, some AMD and Cyrix/IBM chips run hotter than Intel chips. In that case, make sure you have good heatsink/fans (you can get the list of certified parts from their web pages). Clock speeds Contributed by &a.rgrimes;. 1 October 1996. Updated by &a.asami;. 27 December 1997. Pentium class machines use different clock speeds for the various parts of the system. These being the speed of the CPU, external memory bus, and the PCI bus. It is not always true that a faster processor will make a system faster than a slower one, due to the various clock speeds used. Below is a table showing the differences: Rated CPU MHz External Clock and Memory Bus MHz External to Internal Clock Multiplier PCI Bus Clock MHz 60 60 1.0 30 66 66 1.0 33 75 50 1.5 25 90 60 1.5 30 100 50 2 25 100 66 1.5 33 120 60 2 30 133 66 2 33 150 60 2.5 30 (Intel, AMD) 150 75 2 37.5 (Cyrix/IBM 6x86MX) 166 66 2.5 33 180 60 3 30 200 66 3 33 233 66 3.5 33 66MHz may actually be 66.667MHz, but don't assume so. The Pentium 100 can be run at either 50MHz external clock with a multiplier of 2 or at 66MHz and a multiplier of 1.5. As can be seen the best parts to be using are the 100, 133, 166, 200 and 233, with the exception that at a multiplier of 3 or more the CPU starves for memory. The AMD K6 Bug In 1997, there have been reports of the AMD K6 seg faulting during heavy compilation. That problem has been fixed in 3Q '97. According to reports, K6 chips with date mark 9733 or larger (i.e., manufactured in the 33rd week of '97 or later) do not have this bug. * 486 class * 386 class 286 class Sorry, FreeBSD does not run on 80286 machines. It is nearly - impossible to run today's large full-featured UNIXes on such + impossible to run today's large full-featured unices on such hardware. * Memory The minimum amount of memory you must have to install FreeBSD is 5 MB. Once your system is up and running you can build a custom kernel that will use less memory. If you use the boot4.flp you can get away with having only 4 MB. * BIOS Input/Output Devices * Video cards * Sound cards Serial ports and multiport cards The UART: What it is and how it works Copyright © 1996 &a.uhclem;, All Rights Reserved. 13 January 1996. The Universal Asynchronous Receiver/Transmitter (UART) controller is the key component of the serial communications subsystem of a computer. The UART takes bytes of data and transmits the individual bits in a sequential fashion. At the destination, a second UART re-assembles the bits into complete bytes. Serial transmission is commonly used with modems and for non-networked communication between computers, terminals and other devices. There are two primary forms of serial transmission: Synchronous and Asynchronous. Depending on the modes that are supported by the hardware, the name of the communication sub-system will usually include a A if it supports Asynchronous communications, and a S if it supports Synchronous communications. Both forms are described below. Some common acronyms are:
UART Universal Asynchronous Receiver/Transmitter
USART Universal Synchronous-Asynchronous Receiver/Transmitter
Synchronous Serial Transmission Synchronous serial transmission requires that the sender and receiver share a clock with one another, or that the sender provide a strobe or other timing signal so that the receiver knows when to read the next bit of the data. In most forms of serial Synchronous communication, if there is no data available at a given instant to transmit, a fill character must be sent instead so that data is always being transmitted. Synchronous communication is usually more efficient because only data bits are transmitted between sender and receiver, and synchronous communication can be more more costly if extra wiring and circuits are required to share a clock signal between the sender and receiver. A form of Synchronous transmission is used with printers and fixed disk devices in that the data is sent on one set of wires while a clock or strobe is sent on a different wire. Printers and fixed disk devices are not normally serial devices because most fixed disk interface standards send an entire word of data for each clock or strobe signal by using a separate wire for each bit of the word. In the PC industry, these are known as Parallel devices. The standard serial communications hardware in the PC does not support Synchronous operations. This mode is described here for comparison purposes only. Asynchronous Serial Transmission Asynchronous transmission allows data to be transmitted without the sender having to send a clock signal to the receiver. Instead, the sender and receiver must agree on timing parameters in advance and special bits are added to each word which are used to synchronize the sending and receiving units. When a word is given to the UART for Asynchronous transmissions, a bit called the "Start Bit" is added to the beginning of each word that is to be transmitted. The Start Bit is used to alert the receiver that a word of data is about to be sent, and to force the clock in the receiver into synchronization with the clock in the transmitter. These two clocks must be accurate enough to not have the frequency drift by more than 10% during the transmission of the remaining bits in the word. (This requirement was set in the days of mechanical teleprinters and is easily met by modern electronic equipment.) After the Start Bit, the individual bits of the word of data are sent, with the Least Significant Bit (LSB) being sent first. Each bit in the transmission is transmitted for exactly the same amount of time as all of the other bits, and the receiver looks at the wire at approximately halfway through the period assigned to each bit to determine if the bit is a 1 or a 0. For example, if it takes two seconds to send each bit, the receiver will examine the signal to determine if it is a 1 or a 0 after one second has passed, then it will wait two seconds and then examine the value of the next bit, and so on. The sender does not know when the receiver has looked at the value of the bit. The sender only knows when the clock says to begin transmitting the next bit of the word. When the entire data word has been sent, the transmitter may add a Parity Bit that the transmitter generates. The Parity Bit may be used by the receiver to perform simple error checking. Then at least one Stop Bit is sent by the transmitter. When the receiver has received all of the bits in the data word, it may check for the Parity Bits (both sender and receiver must agree on whether a Parity Bit is to be used), and then the receiver looks for a Stop Bit. If the Stop Bit does not appear when it is supposed to, the UART considers the entire word to be garbled and will report a Framing Error to the host processor when the data word is read. The usual cause of a Framing Error is that the sender and receiver clocks were not running at the same speed, or that the signal was interrupted. Regardless of whether the data was received correctly or not, the UART automatically discards the Start, Parity and Stop bits. If the sender and receiver are configured identically, these bits are not passed to the host. If another word is ready for transmission, the Start Bit for the new word can be sent as soon as the Stop Bit for the previous word has been sent. Because asynchronous data is self synchronizing, if there is no data to transmit, the transmission line can be idle. Other UART Functions In addition to the basic job of converting data from parallel to serial for transmission and from serial to parallel on reception, a UART will usually provide additional circuits for signals that can be used to indicate the state of the transmission media, and to regulate the flow of data in the event that the remote device is not prepared to accept more data. For example, when the device connected to the UART is a modem, the modem may report the presence of a carrier on the phone line while the computer may be able to instruct the modem to reset itself or to - not take calls by asserting or deasserting one more more of these + not take calls by asserting or disasserting one more more of these extra signals. The function of each of these additional signals is defined in the EIA RS232-C standard. The RS232-C and V.24 Standards In most computer systems, the UART is connected to circuitry that generates signals that comply with the EIA RS232-C specification. There is also a CCITT standard named V.24 that mirrors the specifications included in RS232-C. RS232-C Bit Assignments (Marks and Spaces) In RS232-C, a value of 1 is called a Mark and a value of 0 is called a Space. When a communication line is idle, the line is said to be Marking, or transmitting continuous 1 values. The Start bit always has a value of 0 (a Space). The Stop Bit always has a value of 1 (a Mark). This means that there will always be a Mark (1) to Space (0) transition on the line at the start of every word, even when multiple word are transmitted back to back. This guarantees that sender and receiver can resynchronize their clocks regardless of the content of the data bits that are being transmitted. The idle time between Stop and Start bits does not have to be an exact multiple (including zero) of the bit rate of the communication link, but most UARTs are designed this way for simplicity. In RS232-C, the "Marking" signal (a 1) is represented by a voltage between -2 VDC and -12 VDC, and a "Spacing" signal (a 0) is represented by a voltage between 0 and +12 VDC. The transmitter is supposed to send +12 VDC or -12 VDC, and the receiver is supposed to allow for some voltage loss in long cables. Some transmitters in low power devices (like portable computers) sometimes use only +5 VDC and -5 VDC, but these values are still acceptable to a RS232-C receiver, provided that the cable lengths are short. RS232-C Break Signal RS232-C also specifies a signal called a Break, which is caused by sending continuous Spacing values (no Start or Stop bits). When there is no electricity present on the data circuit, the line is considered to be sending Break. The Break signal must be of a duration longer than the time it takes to send a complete byte plus Start, Stop and Parity bits. Most UARTs can distinguish between a Framing Error and a Break, but if the UART cannot do this, the Framing Error detection can be used to identify Breaks. In the days of teleprinters, when numerous printers around the country were wired in series (such as news services), any unit could cause a Break by temporarily opening the entire circuit so that no current flowed. This was used to allow a location with urgent news to interrupt some other location that was currently sending information. In modern systems there are two types of Break signals. If the Break is longer than 1.6 seconds, it is considered a "Modem Break", and some modems can be programmed to terminate the conversation and go on-hook or enter the modems' command mode when the modem detects this signal. If the Break is smaller than 1.6 seconds, it signifies a Data Break and it is up to the remote computer to respond to this signal. Sometimes this form of Break is used as an Attention or Interrupt signal and sometimes is accepted as a substitute for the ASCII CONTROL-C character. Marks and Spaces are also equivalent to Holes and No Holes in paper tape systems. Breaks cannot be generated from paper tape or from any other byte value, since bytes are always sent with Start and Stop bit. The UART is usually capable of generating the continuous Spacing signal in response to a special command from the host processor. RS232-C DTE and DCE Devices The RS232-C specification defines two types of equipment: the Data Terminal Equipment (DTE) and the Data Carrier Equipment (DCE). Usually, the DTE device is the terminal (or computer), and the DCE is a modem. Across the phone line at the other end of a conversation, the receiving modem is also a DCE device and the computer that is connected to that modem is a DTE device. The DCE device receives signals on the pins that the DTE device transmits on, and vice versa. When two devices that are both DTE or both DCE must be connected together without a modem or a similar media translater between them, a NULL modem must be used. The NULL modem electrically re-arranges the cabling so that the transmitter output is connected to the receiver input on the other device, and vice versa. Similar translations are performed on all of the control signals so that each device will see what it thinks are DCE (or DTE) signals from the other device. The number of signals generated by the DTE and DCE devices are not symmetrical. The DTE device generates fewer signals for the DCE device than the DTE device receives from the DCE. RS232-C Pin Assignments The EIA RS232-C specification (and the ITU equivalent, V.24) calls for a twenty-five pin connector (usually a DB25) and defines the purpose of most of the pins in that connector. In the IBM Personal Computer and similar systems, a subset of RS232-C signals are provided via nine pin connectors (DB9). The signals that are not included on the PC connector deal mainly with synchronous operation, and this transmission mode is not supported by the UART that IBM selected for use in the IBM PC. Depending on the computer manufacturer, a DB25, a DB9, or both types of connector may be used for RS232-C communications. (The IBM PC also uses a DB25 connector for the parallel printer interface which causes some confusion.) Below is a table of the RS232-C signal assignments in the DB25 and DB9 connectors. DB25 RS232-C Pin DB9 IBM PC Pin EIA Circuit Symbol CCITT Circuit Symbol Common Name Signal Source Description 1 - AA 101 PG/FG - Frame/Protective Ground 2 3 BA 103 TD DTE Transmit Data 3 2 BB 104 RD DCE Receive Data 4 7 CA 105 RTS DTE Request to Send 5 8 CB 106 CTS DCE Clear to Send 6 6 CC 107 DSR DCE Data Set Ready 7 5 AV 102 SG/GND - Signal Ground 8 1 CF 109 DCD/CD DCE Data Carrier Detect 9 - - - - - Reserved for Test 10 - - - - - Reserved for Test 11 - - - - - Reserved for Test 12 - CI 122 SRLSD DCE Sec. Recv. Line Signal Detector 13 - SCB 121 SCTS DCE Secondary Clear to Send 14 - SBA 118 STD DTE Secondary Transmit Data 15 - DB 114 TSET DCE Trans. Sig. Element Timing 16 - SBB 119 SRD DCE Secondary Received Data 17 - DD 115 RSET DCE Receiver Signal Element Timing 18 - - 141 LOOP DTE Local Loopback 19 - SCA 120 SRS DTE Secondary Request to Send 20 4 CD 108.2 DTR DTE Data Terminal Ready 21 - - - RDL DTE Remote Digital Loopback 22 9 CE 125 RI DCE Ring Indicator 23 - CH 111 DSRS DTE Data Signal Rate Selector 24 - DA 113 TSET DTE Trans. Sig. Element Timing 25 - - 142 - DCE Test Mode Bits, Baud and Symbols Baud is a measurement of transmission speed in asynchronous communication. Because of advances in modem communication technology, this term is frequently misused when describing the data rates in newer devices. Traditionally, a Baud Rate represents the number of bits that are actually being sent over the media, not the amount of data that is actually moved from one DTE device to the other. The Baud count includes the overhead bits Start, Stop and Parity that are generated by the sending UART and removed by the receiving UART. This means that seven-bit words of data actually take 10 bits to be completely transmitted. Therefore, a modem capable of moving 300 bits per second from one place to another can normally only move 30 7-bit words if Parity is used and one Start and Stop bit are present. If 8-bit data words are used and Parity bits are also used, the data rate falls to 27.27 words per second, because it now takes 11 bits to send the eight-bit words, and the modem still only sends 300 bits per second. The formula for converting bytes per second into a baud rate and vice versa was simple until error-correcting modems came along. These modems receive the serial stream of bits from the UART in the host computer (even when internal modems are used the data is still frequently serialized) and converts the bits back into bytes. These bytes are then combined into packets and sent over the phone line using a Synchronous transmission method. This means that the Stop, Start, and Parity bits added by the UART in the DTE (the computer) were removed by the modem before transmission by the sending modem. When these bytes are received by the remote modem, the remote modem adds Start, Stop and Parity bits to the words, converts them to a serial format and then sends them to the receiving UART in the remote computer, who then strips the Start, Stop and Parity bits. The reason all these extra conversions are done is so that the two modems can perform error correction, which means that the receiving modem is able to ask the sending modem to resend a block of data that was not received with the correct checksum. This checking is handled by the modems, and the DTE devices are usually unaware that the process is occurring. By striping the Start, Stop and Parity bits, the additional bits of data that the two modems must share between themselves to perform error-correction are mostly concealed from the effective transmission rate seen by the sending and receiving DTE equipment. For example, if a modem sends ten 7-bit words to another modem without including the Start, Stop and Parity bits, the sending modem will be able to add 30 bits of its own information that the receiving modem can use to do error-correction without impacting the transmission speed of the real data. The use of the term Baud is further confused by modems that perform compression. A single 8-bit word passed over the telephone line might represent a dozen words that were transmitted to the sending modem. The receiving modem will expand the data back to its original content and pass that data to the receiving DTE. Modern modems also include buffers that allow the rate that bits move across the phone line (DCE to DCE) to be a different speed than the speed that the bits move between the DTE and DCE on both ends of the conversation. Normally the speed between the DTE and DCE is higher than the DCE to DCE speed because of the use of compression by the modems. Because the number of bits needed to describe a byte varied during the trip between the two machines plus the differing bits-per-seconds speeds that are used present on the DTE-DCE and DCE-DCE links, the usage of the term Baud to describe the overall communication speed causes problems and can misrepresent the true transmission speed. So Bits Per Second (bps) is the correct term to use to describe the transmission rate seen at the DCE to DCE interface and Baud or Bits Per Second are acceptable terms to use when a connection is made between two systems with a wired connection, or if a modem is in use that is not performing error-correction or compression. Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in reality still operate at or below 2400 baud, or more accurately, 2400 Symbols per second. High speed modem are able to encode more bits of data into each Symbol using a technique called Constellation Stuffing, which is why the effective bits per second rate of the modem is higher, but the modem continues to operate within the limited audio bandwidth that the telephone system provides. Modems operating at 28,800 and higher speeds have variable Symbol rates, but the technique is the same. The IBM Personal Computer UART Starting with the original IBM Personal Computer, IBM selected the National Semiconductor INS8250 UART for use in the IBM PC Parallel/Serial Adapter. Subsequent generations of compatible computers from IBM and other vendors continued to use the INS8250 or improved versions of the National Semiconductor UART family. National Semiconductor UART Family Tree There have been several versions and subsequent generations of the INS8250 UART. Each major version is described below. INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D INS8250 This part was used in the original IBM PC and IBM PC/XT. The original name for this part was the INS8250 ACE (Asynchronous Communications Element) and it is made from NMOS technology. The 8250 uses eight I/O ports and has a one-byte send and a one-byte receive buffer. This original UART has several race conditions and other flaws. The original IBM BIOS includes code to work around these flaws, but this made the BIOS dependent on the flaws being present, so subsequent parts like the 8250A, 16450 or 16550 could not be used in the original IBM PC or IBM PC/XT. INS8250-B This is the slower speed of the INS8250 made from NMOS technology. It contains the same problems as the original INS8250. INS8250A An improved version of the INS8250 using XMOS technology with various functional flaws corrected. The INS8250A was used initially in PC clone computers by vendors who used clean BIOS designs. Because of the corrections in the chip, this part could not be used with a BIOS compatible with the INS8250 or INS8250B. INS82C50A This is a CMOS version (low power consumption) of the INS8250A and has similar functional characteristics. NS16450 Same as NS8250A with improvements so it can be used with faster CPU bus designs. IBM used this part in the IBM AT and updated the IBM BIOS to no longer rely on the bugs in the INS8250. NS16C450 This is a CMOS version (low power consumption) of the NS16450. NS16550 Same as NS16450 with a 16-byte send and receive buffer but the buffer design was flawed and could not be reliably be used. NS16550A Same as NS16550 with the buffer flaws corrected. The 16550A and its successors have become the most popular UART design in the PC industry, mainly due it its ability to reliably handle higher data rates on operating systems with sluggish interrupt response times. NS16C552 This component consists of two NS16C550A CMOS UARTs in a single package. PC16550D Same as NS16550A with subtle flaws corrected. This is revision D of the 16550 family and is the latest design available from National Semiconductor. The NS16550AF and the PC16550D are the same thing National reorganized their part numbering system a few years ago, and the NS16550AFN no longer exists by that name. (If you have a NS16550AFN, look at the date code on the part, which is a four digit number that usually starts with a nine. The first two digits of the number are the year, and the last two digits are the week in that year when the part was packaged. If you have a NS16550AFN, it is probably a few years old.) The new numbers are like PC16550DV, with minor differences in the suffix letters depending on the package material and its shape. (A description of the numbering system can be found below.) It is important to understand that in some stores, you may pay $15(US) for a NS16550AFN made in 1990 and in the next bin are the new PC16550DN parts with minor fixes that National has made since the AFN part was in production, the PC16550DN was probably made in the past six months and it costs half (as low as $5(US) in volume) as much as the NS16550AFN because they are readily available. As the supply of NS16550AFN chips continues to shrink, the price will probably continue to increase until more people discover and accept that the PC16550DN really has the same function as the old part number. National Semiconductor Part Numbering System The older NSnnnnnrqp part numbers are now of the format PCnnnnnrgp. The r is the revision field. The current revision of the 16550 from National Semiconductor is D. The p is the package-type field. The types are: "F" QFP (quad flat pack) L lead type "N" DIP (dual inline package) through hole straight lead type "V" LPCC (lead plastic chip carrier) J lead type The g is the product grade field. If an I precedes the package-type letter, it indicates an industrial grade part, which has higher specs than a standard part but not as high as Military Specification (Milspec) component. This is an optional field. So what we used to call a NS16550AFN (DIP Package) is now called a PC16550DN or PC16550DIN. Other Vendors and Similar UARTs Over the years, the 8250, 8250A, 16450 and 16550 have been licensed or copied by other chip vendors. In the case of the 8250, 8250A and 16450, the exact circuit (the megacell) was licensed to many vendors, including Western Digital and Intel. Other vendors reverse-engineered the part or produced emulations that had similar behavior. In internal modems, the modem designer will frequently emulate the 8250A/16450 with the modem microprocessor, and the emulated UART will frequently have a hidden buffer consisting of several hundred bytes. Because of the size of the buffer, these emulations can be as reliable as a 16550A in their ability to handle high speed data. However, most operating systems will still report that the UART is only a 8250A or 16450, and may not make effective use of the extra buffering present in the emulated UART unless special drivers are used. Some modem makers are driven by market forces to abandon a design that has hundreds of bytes of buffer and instead use a 16550A UART so that the product will compare favorably in market comparisons even though the effective performance may be lowered by this action. A common misconception is that all parts with 16550A written on them are identical in performance. There are differences, and in some cases, outright flaws in most of these 16550A clones. When the NS16550 was developed, the National Semiconductor obtained several patents on the design and they also limited licensing, making it harder for other vendors to provide a chip with similar features. Because of the patents, reverse-engineered designs and emulations had to avoid infringing the claims covered by the patents. Subsequently, these copies almost never perform exactly the same as the NS16550A or PC16550D, which are the parts most computer and modem makers want to buy but are sometimes unwilling to pay the price required to get the genuine part. Some of the differences in the clone 16550A parts are unimportant, while others can prevent the device from being used at all with a given operating system or driver. These differences may show up when using other drivers, or when particular combinations of events occur that were not well tested or considered in the Windows driver. This is because most modem vendors and 16550-clone makers use the Microsoft drivers from - Windows for Workgroups 3.11 and the Microsoft MSD utility as the + Windows for Workgroups 3.11 and the Microsoft MS-DOS utility as the primary tests for compatibility with the NS16550A. This over-simplistic criteria means that if a different operating system is used, problems could appear due to subtle differences between the clones and genuine components. National Semiconductor has made available a program named COMTEST that performs compatibility tests independent of any OS drivers. It should be remembered that the purpose of this type of program is to demonstrate the flaws in the products of the competition, so the program will report major as well as extremely subtle differences in behavior in the part being tested. In a series of tests performed by the author of this document in 1994, components made by National Semiconductor, TI, StarTech, and CMD as well as megacells and emulations embedded in internal modems were tested with COMTEST. A difference count for some of these components is listed below. Because these tests were performed in 1994, they may not reflect the current performance of the given product from a vendor. It should be noted that COMTEST normally aborts when an excessive number or certain types of problems have been detected. As part of this testing, COMTEST was modified so that it would not abort no matter how many differences were encountered. Vendor Part Number Errors (aka "differences" reported) National (PC16550DV) 0 National (NS16550AFN) 0 National (NS16C552V) 0 TI (TL16550AFN) 3 CMD (16C550PE) 19 StarTech (ST16C550J) 23 Rockwell Reference modem with internal 16550 or an emulation (RC144DPi/C3000-25) 117 Sierra Modem with an internal 16550 (SC11951/SC11351) 91 To date, the author of this document has not found any non-National parts that report zero differences using the COMTEST program. It should also be noted that National has had five versions of the 16550 over the years and the newest parts behave a bit differently than the classic NS16550AFN that is considered the benchmark for functionality. COMTEST appears to turn a blind eye to the differences within the National product line and reports no errors on the National parts (except for the original 16550) even when there are official erratas that describe bugs in the A, B and C revisions of the parts, so this bias in COMTEST must be taken into account. It is important to understand that a simple count of differences from COMTEST does not reveal a lot about what differences are important and which are not. For example, about half of the differences reported in the two modems listed above that have internal UARTs were caused by the clone UARTs not supporting five- and six-bit character modes. The real 16550, 16450, and 8250 UARTs all support these modes and COMTEST checks the functionality of these modes so over fifty differences are reported. However, almost no modern modem supports five- or six-bit characters, particularly those with error-correction and compression capabilities. This means that the differences related to five- and six-bit character modes can be discounted. Many of the differences COMTEST reports have to do with timing. In many of the clone designs, when the host reads from one port, the status bits in some other port may not update in the same amount of time (some faster, some slower) as a real NS16550AFN and COMTEST looks for these differences. This means that the number of differences can be misleading in that one device may only have one or two differences but they are extremely serious, and some other device that updates the status registers faster or slower than the reference part (that would probably never affect the operation of a properly written driver) could have dozens of differences reported. COMTEST can be used as a screening tool to alert the administrator to the presence of potentially incompatible components that might cause problems or have to be handled as a special case. If you run COMTEST on a 16550 that is in a modem or a modem is attached to the serial port, you need to first issue a ATE0&W command to the modem so that the modem will not echo any of the test characters. If you forget to do this, COMTEST will report at least this one difference: Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 8250/16450/16550 Registers The 8250/16450/16550 UART occupies eight contiguous I/O port addresses. In the IBM PC, there are two defined locations for these eight ports and they are known collectively as COM1 and COM2. The makers of PC-clones and add-on cards have created two additional areas known as COM3 and COM4, but these extra COM ports conflict with other hardware on some systems. The most common conflict is with video adapters that provide IBM 8514 emulation. COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ 4 COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3 COM3 is located from 0x3e8 to 0x3ef and has no standardized IRQ COM4 is located from 0x2e8 to 0x2ef and has no standardized IRQ. A description of the I/O ports of the 8250/16450/16550 UART is provided below. I/O Port Access Allowed Description +0x00 write (DLAB==0) Transmit Holding Register (THR).Information written to this port are treated as data words and will be transmitted by the UART. +0x00 read (DLAB==0) Receive Buffer Register (RBR).Any data words received by the UART form the serial link are accessed by the host by reading this port. +0x00 write/read (DLAB==1) Divisor Latch LSB (DLL)This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 0 thru 7 of the divisor. +0x01 write/read (DLAB==1) Divisor Latch MSB (DLH)This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 8 thru 15 of the divisor. +0x01 write/read (DLAB==0) Interrupt Enable Register (IER)The 8250/16450/16550 UART classifies events into one of four categories. Each category can be configured to generate an interrupt when any of the events occurs. The 8250/16450/16550 UART generates a single external interrupt signal regardless of how many events in the enabled categories have occurred. It is up to the host processor to respond to the interrupt and then poll the enabled interrupt categories (usually all categories have interrupts enabled) to determine the true cause(s) of the interrupt. Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Enable Modem Status Interrupt (EDSSI). Setting this bit to "1" allows the UART to generate an interrupt when a change occurs on one or more of the status lines. Bit 2 Enable Receiver Line Status Interrupt (ELSI) Setting this bit to "1" causes the UART to generate an interrupt when the an error (or a BREAK signal) has been detected in the incoming data. Bit 1 Enable Transmitter Holding Register Empty Interrupt (ETBEI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has room for one or more additional characters that are to be transmitted. Bit 0 Enable Received Data Available Interrupt (ERBFI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has received enough characters to exceed the trigger level of the FIFO, or the FIFO timer has expired (stale data), or a single character has been received when the FIFO is disabled. +0x02 write FIFO Control Register (FCR) (This port does not exist on the 8250 and 16450 UART.) Bit 7 Receiver Trigger Bit #1 Bit 6 Receiver Trigger Bit #0These two bits control at what point the receiver is to generate an interrupt when the FIFO is active. 7 6 How many words are received before an interrupt is generated 0 0 1 0 1 4 1 0 8 1 1 14 Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 DMA Mode Select. If Bit 0 is set to "1" (FIFOs enabled), setting this bit changes the operation of the -RXRDY and -TXRDY signals from Mode 0 to Mode 1. Bit 2 Transmit FIFO Reset. When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being transmitted will be sent intact. This function is useful in aborting transfers. Bit 1 Receiver FIFO Reset. When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being assembled in the shift register will be received intact. Bit 0 16550 FIFO Enable. When set, both the transmit and receive FIFOs are enabled. Any contents in the holding register, shift registers or FIFOs are lost when FIFOs are enabled or disabled. +0x02 read Interrupt Identification Register Bit 7 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 6 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Interrupt ID Bit #2. On the 8250/16450 UART, this bit is zero. Bit 2 Interrupt ID Bit #1 Bit 1 Interrupt ID Bit #0.These three bits combine to report the category of event that caused the interrupt that is in progress. These categories have priorities, so if multiple categories of events occur at the same time, the UART will report the more important events first and the host must resolve the events in the order they are reported. All events that caused the current interrupt must be resolved before any new interrupts will be generated. (This is a limitation of the PC architecture.) 2 1 0 Priority Description 0 1 1 First Received Error (OE, PE, BI, or FE) 0 1 0 Second Received Data Available 1 1 0 Second Trigger level identification (Stale data in receive buffer) 0 0 1 Third Transmitter has room for more words (THRE) 0 0 0 Fourth Modem Status Change (-CTS, -DSR, -RI, or -DCD) Bit 0 Interrupt Pending Bit. If this bit is set to "0", then at least one interrupt is pending. +0x03 write/read Line Control Register (LCR) Bit 7 Divisor Latch Access Bit (DLAB). When set, access to the data transmit/receive register (THR/RBR) and the Interrupt Enable Register (IER) is disabled. Any access to these ports is now redirected to the Divisor Latch Registers. Setting this bit, loading the Divisor Registers, and clearing DLAB should be done with interrupts disabled. Bit 6 Set Break. When set to "1", the transmitter begins to transmit continuous Spacing until this bit is set to "0". This overrides any bits of characters that are being transmitted. Bit 5 Stick Parity. When parity is enabled, setting this bit causes parity to always be "1" or "0", based on the value of Bit 4. Bit 4 Even Parity Select (EPS). When parity is enabled and Bit 5 is "0", setting this bit causes even parity to be transmitted and expected. Otherwise, odd parity is used. Bit 3 Parity Enable (PEN). When set to "1", a parity bit is inserted between the last bit of the data and the Stop Bit. The UART will also expect parity to be present in the received data. Bit 2 Number of Stop Bits (STB). If set to "1" and using 5-bit data words, 1.5 Stop Bits are transmitted and expected in each data word. For 6, 7 and 8-bit data words, 2 Stop Bits are transmitted and expected. When this bit is set to "0", one Stop Bit is used on each data word. Bit 1 Word Length Select Bit #1 (WLSB1) Bit 0 Word Length Select Bit #0 (WLSB0) Together these bits specify the number of bits in each data word. 1 0 Word Length 0 0 5 Data Bits 0 1 6 Data Bits 1 0 7 Data Bits 1 1 8 Data Bits +0x04 write/read Modem Control Register (MCR) Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Loop-Back Enable. When set to "1", the UART transmitter and receiver are internally connected together to allow diagnostic operations. In addition, the UART modem control outputs are connected to the UART modem control inputs. CTS is connected to RTS, DTR is connected to DSR, OUT1 is connected to RI, and OUT 2 is connected to DCD. Bit 3 OUT 2. An auxiliary output that the host processor may set high or low. In the IBM PC serial adapter (and most clones), OUT 2 is used to tri-state (disable) the interrupt signal from the 8250/16450/16550 UART. Bit 2 OUT 1. An auxiliary output that the host processor may set high or low. This output is not used on the IBM PC serial adapter. Bit 1 Request to Send (RTS). When set to "1", the output of the UART -RTS line is Low (Active). Bit 0 Data Terminal Ready (DTR). When set to "1", the output of the UART -DTR line is Low (Active). +0x05 write/read Line Status Register (LSR) Bit 7 Error in Receiver FIFO. On the 8250/16450 UART, this bit is zero. This bit is set to "1" when any of the bytes in the FIFO have one or more of the following error conditions: PE, FE, or BI. Bit 6 Transmitter Empty (TEMT). When set to "1", there are no words remaining in the transmit FIFO or the transmit shift register. The transmitter is completely idle. Bit 5 Transmitter Holding Register Empty (THRE). When set to "1", the FIFO (or holding register) now has room for at least one additional word to transmit. The transmitter may still be transmitting when this bit is set to "1". Bit 4 Break Interrupt (BI). The receiver has detected a Break signal. Bit 3 Framing Error (FE). A Start Bit was detected but the Stop Bit did not appear at the expected time. The received word is probably garbled. Bit 2 Parity Error (PE). The parity bit was incorrect for the word received. Bit 1 Overrun Error (OE). A new word was received and there was no room in the receive buffer. The newly-arrived word in the shift register is discarded. On 8250/16450 UARTs, the word in the holding register is discarded and the newly- arrived word is put in the holding register. Bit 0 Data Ready (DR) One or more words are in the receive FIFO that the host may read. A word must be completely received and moved from the shift register into the FIFO (or holding register for 8250/16450 designs) before this bit is set. +0x06 write/read Modem Status Register (MSR) Bit 7 Data Carrier Detect (DCD). Reflects the state of the DCD line on the UART. Bit 6 Ring Indicator (RI). Reflects the state of the RI line on the UART. Bit 5 Data Set Ready (DSR). Reflects the state of the DSR line on the UART. Bit 4 Clear To Send (CTS). Reflects the state of the CTS line on the UART. Bit 3 Delta Data Carrier Detect (DDCD). Set to "1" if the -DCD line has changed state one more more times since the last time the MSR was read by the host. Bit 2 Trailing Edge Ring Indicator (TERI). Set to "1" if the -RI line has had a low to high transition since the last time the MSR was read by the host. Bit 1 Delta Data Set Ready (DDSR). Set to "1" if the -DSR line has changed state one more more times since the last time the MSR was read by the host. Bit 0 Delta Clear To Send (DCTS). Set to "1" if the -CTS line has changed state one more more times since the last time the MSR was read by the host. +0x07 write/read Scratch Register (SCR). This register performs no function in the UART. Any value can be written by the host to this location and read by the host later on. Beyond the 16550A UART Although National Semiconductor has not offered any components compatible with the 16550 that provide additional features, various other vendors have. Some of these components are described below. It should be understood that to effectively utilize these improvements, drivers may have to be provided by the chip vendor since most of the popular operating systems do not support features beyond those provided by the 16550. ST16650 By default this part is similar to the NS16550A, but an extended 32-byte send and receive buffer can be optionally - enabled. Made by Startech. + enabled. Made by StarTech. TIL16660 By default this part behaves similar to the NS16550A, but an extended 64-byte send and receive buffer can be optionally enabled. Made by Texas Instruments. Hayes ESP This proprietary plug-in card contains a 2048-byte send and receive buffer, and supports data rates to 230.4Kbit/sec. Made by Hayes. In addition to these dumb UARTs, many vendors produce intelligent serial communication boards. This type of design usually provides a microprocessor that interfaces with several UARTs, processes and buffers the data, and then alerts the main PC processor when necessary. Because the UARTs are not directly accessed by the PC processor in this type of communication system, it is not necessary for the vendor to use UARTs that are compatible with the 8250, 16450, or the 16550 UART. This leaves the designer free to components that may have better performance characteristics. Configuring the <devicename>sio</devicename> driver The sio 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 &man.sio.4; manual page for detailed technical documentation. Digi International (DigiBoard) PC/8 Contributed by &a.awebster;. 26 August 1995. Here is a config snippet from a machine with a Digi International PC/8 with 16550. It has 8 modems connected to these 8 lines, and they work just great. Do not forget to add options COM_MULTIPORT or it will not work very well! 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 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. Boca 16 Contributed by &a.whiteside;. 26 August 1995. The procedures to make a Boca 16 port board with FreeBSD are pretty straightforward, but you will need a couple things to make it work: 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 not come with multiport support enabled and you will need to add a device entry for each port anyways. 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. 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 Kernel Configuration for general procedures. The following are the specifics for the Boca 16 board and assume you are using the kernel name MYKERNEL and editing with vi. Add the line options COM_MULTIPORT to the config file. Where the current device sion lines are, you will need to add 16 more devices. Only the last device includes the interrupt vector for the board. (See the &man.sio.4; 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 hexadecimal from the previous port, thus the 100h, 108h, 110h... addresses. 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 The flags entry must be changed from this example unless you are using the exact same sio assignments. Flags are set according to 0xMYY where M indicates the minor number of the master port (the last port on a Boca 16) and YY 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, flags 0x1005 indicates that the master port is sio16. If I added another board and assigned sio17 through sio28, the flags for all 16 ports on that board would be 0x1C05, where 1C indicates the minor number of the master port. Do not change the 05 setting. 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) 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) If the messages go by too fast to see, &prompt.root; dmesg | more will show you the boot messages. Next, appropriate entries in /dev for the devices must be made using the /dev/MAKEDEV script. After becoming root: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tty1 &prompt.root; ./MAKEDEV cua1 (everything in between) &prompt.root; ./MAKEDEV ttyg &prompt.root; ./MAKEDEV cuag - If you do not want or need callout devices for some + If you do not want or need call-out devices for some reason, you can dispense with making the cua* devices. 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) &prompt.root; echo at > ttyd* for each device you have made. You should see the RX lights flash for each working port. Support for Cheap Multi-UART Cards Contributed by Helge Oldach hmo@sep.hamburg.com, September 1999 Ever wondered about FreeBSD support for your 20$ multi-I/O card with two (or more) COM ports, sharing IRQs? Here's how: Usually the only option to support these kind of boards is to use a distinct IRQ for each port. For example, if your CPU board has an on-board COM1 port (aka sio0–I/O address 0x3F8 and IRQ 4) and you have an extension board with two UARTs, you will commonly need to configure them as COM2 (aka sio1–I/O address 0x2F8 and IRQ 3), and the third port (aka sio2) as I/O - 0x3E8 and IRQ 5. Obviously this is a waste of IRQ ressources, as + 0x3E8 and IRQ 5. Obviously this is a waste of IRQ resources, as it should be basically possible to run both extension board ports using a single IRQ with the COM_MULTIPORT configuration described in the previous sections. Such cheap I/O boards commonly have a 4 by 3 jumper matrix for the COM ports, similar to the following: o o o * Port A | o * o * Port B | o * o o IRQ 2 3 4 5 Shown here is port A wired for IRQ 5 and port B wired for IRQ 3. The IRQ columns on your specific board may vary—other boards may supply jumpers for IRQs 3, 4, 5, and 7 instead. One could conclude that wiring both ports for IRQ 3 using a handcrafted wire-made jumper covering all three connection points in the IRQ 3 column would solve the issue, but no. You cannot duplicate IRQ 3 because the output drivers of each UART are wired in a totem pole fashion, so if one of the UARTs drives IRQ 3, the output signal will not be what you would expect. Depending on the implementation of the extension board or your motherboard, the IRQ 3 line will continuously stay up, or always stay low. You need to decouple the IRQ drivers for the two UARTs, so that the IRQ line of the board only goes up if (and only if) one of the UARTs asserts a IRQ, and stays low otherwise. The solution - was proposed by Jrg Wunsch + was proposed by Joerg Wunsch j@ida.interface-business.de: To solder up a wired-or consisting of two diodes (Germanium or Schottky-types strongly preferred) and a 1 kOhm resistor. Here is the schematic, starting from the 4 by 3 jumper field above: Diode +---------->|-------+ / | o * o o | 1 kOhm Port A +----|######|-------+ o * o o | | Port B `-------------------+ ==+== o * o o | Ground \ | +--------->|-------+ IRQ 2 3 4 5 Diode The cathodes of the diodes are connected to a common point, together with a 1 kOhm pull-down resistor. It is essential to connect the resistor to ground to avoid floating of the IRQ line on the bus. Now we are ready to configure a kernel. Staying with this example, we would configure: # standard on-board COM1 port device sio0 at isa? port "IO_COM1" tty flags 0x10 # patched-up multi-I/O extension board options COM_MULTIPORT device sio1 at isa? port "IO_COM2" tty flags 0x205 device sio2 at isa? port "IO_COM3" tty flags 0x205 irq 3 Note that the flags setting for sio1 and sio2 is - truely essential; refer to + truly essential; refer to &man.sio.4; for details. (Generally, the 2 in the "flags" attribute refers to sio2 which holds the IRQ, and you surely want a 5 low nibble.) With kernel verbose mode turned on this should yield something similar to this: sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff flags 0x205 on isa sio1: type 16550A (multiport) sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa sio2: type 16550A (multiport master) Though /sys/i386/isa/sio.c is somewhat cryptic with its use of the irq maps array above, the basic idea is that you observe 0x1 in the first, third, and fourth place. This means that the corresponding IRQ was set upon output and cleared after, which is just what we - would expect. If your kernel does not display this behaviour, most + would expect. If your kernel does not display this behavior, most likely there is something wrong with your wiring. Configuring the <devicename>cy</devicename> driver Contributed by &a.alex;. 6 June 1996. The Cyclades multiport cards are based on the cy driver instead of the usual sio driver used by other multiport cards. Configuration is a simple matter of: Add the cy device to your kernel configuration (note that your irq and iomem settings may differ). device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr Rebuild and install the new kernel. Make the device nodes by typing (the following example assumes an 8-port board): &prompt.root; cd /dev &prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done If appropriate, add dialup entries to /etc/ttys by duplicating serial device (ttyd) entries and using ttyc in place of ttyd. For example: ttyc0 "/usr/libexec/getty std.38400" unknown on insecure ttyc1 "/usr/libexec/getty std.38400" unknown on insecure ttyc2 "/usr/libexec/getty std.38400" unknown on insecure … ttyc7 "/usr/libexec/getty std.38400" unknown on insecure Reboot with the new kernel. Configuring the <devicename>si</devicename> driver Contributed by &a.nsayer;. 25 March 1998. The Specialix SI/XIO and SX multiport cards use the si driver. A single machine can have up to 4 host cards. The following host cards are supported: ISA SI/XIO host card (2 versions) EISA SI/XIO host card PCI SI/XIO host card ISA SX host card PCI SX host card Although the SX and SI/XIO host cards look markedly different, their functionality are basically the same. The host cards do not use I/O locations, but instead require a 32K chunk of memory. The factory configuration for ISA cards places this at 0xd0000-0xd7fff. - They also require an IRQ. PCI cards will, of course, autoconfigure + They also require an IRQ. PCI cards will, of course, auto-configure themselves. You can attach up to 4 external modules to each host card. The external modules contain either 4 or 8 serial ports. They come in the following varieties: SI 4 or 8 port modules. Up to 57600 bps on each port supported. XIO 8 port modules. Up to 115200 bps on each port supported. One type of XIO module has 7 serial and 1 parallel port. SXDC 8 port modules. Up to 921600 bps on each port supported. Like XIO, a module is available with one parallel port as well. To configure an ISA host card, add the following line to your kernel configuration file, changing the numbers as appropriate: device si0 at isa? tty iomem 0xd0000 irq 11 Valid IRQ numbers are 9, 10, 11, 12 and 15 for SX ISA host cards and 11, 12 and 15 for SI/XIO ISA host cards. To configure an EISA or PCI host card, use this line: device si0 After adding the configuration entry, rebuild and install your new kernel. After rebooting with the new kernel, you need to make the device nodes in /dev. The MAKEDEV script will take care of this for you. Count how many total ports you have and type: &prompt.root; cd /dev &prompt.root; ./MAKEDEV ttyAnn cuaAnn (where nn is the number of ports) If you want login prompts to appear on these ports, you will need to add lines like this to /etc/ttys: ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure Change the terminal type as appropriate. For modems, dialup or unknown is fine. * Parallel ports * Modems * Network cards * Keyboards Mice Contributed by Joel Sutton jsutton@bbcon.com.au January 2000 FreeBSD supports a variety of different mice via the PS/2, serial and USB ports. Most users choose to use the mouse daemon to handle their mouse because it allows interaction in both X and on the system console. For more information on the mouse daemon refer to &man.moused.8;. The examples throughout this section assume that the mouse daemon is being used. This section contains the names of specific products that the author has confirmed will work with FreeBSD. Other similar devices not listed may also be supported. PS/2 System Configuration To ensure that your PS/2 mouse functions correctly with the mouse daemon you will need to include the following text in /etc/rc.conf moused_enable="YES" moused_type="ps/2" moused_port="/dev/psm0" Known Compatible Devices Logitech First Mouse - Three Button Microsoft Serial - PS/2 Compatible Mouse Serial System Configuration To ensure that your serial mouse functions correctly with the mouse daemon you will need to include the following text in /etc/rc.conf. This example assumes that the mouse is connected to COM1: and can be - automatically recognised by the mouse daemon. + automatically recognized by the mouse daemon. moused_enable="YES" moused_type="auto" moused_port="/dev/cuaa0" See the &man.moused.8; manual page for a detailed description of how to configure the mouse daemon to work with specific types of serial mice. Known Compatible Devices Generic Microsoft Compatible Mice Logitech First Mouse - Three Button Microsoft Serial - PS/2 Compatible Mouse USB System Configuration The USB device drivers are a relatively new addition to FreeBSD and have not yet been included in the GENERIC kernel. The - following prodecure is an example of how to setup the relevant + following procedure is an example of how to setup the relevant drivers on a typical system. Add the ums device to the usb section of your kernel configuration. For example: controller usb0 controller uhci0 device ums0 Rebuild and install the new kernel. Make the device node by typing: &prompt.root; cd /dev &prompt.root; sh MAKEDEV ums0 Include the following text in /etc/rc.conf to ensure correct operation of the mouse daemon: moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" Reboot the system. &prompt.root; shutdown -r now Known Compatible Devices Logitech TrackMan - Marble Wheel * Other ]]> Storage Devices Using ESDI hard disks Copyright © 1995, &a.wilko;. 24 September 1995. ESDI is an acronym that means Enhanced Small Device Interface. It is loosely based on the good old ST506/412 interface originally devised by Seagate Technology, the makers of the first affordable 5.25" winchester disk. The acronym says Enhanced, and rightly so. In the first place the speed of the interface is higher, 10 or 15 Mbits/second instead of the 5 Mbits/second of ST412 interfaced drives. Secondly some higher level commands are added, making the ESDI interface somewhat 'smarter' to the operating system driver writers. It is by no means as smart as SCSI by the way. ESDI is standardized by ANSI. Capacities of the drives are boosted by putting more sectors on each track. Typical is 35 sectors per track, high capacity drives I have seen were up to 54 sectors/track. Although ESDI has been largely obsoleted by IDE and SCSI interfaces, the availability of free or cheap surplus drives makes them ideal for low (or now) budget systems. Concepts of ESDI Physical connections The ESDI interface uses two cables connected to each drive. One cable is a 34 pin flat cable edge connector that carries the command and status signals from the controller to the drive and vice-versa. The command cable is daisy chained between all the drives. So, it forms a bus onto which all drives are connected. The second cable is a 20 pin flat cable edge connector that carries the data to and from the drive. This cable is radially connected, so each drive has its own direct connection to the controller. To the best of my knowledge PC ESDI controllers are limited to using a maximum of 2 drives per controller. This is compatibility feature(?) left over from the WD1003 standard that reserves only a single bit for device addressing. Device addressing On each command cable a maximum of 7 devices and 1 controller can be present. To enable the controller to uniquely identify which drive it addresses, each ESDI device is equipped with jumpers or switches to select the devices address. On PC type controllers the first drive is set to address 0, the second disk to address 1. Always make sure you set each disk to an unique address! So, on a PC with its two drives/controller maximum the first drive is drive 0, the second is drive 1. Termination The daisy chained command cable (the 34 pin cable remember?) needs to be terminated at the last drive on the chain. For this purpose ESDI drives come with a termination resistor network that can be removed or disabled by a jumper when it is not used. So, one and only one drive, the one at the farthest end of the command cable has its terminator installed/enabled. The controller automatically terminates the other end of the cable. Please note that this implies that the controller must be at one end of the cable and not in the middle. Using ESDI disks with FreeBSD Why is ESDI such a pain to get working in the first place? People who tried ESDI disks with FreeBSD are known to have developed a profound sense of frustration. A combination of factors works against you to produce effects that are hard to understand when you have never seen them before. This has also led to the popular legend ESDI and FreeBSD is a plain NO-GO. The following sections try to list all the pitfalls and solutions. ESDI speed variants As briefly mentioned before, ESDI comes in two speed flavors. The older drives and controllers use a 10 Mbits/second data transfer rate. Newer stuff uses 15 Mbits/second. It is not hard to imagine that 15 Mbits/second drive cause problems on controllers laid out for 10 Mbits/second. As always, consult your controller and drive documentation to see if things match. Stay on track Mainstream ESDI drives use 34 to 36 sectors per track. Most (older) controllers cannot handle more than this number of sectors. Newer, higher capacity, drives use higher numbers of - sectors per track. For instance, I own a 670 Mb drive that has 54 + sectors per track. For instance, I own a 670 MB drive that has 54 sectors per track. In my case, the controller could not handle this number of sectors. It proved to work well except that it only used 35 sectors on each track. This meant losing a lot of disk space. Once again, check the documentation of your hardware for more info. Going out-of-spec like in the example might or might not work. Give it a try or get another more capable controller. Hard or soft sectoring Most ESDI drives allow hard or soft sectoring to be selected using a jumper. Hard sectoring means that the drive will produce a sector pulse on the start of each new sector. The controller uses this pulse to tell when it should start to write or read. Hard sectoring allows a selection of sector size (normally 256, 512 or 1024 bytes per formatted sector). FreeBSD uses 512 byte sectors. The number of sectors per track also varies while still using the same number of bytes per formatted sector. The number of unformatted bytes per sector varies, dependent on your controller it needs more or less overhead bytes to work correctly. Pushing more sectors on a track of course gives you more usable space, but might give problems if your controller needs more bytes than the drive offers. In case of soft sectoring, the controller itself determines where to start/stop reading or writing. For ESDI hard sectoring is the default (at least on everything I came across). I never felt the urge to try soft sectoring. In general, experiment with sector settings before you install FreeBSD because you need to re-run the low-level format after each change. Low level formatting ESDI drives need to be low level formatted before they are usable. A reformat is needed whenever you figgle with the number of sectors/track jumpers or the physical orientation of the drive (horizontal, vertical). So, first think, then format. The format time must not be underestimated, for big disks it can take hours. After a low level format, a surface scan is done to find and flag bad sectors. Most disks have a manufacturer bad block list listed on a piece of paper or adhesive sticker. In addition, on most disks the list is also written onto the disk. Please use the manufacturer's list. It is much easier to remap a defect now than after FreeBSD is installed. Stay away from low-level formatters that mark all sectors of a track as bad as soon as they find one bad sector. Not only does this waste space, it also and more importantly causes you grief with bad144 (see the section on bad144). Translations Translations, although not exclusively a ESDI-only problem, might give you real trouble. Translations come in multiple flavors. Most of them have in common that they attempt to work around the limitations posed upon disk geometries by the original IBM PC/AT design (thanks IBM!). First of all there is the (in)famous 1024 cylinder limit. For a system to be able to boot, the stuff (whatever operating system) must be in the first 1024 cylinders of a disk. Only 10 bits are available to encode the cylinder number. For the number of sectors the limit is 64 (0-63). When you combine the 1024 cylinder limit with the 16 head limit (also a design feature) you max out at fairly limited disk sizes. To work around this problem, the manufacturers of ESDI PC controllers added a BIOS prom extension on their boards. This BIOS extension handles disk I/O for booting (and for some operating systems all disk I/O) by using translation. For instance, a big drive might be presented to the system as having 32 heads and 64 sectors/track. The result is that the number of cylinders is reduced to something below 1024 and is therefore usable by the system without problems. It is noteworthy to know that FreeBSD does not use the BIOS after its kernel has started. More on this later. A second reason for translations is the fact that most older system BIOSes could only handle drives with 17 sectors per track (the old ST412 standard). Newer system BIOSes usually have a user-defined drive type (in most cases this is drive type 47). Whatever you do to translations after reading this document, keep in mind that if you have multiple operating systems on the same disk, all must use the same translation While on the subject of translations, I have seen one controller type (but there are probably more like this) offer the option to logically split a drive in multiple partitions as a BIOS option. I had select 1 drive == 1 partition because this controller wrote this info onto the disk. On power-up it read the info and presented itself to the system based on the info from the disk. Spare sectoring Most ESDI controllers offer the possibility to remap bad sectors. During/after the low-level format of the disk bad sectors are marked as such, and a replacement sector is put in place (logically of course) of the bad one. In most cases the remapping is done by using N-1 sectors on each track for actual data storage, and sector N itself is the spare sector. N is the total number of sectors physically available on the track. The idea behind this is that the operating system sees a 'perfect' disk without bad sectors. In the case of FreeBSD this concept is not usable. The problem is that the translation from bad to good is performed by the BIOS of the ESDI controller. FreeBSD, being a true 32 bit operating system, does not use the BIOS after it has been booted. Instead, it has device drivers that talk directly to the hardware. So: don't use spare sectoring, bad block remapping or whatever it may be called by the controller manufacturer when you want to use the disk for FreeBSD. Bad block handling The preceding section leaves us with a problem. The controller's bad block handling is not usable and still FreeBSD's filesystems assume perfect media without any flaws. To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a Digital Equipment standard for bad block handling) scans a FreeBSD slice for bad blocks. Having found these bad blocks, it writes a table with the offending block numbers to the end of the FreeBSD slice. When the disk is in operation, the disk accesses are checked against the table read from the disk. Whenever a block number is requested that is in the bad144 list, a replacement block (also from the end of the FreeBSD slice) is used. In this way, the bad144 replacement scheme presents 'perfect' media to the FreeBSD filesystems. There are a number of potential pitfalls associated with the use of bad144. First of all, the slice cannot have more than 126 bad sectors. If your drive has a high number of bad sectors, you might need to divide it into multiple FreeBSD slices each containing less than 126 bad sectors. Stay away from low-level format programs that mark every sector of a track as bad when they find a flaw on the track. As you can imagine, the 126 limit is quickly reached when the low-level format is done this way. Second, if the slice contains the root filesystem, the slice should be within the 1024 cylinder BIOS limit. During the boot process the bad144 list is read using the BIOS and this only succeeds when the list is within the 1024 cylinder limit. The restriction is not that only the root filesystem must be within the 1024 cylinder limit, but rather the entire slice that contains the root filesystem. Kernel configuration ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The wd driver should work for all WD1003 compatible interfaces. Most hardware is jumperable for one of two different I/O address ranges and IRQ lines. This allows you to have two wd type controllers in one system. When your hardware allows non-standard strappings, you can use these with FreeBSD as long as you enter the correct info into the kernel config file. An example from the kernel config file (they live in /sys/i386/conf BTW). # First WD compatible controller controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # Second WD compatible controller controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 Particulars on ESDI hardware Adaptec 2320 controllers I successfully installed FreeBSD onto a ESDI disk controlled by a ACB-2320. No other operating system was present on the disk. To do so I low level formatted the disk using NEFMT.EXE (ftpable from www.adaptec.com) and answered NO to the question whether the disk should be formatted with a spare sector on each track. The BIOS on the ACD-2320 was disabled. I used the free configurable option in the system BIOS to allow the BIOS to boot it. Before using NEFMT.EXE I tried to format - the disk using the ACB-2320 BIOS builtin formatter. This proved + the disk using the ACB-2320 BIOS built-in formatter. This proved to be a show stopper, because it did not give me an option to disable spare sectoring. With spare sectoring enabled the FreeBSD installation process broke down on the bad144 run. Please check carefully which ACB-232xy variant you have. The x is either 0 or 2, indicating a controller without or with a floppy controller on board. The y is more interesting. It can either be a blank, a A-8 or a D. A blank indicates a plain 10 Mbits/second controller. An A-8 indicates a 15 Mbits/second controller capable of handling 52 sectors/track. A D means a 15 Mbits/second controller that can also handle drives with > 36 sectors/track (also 52 ?). All variations should be capable of using 1:1 interleaving. Use 1:1, FreeBSD is fast enough to handle it. Western Digital WD1007 controllers I successfully installed FreeBSD onto a ESDI disk controlled by a WD1007 controller. To be precise, it was a WD1007-WA2. Other variations of the WD1007 do exist. To get it to work, I had to disable the sector translation and the WD1007's onboard BIOS. This implied I could not use the low-level formatter built into this BIOS. Instead, I grabbed WDFMT.EXE from www.wdc.com Running this formatted my drive just fine. Ultrastor U14F controllers According to multiple reports from the net, Ultrastor ESDI boards work OK with FreeBSD. I lack any further info on particular settings. Further reading If you intend to do some serious ESDI hacking, you might want to have the official standard at hand: The latest ANSI X3T10 committee document is: Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] On Usenet the newsgroup comp.periphs is a noteworthy place to look for more info. The World Wide Web (WWW) also proves to be a very handy info source: For info on Adaptec ESDI controllers see http://www.adaptec.com/. For info on Western Digital controllers see http://www.wdc.com/. Thanks to... Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk for testing. What is SCSI? Copyright © 1995, &a.wilko;. July 6, 1996. SCSI is an acronym for Small Computer Systems Interface. It is an ANSI standard that has become one of the leading I/O buses in the computer industry. The foundation of the SCSI standard was laid by Shugart Associates (the same guys that gave the world the first mini floppy disks) when they introduced the SASI bus (Shugart Associates Standard Interface). After some time an industry effort was started to come to a more strict standard allowing devices from different vendors to work together. This effort was recognized in the ANSI SCSI-1 standard. - The SCSI-1 standard (approx 1985) is rapidly becoming obsolete. The + The SCSI-1 standard (approximately 1985) is rapidly becoming obsolete. The current standard is SCSI-2 (see Further reading), with SCSI-3 on the drawing boards. In addition to a physical interconnection standard, SCSI defines a logical (command set) standard to which disk devices must adhere. This standard is called the Common Command Set (CCS) and was developed more or less in parallel with ANSI SCSI-1. SCSI-2 includes the (revised) CCS as part of the standard itself. The commands are dependent on the type of device at hand. It does not make much sense of course to define a Write command for a scanner. The SCSI bus is a parallel bus, which comes in a number of variants. The oldest and most used is an 8 bit wide bus, with single-ended signals, carried on 50 wires. (If you do not know what single-ended means, do not worry, that is what this document is all about.) Modern designs also use 16 bit wide buses, with differential signals. This allows transfer speeds of 20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2 allows a maximum bus width of 32 bits, using an additional cable. Quickly emerging are Ultra SCSI (also called Fast-20) and Ultra2 (also called Fast-40). Fast-20 is 20 million transfers per second (20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 million transfers per second (40 Mbytes/sec on a 8 bit bus). Most hard drives sold today are single-ended Ultra SCSI (8 or 16 bits). Of course the SCSI bus not only has data lines, but also a number of control signals. A very elaborate protocol is part of the standard to allow multiple devices to share the bus in an efficient manner. In SCSI-2, the data is always checked using a separate parity line. In pre-SCSI-2 designs parity was optional. In SCSI-3 even faster bus types are introduced, along with a serial SCSI busses that reduces the cabling overhead and allows a higher maximum bus length. You might see names like SSA and - Fiberchannel in this context. None of the serial buses are currently + fibre channel in this context. None of the serial buses are currently in widespread use (especially not in the typical FreeBSD environment). For this reason the serial bus types are not discussed any further. As you could have guessed from the description above, SCSI devices are intelligent. They have to be to adhere to the SCSI standard (which is over 2 inches thick BTW). So, for a hard disk drive for instance you do not specify a head/cylinder/sector to address a particular block, but simply the number of the block you want. Elaborate caching schemes, automatic bad block replacement etc are all made possible by this 'intelligent device' approach. On a SCSI bus, each possible pair of devices can communicate. Whether their function allows this is another matter, but the standard does not restrict it. To avoid signal contention, the 2 devices have to arbitrate for the bus before using it. The philosophy of SCSI is to have a standard that allows older-standard devices to work with newer-standard ones. So, an old SCSI-1 device should normally work on a SCSI-2 bus. I say Normally, because it is not absolutely sure that the implementation of an old device follows the (old) standard closely enough to be acceptable on a new bus. Modern devices are usually more well-behaved, because the standardization has become more strict and is better adhered to by the device manufacturers. Generally speaking, the chances of getting a working set of devices on a single bus is better when all the devices are SCSI-2 or newer. This implies that you do not have to dump all your old stuff when you get that shiny 2GB disk: I own a system on which a pre-SCSI-1 disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan tape unit and 2 SCSI-1 disks work together quite happily. From a performance standpoint you might want to separate your older and newer (=faster) devices however. Components of SCSI As said before, SCSI devices are smart. The idea is to put the knowledge about intimate hardware details onto the SCSI device itself. In this way, the host system does not have to worry about things like how many heads are hard disks has, or how many tracks there are on a specific tape device. If you are curious, the standard specifies commands with which you can query your devices on their hardware particulars. FreeBSD uses this capability during boot to check out what devices are connected and whether they need any special treatment. The advantage of intelligent devices is obvious: the device drivers on the host can be made in a much more generic fashion, there is no longer a need to change (and qualify!) drivers for every odd new device that is introduced. For cabling and connectors there is a golden rule: get good stuff. With bus speeds going up all the time you will save yourself a lot of grief by using good material. So, gold plated connectors, shielded cabling, sturdy connector hoods with strain reliefs etc are the way to go. Second golden rule: do no use cables longer than necessary. I once spent 3 days hunting down a problem with a flaky machine only to discover that shortening the SCSI bus by 1 meter solved the problem. And the original bus length was well within the SCSI specification. SCSI bus types From an electrical point of view, there are two incompatible bus types: single-ended and differential. This means that there are two different main groups of SCSI devices and controllers, which cannot be mixed on the same bus. It is possible however to use special converter hardware to transform a single-ended bus into a differential one (and vice versa). The differences between the bus types are explained in the next sections. In lots of SCSI related documentation there is a sort of jargon in use to abbreviate the different bus types. A small list: FWD: Fast Wide Differential FND: Fast Narrow Differential SE: Single Ended FN: Fast Narrow etc. With a minor amount of imagination one can usually imagine what is meant. Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As far as I know, the 32 bit variant is not (yet) in use, so wide normally means 16 bit. Fast means that the timing on the bus is somewhat different, so that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead of 5 Mbytes/sec for 'slow' SCSI. As discussed before, bus speeds of 20 and 40 million transfers/second are also emerging (Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI). The data lines > 8 are only used for data transfers and device addressing. The transfers of commands and status messages etc are only performed on the lowest 8 data lines. The standard allows narrow devices to operate on a wide bus. The usable bus width is negotiated between the devices. You have to watch your device addressing closely when mixing wide and narrow. Single ended buses A single-ended SCSI bus uses signals that are either 5 Volts or 0 Volts (indeed, TTL levels) and are relative to a COMMON ground reference. A singled ended 8 bit SCSI bus has approximately 25 ground lines, who are all tied to a single `rail' on all devices. A standard single ended bus has a maximum length of 6 meters. If the same bus is used with fast-SCSI devices, the maximum length allowed drops to 3 meters. Fast-SCSI means that instead of 5Mbytes/sec the bus allows 10Mbytes/sec transfers. Fast-20 (Ultra SCSI) and Fast-40 allow for 20 and 40 million transfers/second respectively. So, F20 is 20 Mbytes/second on a 8 bit bus, 40 Mbytes/second on a 16 bit bus etc. For F20 the max bus length is 1.5 meters, for F40 it becomes 0.75 meters. Be aware that F20 is pushing the limits quite a bit, so you will quickly find out if your SCSI bus is electrically sound. If some devices on your bus use 'fast' to communicate your bus must adhere to the length restrictions for fast buses! It is obvious that with the newer fast-SCSI devices the bus length can become a real bottleneck. This is why the differential SCSI bus was introduced in the SCSI-2 standard. For connector pinning and connector types please refer to the SCSI-2 standard (see Further reading) itself, connectors etc are listed there in painstaking detail. Beware of devices using non-standard cabling. For instance Apple uses a 25pin D-type connecter (like the one on serial ports and parallel printers). Considering that the official SCSI bus needs 50 pins you can imagine the use of this connector needs some 'creative cabling'. The reduction of the number of ground wires they used is a bad idea, you better stick to 50 pins cabling in accordance with the SCSI standard. For Fast-20 and 40 do not even think about buses like this. Differential buses A differential SCSI bus has a maximum length of 25 meters. Quite a difference from the 3 meters for a single-ended fast-SCSI bus. The idea behind differential signals is that each bus signal has its own return wire. So, each signal is carried on a (preferably twisted) pair of wires. The voltage difference between these two wires determines whether the signal is asserted or de-asserted. To a certain extent the voltage difference between ground and the signal wire pair is not relevant (do not try 10 kVolts though). It is beyond the scope of this document to explain why this differential idea is so much better. Just accept that electrically seen the use of differential signals gives a much better noise margin. You will normally find differential buses in use for inter-cabinet connections. Because of the lower cost single ended is mostly used for shorter buses like inside cabinets. There is nothing that stops you from using differential stuff with FreeBSD, as long as you use a controller that has device driver support in FreeBSD. As an example, Adaptec marketed the AHA1740 as a single ended board, whereas the AHA1744 was differential. The software interface to the host is identical for both. Terminators Terminators in SCSI terminology are resistor networks that are used to get a correct impedance matching. Impedance matching is important to get clean signals on the bus, without reflections or ringing. If you once made a long distance telephone call on a bad line you probably know what reflections are. With 20Mbytes/sec traveling over your SCSI bus, you do not want signals echoing back. Terminators come in various incarnations, with more or less sophisticated designs. Of course, there are internal and external variants. Many SCSI devices come with a number of sockets in which a number of resistor networks can (must be!) installed. If you remove terminators from a device, carefully store them. You will need them when you ever decide to reconfigure your SCSI bus. There is enough variation in even these simple tiny things to make finding the exact replacement a frustrating business. There are also SCSI devices that have a single jumper to enable or disable a built-in terminator. There are special terminators you can stick onto a flat cable bus. Others look like external connectors, or a connector hood without a cable. So, lots of choice as you can see. There is much debate going on if and when you should switch from simple resistor (passive) terminators to active terminators. Active terminators contain slightly more elaborate circuit to give cleaner bus signals. The general consensus seems to be that the usefulness of active termination increases when you have long buses and/or fast devices. If you ever have problems with your SCSI buses you might consider trying an active terminator. Try to borrow one first, they reputedly are quite expensive. Please keep in mind that terminators for differential and single-ended buses are not identical. You should not mix the two variants. OK, and now where should you install your terminators? This is by far the most misunderstood part of SCSI. And it is by far the simplest. The rule is: every single line on the SCSI bus has 2 (two) terminators, one at each end of the bus. So, two and not one or three or whatever. Do yourself a favor and stick to this rule. It will save you endless grief, because wrong termination has the potential to introduce highly mysterious bugs. (Note the potential here; the nastiest part is that it may or may not work.) A common pitfall is to have an internal (flat) cable in a machine and also an external cable attached to the controller. It seems almost everybody forgets to remove the terminators from the controller. The terminator must now be on the last external device, and not on the controller! In general, every reconfiguration of a SCSI bus must pay attention to this. Termination is to be done on a per-line basis. This means if you have both narrow and wide buses connected to the same host adapter, you need to enable termination on the higher 8 bits of the bus on the adapter (as well as the last devices on each bus, of course). What I did myself is remove all terminators from my SCSI devices and controllers. I own a couple of external terminators, for both the Centronics-type external cabling and for the internal flat cable connectors. This makes reconfiguration much easier. On modern devices, sometimes integrated terminators are used. These things are special purpose integrated circuits that can be - dis/en-abled with a control pin. It is not necessary to + enabled or disabled with a control pin. It is not necessary to physically remove them from a device. You may find them on newer host adapters, sometimes they are software configurable, using some sort of setup tool. Some will even auto-detect the cables attached to the connectors and automatically set up the termination as necessary. At any rate, consult your documentation! Terminator power The terminators discussed in the previous chapter need power to operate properly. On the SCSI bus, a line is dedicated to this purpose. So, simple huh? Not so. Each device can provide its own terminator power to the terminator sockets it has on-device. But if you have external terminators, or when the device supplying the terminator power to the SCSI bus line is switched off you are in trouble. The idea is that initiators (these are devices that initiate actions on the bus, a discussion follows) must supply terminator power. All SCSI devices are allowed (but not required) to supply terminator power. To allow for un-powered devices on a bus, the terminator power must be supplied to the bus via a diode. This prevents the backflow of current to un-powered devices. To prevent all kinds of nastiness, the terminator power is usually fused. As you can imagine, fuses might blow. This can, but does not have to, lead to a non functional bus. If multiple devices supply terminator power, a single blown fuse will not put you out of business. A single supplier with a blown fuse certainly will. Clever external terminators sometimes have a LED indication that shows whether terminator power is present. In newer designs auto-restoring fuses that 'reset' themselves after some time are sometimes used. Device addressing Because the SCSI bus is, ehh, a bus there must be a way to distinguish or address the different devices connected to it. This is done by means of the SCSI or target ID. Each device has a unique target ID. You can select the ID to which a device must respond using a set of jumpers, or a dip switch, or something similar. Some SCSI host adapters let you change the target ID from the boot menu. (Yet some others will not let you change the ID from 7.) Consult the documentation of your device for more information. Beware of multiple devices configured to use the same ID. Chaos normally reigns in this case. A pitfall is that one of the devices sharing the same ID sometimes even manages to answer to I/O requests! For an 8 bit bus, a maximum of 8 targets is possible. The maximum is 8 because the selection is done bitwise using the 8 data lines on the bus. For wide buses this increases to the number of data lines (usually 16). A narrow SCSI device can not communicate with a SCSI device with a target ID larger than 7. This means it is generally not a good idea to move your SCSI host adapter's target ID to - something higher than 7 (or your CD-ROM will stop + something higher than 7 (or your CDROM will stop working). The higher the SCSI target ID, the higher the priority the devices has. When it comes to arbitration between devices that want to use the bus at the same time, the device that has the highest SCSI ID will win. This also means that the SCSI host adapter usually uses target ID 7. Note however that the lower 8 IDs have higher priorities than the higher 8 IDs on a wide-SCSI bus. Thus, the order of target IDs is: [7 6 .. 1 0 15 14 .. 9 8] on a wide-SCSI system. (If you you are wondering why the lower 8 have higher priority, read the previous paragraph for a hint.) For a further subdivision, the standard allows for Logical Units or LUNs for short. A single target ID may have multiple LUNs. For example, a tape device including a tape changer may have LUN 0 for the tape device itself, and LUN 1 for the tape changer. In this way, the host system can address each of the functional units of the tape changer as desired. Bus layout SCSI buses are linear. So, not shaped like Y-junctions, star topologies, rings, cobwebs or whatever else people might want to invent. One of the most common mistakes is for people with wide-SCSI host adapters to connect devices on all three connecters (external connector, internal wide connector, internal narrow connector). Don't do that. It may appear to work if you are really lucky, but I can almost guarantee that your system will stop functioning at the most unfortunate moment (this is also known as Murphy's law). You might notice that the terminator issue discussed earlier becomes rather hairy if your bus is not linear. Also, if you have more connectors than devices on your internal SCSI cable, make sure you attach devices on connectors on both ends instead of using the connectors in the middle and let one or both ends dangle. This will screw up the termination of the bus. The electrical characteristics, its noise margins and ultimately the reliability of it all are tightly related to linear bus rule. Stick to the linear bus rule! Using SCSI with FreeBSD About translations, BIOSes and magic... As stated before, you should first make sure that you have a electrically sound bus. When you want to use a SCSI disk on your PC as boot disk, you must aware of some quirks related to PC BIOSes. The PC BIOS in its first incarnation used a low level physical interface to the hard disk. So, you had to tell the BIOS (using a setup tool or a BIOS built-in setup) how your disk physically looked like. This involved stating number of heads, number of cylinders, number of sectors per track, obscure things like precompensation and reduced write current cylinder etc. One might be inclined to think that since SCSI disks are smart you can forget about this. Alas, the arcane setup issue is still present today. The system BIOS needs to know how to access your SCSI disk with the head/cyl/sector method in order to load the FreeBSD kernel during boot. The SCSI host adapter or SCSI controller you have put in your AT/EISA/PCI/whatever bus to connect your disk therefore has its own on-board BIOS. During system startup, the SCSI BIOS takes over the hard disk interface routines from the system BIOS. To fool the system BIOS, the system setup is normally set to No hard disk present. Obvious, isn't it? The SCSI BIOS itself presents to the system a so called translated drive. This means that a fake drive table is constructed that allows the PC to boot the drive. This translation is often (but not always) done using a pseudo drive with 64 heads and 32 sectors per track. By varying the number of cylinders, the SCSI BIOS adapts to the actual drive size. It is useful to note that 32 * 64 / 2 = the size of your drive in megabytes. The division by 2 is to get from disk blocks that are normally 512 bytes in size to Kbytes. Right. All is well now?! No, it is not. The system BIOS has another quirk you might run into. The number of cylinders of a bootable hard disk cannot be greater than 1024. Using the translation above, this is a show-stopper for disks greater than 1 GB. With disk capacities going up all the time this is causing problems. Fortunately, the solution is simple: just use another translation, e.g. with 128 heads instead of 32. In most cases new SCSI BIOS versions are available to upgrade older SCSI host adapters. Some newer adapters have an option, in the form of a jumper or software setup selection, to switch the translation the SCSI BIOS uses. It is very important that all operating systems on the disk use the same translation to get the right idea about where to find the relevant partitions. So, when installing FreeBSD you must answer any questions about heads/cylinders etc using the translated values your host adapter uses. Failing to observe the translation issue might lead to un-bootable systems or operating systems overwriting each others partitions. Using fdisk you should be able to see all partitions. You might have heard some talk of lying devices? Older FreeBSD kernels used to report the geometry of SCSI disks when booting. An example from one of my systems: aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4> sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 Newer kernels usually do not report this information. e.g. (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) Why has this changed? This info is retrieved from the SCSI disk itself. Newer disks often use a technique called zone bit recording. The idea is that on the outer cylinders of the drive there is more space so more sectors per track can be put on them. This results in disks that have more tracks on outer cylinders than on the inner cylinders and, last but not least, have more capacity. You can imagine that the value reported by the drive when inquiring about the geometry now becomes suspect at best, and nearly always misleading. When asked for a geometry , it is nearly always better to supply the geometry used by the BIOS, or if the BIOS is never going to know about this disk, (e.g. it is not a booting disk) to supply a fictitious geometry that is convenient. SCSI subsystem design FreeBSD uses a layered SCSI subsystem. For each different controller card a device driver is written. This driver knows all the intimate details about the hardware it controls. The driver has a interface to the upper layers of the SCSI subsystem through which it receives its commands and reports back any status. On top of the card drivers there are a number of more generic drivers for a class of devices. More specific: a driver for tape - devices (abbreviation: st), magnetic disks (sd), CD-ROMs (cd) etc. + devices (abbreviation: st), magnetic disks (sd), CDROMs (cd) etc. In case you are wondering where you can find this stuff, it all lives in /sys/scsi. See the man pages in section 4 for more details. The multi level design allows a decoupling of low-level bit banging and more high level stuff. Adding support for another piece of hardware is a much more manageable problem. Kernel configuration Dependent on your hardware, the kernel configuration file must contain one or more lines describing your host adapter(s). This includes I/O addresses, interrupts etc. Consult the man page for your adapter driver to get more info. Apart from that, check out /sys/i386/conf/LINT for an overview of a kernel config file. LINT contains every possible option you can dream of. It does not imply LINT will actually get you to a working kernel at all. Although it is probably stating the obvious: the kernel config file should reflect your actual hardware setup. So, interrupts, I/O addresses etc must match the kernel config file. During system boot messages will be displayed to indicate whether the configured hardware was actually found. Note that most of the EISA/PCI drivers (namely ahb, ahc, ncr and amd will automatically obtain the correct parameters from the host adapters themselves at boot time; thus, you just need to write, for instance, controller ahc0. An example loosely based on the FreeBSD 2.2.5-Release kernel config file LINT with some added comments (between []): # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [For an Adaptec AHA274x/284x/294x/394x etc controller] controller ahc0 [For an NCR/Symbios 53c875 based controller] controller ncr0 [For an Ultrastor adapter] controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr # Map SCSI buses to specific SCSI adapters controller scbus0 at ahc0 controller scbus2 at ncr0 controller scbus1 at uha0 # The actual SCSI devices disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0] disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted] disk sd2 at scbus1 target 3 [SCSI disk on the uha0] disk sd3 at scbus2 target 4 [SCSI disk on the ncr0] tape st1 at scbus0 target 6 [SCSI tape at target 6] -device cd0 at scbus? [the first ever CD-ROM found, no wiring] +device cd0 at scbus? [the first ever CDROM found, no wiring] The example above tells the kernel to look for a ahc (Adaptec 274x) controller, then for an NCR/Symbios board, and so on. The lines following the controller specifications tell the kernel to configure specific devices but only attach them when they match the target ID and LUN specified on the corresponding bus. Wired down devices get first shot at the unit numbers so the first non wired down device, is allocated the unit number one greater than the highest wired down unit number for that kind of device. So, if you had a SCSI tape at target ID 2 it would be configured as st2, as the tape at target ID 6 is wired down to unit number 1. Wired down devices need not be found to get their unit number. The unit number for a wired down device is reserved for that device, even if it is turned off at boot time. This allows the device to be turned on and brought on-line at a later time, without rebooting. Notice that a device's unit number has no relationship with its target ID on the SCSI bus. Below is another example of a kernel config file as used by FreeBSD version < 2.0.5. The difference with the first example is that devices are not wired down. Wired down means that you specify which SCSI target belongs to which device. A kernel built to the config file below will attach the first SCSI disk it finds to sd0, the second disk to sd1 etc. If you ever removed or added a disk, all other devices of the same type (disk in this case) would 'move around'. This implies you have to change /etc/fstab each time. Although the old style still works, you are strongly recommended to use this new feature. It will save you a lot of grief whenever you shift your hardware around on the SCSI buses. So, when you re-use your old trusty config file after upgrading from a pre-FreeBSD2.0.5.R system check this out. [driver for Adaptec 174x] controller ahb0 at isa? bio irq 11 vector ahbintr [for Adaptec 154x] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [for Seagate ST01/02] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 [support for 4 SCSI harddisks, sd0 up sd3] device st0 [support for 2 SCSI tapes] -[for the CD-ROM] +[for the CDROM] device cd0 #Only need one of these, the code dynamically grows Both examples support SCSI disks. If during boot more devices of a specific type (e.g. sd disks) are found than are configured in the booting kernel, the system will simply allocate more devices, incrementing the unit number starting at the last number wired down. If there are no wired down devices then counting starts at unit 0. Use man 4 scsi to check for the latest info on the SCSI subsystem. For more detailed info on host adapter - drivers use eg man 4 ahc for info on the + drivers use e.g., man 4 ahc for info on the Adaptec 294x driver. Tuning your SCSI kernel setup Experience has shown that some devices are slow to respond to INQUIRY commands after a SCSI bus reset (which happens at boot time). An INQUIRY command is sent by the kernel on boot to see - what kind of device (disk, tape, CD-ROM etc) is connected to a + what kind of device (disk, tape, CDROM etc.) is connected to a specific target ID. This process is called device probing by the way. To work around the 'slow response' problem, FreeBSD allows a tunable delay time before the SCSI devices are probed following a SCSI bus reset. You can set this delay time in your kernel configuration file using a line like: options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device This line sets the delay time to 15 seconds. On my own system - I had to use 3 seconds minimum to get my trusty old CD-ROM drive + I had to use 3 seconds minimum to get my trusty old CDROM drive to be recognized. Start with a high value (say 30 seconds or so) when you have problems with device recognition. If this helps, tune it back until it just stays working. Rogue SCSI devices Although the SCSI standard tries to be complete and concise, it is a complex standard and implementing things correctly is no easy task. Some vendors do a better job then others. This is exactly where the rogue devices come into view. Rogues are devices that are recognized by the FreeBSD kernel as behaving slightly (...) non-standard. Rogue devices are reported by the kernel when booting. An example for two of my cartridge tape units: Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:> Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005> Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue For instance, there are devices that respond to all LUNs on a certain target ID, even if they are actually only one device. It is easy to see that the kernel might be fooled into believing that there are 8 LUNs at that particular target ID. The confusion this causes is left as an exercise to the reader. The SCSI subsystem of FreeBSD recognizes devices with bad habits by looking at the INQUIRY response they send when probed. Because the INQUIRY response also includes the version number of the device firmware, it is even possible that for different firmware versions different workarounds are used. See e.g. /sys/scsi/st.c and /sys/scsi/scsiconf.c for more info on how this is done. This scheme works fine, but keep in mind that it of course only works for devices that are known to be weird. If you are the - first to connect your bogus Mumbletech SCSI CD-ROM you might be + first to connect your bogus Mumbletech SCSI CDROM you might be the one that has to define which workaround is needed. After you got your Mumbletech working, please send the required workaround to the FreeBSD development team for inclusion in the next release of FreeBSD. Other Mumbletech owners will be grateful to you. Multiple LUN devices In some cases you come across devices that use multiple logical units (LUNs) on a single SCSI ID. In most cases FreeBSD only probes devices for LUN 0. An example are so called bridge boards that connect 2 non-SCSI harddisks to a SCSI bus (e.g. an Emulex MD21 found in old Sun systems). This means that any devices with LUNs != 0 are not normally found during device probe on system boot. To work around this problem you must add an appropriate entry in /sys/scsi/scsiconf.c and rebuild your kernel. Look for a struct that is initialized like below: { T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", "mx1", SC_ONE_LU } For you Mumbletech BRIDGE2000 that has more than one LUN, acts as a SCSI disk and has firmware revision 123 you would add something like: { T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123", "sd", SC_MORE_LUS } The kernel on boot scans the inquiry data it receives against the table and acts accordingly. See the source for more info. - Tagged command queueing + Tagged command queuing Modern SCSI devices, particularly magnetic disks, support what is called tagged command queuing (TCQ). In a nutshell, TCQ allows the device to have multiple I/O requests outstanding at the same time. Because the device is - intelligent, it can optimise its operations (like head + intelligent, it can optimize its operations (like head positioning) based on its own request queue. On SCSI devices like RAID (Redundant Array of Independent Disks) arrays the TCQ function is indispensable to take advantage of the device's inherent parallelism. Each I/O request is uniquely identified by a tag (hence the name tagged command queuing) and this tag is used by FreeBSD to see which I/O in the device drivers queue is reported as complete by the device. It should be noted however that TCQ requires device driver support and that some devices implemented it not quite right in their firmware. This problem bit me once, and it leads to highly mysterious problems. In such cases, try to disable TCQ. Busmaster host adapters Most, but not all, SCSI host adapters are bus mastering controllers. This means that they can do I/O on their own without putting load onto the host CPU for data movement. This is of course an advantage for a multitasking operating system like FreeBSD. It must be noted however that there might be some rough edges. For instance an Adaptec 1542 controller can be set to use different transfer speeds on the host bus (ISA or AT in this case). The controller is settable to different rates because not all motherboards can handle the higher speeds. Problems like - hangups, bad data etc might be the result of using a higher data + hang-ups, bad data etc might be the result of using a higher data transfer rate then your motherboard can stomach. The solution is of course obvious: switch to a lower data transfer rate and try if that works better. In the case of a Adaptec 1542, there is an option that can be put into the kernel config file to allow dynamic determination of the right, read: fastest feasible, transfer rate. This option is disabled by default: options "TUNE_1542" #dynamic tune of bus DMA speed Check the man pages for the host adapter that you use. Or better still, use the ultimate documentation (read: driver source). Tracking down problems The following list is an attempt to give a guideline for the most common SCSI problems and their solutions. It is by no means complete. Check for loose connectors and cables. Check and double check the location and number of your terminators. Check if your bus has at least one supplier of terminator power (especially with external terminators. Check if no double target IDs are used. Check if all devices to be used are powered up. Make a minimal bus config with as little devices as possible. If possible, configure your host adapter to use slow bus speeds. Disable tagged command queuing to make things as simple as - possible (for a NCR hostadapter based system see man + possible (for a NCR host adapter based system see man ncrcontrol) If you can compile a kernel, make one with the SCSIDEBUG option, and try accessing the device with debugging turned on for that device. If your device does not even probe at startup, you may have to define the address of the device that is failing, and the desired debug level in /sys/scsi/scsidebug.h. If it probes but just does not work, you can use the &man.scsi.8; command to dynamically set a debug level to it in a running kernel (if SCSIDEBUG is defined). This will give you copious debugging output with which to confuse the gurus. See man 4 scsi for more exact information. Also look at man 8 scsi. Further reading If you intend to do some serious SCSI hacking, you might want to have the official standard at hand: Approved American National Standards can be purchased from ANSI at
13th Floor 11 West 42nd Street New York NY 10036 Sales Dept: (212) 642-4900
You can also buy many ANSI standards and most committee draft documents from Global Engineering Documents,
15 Inverness Way East Englewood CO, 80112-5704 Phone: (800) 854-7179 Outside USA and Canada: (303) 792-2181 Fax: (303) 792- 2192
Many X3T10 draft documents are available electronically on the SCSI BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous ftp site. Latest X3T10 committee documents are: AT Attachment (ATA or IDE) [X3.221-1994] (Approved) ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved) Small Computer System Interface — 2 (SCSI-2) [X3.131-1994] (Approved) SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] Other publications that might provide you with additional information are: SCSI: Understanding the Small Computer System Interface, written by NCR Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 Basics of SCSI, a SCSI tutorial written by Ancot Corporation Contact Ancot for availability information at: Phone: (415) 322-5322 Fax: (415) 322-0455 SCSI Interconnection Guide Book, an AMP publication (dated 4/93, Catalog 65237) that lists the various SCSI connectors and suggests cabling schemes. Available from AMP at (800) 522-6752 or (717) 564-0100 Fast Track to SCSI, A Product Guide written by Fujitsu. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X The SCSI Bench Reference, The SCSI Encyclopedia, and the SCSI Tutor, ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642 Zadian SCSI Navigator (quick ref. book) and Discover the Power of SCSI (First book along with a one-hour video and tutorial book), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 On Usenet the newsgroups comp.periphs.scsi and comp.periphs are noteworthy places to look for more info. You can also find the SCSI-Faq there, which is posted periodically. Most major SCSI device and host adapter suppliers operate ftp sites and/or BBS systems. They may be valuable sources of information about the devices you own. * Disk/tape controllers * SCSI * IDE * Floppy Hard drives SCSI hard drives Contributed by &a.asami;. 17 February 1998. As mentioned in the SCSI section, virtually all SCSI hard drives sold today are SCSI-2 compliant and thus will work fine as long as you connect them to a supported SCSI host adapter. Most problems people encounter are either due to badly designed cabling (cable too long, star topology, etc.), insufficient termination, or defective parts. Please refer to the SCSI section first if your SCSI hard drive is not working. However, there are a couple of things you may want to take into account before you purchase SCSI hard drives for your system. Rotational speed Rotational speeds of SCSI drives sold today range from around 4,500RPM to 10,000RPM. Most of them are either 5,400RPM or 7,200RPM. Even though the 7,200RPM drives can generally transfer data faster, they run considerably hotter than their 5,400RPM counterparts. A large fraction of today's disk drive malfunctions are heat-related. If you do not have very good cooling in your PC case, you may want to stick with 5,400RPM or slower drives. Note that newer drives, with higher areal recording densities, can deliver much more bits per rotation than older ones. Today's top-of-line 5,400RPM drives can sustain a throughput comparable to 7,200RPM drives of one or two model generations ago. The number to find on the spec sheet for bandwidth is internal data (or transfer) rate. It is usually in megabits/sec so divide it by 8 and you'll get the rough approximation of how much megabytes/sec you can get out of the drive. (If you are a speed maniac and want a 10,000RPM drive for your - cute little peecee, be my guest; however, those drives become + cute little PC, be my guest; however, those drives become extremely hot. Don't even think about it if you don't have a fan blowing air directly at the drive or a properly ventilated disk enclosure.) Obviously, the latest 10,000RPM drives and 7,200RPM drives can deliver more data than the latest 5,400RPM drives, so if absolute bandwidth is the necessity for your applications, you have little choice but to get the faster drives. Also, if you need low latency, faster drives are better; not only do they usually have lower average seek times, but also the rotational delay is one place where slow-spinning drives can never beat a faster one. (The average rotational latency is half the time it takes to rotate the drive once; thus, it's 3 milliseconds for 10,000RPM drives, 4.2ms for 7,200RPM drives and 5.6ms for 5,400RPM drives.) Latency is seek time plus rotational delay. Make sure you understand whether you need low latency or more accesses per second, though; in the latter case (e.g., news servers), it may not be optimal to purchase one big fast drive. You can achieve similar or even better results by using the ccd (concatenated disk) driver to create a striped disk array out of multiple slower drives for comparable overall cost. Make sure you have adequate air flow around the drive, especially if you are going to use a fast-spinning drive. You generally need at least 1/2" (1.25cm) of spacing above and below a drive. Understand how the air flows through your PC case. Most cases have the power supply suck the air out of the back. See where the air flows in, and put the drive where it will have the largest volume of cool air flowing around it. You may need to seal some unwanted holes or add a new fan for effective cooling. Another consideration is noise. Many 7,200 or faster drives generate a high-pitched whine which is quite unpleasant to most people. That, plus the extra fans often required for cooling, may make 7,200 or faster drives unsuitable for some office and home environments. Form factor Most SCSI drives sold today are of 3.5" form factor. They come in two different heights; 1.6" (half-height) or 1" (low-profile). The half-height drive is the same - height as a CD-ROM drive. However, don't forget the spacing rule + height as a CDROM drive. However, don't forget the spacing rule mentioned in the previous section. If you have three standard 3.5" drive bays, you will not be able to put three half-height drives in there (without frying them, that is). Interface The majority of SCSI hard drives sold today are Ultra or Ultra-wide SCSI. The maximum bandwidth of Ultra SCSI is 20MB/sec, and Ultra-wide SCSI is 40MB/sec. There is no difference in max cable length between Ultra and Ultra-wide; however, the more devices you have on the same bus, the sooner you will start having bus integrity problems. Unless you have a well-designed disk enclosure, it is not easy to make more than 5 or 6 Ultra SCSI drives work on a single bus. On the other hand, if you need to connect many drives, going for Fast-wide SCSI may not be a bad idea. That will have the same max bandwidth as Ultra (narrow) SCSI, while electronically it's much easier to get it right. My advice would be: if you want to connect many disks, get wide SCSI drives; they usually cost a little more but it may save you down the road. (Besides, if you can't afford the cost difference, you shouldn't be building a disk array.) There are two variant of wide SCSI drives; 68-pin and 80-pin SCA (Single Connector Attach). The SCA drives don't have a separate 4-pin power connector, and also read the SCSI ID settings through the 80-pin connector. If you are really serious about building a large storage system, get SCA drives and a good SCA enclosure (dual power supply with at least one extra fan). They are more electronically sound than 68-pin counterparts because there is no stub of the SCSI bus inside the disk canister as in arrays built from 68-pin drives. They are easier to install too (you just need to screw the drive in the canister, instead of trying to squeeze in your fingers in a tight place to hook up all the little cables (like the SCSI ID and disk activity LED lines). * IDE hard drives Tape drives Contributed by &a.jmb;. 2 July 1996. General tape access commands &man.mt.1; provides generic access to the tape drives. Some of the more common commands are rewind, erase, and status. See the &man.mt.1; manual page for a detailed description. Controller Interfaces There are several different interfaces that support tape drives. The interfaces are SCSI, IDE, Floppy and Parallel Port. A wide variety of tape drives are available for these interfaces. Controllers are discussed in Disk/tape controllers. SCSI drives The &man.st.4; driver provides support for 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (Quarter-Inch Cartridge), DLT - (Digital Linear Tape), QIC Minicartridge and 9-track (remember the + (Digital Linear Tape), QIC Mini cartridge and 9-track (remember the big reels that you see spinning in Hollywood computer rooms) tape drives. See the &man.st.4; manual page for a detailed description. The drives listed below are currently being used by members of the FreeBSD community. They are not the only drives that will work with FreeBSD. They just happen to be the ones that we use. 4mm (DAT: Digital Audio Tape) Archive Python 28454 Archive Python 04687 HP C1533A HP C1534A HP 35450A HP 35470A HP 35480A SDT-5000 Wangtek 6200 8mm (Exabyte) EXB-8200 EXB-8500 EXB-8505 QIC (Quarter-Inch Cartridge) - Archive Ananconda + Archive Anaconda 2750 Archive Viper 60 Archive Viper 150 Archive Viper 2525 Tandberg TDC 3600 Tandberg TDC 3620 Tandberg TDC 3800 Tandberg TDC 4222 Wangtek 5525ES DLT (Digital Linear Tape) Digital TZ87 Mini-Cartridge Conner CTMS 3200 Exabyte 2501 Autoloaders/Changers Hewlett-Packard HP C1553A Autoloading DDS2 * IDE drives Floppy drives Conner 420R * Parallel port drives Detailed Information Archive Anaconda 2750 The boot message identifier for this drive is ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 1.35GB when using QIC-1350 tapes. This drive will read and write QIC-150 (DC6150), QIC-250 (DC6250), and QIC-525 (DC6525) tapes as well. Data transfer rate is 350kB/s using &man.dump.8;. Rates of 530kB/s have been reported when using Amanda Production of this drive has been discontinued. The SCSI bus connector on this tape drive is reversed from that on most other SCSI devices. Make sure that you have enough SCSI cable to twist the cable one-half turn before and after the Archive Anaconda tape drive, or turn your other SCSI devices upside-down. Two kernel code changes are required to use this drive. This drive will not work as delivered. If you have a SCSI-2 controller, short jumper 6. Otherwise, the drive behaves are a SCSI-1 device. When operating as a SCSI-1 device, this drive, locks the SCSI bus during some tape operations, including: fsf, rewind, and rewoffl. If you are using the NCR SCSI controllers, patch the file /usr/src/sys/pci/ncr.c (as shown below). Build and install a new kernel. *** 4831,4835 **** }; ! if (np->latetime>4) { /* ** Although we tried to wake it up, --- 4831,4836 ---- }; ! if (np->latetime>1200) { /* ** Although we tried to wake it up, Reported by: &a.jmb; Archive Python 28454 The boot message identifier for this drive is ARCHIVE Python 28454-XXX4ASB type 1 removable SCSI 2 density code 0x8c, 512-byte blocks This is a DDS-1 tape drive. Native capacity is 2.5GB on 90m tapes. Data transfer rate is XXX. This drive was repackaged by Sun Microsystems as model 595-3067. Reported by: Bob Bishop rb@gid.co.uk Throughput is in the 1.5 MByte/sec range, however this will drop if the disks and tape drive are on the same SCSI controller. Reported by: Robert E. Seastrom rs@seastrom.com Archive Python 04687 The boot message identifier for this drive is ARCHIVE Python 04687-XXX 6580 Removable Sequential Access SCSI-2 device This is a DAT-DDS-2 drive. Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Switch 4 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. Switch 4 off enables MRS, on disables MRS. Parity is controlled by switch 5. Switch 5 on to enable parity control. Compression is enabled with Switch 6 off. It is possible to override compression with the SCSI MODE SELECT command (see &man.mt.1;). Data transfer rate is 800kB/s. Archive Viper 60 The boot message identifier for this drive is ARCHIVE VIPER 60 21116 -007 type 1 removable SCSI 1 This is a QIC tape drive. Native capacity is 60MB. Data transfer rate is XXX. Production of this drive has been discontinued. Reported by: Philippe Regnauld regnauld@hsc.fr Archive Viper 150 The boot message identifier for this drive is ARCHIVE VIPER 150 21531 -004 Archive Viper 150 is a known rogue type 1 removable SCSI 1. A multitude of firmware revisions exist for this drive. Your drive may report different numbers (e.g 21247 -005. This is a QIC tape drive. Native capacity is 150/250MB. Both 150MB (DC6150) and 250MB (DC6250) tapes have the recording format. The 250MB tapes are approximately 67% longer than the 150MB tapes. This drive can read 120MB tapes as well. It can not write 120MB tapes. Data transfer rate is 100kB/s This drive reads and writes DC6150 (150MB) and DC6250 (250MB) tapes. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;). - Under FreeBSD 2.2-current, use mt blocksize + Under FreeBSD 2.2-CURRENT, use mt blocksize 512 to set the blocksize. (The particular drive had firmware revision 21247 -005. Other firmware revisions may behave differently) Previous versions of FreeBSD did not have this problem. Production of this drive has been discontinued. Reported by: Pedro A M Vazquez vazquez@IQM.Unicamp.BR - Mike Smith - msmith@atrad.adelaide.edu.au + &a.msmith; Archive Viper 2525 The boot message identifier for this drive is ARCHIVE VIPER 2525 25462 -011 type 1 removable SCSI 1 This is a QIC tape drive. Native capacity is 525MB. Data transfer rate is 180kB/s at 90 inches/sec. The drive reads QIC-525, QIC-150, QIC-120 and QIC-24 tapes. Writes QIC-525, QIC-150, and QIC-120. Firmware revisions prior to 25462 -011 are bug ridden and will not function properly. Production of this drive has been discontinued. Conner 420R The boot message identifier for this drive is Conner tape. - This is a floppy controller, minicartridge tape drive. + This is a floppy controller, mini cartridge tape drive. Native capacity is XXXX Data transfer rate is XXX The drive uses QIC-80 tape cartridges. Reported by: Mark Hannon mark@seeware.DIALix.oz.au Conner CTMS 3200 The boot message identifier for this drive is CONNER CTMS 3200 7.00 type 1 removable SCSI 2. - This is a minicartridge tape drive. + This is a mini cartridge tape drive. Native capacity is XXXX Data transfer rate is XXX The drive uses QIC-3080 tape cartridges. Reported by: Thomas S. Traylor tst@titan.cs.mci.com <ulink url="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink> The boot message identifier for this drive is DEC TZ87 (C) DEC 9206 type 1 removable SCSI 2 density code 0x19 This is a DLT tape drive. Native capacity is 10GB. This drive supports hardware data compression. Data transfer rate is 1.2MB/s. This drive is identical to the Quantum DLT2000. The drive firmware can be set to emulate several well-known drives, including an Exabyte 8mm drive. Reported by: &a.wilko; <ulink url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink> The boot message identifier for this drive is EXABYTE EXB-2501 This is a mini-cartridge tape drive. Native capacity is 1GB when using MC3000XL - minicartridges. + mini cartridges. Data transfer rate is XXX This drive can read and write DC2300 (550MB), DC2750 (750MB), - MC3000 (750MB), and MC3000XL (1GB) minicartridges. + MC3000 (750MB), and MC3000XL (1GB) mini cartridges. WARNING: This drive does not meet the SCSI-2 specifications. The drive locks up completely in response to a SCSI MODE_SELECT command unless there is a formatted tape in the drive. Before using this drive, set the tape blocksize with &prompt.root; mt -f /dev/st0ctl.0 blocksize 1024 - Before using a minicartridge for the first time, the - minicartridge must be formated. FreeBSD 2.1.0-RELEASE and + Before using a mini cartridge for the first time, the + mini cartridge must be formated. FreeBSD 2.1.0-RELEASE and earlier: &prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" (Alternatively, fetch a copy of the scsiformat shell script from FreeBSD 2.1.5/2.2.) FreeBSD 2.1.5 and later: &prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl Right now, this drive cannot really be recommended for FreeBSD. Reported by: Bob Beaulieu ez@eztravel.com Exabyte EXB-8200 The boot message identifier for this drive is EXABYTE EXB-8200 252X type 1 removable SCSI 1 This is an 8mm tape drive. Native capacity is 2.3GB. Data transfer rate is 270kB/s. This drive is fairly slow in responding to the SCSI bus during boot. A custom kernel may be required (set SCSI_DELAY to 10 seconds). There are a large number of firmware configurations for this drive, some have been customized to a particular vendor's hardware. The firmware can be changed via EPROM replacement. Production of this drive has been discontinued. - Reported by: Mike Smith - msmith@atrad.adelaide.edu.au + Reported by: &a.msmith; Exabyte EXB-8500 The boot message identifier for this drive is EXABYTE EXB-8500-85Qanx0 0415 type 1 removable SCSI 2 This is an 8mm tape drive. Native capacity is 5GB. Data transfer rate is 300kB/s. Reported by: Greg Lehey grog@lemis.de <ulink url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink> The boot message identifier for this drive is EXABYTE EXB-85058SQANXR1 05B0 type 1 removable SCSI 2 This is an 8mm tape drive which supports compression, and is upward compatible with the EXB-5200 and EXB-8500. Native capacity is 5GB. The drive supports hardware data compression. Data transfer rate is 300kB/s. Reported by: Glen Foster gfoster@gfoster.com Hewlett-Packard HP C1533A The boot message identifier for this drive is HP C1533A 9503 type 1 removable SCSI 2. This is a DDS-2 tape drive. DDS-2 means hardware data compression and narrower tracks for increased data capacity. Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is 510kB/s. This drive is used in Hewlett-Packard's SureStore 6000eU and 6000i tape drives and C1533A DDS-2 DAT drive. The drive has a block of 8 dip switches. The proper settings for FreeBSD are: 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7 ON; 8 ON. switch 1 switch 2 Result On On Compression enabled at power-on, with host control On Off Compression enabled at power-on, no host control Off On Compression disabled at power-on, with host control Off Off Compression disabled at power-on, no host control Switch 3 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. These identify the tape as DDS (Digital Data Storage) grade media. Tapes that do not have the stripes will be treated as write-protected. Switch 3 OFF enables MRS. Switch 3 ON disables MRS. See HP SureStore Tape Products and Hewlett-Packard Disk and Tape Technical Information for more information on configuring this drive. Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 2 of these drives. Neither lasted more than 5 months. Reported by: &a.se; Hewlett-Packard HP 1534A The boot message identifier for this drive is HP HP35470A T503 type 1 removable SCSI 2 Sequential-Access density code 0x13, variable blocks. This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. Data transfer rate is 183kB/s. The same mechanism is used in Hewlett-Packard's SureStore 2000i tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive and HP C1536A DDS format DAT drive. The HP C1534A DDS format DAT drive has two indicator lights, one green and one amber. The green one indicates tape action: slow flash during load, steady when loaded, fast flash during read/write operations. The amber one indicates warnings: slow flash when cleaning is required or tape is nearing the end of its useful life, steady indicates an hard fault. (factory service required?) Reported by Gary Crutcher gcrutchr@nightflight.com Hewlett-Packard HP C1553A Autoloading DDS2 The boot message identifier for this drive is "". This is a DDS-2 tape drive with a tape changer. DDS-2 means hardware data compression and narrower tracks for increased data capacity. Native capacity is 24GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is 510kB/s (native). This drive is used in Hewlett-Packard's SureStore 12000e tape drive. The drive has two selectors on the rear panel. The selector closer to the fan is SCSI id. The other selector should be set to 7. There are four internal switches. These should be set: 1 ON; 2 ON; 3 ON; 4 OFF. At present the kernel drivers do not automatically change tapes at the end of a volume. This shell script can be used to change tapes: #!/bin/sh PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH usage() { echo "Usage: dds_changer [123456ne] raw-device-name echo "1..6 = Select cartridge" echo "next cartridge" echo "eject magazine" exit 2 } if [ $# -ne 2 ] ; then usage fi cdb3=0 cdb4=0 cdb5=0 case $1 in [123456]) cdb3=$1 cdb4=1 ;; n) ;; e) cdb5=0x80 ;; ?) usage ;; esac scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5" Hewlett-Packard HP 35450A The boot message identifier for this drive is HP HP35450A -A C620 type 1 removable SCSI 2 Sequential-Access density code 0x13 This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 1.2GB. Data transfer rate is 160kB/s. - Reported by: mark thompson + Reported by: Mark Thompson mark.a.thompson@pobox.com Hewlett-Packard HP 35470A The boot message identifier for this drive is HP HP35470A 9 09 type 1 removable SCSI 2 This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. Data transfer rate is 183kB/s. The same mechanism is used in Hewlett-Packard's SureStore 2000i tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive, and HP C1536A DDS format DAT drive. Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 5 of these drives. None lasted more than 9 months. Reported by: David Dawes dawes@rf900.physics.usyd.edu.au (9 09) Hewlett-Packard HP 35480A The boot message identifier for this drive is HP HP35480A 1009 type 1 removable SCSI 2 Sequential-Access density code 0x13. This is a DDS-DC tape drive. DDS-DC is DDS-1 with hardware data compression. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. It cannot handle 120m tapes. This drive supports hardware data compression. Please refer to the section on HP C1533A for the proper switch settings. Data transfer rate is 183kB/s. This drive is used in Hewlett-Packard's SureStore 5000eU and 5000i tape drives and C35480A DDS format DAT drive.. This drive will occasionally hang during a tape eject operation (mt offline). Pressing the front panel button will eject the tape and bring the tape drive back to life. WARNING: HP 35480-03110 only. On at least two occasions this tape drive when used with FreeBSD 2.1.0, an IBM Server 320 and an 2940W SCSI controller resulted in all SCSI disk partitions being lost. The problem has not be analyzed or resolved at this time. <ulink url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink> There are at least two significantly different models: one is a DDS-1 and the other DDS-2. The DDS-1 version is SDT-5000 3.02. The DDS-2 version is SONY SDT-5000 327M. The DDS-2 version has a 1MB cache. This cache is able to keep the tape streaming in almost any circumstances. The boot message identifier for this drive is SONY SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access density code 0x13 Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is depends upon the model or the drive. The rate is 630kB/s for the SONY SDT-5000 327M while compressing the data. For the SONY SDT-5000 3.02, the data transfer rate is 225kB/s. In order to get this drive to stream, set the blocksize to 512 bytes (mt blocksize 512) reported by Kenneth - Merry ken@ulc199.residence.gatech.edu + Merry ken@ulc199.residence.gatech.edu. SONY SDT-5000 327M information reported by - Charles Henrich henrich@msu.edu + Charles Henrich henrich@msu.edu. Reported by: &a.jmz; Tandberg TDC 3600 The boot message identifier for this drive is TANDBERG TDC 3600 =08: type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 150/250MB. This drive has quirks which are known and work around code is present in the scsi tape device driver (&man.st.4;). Upgrading the firmware to XXX version will fix the quirks and provide SCSI 2 capabilities. Data transfer rate is 80kB/s. IBM and Emerald units will not work. Replacing the firmware EPROM of these units will solve the problem. - Reported by: Michael Smith - msmith@atrad.adelaide.edu.au + Reported by: &a.msmith; Tandberg TDC 3620 This is very similar to the Tandberg TDC 3600 drive. Reported by: &a.joerg; Tandberg TDC 3800 The boot message identifier for this drive is TANDBERG TDC 3800 =04Y Removable Sequential Access SCSI-2 device This is a QIC tape drive. Native capacity is 525MB. Reported by: &a.jhs; Tandberg TDC 4222 The boot message identifier for this drive is TANDBERG TDC 4222 =07 type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 2.5GB. The drive will read all cartridges from the 60 MB (DC600A) upwards, and write 150 MB (DC6150) upwards. Hardware compression is optionally supported for the 2.5 GB cartridges. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;) beginning with FreeBSD - 2.2-current. For previous versions of FreeBSD, use + 2.2-CURRENT. For previous versions of FreeBSD, use mt to read one block from the tape, rewind the tape, and then execute the backup program (mt fsr 1; mt rewind; dump ...) Data transfer rate is 600kB/s (vendor claim with compression), 350 KB/s can even be reached in start/stop mode. The rate decreases for smaller cartridges. Reported by: &a.joerg; Wangtek 5525ES The boot message identifier for this drive is WANGTEK 5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code 0x11, 1024-byte blocks This is a QIC tape drive. Native capacity is 525MB. Data transfer rate is 180kB/s. The drive reads 60, 120, 150, and 525MB tapes. The drive will not write 60MB (DC600 cartridge) tapes. In order to overwrite 120 and 150 tapes reliably, first erase (mt erase) the tape. 120 and 150 tapes used a wider track (fewer tracks per tape) than 525MB tapes. The extra width of the previous tracks is not overwritten, as a result the new data lies in a band surrounded on both sides by the previous data unless the tape have been erased. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;). Other firmware revisions that are known to work are: M75D Reported by: Marc van Kempen marc@bowtie.nl REV73R1 Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D Wangtek 6200 The boot message identifier for this drive is WANGTEK 6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access density code 0x13 This is a DDS-1 tape drive. Native capacity is 2GB using 90m tapes. Data transfer rate is 150kB/s. Reported by: Tony Kimball alk@Think.COM * Problem drives - CD-ROM drives + CDROM drives Contributed by &a.obrien;. 23 November 1997. As mentioned in Jordan's Picks Generally speaking those in The FreeBSD Project prefer SCSI CDROM drives over IDE CDROM drives. However not all SCSI CDROM drives are equal. Some feel the quality of some SCSI CDROM drives have been deteriorating to that of IDE CDROM drives. Toshiba used to be the favored stand-by, but many on the SCSI mailing list have found displeasure with the 12x speed XM-5701TA as its volume (when playing audio CDROMs) is not controllable by the various audio player software. Another area where SCSI CDROM manufacturers are cutting corners is adherence to the SCSI specification. Many SCSI CDROMs will respond to multiple LUNs for its target address. Known violators include the 6x Teac CD-56S 1.0D. * Other * Other * PCMCIA diff --git a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml index 2268cea7d6..0070cb3e44 100644 --- a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml @@ -1,1813 +1,1813 @@ Advanced Networking Synopsis The following chapter will cover some of the more frequently used network services on UNIX systems. This, of course, will pertain to configuring said services on your FreeBSD system. Gateways and Routes Contributed by &a.gryphon;. 6 October 1995. For one machine to be able to find another, there must be a mechanism in place to describe how to get from one to the other. This is called Routing. A route is a defined pair of addresses: a destination and a gateway. The pair indicates that if you are trying to get to this destination, send along through this gateway. There are three types of destinations: individual hosts, subnets, and default. The default route is used if none of the other routes apply. We will talk a little bit more about default routes later on. There are also three types of gateways: individual hosts, interfaces (also called links), and ethernet hardware addresses. An example To illustrate different aspects of routing, we will use the following example which is the output of the command netstat -r: Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 The first two lines specify the default route (which we will cover in the next section) and the localhost route. The interface (Netif column) that it specifies to use for localhost is lo0, also known as the loopback device. This says to keep all traffic for this destination internal, rather than sending it out over the LAN, since it will only end up back where it started anyway. The next thing that stands out are the 0:e0:... addresses. These are ethernet hardware addresses. FreeBSD will automatically identify any hosts (test0 in the example) on the local ethernet and add a route for that host, directly to it over the ethernet interface, ed0. There is also a timeout (Expire column) associated with this type of route, which is used if we fail to hear from the host in a specific amount of time. In this case the route will be automatically deleted. These hosts are identified using a mechanism known as RIP (Routing Information Protocol), which figures out routes to local hosts based upon a shortest path determination. FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the subnet 10.20.30, and foobar.com is the domain name associated with that subnet). The designation link#1 refers to the first ethernet card in the machine. You will notice no additional interface is specified for those. Both of these groups (local network hosts and local subnets) have their routes automatically configured by a daemon called routed. If this is not run, then only routes which are statically defined (ie. entered explicitly) will exist. The host1 line refers to our host, which it knows by ethernet address. Since we are the sending host, FreeBSD knows to use the loopback interface (lo0) rather than sending it out over the ethernet interface. The two host2 lines are an example of what happens when we use an ifconfig alias (see the section of ethernet for reasons why we would do this). The => symbol after the lo0 interface says that not only are we using the loopback (since this is address also refers to the local host), but specifically it is an alias. Such routes only show up on the host that supports the alias; all other hosts on the local network will simply have a link#1 line for such. The final line (destination subnet 224) deals with MultiCasting, which will be covered in a another section. The other column that we should talk about are the Flags. Each route has different attributes that are described in the column. Below is a short table of some of these flags and their meanings: U Up: The route is active. H Host: The route destination is a single host. G Gateway: Send anything for this destination on to this remote system, which will figure out from there where to send it. S Static: This route was configured manually, not automatically generated by the system. C Clone: Generates a new route based upon this route for machines we connect to. This type of route is normally used for local networks. W WasCloned: Indicated a route that was auto-configured based upon a local area network (Clone) route. L Link: Route involves references to ethernet hardware. Default routes When the local system needs to make a connection to remote host, it checks the routing table to determine if a known path exists. If the remote host falls into a subnet that we know how to reach (Cloned routes), then the system checks to see if it can connect along that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c in the flags field. For hosts on a local area network, this gateway is set to whatever machine has a direct connection to the outside world (whether via PPP link, or your hardware device attached to a dedicated data line). If you are configuring the default route for a machine which itself is functioning as the gateway to the outside world, then the default route will be the gateway machine at your Internet Service Provider's (ISP) site. Let us look at an example of default routes. This is a common configuration: [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] The hosts Local1 and Local2 are at your site, with the formed being your PPP connection to your ISP's Terminal Server. Your ISP has a local network at their site, which has, among other things, the server where you connect and a hardware device (T1-GW) attached to the ISP's Internet feed. The default routes for each of your machines will be: host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP A common question is Why (or how) would we set the T1-GW to be the default gateway for Local1, rather than the ISP server it is connected to?. Remember, since the PPP interface is using an address on the ISP's local network for your side of the connection, routes for any other machines on the ISP's local network will be automatically generated. Hence, you will already know how to reach the T1-GW machine, so there is no need for the intermediate step of sending traffic to the ISP server. As a final note, it is common to use the address ...1 as the gateway address for your local network. So (using the same example), if your local class-C address space was 10.20.30 and your ISP was using 10.9.9 then the default routes would be: Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) Dual homed hosts There is one other type of configuration that we should cover, and that is a host that sits on two different networks. Technically, any machine functioning as a gateway (in the example above, using a PPP connection) counts as a dual-homed host. But the term is really only used to refer to a machine that sits on two local-area networks. In one case, the machine as two ethernet cards, each having an address on the separate subnets. Alternately, the machine may only have one ethernet card, and be using ifconfig aliasing. The former is used if two physically separate ethernet networks are in use, the latter if there is one physical network segment, but two logically separate subnets. Either way, routing tables are set up so that each subnet knows that this machine is the defined gateway (inbound route) to the other subnet. This configuration, with the machine acting as a Bridge between the two subnets, is often used when we need to implement packet filtering or firewall security in either or both directions. Routing propagation We have already talked about how we define our routes to the outside world, but not about how the outside world finds us. We already know that routing tables can be set up so that all traffic for a particular address space (in our examples, a class-C subnet) can be sent to a particular host on that network, which will forward the packets inbound. When you get an address space assigned to your site, your service provider will set up their routing tables so that all traffic for your subnet will be sent down your PPP link to your site. But how do sites across the country know to send to your ISP? There is a system (much like the distributed DNS information) that keeps track of all assigned address-spaces, and defines their point of connection to the Internet Backbone. The Backbone are the main trunk lines that carry Internet traffic across the country, and around the world. Each backbone machine has a copy of a master set of tables, which direct traffic for a particular network to a specific backbone carrier, and from there down the chain of service providers until it reaches your network. It is the task of your service provider to advertise to the backbone sites that they are the point of connection (and thus the path inward) for your site. This is known as route propagation. Troubleshooting Sometimes, there is a problem with routing propagation, and some sites are unable to connect to you. Perhaps the most useful command for trying to figure out where a routing is breaking down is the &man.traceroute.8; command. It is equally useful if you cannot seem to make a connection to a remote machine (i.e. &man.ping.8; fails). The &man.traceroute.8; command is run with the name of the remote host you are trying to connect to. It will show the gateway hosts along the path of the attempt, eventually either reaching the target host, or terminating because of a lack of connection. For more information, see the manual page for &man.traceroute.8;. NFS Written by &a.unfurl;, 4 March 2000. Among the many different file systems that FreeBSD supports is a very unique type, the Network File System or NFS. NFS allows you to share directories and files on one machine with one or more other machines via the network they are attached to. Using NFS, users and programs can access files on remote systems as if they were local files. NFS has several benefits: Local workstations dont need as much disk space because commonly used data can be stored on a single machine and still remain accessible to everyone on the network. There is no need for users to have unique home directories on every machine on your network. Once they have an established directory that is available via NFS it can be accessed from anywhere. Storage devices such as floppies and CD-ROM drives can be used by other machines on the network eliminating the need for extra hardware. How It Works NFS is composed of two sides – a client side and a server side. Think of it as a want/have relationship. The client wants the data that the server side has. The server shares its data with the client. In order for this system to function properly a few processes have to be configured and running properly. The server has to be running the following daemons: nfsd - The NFS Daemon which services requests from NFS clients. mountd - The NFS Mount Daemon which actually carries out requests that nfsd passes on to it. The client side only needs to run a single daemon: nfsiod - The NFS async I/O Daemon which services requests from its NFS server. Configuring NFS Luckily for us, on a FreeBSD system this setup is a snap. The processes that need to be running can all be run at boot time with - a few modificationss to your /etc/rc.conf + a few modifications to your /etc/rc.conf file. On the NFS server make sure you have: nfs_server_enable="YES" nfs_server_flags="-u -t -n 4" mountd_flags="-r" mountd is automatically run whenever the NFS server is enabled. The and flags to nfsd tell it to serve UDP and TCP clients. The flag tells nfsd to start 4 copies of itself. On the client, make sure you have: nfs_client_enable="YES" nfs_client_flags="-n 4" Like nfsd, the tells nfsiod to start 4 copies of itself. The last configuration step requires that you create a file called /etc/exports. The exports file specifies which file systems on your server will be shared (a.k.a., exported) and with what clients they will be shared. Each line in the file specifies a file system to be shared. There are a handful of options that can be used in this file but I will only touch on a few of them. You can find out about the rest in the &man.exports.5; man page. Here are a few example /etc/exports entries: The following line exports /cdrom to three silly machines that have the same domain name as the server (hence the lack of a domain name for each) or have entries in your /etc/hosts file. The flag makes the shared file system read-only. With this flag, the remote system will not be able to make any changes to the the shared file system. /cdrom -ro moe larry curly The following line exports /home to three hosts by IP address. This is a useful setup if you have a private network but do not have DNS running. The flag allows all the directories below the specified file system to be exported as well. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 The following line exports /a to two machines that have different domain names than the server. The flag allows the root user on the remote system to write to the shared file system as root. Without the -maproot=0 flag even if someone has root access on the remote system they won't be able to modify files on the shared file system. /a -maproot=0 host.domain.com box.example.com In order for a client to share an exported file system it must have permission to do so. Make sure your client is listed in your /etc/exports file. Now that you have made all these changes you can just reboot and let FreeBSD start everything for you at boot time or you can run the following commands as root: On the NFS server: &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r On the NFS client: &prompt.root; nfsiod -n 4 Now you should be ready to actually mount a remote file system. This can be done one of two ways. In these examples the server's name will be server and the client's name will be client. If you just want to temporarily mount a remote file system or just want to test out your config you can run a command like this as root on the client: &prompt.root; mount server:/home /mnt This will mount /home on the server on /mnt on the client. If everything is setup correctly you should be able to go into /mnt on the client and see all the files that are on the server. If you want to permanently (each time you reboot) mount a remote file system you need to add it to your /etc/fstab file. Here is an example line: server:/home /mnt nfs rw 0 0 Read the &man.fstab.5; man page for more options. Practical Uses There are many very cool uses for NFS. I use it quite a bit on the LAN I admin. Here are a few ways I have found it to be useful. I have several machines on my network but only one of them has a CD-ROM drive. Why? Because I have that one CD-ROM drive shared with all the others via NFS. The same can be done with floppy drives. With so many machines on the network it gets old having your personal files strewn all over the place. I have a central NFS server that houses all user home directories and shares them with the rest of the machines on the LAN, so no matter where I login I have the same home directory. When you get to reinstalling FreeBSD on one of your machines, NFS is the way to go. Just pop your distribution CD into your file server and away you go. I have a common /usr/ports/distfiles directory that all my machines share. That way when I go to install a port that I already installed on a different machine I do not have to download the source all over again. Problems integrating with other systems Contributed by &a.jlind;. Certain Ethernet adapters for ISA PC systems have limitations which can lead to serious network problems, particularly with NFS. This difficulty is not specific to FreeBSD, but FreeBSD systems are affected by it. The problem nearly always occurs when (FreeBSD) PC systems are networked with high-performance workstations, such as those made by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will work fine, and some operations may succeed, but suddenly the server will seem to become unresponsive to the client, even though requests to and from other systems continue to be processed. This happens to the client system, whether the client is the FreeBSD system or the workstation. On many systems, there is no way to shut down the client gracefully once this problem has manifested itself. The only solution is often to reset the client, because the NFS situation cannot be resolved. Though the correct solution is to get a higher performance and capacity Ethernet adapter for the FreeBSD system, there is a simple workaround that will allow satisfactory operation. If the FreeBSD system is the server, include the option on the mount from the client. If the FreeBSD system is the client, then mount the NFS file system with the option . These options may be specified using the fourth field of the fstab entry on the client for automatic mounts, or by using the parameter of the mount command for manual mounts. It should be noted that there is a different problem, sometimes mistaken for this one, when the NFS servers and clients are on different networks. If that is the case, make certain that your routers are routing the necessary UDP information, or you will not get anywhere, no matter what else you are doing. In the following examples, fastws is the host (interface) name of a high-performance workstation, and freebox is the host (interface) name of a FreeBSD system with a lower-performance Ethernet adapter. Also, /sharedfs will be the exported NFS filesystem (see man exports), and /project will be the mount point on the client for the exported file system. In all cases, note that additional options, such as or and may be desirable in your application. Examples for the FreeBSD system (freebox) as the client: in /etc/fstab on freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 As a manual mount command on freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Examples for the FreeBSD system as the server: in /etc/fstab on fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 As a manual mount command on fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Nearly any 16-bit Ethernet adapter will allow operation without the above restrictions on the read or write size. For anyone who cares, here is what happens when the failure occurs, which also explains why it is unrecoverable. NFS typically works with a block size of 8k (though it may do fragments of smaller sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS block gets split into multiple Ethernet packets, even though it is still a single unit to the upper-level code, and must be received, assembled, and acknowledged as a unit. The high-performance workstations can pump out the packets which comprise the NFS unit one right after the other, just as close together as the standard allows. On the smaller, lower capacity cards, the later packets overrun the earlier packets of the same unit before they can be transferred to the host and the unit as a whole cannot be reconstructed or acknowledged. As a result, the workstation will time out and try again, but it will try again with the entire 8K unit, and the process will be repeated, ad infinitum. By keeping the unit size below the Ethernet packet size limitation, we ensure that any complete Ethernet packet received can be acknowledged individually, avoiding the deadlock situation. Overruns may still occur when a high-performance workstations is slamming data out to a PC system, but with the better cards, such overruns are not guaranteed on NFS units. When an overrun occurs, the units affected will be retransmitted, and there will be a fair chance that they will be received, assembled, and acknowledged. Diskless Operation Contributed by &a.martin;. netboot.com/netboot.rom allow you to boot your FreeBSD machine over the network and run FreeBSD without having a disk on your client. Under 2.0 it is now possible to have local swap. Swapping over NFS is also still supported. Supported Ethernet cards include: Western Digital/SMC 8003, 8013, 8216 and compatibles; NE1000/NE2000 and compatibles (requires recompile) Setup Instructions Find a machine that will be your server. This machine will require enough disk space to hold the FreeBSD 2.0 binaries and have bootp, tftp and NFS services available. Tested machines: HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't work) Sun/Solaris 2.3. (you may need to get bootp) Set up a bootp server to provide the client with IP, gateway, netmask. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: Set up a TFTP server (on same machine as bootp server) to provide booting information to client. The name of this file is cfg.X.X.X.X (or /tftpboot/cfg.X.X.X.X, it will try both) where X.X.X.X is the IP address of the client. The contents of this file can be any valid netboot commands. Under 2.0, netboot has the following commands: help print help list ip print/set client's IP address server print/set bootp/tftp server address netmask print/set netmask hostname name print/set hostname kernel print/set kernel name rootfs print/set root filesystem swapfs print/set swap filesystem swapsize - set diskless swapsize in Kbytes + set diskless swapsize in KBytes diskboot boot from disk autoboot continue boot process trans | turn transceiver on|off flags set boot flags A typical completely diskless cfg file might contain: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain A cfg file for a machine with local swap might contain: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain Ensure that your NFS server has exported the root (and swap if applicable) filesystems to your client, and that the client has root access to these filesystems A typical /etc/exports file on FreeBSD might look like: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain And on HP-UX: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain If you are swapping over NFS (completely diskless configuration) create a swap file for your client using dd. If your swapfs command has the arguments /swapfs and the size 20000 as in the example above, the swapfile for myclient will be called /swapfs/swap.X.X.X.X where X.X.X.X is the client's IP addr, - eg: + e.g.: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 Also, the client's swap space might contain sensitive information once swapping starts, so make sure to restrict read and write access to this file to prevent unauthorized access: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 Unpack the root filesystem in the directory the client will use for its root filesystem (/rootfs/myclient in the example above). On HP-UX systems: The server should be running HP-UX 9.04 or later for HP9000/800 series machines. Prior versions do not allow the creation of device files over NFS. When extracting /dev in /rootfs/myclient, beware that some systems (HPUX) will not create device files that FreeBSD is happy with. You may have to go to single user mode on the first bootup (press control-c during the bootup phase), cd /dev and do a sh ./MAKEDEV all from the client to fix this. Run netboot.com on the client or make an EPROM from the netboot.rom file Using Shared <filename>/</filename> and <filename>/usr</filename> filesystems At present there isn't an officially sanctioned way of doing this, although I have been using a shared /usr filesystem and individual / filesystems for each client. If anyone has any suggestions on how to do this cleanly, please let me and/or the &a.core; know. Compiling netboot for specific setups Netboot can be compiled to support NE1000/2000 cards by changing the configuration in /sys/i386/boot/netboot/Makefile. See the comments at the top of this file. ISDN Last modified by &a.wlloyd;. A good resource for information on ISDN technology and hardware is Dan Kegel's ISDN Page. - A quick simple roadmap to ISDN follows: + A quick simple road map to ISDN follows: If you live in Europe I suggest you investigate the ISDN card section. If you are planning to use ISDN primarily to connect to the - Internet with an Internet Provider on a dialup non-dedicated basis, + Internet with an Internet Provider on a dial-up non-dedicated basis, I suggest you look into Terminal Adapters. This will give you the most flexibility, with the fewest problems, if you change providers. - If you are connecting two lans together, or connecting to the + If you are connecting two LANs together, or connecting to the Internet with a dedicated ISDN connection, I suggest you consider the stand alone router/bridge option. Cost is a significant factor in determining what solution you will choose. The following options are listed from least expensive to most expensive. ISDN Cards Contributed by &a.hm;. This section is really only relevant to ISDN users in countries where the DSS1/Q.931 ISDN standard is supported. Some growing number of PC ISDN cards are supported under FreeBSD 2.2.x and up by the isdn4bsd driver package. It is still under development but the reports show that it is successfully used all over Europe. The latest isdn4bsd version is available from ftp://isdn4bsd@ftp.consol.de/pub/, the main isdn4bsd ftp site (you have to log in as user isdn4bsd , give your mail address as the password and change to the pub directory. Anonymous ftp as user ftp or anonymous will not give the desired result). Isdn4bsd allows you to connect to other ISDN routers using either IP over raw HDLC or by using synchronous PPP. A telephone answering machine application is also available. Many ISDN PC cards are supported, mostly the ones with a Siemens ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola, Cologne Chip Designs) is currently under development. For an up-to-date list of supported cards, please have a look at the README file. In case you are interested in adding support for a different ISDN protocol, a currently unsupported ISDN PC card or otherwise enhancing isdn4bsd, please get in touch with hm@kts.org. A majordomo maintained mailing list is available. To join the list, send mail to &a.majordomo; and specify: subscribe freebsd-isdn in the body of your message. ISDN Terminal Adapters Terminal adapters(TA), are to ISDN what modems are to regular phone lines. Most TA's use the standard hayes modem AT command set, and can be used as a drop in replacement for a modem. A TA will operate basically the same as a modem except connection and throughput speeds will be much faster than your old modem. You will need to configure PPP exactly the same as for a modem setup. Make sure you set your serial speed as high as possible. The main advantage of using a TA to connect to an Internet Provider is that you can do Dynamic PPP. As IP address space becomes more and more scarce, most providers are not willing to provide you - with a static IP anymore. Most standalone routers are not able to + with a static IP anymore. Most stand-alone routers are not able to accommodate dynamic IP allocation. TA's completely rely on the PPP daemon that you are running for their features and stability of connection. This allows you to upgrade easily from using a modem to ISDN on a FreeBSD machine, if you already have PPP setup. However, at the same time any problems you experienced with the PPP program and are going to persist. If you want maximum stability, use the kernel PPP option, not the user-land iijPPP. The following TA's are know to work with FreeBSD. Motorola BitSurfer and Bitsurfer Pro Adtran Most other TA's will probably work as well, TA vendors try to make sure their product can accept most of the standard modem AT command set. The real problem with external TA's is like modems you need a good serial card in your computer. You should read the serial ports section in the handbook for a detailed understanding of serial devices, and the differences between asynchronous and synchronous serial ports. A TA running off a standard PC serial port (asynchronous) limits you to 115.2Kbs, even though you have a 128Kbs connection. To fully utilize the 128Kbs that ISDN is capable of, you must move the TA to a synchronous serial card. Do not be fooled into buying an internal TA and thinking you have avoided the synchronous/asynchronous issue. Internal TA's simply have a standard PC serial port chip built into them. All this will do, is save you having to buy another serial cable, and find another empty electrical socket. - A synchronous card with a TA is at least as fast as a standalone + A synchronous card with a TA is at least as fast as a stand-alone router, and with a simple 386 FreeBSD box driving it, probably more flexible. - The choice of sync/TA vs standalone router is largely a religious + The choice of sync/TA v.s. stand-alone router is largely a religious issue. There has been some discussion of this in the mailing lists. I suggest you search the archives for the complete discussion. - Standalone ISDN Bridges/Routers + Stand-alone ISDN Bridges/Routers ISDN bridges or routers are not at all specific to FreeBSD or any other operating system. For a more complete description of routing and bridging technology, please refer to a Networking reference book. In the context of this page, I will use router and bridge interchangeably. As the cost of low end ISDN routers/bridges comes down, it will likely become a more and more popular choice. An ISDN router is a small box that plugs directly into your local Ethernet network(or card), and manages its own connection to the other bridge/router. It has all the software to do PPP and other protocols built in. A router will allow you much faster throughput that a standard TA, since it will be using a full synchronous ISDN connection. The main problem with ISDN routers and bridges is that interoperability between manufacturers can still be a problem. If you are planning to connect to an Internet provider, I recommend that you discuss your needs with them. If you are planning to connect two lan segments together, ie: home lan to the office lan, this is the simplest lowest maintenance solution. Since you are buying the equipment for both sides of the connection you can be assured that the link will work. For example to connect a home computer or branch office network to a head office network the following setup could be used. Branch office or Home network Network is 10 Base T Ethernet. Connect router to network cable with AUI/10BT transceiver, if necessary. ---Sun workstation | ---FreeBSD box | ---Windows 95 (Do not admit to owning it) | -Standalone router +Stand-alone router | ISDN BRI line If your home/branch office is only one computer you can use a - twisted pair crossover cable to connect to the standalone router + twisted pair crossover cable to connect to the stand-alone router directly. Head office or other lan Network is Twisted Pair Ethernet. -------Novell Server | H | | ---Sun | | | U ---FreeBSD | | | ---Windows 95 | B | - |___---Standalone router + |___---Stand-alone router | ISDN BRI line One large advantage of most routers/bridges is that they allow you to have 2 separate independent PPP connections to 2 separate sites at the same time. This is not supported on most TA's, except for specific(expensive) models that have two serial ports. Do not confuse this with channel bonding, MPP etc. This can be very useful feature, for example if you have an - dedicated internet ISDN connection at your office and would like to + dedicated ISDN connection at your office and would like to tap into it, but don't want to get another ISDN line at work. A router at the office location can manage a dedicated B channel connection (64Kbs) to the internet, as well as a use the other B channel for a separate data connection. The second B channel can be used for - dialin, dialout or dynamically bond(MPP etc.) with the first B channel + dial-in, dial-out or dynamically bond(MPP etc.) with the first B channel for more bandwidth. An Ethernet bridge will also allow you to transmit more than just IP traffic, you can also send IPX/SPX or whatever other protocols you use. NIS/YP Written by &a.unfurl;, 21 January 2000. What is it? NIS is an RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location. How does it work? - There are 3 types of hosts in an NIS enviornment; master + There are 3 types of hosts in an NIS environment; master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers - hold the authoritatve copy of this information, while slave + hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them. Information in many files can be shared in this manner. The master.passwd, group, and hosts files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the server it is bound to, to get this information. Using NIS/YP Planning If you are setting up a NIS scheme for the first time, it is a good idea to think through how you want to go about it. No matter what the size of your network, there are a few decisions that need to be made. Choosing a NIS Domain Name This might not be the domainname that you are used to. It is more accurately called the NIS domainname. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in someway way. Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique within your network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the "acme-art" NIS domain. Physical Server Requirements - There are several things to keep in mind when chosing a + There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind you should make sure to choose a machine that won't be prone to being rebooted regularly, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an NIS server. If you have a network that is not very heavily used, it is acceptable to put the NIS server on a machine running other services, just keep in mind that if the NIS server becomes unavailable, it will affect all of your NIS clients adversely. NIS Servers The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In FreeBSD, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps. NIS master and slave servers handle all NIS requests with the ypserv daemon. Ypserv is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file and transmitting data from the database back to the client. Setting up a NIS master server - Setting up a master NIS server can be relativly straight + Setting up a master NIS server can be relatively straight forward, depending on your needs. FreeBSD comes with a handy script called ypinit that makes the initial setup procedure very easy. A few steps are needed ahead of time to make the setup process go smoothly. Make sure your NIS domainname is set, using the domainname command. You can run ypinit for domains other than the one your host is in but if domainname is not set, now is a good time to do so. Make sure a copy of the master.passwd file is in /var/yp. This where NIS will get the password entries it will share with it's clients. ypinit runs with errors if this file is not present. You can either start a new master.passwd or copy the existing one from /etc/master.passwd. If you do the latter, make sure the permissions are set properly to disallow world/group reading of the file. Start the ypserv daemon. ypinit requires ypserv to be running to answer some RPC calls it makes. In its basic configuration ypserv does not need to be run with any flags. Once you've done the above steps, run ypinit with the flag. You might want to specify the domain you are building a master server for if it is different than what the domainname is set to. In this example, test-domain will be our NIS domainname. # ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. master.example.com is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <Control D>. master server : master.example.com next host to add: ^D The current list of NIS servers looks like this: master.example.com Is this correct? [y/n: y] y Building /var/yp/test-domain/ypservers... Running /var/yp/Makefile... NIS Map update started on Fri Dec 3 16:54:12 PST 1999 for domain test-domain Updating hosts.byname... Creating new /var/yp/passwd file from /var/yp/master.passwd... Updating netid.byname... Updating hosts.byaddr... Updating networks.byaddr... Updating networks.byname... Updating protocols.bynumber... Updating protocols.byname... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating group.byname... Updating group.bygid... Updating passwd.byname... Updating passwd.byuid... Updating master.passwd.byname... Updating master.passwd.byuid... NIS Map update completed. master.example.com has been setup as an YP master server without any errors. There are a few crucial lines that need to be added to your /etc/rc.conf in order for the NIS server to start properly. Make sure that these lines are included: nis_server_enable="YES" nis_server_flags="" nis_yppasswdd_enable="YES" nis_yppasswdd_flags="" You will most likely want to run yppasswd on the NIS server. This allows users on NIS client machines to change their passwords and other user information remotely. Setting up a NIS slave server Setting up an NIS slave server is even more simple than setting up the master. Again the ypinit command helps out a great deal. As in the previous example we'll use test-domain as our target NIS domainname. # ypinit -s master.example.com test-domain Server Type: SLAVE Domain: test-domain Master: master.example.com Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from master.example.com. -Transfering netgroup... -ypxfr: Exiting: Map successfully transfered -Transfering netgroup.byuser... -ypxfr: Exiting: Map successfully transfered -Transfering netgroup.byhost... -ypxfr: Exiting: Map successfully transfered -Transfering master.passwd.byuid... -ypxfr: Exiting: Map successfully transfered -Transfering passwd.byuid... -ypxfr: Exiting: Map successfully transfered -Transfering passwd.byname... -ypxfr: Exiting: Map successfully transfered -Transfering group.bygid... -ypxfr: Exiting: Map successfully transfered -Transfering group.byname... -ypxfr: Exiting: Map successfully transfered -Transfering services.byname... -ypxfr: Exiting: Map successfully transfered -Transfering rpc.bynumber... -ypxfr: Exiting: Map successfully transfered -Transfering rpc.byname... -ypxfr: Exiting: Map successfully transfered -Transfering protocols.byname... -ypxfr: Exiting: Map successfully transfered -Transfering master.passwd.byname... -ypxfr: Exiting: Map successfully transfered -Transfering networks.byname... -ypxfr: Exiting: Map successfully transfered -Transfering networks.byaddr... -ypxfr: Exiting: Map successfully transfered -Transfering netid.byname... -ypxfr: Exiting: Map successfully transfered -Transfering hosts.byaddr... -ypxfr: Exiting: Map successfully transfered -Transfering protocols.bynumber... -ypxfr: Exiting: Map successfully transfered -Transfering ypservers... -ypxfr: Exiting: Map successfully transfered -Transfering hosts.byname... -ypxfr: Exiting: Map successfully transfered +Transferring netgroup... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byuser... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byhost... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring group.bygid... +ypxfr: Exiting: Map successfully transferred +Transferring group.byname... +ypxfr: Exiting: Map successfully transferred +Transferring services.byname... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.byname... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.byname... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring netid.byname... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring ypservers... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byname... +ypxfr: Exiting: Map successfully transferred slave.example.com has been setup as an YP slave server without any errors. Don't forget to update map ypservers on master.example.com. You should now have a directory called /var/yp/test-domain. Copies of the NIS master server's maps should be in this directory. You will need to make sure that these stay updated. The following /etc/crontab entries on your slave servers should do the job: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid These two lines force the slave to sync its maps with the maps on the master server. Although this is not mandatory, because the master server tries to make sure any changes to it's NIS maps are communicated to it's slaves, the password information is so vital to systems that depend on the server, that it is a good idea to force the updates. This is more important on busy networks where map updates might not always complete. NIS Clients An NIS client establishes what is called a binding to a particular NIS server using the ypbind daemon. Ypbind checks the system's default domain (as set by the domainname command), and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind, which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. Ypbind will occasionally ping the server to make sure it is still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. Setting up an NIS client Setting up a FreeBSD machine to be a NIS client is fairly straight forward. Set the host's NIS domainname with the domainname command, or at boot time with this entry in /etc/rc.conf: nisdomainname="test-domain" To import all possible password entries from the NIS server, add this line to your /etc/master.passwd file, using vipw: +::::::::: This line will afford anyone with a valid account in the NIS server's password maps an account. There are many ways to configure your NIS client by changing this line. For more detailed reading see O'Reilly's book on Managing NFS and NIS. To import all possible group entries from the NIS server, add this line to your /etc/group file: +:*:: After completing these steps, you should be able to run ypcat passwd and see the NIS server's passwd map. NIS Security In general, any remote user can issue an RPC to ypserv and retrieve the contents of your NIS maps, provided the remote user knows your domainname. To prevent such unauthorized transactions, ypserv supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, ypserv will attempt to load the securenets information from a file called /var/yp/securenets. This path varies depending on the path specified with the option. This file contains entries that consist of a network specification and a network mask separated by white space. Lines starting with # are considered to be comments. A sample securenets file might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 If ypserv receives a request from an address that matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the /var/yp/securenets file does not exist, ypserv will allow connections from any host. The ypserv program also has support for Wietse Venema's tcpwrapper package. This allows the administrator to use the tcpwrapper configuration files for access control instead of /var/yp/securenets. While both of these access control mechanisms provide some security, they, like the privileged port test, are both vulnerable to IP spoofing attacks. NIS v1 compatibility FreeBSD's ypserv has some support for serving NIS v1 clients. FreeBSD's NIS implementation only uses the NIS v2 protocol, however other implementations include support for the v1 protocol for backwards compatibility with older systems. The ypbind daemons supplied with these systems will try to establish a binding to an NIS v1 server even though they may never actually need it (and they may persist in broadcasting in search of one even after they receive a response from a v2 server). Note that while support for normal client calls is provided, this version of ypserv does not handle v1 map transfer requests; consequently, it can not be used as a master or slave in conjunction with older NIS servers that only support the v1 protocol. Fortunately, there probably are not any such servers still in use today. NIS servers that are also NIS clients Care must be taken when running ypserv in a multi-server domain where the server machines are also NIS clients. It is generally a good idea to force the servers to bind to themselves rather than allowing them to broadcast bind requests and possibly become bound to each other. Strange failure modes can result if one server goes down and others are dependent upon on it. Eventually all the clients will time out and attempt to bind to other servers, but the delay involved can be considerable and the failure mode is still present since the servers might bind to each other all over again. You can force a host to bind to a particular server by running ypbind with the flag. - libscrypt vs. libdescrypt + libscrypt v.s. libdescrypt One of the most common issues that people run into when trying to implement NIS is crypt library compatibility. If your NIS server is using the DES crypt libraries, it will only support clients that are using DES as well. To check which one your server and clients are using look at the symlinks in /usr/lib. If the machine is configured to use the DES libraries, it will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a If the machine is configured to use the standard FreeBSD MD5 - crypt libraries they will look somethine like this: + crypt libraries they will look something like this: &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a If you have trouble authenticating on an NIS client, this is a pretty good place to start looking for possible problems. DHCP Written by &a.gsutter;, March 2000. What is DHCP? DHCP, the Dynamic Host Configuration Protocol, describes the means by which a system can connect to a network and obtain the necessary information for communication upon that network. FreeBSD uses the ISC (Internet Software Consortium) DHCP implementation, so all implementation-specific information here is for use with the ISC distribution. What This Section Covers This handbook section attempts to describe only the parts of the DHCP system that are integrated with FreeBSD; consequently, the server portions are not described. The DHCP manual pages, in addition to the references below, are useful resources. How it Works When dhclient, the DHCP client, is executed on the client machine, it begins broadcasting requests for configuration information. By default, these requests are on UDP port 68. The server replies on UDP 67, giving the client an IP address and other relevant network information such as netmask, router, and DNS servers. All of this information comes in the form of a DHCP "lease" and is only valid for a certain time (configured by the DHCP server maintainer). In this manner, stale IP addresses for clients no longer connected to the network can be automatically reclaimed. DHCP clients can obtain a great deal of information from the server. An exhaustive list may be found in &man.dhcp-options.5;. FreeBSD Integration FreeBSD fully integrates the ISC DHCP client, dhclient. DHCP client support is provided within both the installer and the base system, obviating the need for detailed knowledge of network configurations on any network that runs a DHCP server. dhclient has been included in all FreeBSD distributions since 3.2. DHCP is supported by sysinstall. When configuring a network interface within sysinstall, the first question asked is, "Do you want to try dhcp configuration of this interface?" Answering affirmatively will execute dhclient, and if successful, will fill in the network configuration information automatically. To have your system use DHCP to obtain network information upon startup, edit your /etc/rc.conf to include the following: ifconfig_fxp0="DHCP" Be sure to replace fxp0 with the designation for the interface that you wish to dynamically configure. If you are using a different location for dhclient, or if you wish to pass additional flags to dhclient, also include the following (editing as necessary): dhcp_program="/sbin/dhclient" dhcp_flags="" The DHCP server, dhcpd, is included as part of the isc-dhcp2 port in the ports collection. This port contains the full ISC DHCP distribution, consisting of client, server, relay agent and documentation. Files /etc/dhclient.conf dhclient requires a configuration file, /etc/dhclient.conf. Typically the file contains only comments, the defaults being reasonably sane. This configuration file is described by the &man.dhclient.conf.5; man page. /sbin/dhclient dhclient is statically linked and resides in /sbin. The &man.dhclient.8; manual page gives more information about dhclient. /sbin/dhclient-script dhclient-script is the FreeBSD-specific DHCP client configuration script. It is described in &man.dhclient-script.8;, but should not need any user modification to function properly. /var/db/dhclient.leases The DHCP client keeps a database of valid leases in this file, which is written as a log. &man.dhclient.leases.5; gives a slightly longer description. Further Reading The DHCP protocol is fully described in RFC 2131. An informational resource has also been set up at dhcp.org. diff --git a/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml index b6c5c3c292..12de057851 100644 --- a/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml @@ -1,732 +1,732 @@ Backups Synopsis The following chapter will cover methods of backing up data, and the programs used to create those backups. If you would like to contribute something to this section, send it to the &a.doc;. Tape Media The major tape media are the 4mm, 8mm, QIC, mini-cartridge and DLT. 4mm (DDS: Digital Data Storage) 4mm tapes are replacing QIC as the workstation backup media of choice. This trend accelerated greatly when Conner purchased Archive, a leading manufacturer of QIC drives, and then stopped production of QIC drives. 4mm drives are small and quiet but do not have the reputation for reliability that is enjoyed by 8mm drives. The cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short head life for the same reason, both use helical scan. - Data thruput on these drives starts ~150kB/s, peaking at ~500kB/s. + Data throughput on these drives starts ~150kB/s, peaking at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. Multi-drive tape library units can have 6 drives in a single cabinet with automatic tape changing. Library capacities reach 240 GB. The DDS-3 standard now supports tape capacities up to 12GB (or 24GB compressed). 4mm drives, like 8mm drives, use helical-scan. All the benefits and drawbacks of helical-scan apply to both 4mm and 8mm drives. Tapes should be retired from use after 2,000 passes or 100 full backups. 8mm (Exabyte) 8mm tapes are the most common SCSI tape drives; they are the best choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm tape drive. 8mm drives are reliable, convenient and quiet. Cartridges are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is relatively short head and tape life due to the high rate of relative motion of the tape across the heads. - Data thruput ranges from ~250kB/s to ~500kB/s. Data sizes start + Data throughput ranges from ~250kB/s to ~500kB/s. Data sizes start at 300 MB and go up to 7 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. These drives are available as single units or multi-drive tape libraries with 6 drives and 120 tapes in a single cabinet. Tapes are changed automatically by the unit. Library capacities reach 840+ GB. The Exabyte Mammoth model supports 12GB on one tape (24MB with compression) and costs approximately twice as much as conventional tape drives. Data is recorded onto the tape using helical-scan, the heads are positioned at an angle to the media (approximately 6 degrees). The tape wraps around 270 degrees of the spool that holds the heads. The spool spins while the tape slides over the spool. The result is a high density of data and closely packed tracks that angle across the tape from one edge to the other. QIC QIC-150 tapes and drives are, perhaps, the most common tape drive and media around. QIC tape drives are the least expensive "serious" backup drives. The downside is the cost of media. QIC tapes are expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB data storage. But, if your needs can be satisfied with a half-dozen tapes, QIC may be the correct choice. QIC is the most common tape drive. Every site has a QIC drive of some density or another. Therein lies the rub, QIC has a large number of densities on physically similar (sometimes identical) tapes. QIC drives are not quiet. These drives audibly seek before they begin to record data and are clearly audible whenever reading, writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x 10.2 x 1.7 mm). Mini-cartridges, which also use 1/4" wide tape are discussed separately. Tape libraries and changers are not available. - Data thruput ranges from ~150kB/s to ~500kB/s. Data capacity + Data throughput ranges from ~150kB/s to ~500kB/s. Data capacity ranges from 40 MB to 15 GB. Hardware compression is available on many of the newer QIC drives. QIC drives are less frequently installed; they are being supplanted by DAT drives. Data is recorded onto the tape in tracks. The tracks run along the long axis of the tape media from one end to the other. The number of tracks, and therefore the width of a track, varies with the tape's capacity. Most if not all newer drives provide backward-compatibility at least for reading (but often also for writing). QIC has a good reputation regarding the safety of the data (the mechanics are simpler and more robust than for helical scan drives). Tapes should be retired from use after 5,000 backups. * Mini-Cartridge ]]> DLT DLT has the fastest data transfer rate of all the drive types listed here. The 1/2" (12.5mm) tape is contained in a single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging gate along one entire side of the cartridge. The drive mechanism opens this gate to extract the tape leader. The tape leader has an oval hole in it which the drive uses to "hook" the tape. The take-up spool is located inside the tape drive. All the other tape cartridges listed here (9 track tapes are the only exception) have both the supply and take-up spools located inside the tape cartridge itself. - Data thruput is approximately 1.5MB/s, three times the thruput of + Data throughput is approximately 1.5MB/s, three times the throughput of 4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB for a single drive. Drives are available in both multi-tape changers and multi-tape, multi-drive tape libraries containing from 5 to 900 tapes over 1 to 20 drives, providing from 50GB to 9TB of storage. With compression, DLT Type IV format supports up to 70GB capacity. Data is recorded onto the tape in tracks parallel to the direction of travel (just like QIC tapes). Two tracks are written at once. Read/write head lifetimes are relatively long; once the tape stops moving, there is no relative motion between the heads and the tape. AIT AIT is a new format from Sony, and can hold up to 50GB (with compression) per tape. The tapes contain memory chips which retain an index of the tape's contents. This index can be rapidly read by the tape drive to determine the position of files on the tape, instead of the several minutes that would be required for other tapes. Software such as SAMS:Alexandria can operate forty or more AIT tape libraries, communicating directly with the tape's memory chip to display the contents on screen, determine what files where backed up to which tape, locate the correct tape, load it, and restore the data from the tape. Libraries like this cost in the region of $20,000, pricing them a little out of the hobbyist market. Using a New Tape for the First Time The first time that you try to read or write a new, completely blank tape, the operation will fail. The console messages should be similar to: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready The tape does not contain an Identifier Block (block number 0). All QIC tape drives since the adoption of QIC-525 standard write an Identifier Block to the tape. There are two solutions: mt fsf 1 causes the tape drive to write an Identifier Block to the tape. Use the front panel button to eject the tape. Re-insert the tape and &man.dump.8; data to the tape. &man.dump.8; will report DUMP: End of tape detected and the console will show: HARDWARE FAILURE info:280 asc:80,96 rewind the tape using: mt rewind Subsequent tape operations are successful. Backup Programs The three major programs are &man.dump.8;, &man.tar.1;, and &man.cpio.1;. Dump and Restore &man.dump.8; and &man.restore.8; are the traditional Unix backup programs. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the filesystems. &man.dump.8; backs up devices, entire filesystems, not parts of a filesystem and not directory trees that span more than one filesystem, using either soft links &man.ln.1; or mounting one filesystem onto another. &man.dump.8; does not write files and directories to tape, but rather writes the data blocks that are the building blocks of files and directories. &man.dump.8; has quirks that remain from its early days in Version 6 of ATT Unix (circa 1975). The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. &man.rdump.8; and &man.rrestore.8; backup data across the network to a tape drive attached to another computer. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must have rhosts access to the remote computer. The arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use on the remote computer. (e.g. When rdump'ing from a FreeBSD computer to an Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there are security implications to allowing rhosts commands. Evaluate your situation carefully. Tar &man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975). &man.tar.1; operates in cooperation with the filesystem; &man.tar.1; writes files and directories to tape. &man.tar.1; does not support the full range of options that are available from &man.cpio.1;, but &man.tar.1; does not require the unusual command pipeline that &man.cpio.1; uses. Most versions of &man.tar.1; do not support backups across the network. The GNU version of &man.tar.1;, which FreeBSD utilizes, supports remote devices using the same syntax as &man.rdump.8;. To &man.tar.1; to an Exabyte tape drive connected to a Sun called komodo, use: /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1. For versions without remote device support, you can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b If you're worried about the security of backing over a network you should use the &man.ssh.1; command instead of &man.rsh.1;. Cpio &man.cpio.1; is the original Unix file interchange tape program for magnetic media. &man.cpio.1; has options (among many others) to perform byte-swapping, write a number of different archives format, and pipe the data to other programs. This last feature makes &man.cpio.1; and excellent choice for installation media. &man.cpio.1; does not know how to walk the directory tree and a list of files must be provided through stdin. &man.cpio.1; does not support backups across the network. You can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. (XXX add an example command) Pax &man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and &man.cpio.1;. Over the years the various versions of &man.tar.1; and &man.cpio.1; have gotten slightly incompatible. So rather than fight it out to fully standardize them, POSIX created a new archive utility. &man.pax.1; attempts to read and write many of the various &man.cpio.1; and &man.tar.1; formats, plus new formats of its own. Its command set more resembles &man.cpio.1; than &man.tar.1;. Amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and network communications with the Amanda server. A common problem at locations with a number of large disks is the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem. Amanda can use a "holding disk" to backup several filesystems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the filesystems listed in Amanda's configuration file. The "archive set" also contains nightly incremental (or differential) backups of all the filesystems. Restoring a damaged filesystem requires the most recent full backup and the incremental backups. The configuration file provides fine control backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is available as either a port or a package, it is not installed by default. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and your data is worth little to nothing, then Do nothing is the most suitable backup program for your computer. But beware, Unix is a useful tool, you may find that within six months you have a collection of files that are valuable to you. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by your computer. An example is the files that comprise these handbook pages-they have been generated from SGML input files. Creating backups of these HTML files is not necessary. The SGML source files are backed up regularly. Which Backup Program is Best? &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of Unix filesystems is &man.dump.8;. Elizabeth created filesystems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by do a backup and restore of that filesystems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are only four steps that you need to perform in preparation for any disaster that may occur. First, print the disklabel from each of your disks (e.g. disklabel da0 | lpr), your filesystem table (/etc/fstab) and all boot messages, two copies of each. - Second, determine that the boot and fixit floppies + Second, determine that the boot and fix-it floppies (boot.flp and fixit.flp) have all your devices. The easiest way to check is to reboot your machine with the boot floppy in the floppy drive and check the boot messages. If all your devices are listed and functional, skip on to step three. Otherwise, you have to create two custom bootable floppies which has a kernel that can mount your all of your disks and access your tape drive. These floppies must contain: &man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and whichever backup program you use. These programs must be statically linked. If you use &man.dump.8;, the floppy must contain &man.restore.8;. Third, create backup tapes regularly. Any changes that you make after your last backup may be irretrievably lost. Write-protect the backup tapes. Fourth, test the floppies (either boot.flp and fixit.flp or the two custom bootable floppies you made in step two.) and backup tapes. Make notes of the procedure. Store these notes with the bootable floppy, the printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you might accidently type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two backup tapes each time. Store one of each at a remote location. A remote location is NOT the basement of the same office building. A number of firms in the World Trade Center learned this lesson the hard way. A remote location should be physically separated from your computers and disk drives by a significant distance. An example script for creating a bootable floppy: /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum filesystem table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < After the Disaster The key question is: did your hardware survive? You have been doing regular backups so there is no need to worry about the software. If the hardware has been damaged. First, replace those parts that have been damaged. If your hardware is okay, check your floppies. If you are using a custom boot floppy, boot single-user (type -s at the boot: prompt). Skip the following paragraph. If you are using the boot.flp and fixit.flp floppies, keep reading. Insert the boot.flp floppy in the first floppy drive and boot the computer. The original install menu will be displayed on the screen. Select the Fixit--Repair mode with CDROM or floppy. option. Insert the fixit.flp when prompted. restore and the other programs that you need are located in /mnt2/stand. Recover each filesystem separately. Try to &man.mount.8; (e.g. mount /dev/da0a /mnt) the root partition of your first disk. If the disklabel was damaged, use &man.disklabel.8; to re-partition and label the disk to match the label that your printed and saved. Use &man.newfs.8; to re-create the filesystems. Re-mount the root partition of the floppy read-write (mount -u -o rw /mnt). Use your backup program and backup tapes to recover the data for this filesystem (e.g. restore vrf /dev/sa0). Unmount the filesystem (e.g. umount /mnt) Repeat for each filesystem that was damaged. Once your system is running, backup your data onto new tapes. Whatever caused the crash or data loss may strike again. An another hour spent now, may save you from further distress later. * I did not prepare for the Disaster, What Now? ]]> What about Backups to Floppies? Can I use floppies for backing up my data? Floppy disks are not really a suitable media for making backups as: The media is unreliable, especially over long periods of time Backing up and restoring is very slow They have a very limited capacity (the days of backing up an entire hard disk onto a dozen or so floppies has long since passed). However, if you have no other method of backing up your data then floppy disks are better than no backup at all. If you do have to use floppy disks then ensure that you use good quality ones. Floppies that have been lying around the office for a couple of years are a bad choice. Ideally use new ones from a reputable manufacturer. So how do I backup my data to floppies? The best way to backup to floppy disk is to use &man.tar.1; with the (multi volume) option, which allows backups to span multiple floppies. To backup all the files in the current directory and sub-directory use this (as root): &prompt.root; tar Mcvf /dev/rfd0 * When the first floppy is full &man.tar.1; will prompt you to insert the next volume (because &man.tar.1; is media independent it refers to volumes. In this context it means floppy disk) Prepare volume #2 for /dev/rfd0 and hit return: This is repeated (with the volume number incrementing) until all the specified files have been archived. Can I compress my backups? Unfortunately, &man.tar.1; will not allow the option to be used for multi-volume archives. You could, of course, &man.gzip.1; all the files, &man.tar.1; them to the floppies, then &man.gunzip.1; the files again! How do I restore my backups? To restore the entire archive use: &prompt.root; tar Mxvf /dev/rfd0 To restore only specific files you can either start with the first floppy and use: &prompt.root; tar Mxvf /dev/rfd0 filename &man.tar.1; will prompt you to insert subsequent floppies until it finds the required file. Alternatively, if you know which floppy the file is on then you can simply insert that floppy and use the same command as above. Note that if the first file on the floppy is a continuation from the previous one then &man.tar.1; will warn you that it cannot restore it, even if you have not asked it to! diff --git a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml index da26d06487..41322bc613 100644 --- a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml @@ -1,6011 +1,6011 @@ Contributing to FreeBSD Contributed by &a.jkh;. So you want to contribute something to FreeBSD? That is great! We can always use the help, and FreeBSD is one of those systems that relies on the contributions of its user base in order to survive. Your contributions are not only appreciated, they are vital to FreeBSD's continued growth! Contrary to what some people might also have you believe, you do not need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. Since the FreeBSD project is responsible for an entire operating system environment (and its installation) rather than just a kernel or a few scattered utilities, our TODO list also spans a very wide range of tasks, from documentation, beta testing and presentation to highly specialized types of kernel development. No matter what your skill level, there is almost certainly something you can do to help the project! Commercial entities engaged in FreeBSD-related enterprises are also encouraged to contact us. Need a special extension to make your product work? You will find us receptive to your requests, given that they are not too outlandish. Working on a value-added product? Please let us know! We may be able to work cooperatively on some aspect of it. The free software world is challenging a lot of existing assumptions about how software is developed, sold, and maintained throughout its life cycle, and we urge you to at least give it a second look. What is Needed The following list of tasks and sub-projects represents something of an amalgam of the various core team TODO lists and user requests we have collected over the last couple of months. Where possible, tasks have been ranked by degree of urgency. If you are interested in working on one of the tasks you see here, send mail to the coordinator listed by clicking on their names. If no coordinator has been appointed, maybe you would like to volunteer? High priority tasks The following tasks are considered to be urgent, usually because they represent something that is badly broken or sorely needed: 3-stage boot issues. Overall coordination: &a.hackers; Do WinNT compatible drive tagging so that the 3rd stage can provide an accurate mapping of BIOS geometries for disks. Filesystem problems. Overall coordination: &a.fs; Clean up and document the nullfs filesystem code. Coordinator: &a.eivind; Fix the union file system. Coordinator: &a.dg; Implement Int13 vm86 disk driver. Coordinator: &a.hackers; New bus architecture. Coordinator: &a.newbus; Port existing ISA drivers to new architecture. Move all interrupt-management code to appropriate parts of the bus drivers. Port PCI subsystem to new architecture. Coordinator: &a.dfr; Figure out the right way to handle removable devices and then use that as a substrate on which PC-Card and CardBus support can be implemented. Resolve the probe/attach priority issue once and for all. Move any remaining buses over to the new architecture. Kernel issues. Overall coordination: &a.hackers; Add more pro-active security infrastructure. Overall coordination: &a.security; Build something like Tripwire(TM) into the kernel, with a remote and local part. There are a number of cryptographic issues to getting this right; contact the coordinator for details. Coordinator: &a.eivind; Make the entire kernel use suser() instead of comparing to 0. It is presently using about half of each. Coordinator: &a.eivind; Split securelevels into different parts, to allow an administrator to throw away those privileges he can throw away. Setting the overall securelevel needs to have the same effect as now, obviously. Coordinator: &a.eivind; Make it possible to upload a list of allowed program to BPF, and then block BPF from accepting other programs. This would allow BPF to be used e.g. for DHCP, without allowing an attacker to start snooping the local network. Update the security checker script. We should at least grab all the checks from the other BSD derivatives, and add checks that a system with securelevel increased also have reasonable flags on the relevant parts. Coordinator: &a.eivind; Add authorization infrastructure to the kernel, to allow different authorization policies. Part of this could be done by modifying suser(). Coordinator: &a.eivind; Add code to the NFS layer so that you cannot chdir("..") out of an NFS partition. E.g., /usr is a UFS partition with /usr/src NFS exported. Now it is possible to use the NFS filehandle for /usr/src to get access to /usr. Medium priority tasks The following tasks need to be done, but not with any particular urgency: Full KLD based driver support/Configuration Manager. Write a configuration manager (in the 3rd stage boot?) that probes your hardware in a sane manner, keeps only the KLDs required for your hardware, etc. PCMCIA/PCCARD. Coordinators: &a.msmith; and &a.imp; Documentation! Reliable operation of the pcic driver (needs testing). Recognizer and handler for sio.c (mostly done). Recognizer and handler for ed.c (mostly done). Recognizer and handler for ep.c (mostly done). User-mode recognizer and handler (partially done). Advanced Power Management. Coordinators: &a.msmith; and &a.phk; APM sub-driver (mostly done). IDE/ATA disk sub-driver (partially done). syscons/pcvt sub-driver. Integration with the PCMCIA/PCCARD drivers (suspend/resume). Low priority tasks The following tasks are purely cosmetic or represent such an investment of work that it is not likely that anyone will get them done anytime soon: The first N items are from Terry Lambert terry@lambert.org NetWare Server (protected mode ODI driver) loader and - subservices to allow the use of ODI card drivers supplied with + sub-services to allow the use of ODI card drivers supplied with network cards. The same thing for NDIS drivers and NetWare SCSI drivers. An "upgrade system" option that works on Linux boxes instead of just previous rev FreeBSD boxes. Symmetric Multiprocessing with kernel preemption (requires kernel preemption). A concerted effort at support for portable computers. This is somewhat handled by changing PCMCIA bridging rules and power management event handling. But there are things like detecting - internal vs. external display and picking a different screen + internal v.s.. external display and picking a different screen resolution based on that fact, not spinning down the disk if the machine is in dock, and allowing dock-based cards to disappear without affecting the machines ability to boot (same issue for PCMCIA). Smaller tasks Most of the tasks listed in the previous sections require either a considerable investment of time or an in-depth knowledge of the FreeBSD kernel (or both). However, there are also many useful tasks which are suitable for "weekend hackers", or people without programming skills. If you run FreeBSD-current and have a good Internet connection, there is a machine current.FreeBSD.org which builds a full release once a day — every now and again, try and install the latest release from it and report any failures in the process. Read the freebsd-bugs mailing list. There might be a problem you can comment constructively on or with patches you can test. Or you could even try to fix one of the problems yourself. Read through the FAQ and Handbook periodically. If anything is badly explained, out of date or even just completely wrong, let us know. Even better, send us a fix (SGML is not difficult to learn, but there is no objection to ASCII submissions). Help translate FreeBSD documentation into your native language (if not already available) — just send an email to &a.doc; asking if anyone is working on it. Note that you are not committing yourself to translating every single FreeBSD document by doing this — in fact, the documentation most in need of translation is the installation instructions. Read the freebsd-questions mailing list and &ng.misc occasionally (or even regularly). It can be very satisfying to share your expertise and help people solve their problems; sometimes you may even learn something new yourself! These forums can also be a source of ideas for things to work on. - If you know of any bugfixes which have been successfully + If you know of any bug fixes which have been successfully applied to -current but have not been merged into -stable after a decent interval (normally a couple of weeks), send the committer a polite reminder. Move contributed software to src/contrib in the source tree. Make sure code in src/contrib is up to date. Look for year 2000 bugs (and fix any you find!) Build the source tree (or just part of it) with extra warnings enabled and clean up the warnings. Fix warnings for ports which do deprecated things like using gets() or including malloc.h. If you have contributed any ports, send your patches back to the original author (this will make your life easier when they bring out the next version) Suggest further tasks for this list! Work through the PR database The FreeBSD PR list shows all the current active problem reports and requests for enhancement that have been submitted by FreeBSD users. Look through the open PRs, and see if anything there takes your interest. Some of these might be very simple tasks, that just need an extra pair of eyes to look over them and confirm that the fix in the PR is a good one. Others might be much more complex. Start with the PRs that have not been assigned to anyone else, but if one them is assigned to someone else, but it looks like something you can handle, e-mail the person it is assigned to and ask if you can work on it—they might already have a patch ready to be tested, or further ideas that you can discuss with them. How to Contribute Contributions to the system generally fall into one or more of the following 6 categories: Bug reports and general commentary An idea or suggestion of general technical interest should be mailed to the &a.hackers;. Likewise, people with an interest in such things (and a tolerance for a high volume of mail!) may subscribe to the hackers mailing list by sending mail to &a.majordomo;. See mailing lists for more information about this and other mailing lists. If you find a bug or are submitting a specific change, please report it using the &man.send-pr.1; program or its WEB-based equivalent. Try to fill-in each field of the bug report. Unless they exceed 65KB, include any patches directly in the report. When including patches, do not use cut-and-paste because cut-and-paste turns tabs into spaces and makes them unusable. Consider compressing patches and using &man.uuencode.1; if they exceed 20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/. After filing a report, you should receive confirmation along with a tracking number. Keep this tracking number so that you can update us with details about the problem by sending mail to bug-followup@FreeBSD.org. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way. If you do not receive confirmation in a timely fashion (3 days to a week, depending on your email connection) or are, for some reason, unable to use the &man.send-pr.1; command, then you may ask someone to file it for you by sending mail to the &a.bugs;. Changes to the documentation Changes to the documentation are overseen by the &a.doc;. Send submissions and changes (even small ones are welcome!) using send-pr as described in Bug Reports and General Commentary. Changes to existing source code An addition or change to the existing source code is a somewhat trickier affair and depends a lot on how far out of date you are with the current state of the core FreeBSD development. There is a special on-going release of FreeBSD known as FreeBSD-current which is made available in a variety of ways for the convenience of developers working actively on the system. See Staying current with FreeBSD for more information about getting and using FreeBSD-current. Working from older sources unfortunately means that your changes may sometimes be too obsolete or too divergent for easy re-integration into FreeBSD. Chances of this can be minimized somewhat by subscribing to the &a.announce; and the &a.current; lists, where discussions on the current state of the system take place. Assuming that you can manage to secure fairly up-to-date sources to base your changes on, the next step is to produce a set of diffs to send to the FreeBSD maintainers. This is done with the &man.diff.1; command, with the context diff form being preferred. For example: &prompt.user; diff -c oldfile newfile or &prompt.user; diff -c -r olddir newdir would generate such a set of context diffs for the given source file or directory hierarchy. See the man page for &man.diff.1; for more details. Once you have a set of diffs (which you may test with the &man.patch.1; command), you should submit them for inclusion with FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary. Do not just send the diffs to the &a.hackers; or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the pr database until we do. If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a tar file and run the &man.uuencode.1; program on it. Shar archives are also welcome. If your change is of a potentially sensitive nature, e.g. you are unsure of copyright issues governing its further distribution or you are simply not ready to release it without a tighter review first, then you should send it to &a.core; directly rather than submitting it with &man.send-pr.1;. The core mailing list reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also very busy and so you should only send mail to them where it is truly necessary. Please refer to man 9 intro and man 9 style for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code. New code or major value-added packages In the rare case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it - becomes almost always necessary to either send changes as uuencode'd + becomes almost always necessary to either send changes as uuencoded tar files or upload them to our ftp site ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/. When working with large amounts of code, the touchy subject of copyrights also invariably comes up. Acceptable copyrights for code included in FreeBSD are: The BSD copyright. This copyright is most preferred due to its no strings attached nature and general attractiveness to commercial enterprises. Far from discouraging such commercial use, the FreeBSD Project actively encourages such participation by commercial interests who might eventually be inclined to invest something of their own into FreeBSD. The GNU Public License, or GPL. This license is not quite as popular with us due to the amount of extra effort demanded of anyone using the code for commercial purposes, but given the sheer quantity of GPL'd code we currently require (compiler, assembler, text formatter, etc) it would be silly to refuse additional contributions under this license. Code under the GPL also goes into a different part of the tree, that being /sys/gnu or /usr/src/gnu, and is therefore easily identifiable to anyone for whom the GPL presents a problem. Contributions coming under any other type of copyright must be carefully reviewed before their inclusion into FreeBSD will be considered. Contributions for which particularly restrictive commercial copyrights apply are generally rejected, though the authors are always encouraged to make such changes available through their own channels. To place a BSD-style copyright on your work, include the following text at the very beginning of every source code file you wish to protect, replacing the text between the %% with the appropriate information. Copyright (c) %%proper_years_here%% %%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ For your convenience, a copy of this text can be found in /usr/share/examples/etc/bsd-style-copyright. Money, Hardware or Internet access We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves. <anchor id="donations">Donating funds While the FreeBSD Project is not a 501(c)(3) (charitable) corporation and hence cannot offer special tax incentives for any donations made, any such donations will be gratefully accepted on behalf of the project by FreeBSD, Inc. FreeBSD, Inc. was founded in early 1995 by &a.jkh; and &a.dg; with the goal of furthering the aims of the FreeBSD Project and giving it a minimal corporate presence. Any and all funds donated (as well as any profits that may eventually be realized by FreeBSD, Inc.) will be used exclusively to further the project's goals. Please make any checks payable to FreeBSD, Inc., sent in care of the following address:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
(currently using the Walnut Creek CDROM address until a PO box can be opened) Wire transfers may also be sent directly to:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to &a.jkh, either via email or to the FreeBSD, Inc. postal address given above. If you do not wish to be listed in our donors section, please specify this when making your donation. Thanks! Donating hardware Donations of hardware in any of the 3 following categories are also gladly accepted by the FreeBSD Project: General purpose hardware such as disk drives, memory or complete systems should be sent to the FreeBSD, Inc. address listed in the donating funds section. Hardware for which ongoing compliance testing is desired. We are currently trying to put together a testing lab of all components that FreeBSD supports so that proper regression testing can be done with each new release. We are still lacking many important pieces (network cards, motherboards, etc) and if you would like to make such a donation, please contact &a.dg; for information on which items are still required. Hardware currently unsupported by FreeBSD for which you would like to see such support added. Please contact the &a.core; before sending such items as we will need to find a developer willing to take on the task before we can accept delivery of new hardware. Donating Internet access We can always use new mirror sites for FTP, WWW or cvsup. If you would like to be such a mirror, please contact the FreeBSD project administrators hubs@FreeBSD.org for more information. Donors Gallery The FreeBSD Project is indebted to the following donors and would - like to publically thank them here! + like to publicly thank them here! Contributors to the central server project: The following individuals and businesses made it possible for the FreeBSD Project to build a new central server machine to eventually replace freefall.FreeBSD.org by donating the following items: &a.mbarkah and his employer, Hemisphere Online, donated a Pentium Pro (P6) 200Mhz CPU ASA Computers donated a Tyan 1662 motherboard. Joe McGuckin joe@via.net of ViaNet Communications donated a Kingston ethernet controller. Jack O'Neill jack@diamond.xtalwind.net donated an NCR 53C875 SCSI controller card. Ulf Zimmermann ulf@Alameda.net of Alameda Networks donated 128MB of memory, a 4 Gb disk drive and the case. Direct funding: The following individuals and businesses have generously contributed direct funding to the project: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Blue Mountain Arts Epilogue Technology Corporation &a.sef Global Technology Associates, Inc Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Kenneth P. Stox ken@stox.sa.enteract.com of Imaginary Landscape, LLC. Dmitry S. Kohmanyuk dk@dog.farm.org Laser5 of Japan (a portion of the profits from sales of their various FreeBSD - CD-ROMs). + CDROMs). Fuki Shuppan Publishing Co. donated a portion of their profits from Hajimete no FreeBSD (FreeBSD, Getting started) to the FreeBSD and XFree86 projects. ASCII Corp. donated a portion of their profits from several FreeBSD-related books to the FreeBSD project. Yokogawa Electric Corp has generously donated significant funding to the FreeBSD project. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva Hardware contributors: The following individuals and businesses have generously contributed hardware for testing and device driver development/support: 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. TRW Financial Systems, Inc. provided 130 PCs, three 68 GB fileservers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code. Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in freefall. &a.chuck; contributed his floppy tape streamer for experimental work. Larry Altneu larry@ALR.COM, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver. Ernst Winter ewinter@lobo.muc.de contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-) Tekram Technologies sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD/. Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! Christoph Kukulies kuku@FreeBSD.org donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. Special contributors: Walnut Creek CDROM has donated almost more than we can say (see the history document for more details). In particular, we would like to thank them for the original hardware used for freefall.FreeBSD.org, our primary development machine, and for thud.FreeBSD.org, a testing and build box. We are also indebted to them for funding various contributors over the years and providing us with unrestricted use of their T1 connection to the Internet. The interface business GmbH, Dresden has been patiently supporting - &a.joerg; who has often preferred FreeBSD work over paywork, and + &a.joerg; who has often preferred FreeBSD work over paid work, and used to fall back to their (quite expensive) EUnet Internet connection whenever his private connection became too slow or - flakey to work with it... + flaky to work with it... Berkeley Software Design, Inc. has contributed their DOS emulator code to the remaining BSD world, which is used in the doscmd command. Core Team Alumni The following people were members of the FreeBSD core team during the periods indicated. We thank them for their past efforts in the service of the FreeBSD project. In rough chronological order: &a.jdp (1997 - 2000) &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) Derived Software Contributors This software was originally derived from William F. Jolitz's 386BSD release 0.1, though almost none of the original 386BSD specific code remains. This software has been essentially re-implemented from the 4.4BSD-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 and OpenBSD that have been integrated into FreeBSD as well, and we would therefore like to thank all the contributors to NetBSD and OpenBSD for their work. Additional FreeBSD Contributors (in alphabetical order by first name): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adam Strohl troll@digitalspark.net Adoal Xu adoal@iname.com - Adrian Chadd adrian@freebsd.org + Adrian Chadd adrian@FreeBSD.org Adrian Colley aecolley@ois.ie Adrian Hall adrian@ibmpcug.co.uk Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Aleksandr A Babaylov .@babolo.ru Alex garbanzo@hooked.net Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex G. Bulushev bag@demos.su Alex Le Heux alexlh@funk.org Alex Perel veers@disturbed.net Alex Varju varju@webct.com Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Gelfenbain mail@gelf.com Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Bowhill bowhill@bowhill.vservers.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby anders@fix.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew L. Neporada andrew@chg.ru Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andrey Novikov andrey@novikov.com Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Anton N. Bruesov antonz@library.ntu-kpi.kiev.ua Antti Kaipila anttik@iki.fi arci vega@sophia.inria.fr Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arindum Mukerji rmukerji@execpc.com Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Arun Sharma adsharma@sharmas.dhs.org Assar Westerlund assar@sics.se Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Smithurst ben@scientia.demon.co.uk Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Benno Rice benno@netizen.com.au Berend de Boer berend@pobox.com Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Wilcox bob@obiwan.uucp Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd Faulkner faulkner@mpd.tandem.com Boyd R. Faulkner faulkner@asgard.bga.com Brad Hendrickse bradh@uunet.co.za Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce A. Mah bmah@ca.sandia.gov Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@scientech.com Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Choi Jun Ho junker@jazz.snu.ac.kr Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@mips.inka.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Cliff Rowley dozprompt@onsea.com Clive Lin clive@CiRX.ORG Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@neosoft.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Papasian bugg@bugg.strangled.net Dan Piponi wmtop@tanelorn.demon.co.uk Dan Walters hannibal@cyberstation.net Daniel Hagan dhagan@cs.vt.edu Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Harris dannyboy@dannyboy.eyep.net Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@umiacs.umd.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo unknown David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Malone dwmalone@maths.tcd.ie David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com der Mouse mouse@Collatz.McRCIM.McGill.EDU Derek Inksetter derek@saidev.com DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dima Sivachenko dima@Chg.RU Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Dominik Brettnacher domi@saargate.de Dominik Rother dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com Doug Barton Doug@gorean.org Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Duncan Barclay dmlb@ragnet.demon.co.uk Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Chuang edwardc@firebird.org.tw Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Edwin Mons e@ik.nu Ege Rekk aagero@aage.priv.no Eiji-usagi-MATSUmoto usagi@clave.gr.jp ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eoin Lawless eoin@maths.tcd.ie Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erik H. Bakke erikhb@bgnett.no Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@lab321.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Frank Volf volf@oasis.IAEhv.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp G. Adam Stanislavadam@whizkidtech.net Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu Garance A Drosehn gad@eclipse.its.rpi.edu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gianlorenzo Masini masini@uniroma3.it Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Giles Lean giles@nemeton.com.au Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giorgos Keramidas keramida@ceid.upatras.gr Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Robinson greg@rosevale.com.au Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw Ian Dowse iedowse@maths.tcd.ie Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilya V. Komarov mur@lynx.ru IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Issei Suzuki issei@jp.FreeBSD.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@photino.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com J.T. Jang keith@email.gcn.net.tw Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James da Silva jds@cs.umd.edu James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu Jamie Heckford jamie@jamiesdomain.co.uk Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Brown jabrown@caida.org Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeff Palmer jeff@isni.net Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chadwick yoshi@parodius.com Jeremy Chatfield jdc@xinside.com Jeremy Prior unknown Jeremy Shaffner jeremy@external.org Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Bloom bloom@acm.org Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart unknown Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton jsutton@bbcon.com.au Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jua@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp Justas justas@mbank.lv K.Higashino a00303@cc.hc.keio.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp Kazuo Horikawa horikawa@jp.FreeBSD.org Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Kelly Yancey kbyanc@posi.net Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Lokevlo@hello.com.tw Kevin Meltzer perlguy@perlguy.com Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kris Dow kris@vilnya.demon.co.uk KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Larry Altneu larry@ALR.COM Lars Köller Lars.Koeller@Uni-Bielefeld.DE Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lowell Gilbert lowell@world.std.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.ab.ca M.C. Wong unknown Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Malte Lance malte.lance@gmx.net MANTANI Nobutaka nobutaka@nobutaka.com Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcin Cieslak saper@system.pl Mario Sergio Fujikawa Ferreira lioux@gns.com.br Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Ovens mark@dogma.freebsd-uk.eu.org Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk Markus Holmberg saska@acc.umu.se Martin Birgmeier Martin Blapp blapp@attic.ch Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Minkus diskiller@cnbinc.com Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Mas.TAKEMURA unknown Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Heckaman matt@LUCIDA.QC.CA Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthew West mwest@uct.ac.za Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Micha Class michael_class@hpbbse.bbn.hp.com Michael Lucas mwlucas@blackhelicopters.org Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michael Urban murban@tznet.com Michael Vasilenko acid@stu.cn.ua Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar MIHIRA Sanpei Yoshiro sanpei@sanpei.org Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Barcroft mike@q9media.com Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Harding mvh@ix.netcom.com Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@shiva.the-park.com Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Sherwood mike@fate.com Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.ziplink.net Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW MITA Yoshio mita@jp.FreeBSD.org MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp N.G.Smith ngs@sesame.hensa.ac.uk Nadav Eiron nadav@barcode.co.il NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Niall Smart rotel@indigo.ie Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org Nick Johnson freebsd@spatula.net &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su NIIMI Satoshi sa2c@and.or.jp Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name frf@xocolatl.com No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org No Name ZW6T-KND@j.asahi-net.or.jp Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Semyonov os@altavista.net Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Hausen unknown Patrick Seal patseal@hyperhost.net Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul M. Lambert plambert@plambert.net Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com Priit Järv priit@cc.ttu.ee R Joseph Wright rjoseph@mammalia.org R. Kym Horsell Rajesh Vaidheeswarran rv@fore.com Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@drmemory.fnal.gov Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Roman Shterenzon roman@xpert.com Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka cejkar@dcse.fee.vutbr.cz Ruslan Belkin rus@home2.UA.net Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuel Tardieu sam@inf.enst.fr Samuele Zannoli zannoli@cs.unibo.it Sander Janssen janssen@rendo.dekooi.nl Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it SANETO Takanori sanewo@strg.sony.co.jp SASAKI Shunsuke ele@pop17.odn.ne.jp Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott A. Moberly smoberly@xavier.dyndns.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge A. Babkin babkin@hq.icb.chel.su Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@tamacom.com Shinya Esu esu@yk.rim.or.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Shunsuke Akiyama akiyama@jp.FreeBSD.org Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@unm.edu Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sune Stjerneby stjerneby@usa.net SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas A. Stephens tas@stephens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Timothy Jensen toast@blackened.com Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher Tony.Maher@eBioinformatics.com Torbjorn Granlund tege@matematik.su.se Toshihiko ARAI toshi@tenchi.ne.jp Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com Trevor Johnson trevor@jpj.net Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vince Valenti vince@blue-box.net Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Walt M. Shandruk walt@erudition.net Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wiljo Heinen wiljo@freeside.ki.open.de Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhiro Fukama yasuf@big.or.jp Yasuhito FUTATSUKI futatuki@fureai.or.jp Yen-Ming Lee leeym@bsd.ce.ntu.edu.tw Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko OHTA yohta@bres.tsukuba.ac.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yu-Shun Wang yushunwa@isi.edu Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuuichi Narahara aconitum@po.teleway.ne.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zach Zurflu zach@pabst.bendnet.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw 386BSD Patch Kit Patch Contributors (in alphabetical order by first name): Adam Glass glass@postgres.berkeley.edu Adrian Hall adrian@ibmpcug.co.uk Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rod Taylor rod@idiotswitch.org Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuuki SAWADA mami@whale.cc.muroran-it.ac.jp Yuval Yarom yval@cs.huji.ac.il diff --git a/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml index 35bf891f54..6d56021fa1 100644 --- a/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,1860 +1,1860 @@ The Cutting Edge Restructured, reorganized, and parts updated by &a.jim; March 2000. Original work by &a.jkh;, &a.phk;, &a.jdp;, and &a.nik; with feedback from various others. Synopsis FreeBSD is under constant development between releases. For people who want to be on the cutting edge, there are several easy mechanisms for keeping your system in sync with the latest developments. Be warned—the cutting edge is not for everyone! This chapter will help you decide if you want to track the development system, or stick with one of the released versions. - -CURRENT vs. -STABLE + -CURRENT v.s.. -STABLE There are two development branches to FreeBSD; -CURRENT and -STABLE. This section will explain a bit about each and describe how to keep your system up-to-date with each respective tree. -CURRENT will be discussed first, then -STABLE. Staying Current with FreeBSD As you are reading this, keep in mind that -CURRENT is the bleeding edge of FreeBSD development and that if you are new to FreeBSD, you are most likely going to want to think twice about running it. What is FreeBSD-CURRENT? FreeBSD-CURRENT is, quite literally, nothing more than a daily snapshot of the working sources for FreeBSD. These include work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. While many of us compile almost daily from FreeBSD-CURRENT sources, there are periods of time when the sources are literally un-compilable. These problems are generally resolved as expeditiously as possible, but whether or not FreeBSD-CURRENT sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in! Who needs FreeBSD-CURRENT? FreeBSD-CURRENT is made generally available for 3 primary interest groups: Members of the FreeBSD group who are actively working on some part of the source tree and for whom keeping current is an absolute requirement. Members of the FreeBSD group who are active testers, willing to spend time working through problems in order to ensure that FreeBSD-CURRENT remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of FreeBSD. Peripheral members of the FreeBSD (or some other) group who merely wish to keep an eye on things and use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code. What is FreeBSD-CURRENT <emphasis>not</emphasis>? A fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it. A quick way of getting bug fixes. In any way officially supported by us. We do our best to help people genuinely in one of the 3 legitimate FreeBSD-CURRENT categories, but we simply do not have the time to provide tech support for it. This is not because we are mean and nasty people who do not like helping people out (we would not even be doing FreeBSD if we were), it is literally because we cannot answer 400 messages a day and actually work on FreeBSD! I am sure that, if given the choice between having us answer lots of questions or continuing to improve FreeBSD, most of you would vote for us improving it. Using FreeBSD-CURRENT Join the &a.current; and the &a.cvsall; . This is not just a good idea, it is essential. If you are not on the FreeBSD-CURRENT mailing list, you will not see the comments that people are making about the current state of the system and thus will probably end up stumbling over a lot of problems that others have already found and solved. Even more importantly, you will miss out on important bulletins which may be critical to your system's continued health. The &a.cvsall; mailing list will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-current subscribe cvs-all Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. Grab the sources from ftp.FreeBSD.org. You can do this in one of three ways: Use the CTM facility. Unless you have a good TCP/IP connection at a flat rate, this is the way to do it. Use the cvsup program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron and keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 Use ftp. The source tree for FreeBSD-CURRENT is always exported on: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/. We also use wu-ftpd which allows - compressed/tar'd grabbing of whole trees. e.g. you + compressed/tarred grabbing of whole trees. e.g. you see: usr.bin/lex You can do the following to get the whole directory as a tar file: ftp> cd usr.bin ftp> get lex.tar Essentially, if you need rapid on-demand access to the source and communications bandwidth is not a consideration, use cvsup or ftp. Otherwise, use CTM. If you are grabbing the sources to run, and not just look at, then grab all of current, not just selected portions. The reason for this is that various parts of the source depend on updates elsewhere, and trying to compile just a subset is almost guaranteed to get you into trouble. Before compiling current, read the Makefilein /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.current; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. Be active! If you are running FreeBSD-CURRENT, we want to know what you have to say about it, especially if you have suggestions for enhancements or bug fixes. Suggestions with accompanying code are received most enthusiastically! Staying Stable with FreeBSD If you are using FreeBSD in a production environment and want to make sure you have the latest fixes from the -CURRENT branch, you want to be running -STABLE. This is the tree that -RELEASEs are branched from when we are putting together a new release. For example, if you have a copy of 3.4-RELEASE, that is really just a snapshot from the -STABLE branch that we put on CDROM. In order to get any changes merged into -STABLE after the -RELEASE, you need to track the -STABLE branch. What is FreeBSD-STABLE? FreeBSD-STABLE is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Changes of an experimental or untested nature do not go into this branch (see FreeBSD-CURRENT). Who needs FreeBSD-STABLE? If you are a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking stable. This is especially true if you have installed the most recent release (&rel.current;-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release. The stable tree endeavors, above all, to be fully compilable and stable at all times, but we do occasionally make mistakes (these are still active sources with quickly-transmitted updates, after all). We also do our best to thoroughly test fixes in current before bringing them into stable, but sometimes our tests fail to catch every case. If something breaks for you in stable, please let us know immediately! (see next section). Using FreeBSD-STABLE Join the &a.stable;. This will keep you informed of build-dependencies that may appear in stable or any other issues requiring special attention. Developers will also make announcements in this mailing list when they are contemplating some controversial fix or update, giving the users a chance to respond if they have any issues to raise concerning the proposed change. The &a.cvsall; mailing list will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-stable subscribe cvs-all Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. If you are installing a new system and want it to be as stable as possible, you can simply grab the latest dated branch snapshot from ftp://releng4.FreeBSD.org/pub/FreeBSD/ and install it like any other release. If you are already running a previous release of FreeBSD and wish to upgrade via sources then you can easily do so from ftp.FreeBSD.org. This can be done in one of three ways: Use the CTM facility. Unless you have a good TCP/IP connection at a flat rate, this is the way to do it. Use the cvsup program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then on. Many people run cvsup from cron to keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 Use ftp. The source tree for FreeBSD-STABLE is always exported on: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ We also use wu-ftpd which allows - compressed/tar'd grabbing of whole trees. e.g. you + compressed/tarred grabbing of whole trees. e.g. you see: usr.bin/lex You can do the following to get the whole directory for you as a tar file: ftp> cd usr.bin ftp> get lex.tar Essentially, if you need rapid on-demand access to the source and communications bandwidth is not a consideration, use cvsup or ftp. Otherwise, use CTM. Before compiling stable, read the Makefile in /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.stable; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. Synchronizing Your Source There are various ways of using an Internet (or email) connection to stay up-to-date with any given area of the FreeBSD project sources, or all areas, depending on what interests you. The primary services we offer are Anonymous CVS, CVSup, and CTM. Anonymous CVS and CVSup use the pull model of updating sources. In the case of CVSup the user (or a cron script) invokes the cvsup program, and it interacts with a cvsupd server somewhere to bring your files up-to-date. The updates you receive are up-to-the-minute and you get them when, and only when, you want them. You can easily restrict your updates to the specific files or directories that are of interest to you. Updates are generated on the fly by the server, according to what you have and what you want to have. Anonymous CVS is quite a bit more simplistic than CVSup in that it's just an extension to CVS which allows it to pull changes directly from a remote CVS repository. CVSup can do this far more efficiently, but Anonymous CVS is easier to use. CTM, on the other hand, does not interactively compare the sources you have with those on the master archive or otherwise pull them across.. Instead, a script which identifies changes in files since its previous run is executed several times a day on the master CTM machine, any detected changes being compressed, stamped with a sequence-number and encoded for transmission over email (in printable ASCII only). Once received, these CTM deltas can then be handed to the &man.ctm.rmail.1; utility which will automatically decode, verify and apply the changes to the user's copy of the sources. This process is far more efficient than CVSup, and places less strain on our server resources since it is a push rather than a pull model. There are other trade-offs, of course. If you inadvertently wipe out portions of your archive, CVSup will detect and rebuild the damaged portions for you. CTM won't do this, and if you wipe some portion of your source tree out (and don't have it backed up) then you will have to start from scratch (from the most recent CVS base delta) and rebuild it all with CTM or, with anoncvs, simply delete the bad bits and resync. More information about Anonymous CVS, CTM, and CVSup is available further down in this section. Anonymous CVS <anchor id="anoncvs-intro">Introduction Anonymous CVS (or, as it is otherwise known, anoncvs) is a feature provided by the CVS utilities bundled with FreeBSD for synchronizing with a remote CVS repository. Among other things, it allows users of FreeBSD to perform, with no special privileges, read-only CVS operations against one of the FreeBSD project's official anoncvs servers. To use it, one simply sets the CVSROOT environment variable to point at the appropriate anoncvs server, provides the well-known password anoncvs with the cvs login command, and then uses the &man.cvs.1; command to access it like any local repository. While it can also be said that the CVSup and anoncvs services both perform essentially the same function, there are various trade-offs which can influence the user's choice of synchronization methods. In a nutshell, CVSup is much more efficient in its usage of network resources and is by far the most technically sophisticated of the two, but at a price. To use CVSup, a special client must first be installed and configured before any bits can be grabbed, and then only in the fairly large chunks which CVSup calls collections. Anoncvs, by contrast, can be used to examine anything from an individual file to a specific program (like ls or grep) by referencing the CVS module name. Of course, anoncvs is also only good for read-only operations on the CVS repository, so if it's your intention to support local development in one repository shared with the FreeBSD project bits then CVSup is really your only option. <anchor id="anoncvs-usage">Using Anonymous CVS Configuring &man.cvs.1; to use an Anonymous CVS repository is a simple matter of setting the CVSROOT environment variable to point to one of the FreeBSD project's anoncvs servers. At the time of this writing, the following servers are available: USA: :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs (Use cvs login and enter the password anoncvs when prompted.) Since CVS allows one to check out virtually any version of the FreeBSD sources that ever existed (or, in some cases, will exist :-), you need to be familiar with the revision () flag to &man.cvs.1; and what some of the permissible values for it in the FreeBSD Project repository are. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. Here are the branch tags that users might be interested in (keep in mind that the only tags valid for the ports collection is HEAD). HEAD Symbolic name for the main line, or FreeBSD-CURRENT. Also the default when no revision is specified. RELENG_3 The line of development for FreeBSD-3.X, also known as FreeBSD-STABLE. RELENG_2_2 The line of development for FreeBSD-2.2.X, also known as 2.2-STABLE. This branch is mostly obsolete. Here are the revision tags that users might be interested in. Again, none of these are valid for the ports collection since the ports collection does not have multiple revisions. RELENG_3_4_0_RELEASE FreeBSD-3.4. RELENG_3_3_0_RELEASE FreeBSD-3.3. RELENG_3_2_0_RELEASE FreeBSD-3.2. RELENG_3_1_0_RELEASE FreeBSD-3.1. RELENG_3_0_0_RELEASE FreeBSD-3.0. RELENG_2_2_8_RELEASE FreeBSD-2.2.8. RELENG_2_2_7_RELEASE FreeBSD-2.2.7. RELENG_2_2_6_RELEASE FreeBSD-2.2.6. RELENG_2_2_5_RELEASE FreeBSD-2.2.5. RELENG_2_2_2_RELEASE FreeBSD-2.2.2. RELENG_2_2_1_RELEASE FreeBSD-2.2.1. RELENG_2_2_0_RELEASE FreeBSD-2.2.0. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the flag. See the &man.cvs.1; man page for more details. Examples While it really is recommended that you read the manual page for &man.cvs.1; thoroughly before doing anything, here are some quick examples which essentially show how to use Anonymous CVS: Checking out something from -CURRENT (&man.ls.1;) and deleting it again: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co ls &prompt.user; cvs release -d ls &prompt.user; cvs logout Checking out the version of &man.ls.1; in the 2.2-STABLE branch: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co -rRELENG_2_2 ls &prompt.user; cvs release -d ls &prompt.user; cvs logout - Creating a list of changes (as unidiffs) to &man.ls.1; + Creating a list of changes (as unified diffs) to &man.ls.1; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE ls &prompt.user; cvs logout Finding out what other module names can be used: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co modules &prompt.user; more modules/modules &prompt.user; cvs release -d modules &prompt.user; cvs logout Other Resources The following additional resources may be helpful in learning CVS: CVS Tutorial from Cal Poly. Cyclic Software, commercial maintainers of CVS. CVSWeb is the FreeBSD Project web interface for CVS. Using <command>make world</command> - Once you have synchronised your local source tree against a + Once you have synchronized your local source tree against a particular version of FreeBSD (stable, current and so on) you must then use the source tree to rebuild the system. Take a backup I cannot stress highly enough how important it is to take a backup of your system before you do this. While remaking the world is (as long as you follow these instructions) an easy task to do, there will inevitably be times when you make mistakes, or when mistakes made by others in the source tree render your system unbootable. - Make sure you have taken a backup. And have a fixit floppy to + Make sure you have taken a backup. And have a fix-it floppy to hand. I have never needed to use them, and, touch wood, I never will, but it is always better to be safe than sorry. Subscribe to the right mailing list The -STABLE and -CURRENT FreeBSD code branches are, by their nature, in development. People that contribute to FreeBSD are human, and mistakes occasionally happen. Sometimes these mistakes can be quite harmless, just causing your system to print a new diagnostic warning. Or the change may be catastrophic, and render your system unbootable or destroy your filesystems (or worse). If problems like these occur, a heads up is posted to the appropriate mailing list, explaining the nature of the problem and which systems it affects. And an all clear announcement is posted when the problem has been solved. If you try and track -STABLE or -CURRENT and do not read the stable@FreeBSD.org or current@FreeBSD.org mailing lists then you are asking for trouble. Read <filename>/usr/src/UPDATING</filename> Before you do anything else, read /usr/src/UPDATING (or the equivalent file wherever you have a copy of the source code). This file should contain important information about problems you might encounter, or specify the order in which you might have to run certain commands. If UPDATING contradicts something you read here, UPDATING takes precedence. Reading UPDATING is not an acceptable substitute for subscribing to the correct mailing list, as described previously. The two requirements are complementary, not exclusive. Check <filename>/etc/make.conf</filename> Examine the file /etc/make.conf. This contains some default defines for Everything is, by default, commented out. Uncomment those entries that look useful. For a typical user (not a developer), you will probably want to uncomment the CFLAGS and NOPROFILE definitions. If your machine has a floating point unit (386DX, 486DX, Pentium and up class machines) then you can also uncomment the HAVE_FPU line.</para> <para>This definition was removed for version 2.2.2 and up of FreeBSD.</para> </note> <para>Examine the other definitions (COPTFLAGS, NOPORTDOCS and so on) and decide if they are relevant to you.</para> </sect2> <sect2> <title>Update <filename>/etc/group</filename> The /etc directory contains a large part of your system's configuration information, as well as scripts that are run at system startup. Some of these scripts change from version to version of FreeBSD. Some of the configuration files are also used in the day to day running of the system. In particular, /etc/group. There have been occasions when the installation part of make world has expected certain usernames or groups to exist. When performing an upgrade it is likely that these groups did not exist. This caused problems when upgrading. The most recent example of this is when the ppp subsystem were installed using a non-existent (for them) group name. The solution is to examine /usr/src/etc/group and compare its list of groups with your own. If they are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in /etc/group which have the same GID but a different name to those in /usr/src/etc/group. If you are feeling particularly paranoid, you can check your system to see which files are owned by the group you are renaming or deleting. &prompt.root; find / -group GID -print will show all files owned by group GID (which can be either a group name or a numeric group ID). You may want to compile the system in single user mode. Apart from the obvious benefit of making things go slightly faster, reinstalling the system will touch a lot of important system files, all the standard system binaries, libraries, include files and so on. Changing these on a running system (particularly if you have active users on their at the time) is asking for trouble.</para> <para>That said, if you are confident, you can omit this step.</para> <note> <title>Version 2.2.5 and above As described in more detail below, versions 2.2.5 and above of FreeBSD have separated the building process from the installing process. You can therefore build the new system in multi-user mode, and then drop to single user mode to do the installation. As the superuser, you can execute &prompt.root; from a running system, which will drop it to single user mode. Alternatively, reboot the system, and at the boot prompt, enter the flag. The system will then boot single user. At the shell prompt you should then run: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a This checks the filesystems, remounts / read/write, mounts all the other UFS filesystems referenced in /etc/fstab and then turns swapping on. Remove <filename>/usr/obj</filename> As parts of the system are rebuilt they are placed in directories which (by default) go under /usr/obj. The directories shadow those under /usr/src. You can speed up the make world process, and possibly save yourself some dependency headaches by removing this directory as well. Some files below /usr/obj will have the immutable flag set (see &man.chflags.1; for more information) which must be removed first. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * <title>All versions You must be in the /usr/src directory... &prompt.root; cd /usr/src (unless, of course, your source code is elsewhere, in which case change to that directory instead). To rebuild the world you use the &man.make.1; command. This command reads instructions from the Makefile which describes how the programs that comprise FreeBSD should be rebuilt, the order they should be built in, and so on. The general format of the command line you will type is as follows: &prompt.root; make In this example, is an option that you would pass to &man.make.1;. See the &man.make.1; manual page for an example of the options you can pass. passes a variable to the Makefile. The behavior of the Makefile is controlled by these variables. These are the same variables as are set in /etc/make.conf, and this provides another way of setting them. &prompt.root; make -DNOPROFILE=true target - is another way of specifying that profiled libaries should + is another way of specifying that profiled libraries should not be built, and corresponds with the NOPROFILE= true # Avoid compiling profiled libraries lines in /etc/make.conf. target tells &man.make.1; what you want to do. Each Makefile defines a number of different targets, and your choice of target determines what happens. Some targets are listed in the Makefile, but are not meant for you to run. Instead, they are used by the build process to break out the steps necessary to rebuild the system into a number of sub-steps. Most of the time you won't need to pass any parameters to &man.make.1;, and so your command like will look like this: &prompt.root; make target Saving the output It's a good idea to save the output you get from running &man.make.1; to another file. If something goes wrong you will have a copy of the error message, and a complete list of where the process had got to. While this might not help you in diagnosing what has gone wrong, it can help others if you post your problem to one of the FreeBSD mailing lists. The easiest way to do this is to use the &man.script.1; command, with a parameter that specifies the name of the file to save all output to. You would do this immediately before remaking the world, and then type exit when the process has finished. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make world … compile, compile, compile … &prompt.root; exit Script done, … If you do this, do not save the output in /tmp. This directory may be cleared next time you reboot. A better place to store it is in /var/tmp (as in the previous example) or in root's home directory. Version 2.2.2 and below /usr/src/Makefile contains the world target, which will rebuild the entire system and then install it. Use it like this: &prompt.root; make world Version 2.2.5 and above Beginning with version 2.2.5 of FreeBSD (actually, it was first created on the -CURRENT branch, and then retrofitted to -STABLE midway between 2.2.2 and 2.2.5) the world target has been split in two. buildworld and installworld. As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld installs this tree on the current machine. This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is self hosted. Because of this, you can safely run buildworld on a machine running in multi-user mode with no fear of ill-effects. I still recommend you run the installworld part in single user mode though. Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run make buildworld and make installworld on A. B and C should then NFS mount /usr/src and /usr/obj from A, and you can then run make installworld to install the results of the build on B and C. The world target still exists, and you can use it exactly as shown for version 2.2.2. make world runs make buildworld followed by make installworld. If you do the make buildworld and make installworld commands separately, you must pass the same parameters to &man.make.1; each time. If you run: &prompt.root; make -DNOPROFILE=true buildworld you must install the results with: &prompt.root; make -DNOPROFILE=true installworld otherwise it would try and install profiled libraries that had not been built during the make buildworld phase. -CURRENT and above If you are tracking -CURRENT you can also pass the option to make. This lets make spawn several simultaneous processes. This is most useful on true multi-CPU machines. However, since much of the compiling process is IO bound rather than CPU bound it is also useful on single CPU machines. On a typical single-CPU machine you would run: &prompt.root; make -j4 target &man.make.1; will then have up to 4 processes running at any one time. Empirical evidence posted to the mailing lists shows this generally gives the best performance benefit. If you have a multi-CPU machine and you are using an SMP configured kernel try values between 6 and 10 and see how they speed things up. Be aware that (at the time of writing) this is still experimental, and commits to the source tree may occasionally break this feature. If the world fails to compile using this parameter try again without it before you report any problems. Timings Assuming everything goes well you have anywhere between an hour and a half and a day or so to wait. As a general rule of thumb, a 200MHz P6 with more than 32MB of RAM and reasonable SCSI disks will complete make world in about an hour and a half. A 32MB P133 will take 5 or 6 hours. Revise these figures down if your machines are slower… Update <filename>/etc</filename> Remaking the world will not update certain directories (in particular, /etc, /var and /usr) with new or changed configuration files. This is something you have to do by hand, eyeball, and judicious use of &man.diff.1;. You cannot just copy over the files from /usr/src/etc to /etc and have it work. Some of these files must be installed first. This is because the /usr/src/etc directory is not a copy of what your /etc directory should look like. In addition, there are files that should be in /etc that are not in /usr/src/etc. The simplest way to do this is to install the files into a new directory, and then work through them looking for differences. Backup your existing <filename>/etc</filename> Although, in theory, nothing is going to touch this directory automatically, it is always better to be sure. So copy your existing /etc directory somewhere safe. Something like: &prompt.root; cp -Rp /etc /etc.old does a recursive copy, preserves times, ownerships on files and suchlike. You need to build a dummy set of directories to install the new /etc and other files into. I generally choose to put this dummy directory in /var/tmp/root, and there are a number of subdirectories required under this as well. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution This will build the necessary directory structure and install the files. A lot of the subdirectories that have been created under /var/tmp/root are empty and should be deleted. The simplest way to do this is to: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | /usr/bin/perl -lne \ 'opendir(D,$_);@f=readdir(D);rmdir if $#f == 1;closedir(D);' This does a depth first search, examines each directory, and if the number of files in that directory is 2 ( /var/tmp/root now contains all the files that should be placed in appropriate locations below /. You now have to go through each of these files, determining how they differ with your existing files. Note that some of the files that will have been installed in /var/tmp/root have a leading /var/tmp/root/ and /var/tmp/root/root/, although there may be others (depending on when you are reading this. Make sure you use The simplest way to do this is to use &man.diff.1; to compare the two files. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells This will show you the differences between your /etc/shells file and the new /etc/shells file. Use these to decide whether to merge in changes that you have made or whether to copy over your old file. Name the new root directory - (<filename>/var/tmp/root</filename>)with a timestamp, so you can + (<filename>/var/tmp/root</filename>)with a time stamp, so you can easily compare differences between versions Frequently remaking the world means that you have to update /etc frequently as well, which can be a bit of a chore. You can speed this process up by keeping a copy of the last set of changed files that you merged into /etc. The following procedure gives one idea of how to do this. Make the world as normal. When you want to update /etc and the other directories, give the target directory a name based on the current date. If you were doing this on the 14th of February 1998 you could do the following. &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Merge in the changes from this directory as outlined above. Do not remove the /var/tmp/root-19980214 directory when you have finished. When you have downloaded the latest version of the source and remade it, follow step 1. This will give you a new directory, which might be called /var/tmp/root-19980221 (if you wait a week between doing updates). You can now see the differences that have been made in the intervening week using &man.diff.1; to create a recursive diff between the two directories. &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Typically, this will be a much smaller set of differences than those between /var/tmp/root-19980221/etc and /etc. Because the set of differences is smaller, it is easier to migrate those changes across into your /etc directory. You can now remove the older of the two /var/tmp/root-* directories. &prompt.root; rm -rf /var/tmp/root-19980214 Repeat this process every time you need to merge in changes to /etc. You can use &man.date.1; to automate the generation of the directory names. &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Update <filename>/dev</filename> DEVFS If you are using DEVFS then this is probably unnecessary. - For safety's sake, this is a multistep process. + For safety's sake, this is a multi-step process. Copy /var/tmp/root/dev/MAKEDEV to /dev. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev Now, take a snapshot of your current /dev. This snapshot needs to contain the permissions, ownerships, major and minor numbers of each filename, - but it should not contain the timestamps. The easiest way to do + but it should not contain the time stamps. The easiest way to do this is to use &man.awk.1; to strip out some of the information. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Remake all the devices. &prompt.root; Write another snapshot of the directory, this time to /var/tmp/dev2.out. Now look through these two files for any devices that you missed creating. There should not be any, but it is better to be safe than sorry. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out You are most likely to notice disk slice discrepancies which will involve commands such as &prompt.root; sh MAKEDEV sd0s1 to recreate the slice entries. Your precise circumstances may vary. Update <filename>/stand</filename> - This step is included only for completeness, it can safely be + This step is included only for completeness. It can safely be omitted. - For completenesses sake you may want to update the files in + For the sake of completeness, you may want to update the files in /stand as well. These files consist of hard links to the /stand/sysinstall binary. This binary should be statically linked, so that it can work when no other filesystems (and in particular /usr) have been mounted. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install Source older than 2 April 1998 If your source code is older than 2nd April 1998, or the Makefile version is not 1.68 or higher (for FreeBSD current and 3.X systems) or 1.48.2.21 or higher (for 2.2.X systems) you will need to add the NOSHARED=yes option, like so; &prompt.root; make NOSHARED=yes all install Compile and install a new kernel To take full advantage of your new system you should recompile the kernel. This is practically a necessity, as certain memory structures may have changed, and programs like &man.ps.1; and &man.top.1; will fail to work until the kernel and source code versions are the same. Follow the handbook instructions for compiling a new kernel. If you have previously built a custom kernel then carefully examine the LINT config file to see if there are any new options which you should take advantage of. A previous version of this document suggested rebooting before rebuilding the kernel. This is wrong because: Commands like &man.ps.1;, &man.ifconfig.8;, and &man.sysctl.8; may fail. This could leave your machine unable to connect to the network. Basic utilities like &man.mount.8; could fail, making it impossible to mount /, /usr and so on. This is unlikely if you are tracking a -STABLE candidate, but more likely if you are tracking -CURRENT during a large merge. Loadable kernel modules (LKMs on pre-3.X systems, KLDs on 3.X systems and above) built as part of the world may crash an older kernel. For these reasons, it is always best to rebuild and install a new kernel before rebooting. You should build your new kernel after you have completed make world (or make installworld). If you do not want to do this (perhaps you want to confirm that the kernel builds before updating your system) you may have problems. These may be because your &man.config.8; command is out of date with respect to your kernel sources. In this case you could build your kernel with the new version of &man.config.8; &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME This may not work in all cases. It is recommended that you complete make world (or make installworld) before compiling a new kernel. You are now done. After you have verified that everything appears to be in the right place you can reboot the system. A simple &man.fastboot.8; should do it.</para> <screen>&prompt.root; <userinput>fastboot</userinput></screen> </sect2> <sect2> <title>Finished You should now have successfully upgraded your FreeBSD system. Congratulations. You may notice small problems due to things that you have missed. For example, I once deleted /etc/magic as part of the upgrade and merge to /etc, and the file command stopped working. A moment's thought meant that &prompt.root; cd /usr/src/usr.bin/file &prompt.root; was sufficient to fix that one. <qandaentry> <question> <para>Do I need to re-make the world for every change?</para> </question> <answer> <para>There is no easy answer to this one, as it depends on the nature of the change. For example, I have just run CVSup, and it has shown the following files as being updated since I last ran it;</para> <screen><filename>src/games/cribbage/instr.c</filename> <filename>src/games/sail/pl_main.c</filename> <filename>src/release/sysinstall/config.c</filename> <filename>src/release/sysinstall/media.c</filename> <filename>src/share/mk/bsd.port.mk</filename></screen> <para>There is nothing in there that I would re-make the world for. I would go to the appropriate sub-directories and <command>make all install</command>, and that's about it. But if something major changed, for example <filename>src/lib/libc/stdlib</filename> then I would either re-make the world, or at least those parts of it that are statically linked (as well as anything else I might have added that is statically linked).</para> <para>At the end of the day, it is your call. You might be happy re-making the world every fortnight say, and let changes accumulate over that fortnight. Or you might want to re-make just those things that have changed, and are confident you can spot all the dependencies.</para> <para>And, of course, this all depends on how often you want to upgrade, and whether you are tracking -STABLE or -CURRENT.</para> </answer> </qandaentry> <qandaentry> <question> <para>My compile failed with lots of signal 12 (or other signal number) errors. What has happened?</para> </question> <answer> <para>This is normally indicative of hardware problems. (Re)making the world is an effective way to stress test your hardware, and will frequently throw up memory problems. These normally manifest themselves as the compiler mysteriously dying on receipt of strange signals.</para> <para>A sure indicator of this is if you can restart the make and it dies at a different point in the process.</para> <para>In this instance there is little you can do except start swapping around the components in your machine to determine which one is failing.</para> </answer> </qandaentry> <qandaentry> <question> <para>Can I remove <filename>/usr/obj</filename> when I have finished?</para> </question> <answer> <para>That depends on how you want to make the world on future occasions.</para> <para><filename>/usr/obj</filename> contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the <quote/make world/ process is to remove this directory and start afresh. In this case, keeping <filename>/usr/obj</filename> around after you have finished makes little sense, and will free up a large chunk of disk space (currently about 150MB).</para> <para>However, if you know what you are doing you can have <quote/make world/ skip this step. This will make subsequent builds run much faster, since most of sources will not need to be recompiled. The flip side of this is that subtle dependency problems can creep in, causing your build to fail in odd ways. This frequently generates noise on the FreeBSD mailing lists, when one person complains that their build has failed, not realising that it is because they have tried to cut corners.</para> <para>If you want to live dangerously then make the world, passing the <makevar>NOCLEAN</makevar> definition to make, like this:</para> <screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen> </answer> </qandaentry> <qandaentry> <question> <para>Can interrupted builds be resumed?</para> </question> <answer> <para>This depends on how far through the process you got before you found a problem.</para> <para><emphasis>In general</emphasis> (and this is not a hard and fast rule) the <quote>make world</quote> process builds new copies of essential tools (such as &man.gcc.1;, and &man.make.1;>) and the system libraries. These tools and libraries are then installed. The new tools and libraries are then used to rebuild themselves, and are installed again. The entire system (now including regular user programs, such as &man.ls.1; or &man.grep.1;) is then rebuilt with the new system files.</para> <para>If you are at the last state, and you know it (because you have looked through the output that you were storing) then you can (fairly safely) do</para> <screen><emphasis>… fix the problem …</emphasis> &prompt.root; <userinput>cd /usr/src</userinput> &prompt.root; <userinput>make -DNOCLEAN all</userinput></screen> <para>This will not undo the work of the previous <quote>make world</quote>.</para> <para>If you see the message <screen>-------------------------------------------------------------- Building everything.. --------------------------------------------------------------</screen> in the <quote>make world</quote> output then it is probably fairly safe to do so.</para> <para>If you do not see that message, or you are not sure, then it is always better to be safe than sorry, and restart the build from scratch.</para> </answer> </qandaentry> <qandaentry> <question> <para>Can I use one machine as a <emphasis/master/ to upgrade lots of machines (NFS)?</para> </question> <answer> <para>People often ask on the FreeBSD mailing lists whether they can do all the compiling on one machine, and then use the results of that compile to <command>make install</command> on to other machines around the network.</para> <para>This is not something I have done, so the suggestions below are either from other people, or deduced from the Makefiles.</para> <para>The precise approach to take depends on your version of FreeBSD</para> <para>You must still upgrade <filename>/etc</filename> and <filename>/dev</filename> on the target machines after doing this.</para> <para>For 2.1.7 and below, Antonio Bemfica suggested the following approach:</para> <screen>Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST) From: Antonio Bemfica <bemfica@militzer.me.tuns.ca> To: freebsd-questions@FreeBSD.org Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca> Josef Karthauser asked: > Has anybody got a good method for upgrading machines on a network First make world, etc. on your main machine Second, mount / and /usr from the remote machine: main_machine% mount remote_machine:/ /mnt main_machine% mount remote_machine:/usr /mnt/usr Third, do a 'make install' with /mnt as the destination: main_machine% make install DESTDIR=/mnt Repeat for every other remote machine on your network. It works fine for me. Antonio</screen> <para>This mechanism will only work (to the best of my knowledge) if you can write to <filename>/usr/src</filename> on the NFS server, as the <maketarget>install</maketarget> target in 2.1.7 and below needed to do this.</para> <para>Midway between 2.1.7 and 2.2.0 the <quote>reinstall</quote> target was committed. You can use the approach exactly as outlined above for 2.1.7, but use <quote>reinstall</quote> instead of <quote>install</quote>.</para> <para>This approach <emphasis>does not</emphasis> require write access to the <filename>/usr/src</filename> directory on the NFS server.</para> <para>There was a bug introduced in this target between versions 1.68 and 1.107 of the Makefile, which meant that write access to the NFS server <emphasis>was</emphasis> required. This bug was fixed before version 2.2.0 of FreeBSD was released, but may be an issue of you have an old server still running -STABLE from this era.</para> <para>For version 2.2.5 and above, you can use the <quote>buildworld</quote> and <quote>installworld</quote> targets. Use them to build a source tree on one machine, and then NFS mount <filename>/usr/src</filename> and <filename>/usr/obj</filename> on the remote machine and install it there.</para> </answer> </qandaentry> <qandaentry> <question> <para>How can I speed up making the world?</para> <itemizedlist> <listitem> <para>Run in single user mode.</para> </listitem> <listitem> <para>Put the <filename>/usr/src</filename> and <filename>/usr/obj</filename> directories on separate filesystems held on separate disks. If possible, put these disks on separate disk controllers.</para> </listitem> <listitem> <para>Better still, put these filesystems across separate disks using the <quote>ccd</quote> (concatenated disk driver) device.</para> </listitem> <listitem> <para>Turn off profiling (set <quote>NOPROFILE=true</quote> in <filename>/etc/make.conf</filename>). You almost certainly do not need it.</para> </listitem> <listitem> <para>Also in <filename>/etc/make.conf</filename>, set <quote>CFLAGS</quote> to something like <quote>-O - -pipe</quote>. The optimisation <quote>-O2</quote> is much - slower, and the optimisation difference between + -pipe</quote>. The optimization <quote>-O2</quote> is much + slower, and the optimization difference between <quote>-O</quote> and <quote>-O2</quote> is normally negligible. <quote>-pipe</quote> lets the compiler use pipes rather than temporary files for communication, which saves disk access (at the expense of memory).</para> </listitem> <listitem> <para>Pass the <option>-j<n></option> option to make (if you are running a sufficiently recent version of FreeBSD) to run multiple processes in parallel. This helps regardless of whether you have a single or a multi processor machine.</para> </listitem> <listitem><para>The filesystem holding <filename>/usr/src</filename> can be mounted (or remounted) with the <quote>noatime</quote> option. This stops the time files in the filesystem were last accessed from being written to the disk. You probably do not need this information anyway. <note> <para><quote>noatime</quote> is in version 2.2.0 and above.</para> </note> <screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen> <warning> <para>The example assumes <filename>/usr/src</filename> is on its own filesystem. If it is not (if it is a part of <filename>/usr</filename> for example) then you will need to use that filesystem mount point, and not <filename>/usr/src</filename>.</para> </warning> </para> </listitem> <listitem> <para>The filesystem holding <filename>/usr/obj</filename> can be mounted (or remounted) with the <quote>async</quote> option. This causes disk writes to happen asynchronously. In other words, the write completes immediately, and the data is written to the disk a few seconds later. This allows writes to be clustered together, and can be a dramatic performance boost.</para> <warning> <para>Keep in mind that this option makes your filesystem more fragile. With this option there is an increased chance that, should power fail, the filesystem will be in an unrecoverable state when the machine restarts.</para> <para>If <filename>/usr/obj</filename> is the only thing on this filesystem then it is not a problem. If you have other, valuable data on the same filesystem then ensure your backups are fresh before you enable this option.</para> </warning> <screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen> <warning> <para>As above, if <filename>/usr/obj</filename> is not on its own filesystem, replace it in the example with the name of the appropriate mount point.</para> </warning> </listitem> </itemizedlist> </question> </qandaentry> </qandaset> </sect2> </sect1> </chapter> <!-- Local Variables: mode: sgml sgml-declaration: "../chapter.decl" sgml-indent-data: t sgml-omittag: nil sgml-always-quote-attributes: t sgml-parent-document: ("../book.sgml" "part" "chapter") End: --> diff --git a/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml b/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml index 24c97212b4..bca1791fdd 100644 --- a/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml @@ -1,882 +1,882 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml,v 1.18 2000/04/30 22:10:06 nik Exp $ + $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/disks/chapter.sgml,v 1.19 2000/06/08 01:56:07 jim Exp $ --> <chapter id="disks"> <title>Disks Synopsis This chapter covers how to use disks, whether physical, memory, or networked, on FreeBSD. BIOS Drive Numbering Before you install and configure FreeBSD on your system, there is an important subject that you should be aware of if, especially if you have multiple hard drives. In a PC running DOS or any of the BIOS-dependent operating systems (WINxxx), the BIOS is able to abstract the normal disk drive order, and the operating system goes along with the change. This allows the user to boot from a disk drive other than the so-called primary master. This is especially convenient for some users who have found that the simplest and cheapest way to keep a system backup is to buy an identical second hard drive, and perform routine copies of the first drive to the second drive using Ghost or XCOPY. Then, if the first drive fails, or is attacked by a virus, or is scribbled upon by an operating system defect, he can easily recover by instructing the BIOS to logically swap the drives. It's like switching the cables on the drives, but without having to open the case. More expensive systems with SCSI controllers often include BIOS extensions which allow the SCSI drives to be re-ordered in a similar fashion for up to seven drives. A user who is accustomed to taking advantage of these features may become surprised when the results with FreeBSD are not as expected. FreeBSD does not use the BIOS, and does not know the logical BIOS drive mapping. This can lead to very perplexing situations, especially when drives are physically identical in geometry, and have also been made as data clones of one another. When using FreeBSD, always restore the BIOS to natural drive numbering before installing FreeBSD, and then leave it that way. If you need to switch drives around, then do so, but do it the hard way, and open the case and move the jumpers and cables. An illustration from the files of Bill and Fred's Exceptional Adventures: - Bill breaks-down an older WIntel box to make another FreeBSD box + Bill breaks-down an older Wintel box to make another FreeBSD box for Fred. Bill installs a single SCSI drive as SCSI unit zero, and installs FreeBSD on it. Fred begins using the system, but after several days notices that the older SCSI drive is reporting numerous soft errors, and reports this fact to Bill. After several more days, Bill decides it's time to address the situation, so he grabs an identical SCSI drive from the disk drive "archive" in the back room. An initial surface scan indicates that this drive is functioning well, so Bill installs this drive as SCSI unit four, and makes an image copy from drive zero to drive four. Now that the new drive is installed and functioning nicely, Bill decides that it's a good idea to start using it, so he uses features in the SCSI BIOS to re-order the disk drives so that the system boots from SCSI unit four. FreeBSD boots and runs just fine. Fred continues his work for several days, and soon Bill and Fred decide that it's time for a new adventure -- time to upgrade to a newer version of FreeBSD. Bill removes SCSI unit zero because it was - a bit flakey, and replaces it with another identical disk drive from + a bit flaky, and replaces it with another identical disk drive from the "archive." Bill then installs the new version of FreeBSD onto the new SCSI unit zero using Fred's magic internet FTP floppies. The installation goes well. Fred uses the new version of FreeBSD for a few days, and certifies that it is good enough for use in the engineering department...it's time to copy all of his work from the old version. So Fred mounts SCSI unit four (the latest copy of the older FreeBSD version). Fred is dismayed to find that none of his precious work is present on SCSI unit four. Where did the data go? When Bill made an image copy of the original SCSI unit zero onto SCSI unit four, unit four became the "new clone," When Bill re-ordered the SCSI BIOS so that he could boot from SCSI unit four, he was only fooling himself. FreeBSD was still running on SCSI unit zero. Making this kind of BIOS change will cause some or all of the Boot and Loader code to be fetched from the selected BIOS drive, but when the FreeBSD kernel drivers take-over, the BIOS drive numbering will be ignored, and FreeBSD will transition back to normal drive numbering. In the illustration at hand, the system continued to operate on the original SCSI unit zero, and all of Fred's data was there, not on SCSI unit four. The fact that the system appeared to be running on SCSI unit four was simply an artifact of human expectations. We are delighted to mention that no data bytes were killed or harmed in any way by our discovery of this phenomenon. The older SCSI - unit zero was retrieved from the bonepile, and all of Fred's work was + unit zero was retrieved from the bone pile, and all of Fred's work was returned to him, (and now Bill knows that he can count as high as zero). Although SCSI drives were used in this illustration, the concepts apply equally to IDE drives. Disk Naming - Physical drives come in two main flavours, + Physical drives come in two main flavors, IDE, or SCSI; but there are also drives backed by RAID controllers, flash memory, and so forth. Since these behave quite differently, they have their own drivers and devices. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad in 4.0-RELEASE, wd before 4.0-RELEASE. IDE CDROM drives acd in 3.1-RELEASE, wcd before 4.0-RELEASE. SCSI hard drives da from 3.0-RELEASE, sd before 3.0-RELEASE. SCSI CDROM drives cd Assorted non-standard CDROM drives mcd for Mitsumi CD-ROM, scd for Sony CD-ROM, matcd for Matsushita/Panasonic CD-ROM Floppy drives fd SCSI tape drives sa from 3.0-RELEASE, st before 3.0-RELEASE. IDE tape drives ast from 4.0-RELEASE, wst before 4.0-RELEASE. Flash drives fla for DiskOnChip Flash device from 3.3-RELEASE. RAID drives myxd for Mylex, and amrd for AMI MegaRAID, idad for Compaq Smart RAID. from 4.0-RELEASE. id between 3.2-RELEASE and 4.0-RELEASE.
Slices and Partitions Physical disks usually contain slices, unless they are dangerously dedicated. Slice numbers follow the device name, prefixed with an s: da0s1. Slices, dangerously dedicated physical drives, and other drives contain partitions, which represented as letters from a to h. b is reserved for swap partitions, and c is an unused partition the size of the entire slice or drive. This is explained in . Mounting and Unmounting Filesystems The filesystem is best visualized as a tree, rooted, as it were, at /. /dev, /usr, and the other directories in the root directory are branches, which may have their own branches, such as /usr/local, and so on. There are various reasons to house certain of these directories on separate filesystems. /var contains log, spool, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem isn't a good idea, so splitting /var from / is often a good idea. Another common reason to contain certain directory trees on other filesystems is if they are to be housed on separate physical disks, or are separate virtual disks, such as Network File System mounts, or CDROM drives. The fstab File During the boot process, filesystems listed in /etc/fstab are automatically mounted (unless they are listed with ). The /etc/fstab file contains a list of lines of the following format: device /mount-point fstype options dumpfreq passno device is a device name (which should exist), as explained in the Disk naming conventions above. mount-point is a directory (which should exist), on which to mount the filesystem. fstype is the filesystem type to pass to &man.mount.8;. The default FreeBSD filesystem is ufs. options is either for read-write filesystems, or for read-only filesystems, followed by any other options that may be needed. A common option is for filesystems not normally mounted during the boot sequence. Other options in the &man.mount.8; manual page. dumpfreq is the number of days the filesystem should be dumped, and passno is the pass number during which the filesystem is mounted during the boot sequence. The mount Command The &man.mount.8; command is what is ultimately used to mount filesystems. In its most basic form, you use: &prompt.root; mount device mountpoint There are plenty of options, as mentioned in the &man.mount.8; manual page, but the most common are: mount options Mount all filesystems in /etc/fstab, as modified by , if given. Do everything but actually mount the filesystem. Force the mounting the filesystem. Mount the filesystem read-only. fstype Mount the given filesystem as the given filesystem type, or mount only filesystems of the given type, if given the option. ufs is the default filesystem type. Update mount options on the filesystem. Be verbose. Mount the filesystem read-write. The takes a comma-separated list of the options, including the following: nodev Do not interpret special devices on the filesystem. Useful security option. noexec Do not allow execution of binaries on this filesystem. Useful security option. nosuid Do not interpret setuid or setgid flags on the filesystem. Useful security option. The umount Command The umount command takes, as a parameter, one of a mountpoint, a device name, or the or option. All forms take to force unmounting, and for verbosity. and are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after . , however, doesn't attempt to unmount the root filesystem. Adding Disks Originally contributed by &a.obrien; 26 April 1998 Lets say we want to add a new SCSI disk to a machine that currently only has a single drive. First turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturer. Due the wide variations of procedures to do this, the details are beyond the scope of this document. Login as user root. After you've installed the drive, inspect /var/run/dmesg.boot to ensure the new disk was found. Continuing with our example, the newly added drive will be da1 and we want to mount it on /1. (if you are adding an IDE drive substitute wd for da) Because FreeBSD runs on IBM-PC compatible computers, it must take into account the PC BIOS partitions. These are different from the traditional BSD partitions. A PC disk has up to four BIOS partition entries. If the disk is going to be truly dedicated to FreeBSD, you can use the dedicated mode. Otherwise, FreeBSD will have to live with in one of the PC BIOS partitions. FreeBSD calls the PC BIOS partitions, slices so as not to confuse them with traditional BSD partitions. You may also use slices on a disk that is dedicated to FreeBSD, but used in a computer that also has another operating system installed. This is to not confuse the fdisk utility of the other operating system. In the slice case the drive will be added as /dev/da1s1e. This is read as: SCSI disk, unit number 1 (second SCSI disk), slice 1 (PC BIOS partition 1), and e BSD partition. In the dedicated case, the drive will be added simply as /dev/da1e. Using sysinstall You may use /stand/sysinstall to partition and label a new disk using its easy to use menus. Either login as user root or use the su command. Run /stand/sysinstall and enter the Configure menu. With in the FreeBSD Configuration Menu, scroll down and select the Partition item. Next you should be presented with a list of hard drives installed in your system. If you do not see da1 listed, you need to recheck your physical installation and dmesg output in the file /var/run/dmesg.boot. Select da1 to enter the FDISK Partition Editor. Choose A to use the entire disk for FreeBSD. When asked if you want to remain cooperative with any future possible operating systems, answer YES. Write the changes to the disk using W. Now exit the FDISK editor using q. Next you will be asked about the Master Boot Record. Since you are adding a disk to an already running system, choose None. Next enter the Disk Label Editor. This is where you will create the traditional BSD partitions. A disk can have up to eight partitions, labeled a-h. A few of the partition labels have special uses. The a partition is used for the root partition (/). Thus only your system disk (e.g, the disk you boot from) should have an a partition. The b partition is used for swap partitions, and you may have many disks with swap partitions. The c partition addresses the entire disk in dedicated mode, or the entire FreeBSD slice in slice mode. The other partitions are for general use. Sysinstall's Label editor favors the e partition for non-root, non-swap partitions. With in the Label editor, create a single file system using C. When prompted if this will be a FS (file system) or swap, choose FS and give a mount point (e.g, /mnt). When adding a disk in post-install mode, Sysinstall will not create entries in /etc/fstab for you, so the mount point you specify isn't important. You are now ready to write the new label to the disk and create a file system on it. Do this by hitting W. Ignore any errors from Sysinstall that it could not mount the new partition. Exit the Label Editor and Sysinstall completely. The last step is to edit /etc/fstab to add an entry for your new disk. Using Command Line Utilities * Using Slices Dedicated If you will not be sharing the new drive with another operating system, you may use the dedicated mode. Remember this mode can confuse Microsoft operating systems; however, no damage will be done by them. IBM's OS/2 however, will appropriate any partition it finds which it doesn't understand. &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; disklabel -Brw da1 auto &prompt.root; disklabel -e da1 # create the `e' partition &prompt.root; newfs -d0 /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 An alternate method is: &prompt.root; dd if=/dev/zero of=/dev/rda1 count=2 &prompt.root; disklabel /dev/rda1 | disklabel -BrR da1 /dev/stdin &prompt.root; newfs /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 Virtual Disks: Network, Memory, and File-Based Filesystems Besides the disks you physically insert into your computer; floppies, CDs, hard drives, and so forth, other forms of disks are understood by FreeBSD - the virtual disks. These include network filesystems such as the Network Filesystem and Coda, memory-based filesystems such as md and file-backed filesystems created by vnconfig. vnconfig: file-backed filesystem &man.vnconfig.8; configures and enables vnode pseudo disk devices. A vnode is a representation of a file, and is the focus of file activity. This means that &man.vnconfig.8; uses files to create and operate a filesystem. One possible use is the mounting of floppy or CD images kept in files. To mount an existing filesystem image: Using vnconfig to mount an existing filesystem image &prompt.root; vnconfig vn0 diskimage &prompt.root; mount /dev/vn0c /mnt To create a new filesystem image with vnconfig: Creating a New File-Backed Disk with vnconfig &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; vnconfig -s labels -c vn0 newimage &prompt.root; disklabel -r -w vn0 auto &prompt.root; newfs vn0c Warning: 2048 sector(s) in last cylinder unallocated /dev/rvn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors 5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g) super-block backups (for fsck -b #) at: 32 &prompt.root; mount /dev/vn0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 4927 1 4532 0% /mnt md: Memory Filesystem md is a simple, efficient means to do memory filesystems. Simply take a filesystem you've prepared with, for example, &man.vnconfig.8;, and: md memory disk &prompt.root; dd if=newimage of=/dev/md0 5120+0 records in 5120+0 records out &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4927 1 4532 0% /mnt Disk Quotas Quotas are an optional feature of the operating system that allow you to limit the amount of disk space and/or the number of files a user, or members of a group, may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This will prevent one user from consuming all of the available disk space. Configuring Your System to Enable Disk Quotas Before attempting to use disk quotas it is necessary to make sure that quotas are configured in your kernel. This is done by adding the following line to your kernel configuration file: options QUOTA The stock GENERIC kernel does not have this enabled by default, so you will have to configure, build and install a custom kernel in order to use disk quotas. Please refer to the Configuring the FreeBSD Kernel section for more information on kernel configuration. Next you will need to enable disk quotas in /etc/rc.conf. This is done by adding the line: enable_quotas=YES For finer control over your quota startup, there is an additional configuration variable available. Normally on bootup, the quota integrity of each file system is checked by the quotacheck program. The quotacheck facility insures that the data in the quota database properly reflects the data on the file system. This is a very time consuming process that will significantly affect the time your system takes to boot. If you would like to skip this step, a variable is made available for the purpose: check_quotas=NO If you are running FreeBSD prior to 3.2-RELEASE, the configuration is simpler, and consists of only one variable. Set the following in your /etc/rc.conf: check_quotas=YES Finally you will need to edit /etc/fstab to enable disk quotas on a per-file system basis. This is where you can either enable user or group quotas or both for all of your file systems. To enable per-user quotas on a file system, add the userquota option to the options field in the /etc/fstab entry for the file system you want to to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 Similarly, to enable group quotas, use the groupquota option instead of the userquota keyword. To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default the quota files are stored in the root directory of the file system with the names quota.user and quota.group for user and group quotas respectively. See man fstab for more information. Even though that man page says that you can specify an alternate location for the quota files, this is not recommended because the various quota utilities do not seem to handle this properly. At this point you should reboot your system with your new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas you enabled in /etc/fstab, so there is no need to manually create any zero length quota files. In the normal course of operations you should not be required to run the quotacheck, quotaon, or quotaoff commands manually. However, you may want to read their man pages just to be familiar with their operation. Setting Quota Limits Once you have configured your system to enable quotas, verify that they really are enabled. An easy way to do this is to run: &prompt.root; quota -v You should see a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. You are now ready to start assigning quota limits with the edquota command. You have several options on how to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. You may limit allocations based on disk space (block quotas) or number of files (inode quotas) or a combination of both. Each of these limits are further broken down into two categories; hard and soft limits. A hard limit may not be exceeded. Once a user reaches their hard limit they may not make any further allocations on the file system in question. For example, if the user has a hard limit of 500 blocks on a file system and is currently using 490 blocks, the user can only allocate an additional 10 blocks. Attempting to allocate an additional 11 blocks will fail. Soft limits on the other hand can be exceeded for a limited amount of time. This period of time is known as the grace period, which is one week by default. If a user stays over his or her soft limit longer than their grace period, the soft limit will turn into a hard limit and no further allocations will be allowed. When the user drops back below the soft limit, the grace period will be reset. The following is an example of what you might see when you run the edquota command. When the edquota command is invoked, you are placed into the editor specified by the EDITOR environment variable, or in the vi editor if the EDITOR variable is not set, to allow you to edit the quota limits. &prompt.root; edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) You will normally see two lines for each file system that has quotas enabled. One line for the block limits, and one line for inode limits. Simply change the value you want updated to modify the quota limit. For example, to raise this users block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: blocks in use: 65, limits (soft = 50, hard = 75) to: /usr: blocks in use: 65, limits (soft = 500, hard = 600) The new quota limits will be in place when you exit the editor. Sometimes it is desirable to set quota limits on a range of uids. This can be done by use of the option on the edquota command. First, assign the desired quota limit to a user, and then run edquota -p protouser startuid-enduid. For example, if user test has the desired quota limits, the following command can be used to duplicate those quota limits for uids 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 See man edquota for more detailed information. Checking Quota Limits and Disk Usage You can use either the quota or the repquota commands to check quota limits and disk usage. The quota command can be used to check individual user and group quotas and disk usage. Only the super-user may examine quotas and usage for other users, or for groups that they are not a member of. The repquota command can be used to get a summary of all quotas and disk usage for file systems with quotas enabled. The following is some sample output from the quota -v command for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 On the /usr file system in the above example this user is currently 15 blocks over their soft limit of 50 blocks and has 5 days of their grace period left. Note the asterisk * which indicates that the user is currently over their quota limit. Normally file systems that the user is not using any disk space on will not show up in the output from the quota command, even if they have a quota limit assigned for that file system. The option will display those file systems, such as the /usr/var file system in the above example. Quotas over NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to the &man.quota.1; command on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; kill -HUP `cat /var/run/inetd.pid` diff --git a/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml index 4a90d4b5d9..739d6adc18 100644 --- a/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/eresources/chapter.sgml @@ -1,1454 +1,1454 @@ Resources on the Internet Contributed by &a.jkh;. The rapid pace of FreeBSD progress makes print media impractical as a means of following the latest developments. Electronic resources are the best, if not often the only, way stay informed of the latest advances. Since FreeBSD is a volunteer effort, the user community itself also generally serves as a technical support department of sorts, with electronic mail and USENET news being the most effective way of reaching that community. The most important points of contact with the FreeBSD user community are outlined below. If you are aware of other resources not mentioned here, please send them to the &a.doc;so that they may also be included. Mailing Lists Though many of the FreeBSD development members read USENET, we cannot always guarantee that we will get to your questions in a timely fashion (or at all) if you post them only to one of the comp.unix.bsd.freebsd.* groups. By addressing your questions to the appropriate mailing list you will reach both us and a concentrated FreeBSD audience, invariably assuring a better (or at least faster) response. The charters for the various lists are given at the bottom of this document. Please read the charter before joining or sending mail to any list. Most of our list subscribers now receive many hundreds of FreeBSD related messages every day, and by setting down charters and rules for proper use we are striving to keep the signal-to-noise ratio of the lists high. To do less would see the mailing lists ultimately fail as an effective communications medium for the project. Archives are kept for all of the mailing lists and can be searched using the FreeBSD World Wide Web server. The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question. List Summary General lists: The following are general lists which anyone is free (and encouraged) to join: List Purpose freebsd-advocacy FreeBSD Evangelism freebsd-announce Important events and project milestones freebsd-arch Architecture and design discussions freebsd-bugs Bug reports freebsd-chat Non-technical items related to the FreeBSD community freebsd-current Discussion concerning the use of FreeBSD-current freebsd-isp Issues for Internet Service Providers using FreeBSD freebsd-jobs FreeBSD employment and consulting opportunities freebsd-newbies New FreeBSD users activities and discussions freebsd-policy FreeBSD Core team policy decisions. Low volume, and read-only freebsd-questions User questions and technical support freebsd-stable Discussion concerning the use of FreeBSD-stable Technical lists: The following lists are for technical discussion. You should read the charter for each list carefully before joining or sending mail to one as there are firm guidelines for their use and content. List Purpose freebsd-afs Porting AFS to FreeBSD freebsd-alpha Porting FreeBSD to the Alpha freebsd-database Discussing database use and development under FreeBSD freebsd-doc Creating FreeBSD related documents freebsd-emulation Emulation of other systems such as Linux/DOS/Windows freebsd-fs Filesystems freebsd-hackers General technical discussion freebsd-hardware General discussion of hardware for running FreeBSD freebsd-i18n FreeBSD Internationalization freebsd-ipfw Technical discussion concerning the redesign of the IP firewall code freebsd-isdn ISDN developers freebsd-java Java developers and people porting JDKs to FreeBSD freebsd-mobile Discussions about mobile computing freebsd-mozilla Porting mozilla to FreeBSD freebsd-net Networking discussion and TCP/IP/source code freebsd-platforms Concerning ports to non-Intel architecture platforms freebsd-ports Discussion of the ports collection freebsd-ppc Porting FreeBSD to the PowerPC freebsd-scsi The SCSI subsystem freebsd-security Security issues freebsd-security-notifications Security notifications freebsd-small Using FreeBSD in embedded applications freebsd-smp Design discussions for [A]Symmetric MultiProcessing freebsd-sparc Porting FreeBSD to Sparc systems freebsd-tokenring Support Token Ring in FreeBSD Limited lists: The following lists are for more specialized (and demanding) audiences and are probably not of interest to the general public. It is also a good idea to establish a presence in the technical lists before joining one of these limited lists so that you'll understand the communications etiquette involved. List Purpose freebsd-core FreeBSD core team freebsd-hubs People running mirror sites (infrastructural support) freebsd-install Installation development freebsd-user-groups User group coordination freebsd-www Maintainers of www.freebsd.org CVS lists: The following lists are for people interested in seeing the log messages for changes to various areas of the source tree. They are Read-Only lists and should not have mail sent to them. List Source area Area Description (source for) cvs-all /usr/src All changes to the tree (superset) How to Subscribe All mailing lists live on FreeBSD.org, so to post to a given list you simply mail to <listname@FreeBSD.org>. It will then be redistributed to mailing list members world-wide. To subscribe to a list, send mail to &a.majordomo; and include subscribe <listname> [<optional address>] in the body of your message. For example, to subscribe yourself to freebsd-announce, you'd do: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D If you want to subscribe yourself under a different name, or submit a subscription request for a local mailing list (this is more efficient if you have several interested parties at one site, and highly appreciated by us!), you would do something like: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@somesite.com ^D Finally, it is also possible to unsubscribe yourself from a list, get a list of other list members or see the list of mailing lists again by sending other types of control messages to majordomo. For a complete list of available commands, do this: &prompt.user; mail majordomo@FreeBSD.org help ^D Again, we would like to request that you keep discussion in the technical mailing lists on a technical track. If you are only interested in important announcements then it is suggested that you join freebsd-announce, which is intended only for infrequent traffic. List Charters All FreeBSD mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result in two (2) written warnings from the FreeBSD Postmaster postmaster@FreeBSD.org, after which, on a third offense, the poster will removed from all FreeBSD mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: The topic of any posting should adhere to the basic charter of the list it is posted to, e.g. if the list is about technical issues then your posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the freebsd-chat freebsd-chat@FreeBSD.org mailing list is freely available and should be used instead. No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say "-stable & -scsi"), there really is no reason to post to more than one list at a time. If a message is sent to you in such a - way that multiple mailing lists appear on the Cc line then the cc + way that multiple mailing lists appear on the Cc line then the Cc line should also be trimmed before sending it out again. You are still responsible for your own cross-postings, no matter who the originator might have been. Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. Advertising of non-FreeBSD related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. Individual list charters: FREEBSD-AFS Andrew File System This list is for discussion on porting and using AFS from CMU/Transarc FREEBSD-ANNOUNCE Important events / milestones This is the mailing list for people interested only in occasional announcements of significant FreeBSD events. This includes announcements about snapshots and other releases. It contains announcements of new FreeBSD capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. FREEBSD-ARCH Architecture and design discussions This is a moderated list for discussion of FreeBSD architecture. Messages will mostly be kept technical in nature, with (rare) exceptions for other messages the moderator deems need to reach all the subscribers of the list. Examples of suitable topics; How to re-vamp the build system to have several customized builds running at the same time. What needs to be fixed with VFS to make Heidemann layers work. How do we change the device driver interface to be able to use the ame drivers cleanly on many buses and architectures? How do I write a network driver? The moderator reserves the right to do minor editing (spell-checking, grammar correction, trimming) of messages that are posted to the list. The volume of the list will be kept low, which may involve having to delay topics until an active discussion has been resolved. FREEBSD-BUGS Bug reports This is the mailing list for reporting bugs in FreeBSD Whenever possible, bugs should be submitted using the &man.send-pr.1; command or the WEB interface to it. FREEBSD-CHAT Non technical items related to the FreeBSD community This list contains the overflow from the other lists about non-technical, social information. It includes discussion about whether Jordan looks like a toon ferret or not, whether or not to type in capitals, who is drinking too much coffee, where the best beer is brewed, who is brewing beer in their basement, and so on. Occasional announcements of important events (such as upcoming parties, weddings, births, new jobs, etc) can be made to the technical lists, but the follow ups should be directed to this -chat list. FREEBSD-CORE FreeBSD core team This is an internal mailing list for use by the core members. Messages can be sent to it when a serious FreeBSD-related matter requires arbitration or high-level scrutiny. FREEBSD-CURRENT Discussions about the use of FreeBSD-current This is the mailing list for users of freebsd-current. It includes warnings about new features coming out in -current that will affect the users, and instructions on steps that must be taken to remain -current. Anyone running current must subscribe to this list. This is a technical mailing list for which strictly technical content is expected. FREEBSD-CURRENT-DIGEST Discussions about the use of FreeBSD-current This is the digest version of the freebsd-current mailing list. The digest consists of all messages sent to freebsd-current bundled together and mailed out as a single message. The average digest size is about 40kB. This list is Read-Only and should not be posted to. FREEBSD-DOC Documentation project This mailing list is for the discussion of issues and projects related to the creation of documentation for FreeBSD. The members of this mailing list are collectively referred to as The FreeBSD Documentation Project. It is an open list; feel free to join and contribute! FREEBSD-FS Filesystems Discussions concerning FreeBSD filesystems. This is a technical mailing list for which strictly technical content is expected. FREEBSD-IPFW IP Firewall This is the forum for technical discussions concerning the redesign of the IP firewall code in FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-ISDN ISDN Communications This is the mailing list for people discussing the development of ISDN support for FreeBSD. FREEBSD-JAVA Java Development This is the mailing list for people discussing the development of significant Java applications for FreeBSD and the porting and maintenance of JDKs. FREEBSD-HACKERS Technical discussions This is a forum for technical discussions related to FreeBSD. This is the primary technical mailing list. It is for individuals actively working on FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. This is a technical mailing list for which strictly technical content is expected. FREEBSD-HACKERS-DIGEST Technical discussions This is the digest version of the freebsd-hackers mailing list. The digest consists of all messages sent to freebsd-hackers bundled together and mailed out as a single message. The average digest size is about 40kB. This list is Read-Only and should not be posted to. FREEBSD-HARDWARE General discussion of FreeBSD hardware General discussion about the types of hardware that FreeBSD runs on, various problems and suggestions concerning what to buy or avoid. FREEBSD-HUBS Mirror sites Announcements and discussion for people who run FreeBSD mirror sites. FREEBSD-INSTALL Installation discussion This mailing list is for discussing FreeBSD installation development for the future releases. FREEBSD-ISP Issues for Internet Service Providers This mailing list is for discussing topics relevant to Internet Service Providers (ISPs) using FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-NEWBIES Newbies activities discussion We cover any of the activities of newbies that are not already dealt with elsewhere, including: independent learning and problem solving techniques, finding and using resources and asking for help elsewhere, how to use mailing lists and which lists to use, general chat, making mistakes, boasting, sharing ideas, stories, moral (but not technical) support, and taking an active part in the FreeBSD community. We take our problems and support questions to freebsd-questions, and use freebsd-newbies to meet others who are doing the same things that we do as newbies. FREEBSD-PLATFORMS Porting to Non-Intel platforms Cross-platform FreeBSD issues, general discussion and proposals for non-Intel FreeBSD ports. This is a technical mailing list for which strictly technical content is expected. FREEBSD-POLICY Core team policy decisions This is a low volume, read-only mailing list for FreeBSD Core Team Policy decisions. FREEBSD-PORTS Discussion of ports Discussions concerning FreeBSD's ports collection (/usr/ports), proposed ports, modifications to ports collection infrastructure and general coordination efforts. This is a technical mailing list for which strictly technical content is expected. FREEBSD-QUESTIONS User questions This is the mailing list for questions about FreeBSD. You should not send how to questions to the technical lists unless you consider the question to be pretty technical. FREEBSD-QUESTIONS-DIGEST User questions This is the digest version of the freebsd-questions mailing list. The digest consists of all messages sent to freebsd-questions bundled together and mailed out as a single message. The average digest size is about 40kB. FREEBSD-SCSI SCSI subsystem This is the mailing list for people working on the scsi subsystem for FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-SECURITY Security issues FreeBSD computer security issues (DES, Kerberos, known security holes and fixes, etc). This is a technical mailing list for which strictly technical content is expected. FREEBSD-SECURITY-NOTIFICATIONS Security Notifications Notifications of FreeBSD security problems and fixes. This is not a discussion list. The discussion list is FreeBSD-security. FREEBSD-SMALL This list discusses topics related to unusually small and embedded FreeBSD installations. This is a technical mailing list for which strictly technical content is expected. FREEBSD-STABLE Discussions about the use of FreeBSD-stable This is the mailing list for users of freebsd-stable. It includes warnings about new features coming out in -stable that will affect the users, and instructions on steps that must be taken to remain -stable. Anyone running stable should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. FREEBSD-USER-GROUPS User Group Coordination List This is the mailing list for the coordinators from each of the local area Users Groups to discuss matters with each other and a designated individual from the Core Team. This mail list should be limited to meeting synopsis and coordination of projects that span User Groups. Usenet Newsgroups In addition to two FreeBSD specific newsgroups, there are many others in which FreeBSD is discussed or are otherwise relevant to FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.edu.au. BSD Specific Newsgroups comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc Other Unix Newsgroups of Interest comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Servers http://www.FreeBSD.org/ — Central Server. http://www.au.FreeBSD.org/ — Australia/1. http://www2.au.FreeBSD.org/ — Australia/2. http://www3.au.FreeBSD.org/ — Australia/3. http://freebsd.itworks.com.au/ — Australia/4. http://www.br.FreeBSD.org/www.freebsd.org/ — Brazil/1. http://www2.br.FreeBSD.org/www.freebsd.org/ — Brazil/2. http://www3.br.FreeBSD.org/ — Brazil/3. http://www.bg.FreeBSD.org/ — Bulgaria. http://www.ca.FreeBSD.org/ — Canada/1. http://www2.ca.FreeBSD.org/ — Canada/2. http://www3.ca.FreeBSD.org/ — Canada/3. http://www.cn.FreeBSD.org/ — China. http://www.cz.FreeBSD.org/ — Czech Republic/1. http://www2.cz.FreeBSD.org/ — Czech Republic/2. http://www.dk.FreeBSD.org/ — Denmark. http://www.ee.FreeBSD.org/ — Estonia. http://www.fi.FreeBSD.org/ — Finland. http://www.fr.FreeBSD.org/ — France. http://www.de.FreeBSD.org/ — Germany/1. http://www1.de.FreeBSD.org/ — Germany/2. http://www2.de.FreeBSD.org/ — Germany/3. http://www.gr.FreeBSD.org/ — Greece. http://www.hu.FreeBSD.org/ — Hungary. http://www.is.FreeBSD.org/ — Iceland. http://www.ie.FreeBSD.org/ — Ireland. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Japan. http://www.kr.FreeBSD.org/ — Korea/1. http://www2.kr.FreeBSD.org/ — Korea/2. http://www.lv.FreeBSD.org/ — Latvia. http://rama.asiapac.net/freebsd/ — Malaysia. http://www.nl.FreeBSD.org/ — Netherlands/1. http://www2.nl.FreeBSD.org/ — Netherlands/2. http://www.no.FreeBSD.org/ — Norway. http://www.nz.FreeBSD.org/ — New Zeland. + url="http://www.nz.FreeBSD.org/">http://www.nz.FreeBSD.org/ — New Zealand. http://www.pl.FreeBSD.org/ — Poland/1. http://www2.pl.FreeBSD.org/ — Poland/2. http://www.pt.FreeBSD.org/ — Portugal/1. http://www2.pt.FreeBSD.org/ — Portugal/2. http://www3.pt.FreeBSD.org/ — Portugal/3. http://www.ro.FreeBSD.org/ — Romania. http://www.ru.FreeBSD.org/ — Russia/1. http://www2.ru.FreeBSD.org/ — Russia/2. http://www3.ru.FreeBSD.org/ — Russia/3. http://www4.ru.FreeBSD.org/ — Russia/4. http://freebsd.s1web.com/ — Singapore. http://www.sk.FreeBSD.org/ — Slovak Republic. http://www.si.FreeBSD.org/ — Slovenia. http://www.es.FreeBSD.org/ — Spain. http://www.za.FreeBSD.org/ — South Africa/1. http://www2.za.FreeBSD.org/ — South Africa/2. http://www.se.FreeBSD.org/ — Sweden. http://www.ch.FreeBSD.org/ — Switzerland. http://www.tw.FreeBSD.org/www.freebsd.org/data/ — Taiwan. http://www.tr.FreeBSD.org/ — Turkey. http://www.ua.FreeBSD.org/www.freebsd.org/ — Ukraine/1. http://www2.ua.FreeBSD.org/ — Ukraine/2. http://www4.ua.FreeBSD.org/ — Ukraine/Crimea. http://www.uk.FreeBSD.org/ — United Kingdom. http://www6.FreeBSD.org/ — USA/Oregon. http://www2.FreeBSD.org/ — USA/Texas. Email Addresses The following user groups provide FreeBSD related email addresses for their members. The listed administrator reserves the right to revoke the address if it is abused in any way. Domain Facilities User Group Administrator ukug.uk.FreeBSD.org Forwarding only freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Shell Accounts The following user groups provide shell accounts for people who are actively supporting the FreeBSD project. The listed administrator reserves the right to cancel the account if it is abused in any way. Host Access Facilities Administrator storm.uk.FreeBSD.org - ssh only - Read-only cvs, personal webspace, email + SSH only + Read-only cvs, personal web space, email &a.brian dogma.freebsd-uk.eu.org Telnet/FTP/SSH - E-Mail, Webspace, Anonymous FTP + E-Mail, Web space, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml b/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml index b2f9347a91..06c7ea9e2e 100644 --- a/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/hw/chapter.sgml @@ -1,5874 +1,5872 @@ PC Hardware compatibility 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 commodity 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. You may also want to refer to the kernel configuration file section in this handbook for a list of supported devices. 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 e-mail to the &a.doc;. Questions about supported hardware should be directed to the &a.questions; (see 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. Resources on the Internet The following links have proven useful in selecting hardware. Though some of what you see won't necessarily be specific (or even applicable) to FreeBSD, most of the hardware information out there is OS independent. Please check with the FreeBSD hardware guide to make sure that your chosen configuration is supported before making any purchases. The Pentium Systems Hardware Performance Guide Sample Configurations The following list of sample hardware configurations by no means constitutes an endorsement of a given hardware vendor or product by The FreeBSD Project. This information is provided only as a public service and merely catalogs some of the experiences that various individuals have had with different hardware combinations. Your mileage may vary. Slippery when wet. Beware of dog. Jordan's Picks I have had fairly good luck building workstation and server configurations with the following components. I can't guarantee that you will too, nor that any of the companies here will remain best buys forever. I will try, when I can, to keep this list up-to-date but cannot obviously guarantee that it will be at any given time. Motherboards For Pentium Pro (P6) systems, I'm quite fond of the Tyan S1668 dual-processor motherboard as well as the Intel PR440FX motherboard - with on-board SCSI WIDE and 100/10MB Intel Etherexpress NIC. You + with on-board SCSI WIDE and 100/10MB Intel EtherExpress NIC. You can build a dandy little single or dual processor system (which is supported in FreeBSD 3.0) for very little cost now that the Pentium Pro 180/256K chips have fallen so greatly in price, but no telling how much longer this will last. For the Pentium II, I'm rather partial to the ASUS P2l97-S motherboard with the on-board Adaptec SCSI WIDE controller. For Pentium machines, the ASUS P55T2P4 motherboard appears to be a good choice for mid-to-high range Pentium server and workstation systems. Those wishing to build more fault-tolerant systems should also be sure to use Parity memory or, for truly 24/7 applications, ECC memory. ECC memory does involve a slight performance trade-off (which may or may not be noticeable depending on your application) but buys you significantly increased fault-tolerance to memory errors. Disk Controllers This one is a bit trickier, and while I used to recommend the Buslogic controllers unilaterally for everything from ISA to PCI, now I tend to lean towards the Adaptec 1542CF for ISA, Buslogic Bt747c for EISA and Adaptec 2940UW for PCI. The NCR/Symbios cards for PCI have also worked well for me, though you need to make sure that your motherboard supports the BIOS-less model if you're using one of those (if your card has nothing which looks even vaguely like a ROM chip on it, you've probably got one which expects its BIOS to be on your motherboard). If you should find that you need more than one SCSI controller in a PCI machine, you may wish to consider conserving your scarce PCI bus resources by buying the Adaptec 3940 card, which puts two SCSI controllers (and internal busses) in a single slot. There are two types of 3940 on the market—the older model with AIC 7880 chips on it, and the newer one with AIC 7895 chips. The newer model requires CAM support which is not yet part of FreeBSD—you have to add it, or install from one of the CAM binary snapshot release. Disk drives In this particular game of Russian roulette, I'll make few specific recommendations except to say SCSI over IDE whenever you can afford it. Even in small desktop configurations, SCSI often makes more sense since it allows you to easily migrate drives from server to desktop as falling drive prices make it economical to do so. If you have more than one machine to administer then think of it not simply as storage, think of it as a food chain! For a serious server configuration, there's not even any argument—use SCSI equipment and good cables. CDROM drives My SCSI preferences extend to SCSI CDROM drives as well, and while the Toshiba drives - have always been favourites of mine (in whatever speed is hot that + have always been favorites of mine (in whatever speed is hot that week), I'm still fond of my good old Plextor PX-12CS drive. It's only a 12 speed, but it's offered excellent performance and reliability. Generally speaking, most SCSI CDROM drives I've seen have been of pretty solid construction and you probably won't go wrong with an HP or NEC SCSI CDROM drive either. SCSI CDROM prices also appear to have dropped considerably in the last few months and are now quite competitive with IDE CDROMs while remaining a technically superior solution. I now see no reason whatsoever to settle for an IDE CDROM drive if given a choice between the two. CD Recordable (WORM) drives At the time of this writing, FreeBSD supports 3 types of CDR drives (though I believe they all ultimately come from Phillips anyway): The Phillips CDD 522 (Acts like a Plasmon), the PLASMON RF4100 and the HP 6020i. I myself use the HP 6020i for burning CDROMs (in 2.2 and alter releases—it does not work with earlier releases of the SCSI code) and it works very well. See /usr/share/examples/worm on your 2.2 system for example scripts used to created ISO9660 filesystem images (with RockRidge extensions) and burn them onto an HP6020i CDR. Tape drives I've had pretty good luck with both 8mm drives from Exabyte and 4mm (DAT) drives from HP. For backup purposes, I'd have to give the higher recommendation to the Exabyte due to the more robust nature (and higher storage capacity) of 8mm tape. Video Cards If you can also afford to buy a commercial X server for US$99 from Xi Graphics, Inc. (formerly X Inside, Inc) then I can heartily recommend the Matrox Millenium II card. Note that support for this card is also excellent with the XFree86 server, which is now at version 3.3.2. You also certainly can't go wrong with one of Number 9's cards — their S3 Vision 868 and 968 based cards (the 9FX series) also being quite fast and very well supported by XFree86's S3 server. You can also pick up their Revolution 3D cards very cheaply these days, especially if you require a lot of video memory. Monitors I have had very good luck with the Sony Multiscan 17seII monitors, as have I with the Viewsonic offering in the same (Trinitron) tube. For larger than 17", all I can recommend at the time of this writing is to not spend any less than U.S. $2,000 for a 21" monitor or $1,700 for a 20" monitor if that's what you really need. There are good monitors available in the >=20" range and there are also cheap monitors in the >=20" range. Unfortunately, very few are both cheap and good! Networking I can recommend the Intel EtherExpress Pro/100B card first and foremost, followed by the SMC Ultra 16 controller for any ISA application and the SMC EtherPower or Compex ENET32 cards for slightly cheaper PCI based networking. In general, any PCI NIC based around DEC's DC21041 Ethernet controller chip, such as the Znyx ZX342 or DEC DE435/450, will generally work quite well and can frequently be found in 2-port and 4-port version (useful for firewalls and routers), though the Pro/100MB card has the edge when it comes to providing the best performance with lower overhead. If what you're looking for is the cheapest possible solution then almost any NE2000 clone will do a fine job for very little cost. Serial If you're looking for high-speed serial networking solutions, then Digi International makes the SYNC/570 - series, with drivers now in FreeBSD-current. Emerging Technologies also manufactures a board with T1/E1 capabilities, using software they provide. I have no direct experience using either product, however. - Multiport card options are somewhat more numerous, though it has + multiport card options are somewhat more numerous, though it has to be said that FreeBSD's support for Cyclades's products is probably the tightest, primarily as a result of that company's commitment to making sure that we are adequately supplied with evaluation boards and technical specs. I've heard that the Cyclom-16Ye offers the best price/performance, though I've not checked the prices lately. Other multiport cards I've heard good things about are the BOCA and AST cards, and Stallion Technologies apparently offers an unofficial driver for their cards at this location. Audio I currently use a Creative Labs AWE32 though just about anything from Creative Labs will generally work these days. This is not to say that other types of sound cards don't also work, simply that I have little experience - with them (I was a former GUS fan, but Gravis's soundcard situation + with them (I was a former GUS fan, but Gravis's sound card situation has been dire for some time). Video For video capture, there are two good choices — any card based on the Brooktree BT848 chip, such as the Hauppage or WinTV boards, will work very nicely with FreeBSD. Another board which works for me is the Matrox Meteor card. FreeBSD also supports the older video spigot card from Creative Labs, but those are getting somewhat difficult to find. Note that the Meteor frame grabber card will not work with motherboards based on the 440FX chipset! See the motherboard reference section for details. In such cases, it's better to go with a BT848 based board. Core/Processing Motherboards, busses, and chipsets * ISA * EISA * VLB PCI Contributed by &a.obrien; from postings by &a.rgrimes;. 25 April 1995. Continuing updates by &a.jkh;. Last update on 26 August 1996. Of the Intel PCI chip sets, the following list describes various types of known-brokenness and the degree of breakage, listed from worst to best. Mercury: 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. Saturn-I (ie, 82424ZX at rev 0, 1 or 2): 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. Saturn-II (ie, 82424ZX at rev 3 or 4): 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). + external dirty bit SRAM needed for write back operation. + You can work around this either by running 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). Neptune: 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. Triton (ie, 430FX): No known cache coherency or bus master problems, chip set does not implement parity checking. Workaround for parity issue. Use Triton-II based motherboards if you have the choice. Triton-II (ie, 430HX): All reports on motherboards using this chipset have been favorable so far. No known problems. Orion: Early versions of this chipset suffered from a PCI write-posting bug which can cause noticeable performance degradation in applications where large amounts of PCI bus traffic is involved. B0 stepping or later revisions of the chipset fixed this problem. 440FX: This Pentium Pro support chipset seems to work well, and does not suffer from any of the early Orion chipset problems. It also supports a wider variety of memory, including ECC and parity. The only known problem with it is that the Matrox Meteor frame grabber card doesn't like it. CPUs/FPUs Contributed by &a.asami;. 26 December 1997. P6 class (Pentium Pro/Pentium II) Both the Pentium Pro and Pentium II work fine with FreeBSD. In - fact, our main ftp site ftp.FreeBSD.org (also known as "ftp.cdrom.com", world's largest ftp site) runs FreeBSD on a Pentium Pro. Configurations details are available for interested parties. Pentium class The Intel Pentium (P54C), Pentium MMX (P55C), AMD K6 and Cyrix/IBM 6x86MX processors are all reported to work with FreeBSD. I will not go into details of which processor is faster than what, - there are zillions of web sites on the Internet that tells you one + there are millions of web sites on the Internet that tells you one way or another. :) Various CPUs have different voltage/cooling requirements. Make sure your motherboard can supply the exact voltage needed by the CPU. For instance, many recent MMX chips require split voltage (e.g., 2.9V core, 3.3V I/O). Also, some AMD and Cyrix/IBM chips run hotter than Intel chips. In that case, make sure you have good heatsink/fans (you can get the list of certified parts from their web pages). Clock speeds Contributed by &a.rgrimes;. 1 October 1996. Updated by &a.asami;. 27 December 1997. Pentium class machines use different clock speeds for the various parts of the system. These being the speed of the CPU, external memory bus, and the PCI bus. It is not always true that a faster processor will make a system faster than a slower one, due to the various clock speeds used. Below is a table showing the differences: Rated CPU MHz External Clock and Memory Bus MHz External to Internal Clock Multiplier PCI Bus Clock MHz 60 60 1.0 30 66 66 1.0 33 75 50 1.5 25 90 60 1.5 30 100 50 2 25 100 66 1.5 33 120 60 2 30 133 66 2 33 150 60 2.5 30 (Intel, AMD) 150 75 2 37.5 (Cyrix/IBM 6x86MX) 166 66 2.5 33 180 60 3 30 200 66 3 33 233 66 3.5 33 66MHz may actually be 66.667MHz, but don't assume so. The Pentium 100 can be run at either 50MHz external clock with a multiplier of 2 or at 66MHz and a multiplier of 1.5. As can be seen the best parts to be using are the 100, 133, 166, 200 and 233, with the exception that at a multiplier of 3 or more the CPU starves for memory. The AMD K6 Bug In 1997, there have been reports of the AMD K6 seg faulting during heavy compilation. That problem has been fixed in 3Q '97. According to reports, K6 chips with date mark 9733 or larger (i.e., manufactured in the 33rd week of '97 or later) do not have this bug. * 486 class * 386 class 286 class Sorry, FreeBSD does not run on 80286 machines. It is nearly - impossible to run today's large full-featured UNIXes on such + impossible to run today's large full-featured unices on such hardware. * Memory The minimum amount of memory you must have to install FreeBSD is 5 MB. Once your system is up and running you can build a custom kernel that will use less memory. If you use the boot4.flp you can get away with having only 4 MB. * BIOS Input/Output Devices * Video cards * Sound cards Serial ports and multiport cards The UART: What it is and how it works Copyright © 1996 &a.uhclem;, All Rights Reserved. 13 January 1996. The Universal Asynchronous Receiver/Transmitter (UART) controller is the key component of the serial communications subsystem of a computer. The UART takes bytes of data and transmits the individual bits in a sequential fashion. At the destination, a second UART re-assembles the bits into complete bytes. Serial transmission is commonly used with modems and for non-networked communication between computers, terminals and other devices. There are two primary forms of serial transmission: Synchronous and Asynchronous. Depending on the modes that are supported by the hardware, the name of the communication sub-system will usually include a A if it supports Asynchronous communications, and a S if it supports Synchronous communications. Both forms are described below. Some common acronyms are:
UART Universal Asynchronous Receiver/Transmitter
USART Universal Synchronous-Asynchronous Receiver/Transmitter
Synchronous Serial Transmission Synchronous serial transmission requires that the sender and receiver share a clock with one another, or that the sender provide a strobe or other timing signal so that the receiver knows when to read the next bit of the data. In most forms of serial Synchronous communication, if there is no data available at a given instant to transmit, a fill character must be sent instead so that data is always being transmitted. Synchronous communication is usually more efficient because only data bits are transmitted between sender and receiver, and synchronous communication can be more more costly if extra wiring and circuits are required to share a clock signal between the sender and receiver. A form of Synchronous transmission is used with printers and fixed disk devices in that the data is sent on one set of wires while a clock or strobe is sent on a different wire. Printers and fixed disk devices are not normally serial devices because most fixed disk interface standards send an entire word of data for each clock or strobe signal by using a separate wire for each bit of the word. In the PC industry, these are known as Parallel devices. The standard serial communications hardware in the PC does not support Synchronous operations. This mode is described here for comparison purposes only. Asynchronous Serial Transmission Asynchronous transmission allows data to be transmitted without the sender having to send a clock signal to the receiver. Instead, the sender and receiver must agree on timing parameters in advance and special bits are added to each word which are used to synchronize the sending and receiving units. When a word is given to the UART for Asynchronous transmissions, a bit called the "Start Bit" is added to the beginning of each word that is to be transmitted. The Start Bit is used to alert the receiver that a word of data is about to be sent, and to force the clock in the receiver into synchronization with the clock in the transmitter. These two clocks must be accurate enough to not have the frequency drift by more than 10% during the transmission of the remaining bits in the word. (This requirement was set in the days of mechanical teleprinters and is easily met by modern electronic equipment.) After the Start Bit, the individual bits of the word of data are sent, with the Least Significant Bit (LSB) being sent first. Each bit in the transmission is transmitted for exactly the same amount of time as all of the other bits, and the receiver looks at the wire at approximately halfway through the period assigned to each bit to determine if the bit is a 1 or a 0. For example, if it takes two seconds to send each bit, the receiver will examine the signal to determine if it is a 1 or a 0 after one second has passed, then it will wait two seconds and then examine the value of the next bit, and so on. The sender does not know when the receiver has looked at the value of the bit. The sender only knows when the clock says to begin transmitting the next bit of the word. When the entire data word has been sent, the transmitter may add a Parity Bit that the transmitter generates. The Parity Bit may be used by the receiver to perform simple error checking. Then at least one Stop Bit is sent by the transmitter. When the receiver has received all of the bits in the data word, it may check for the Parity Bits (both sender and receiver must agree on whether a Parity Bit is to be used), and then the receiver looks for a Stop Bit. If the Stop Bit does not appear when it is supposed to, the UART considers the entire word to be garbled and will report a Framing Error to the host processor when the data word is read. The usual cause of a Framing Error is that the sender and receiver clocks were not running at the same speed, or that the signal was interrupted. Regardless of whether the data was received correctly or not, the UART automatically discards the Start, Parity and Stop bits. If the sender and receiver are configured identically, these bits are not passed to the host. If another word is ready for transmission, the Start Bit for the new word can be sent as soon as the Stop Bit for the previous word has been sent. Because asynchronous data is self synchronizing, if there is no data to transmit, the transmission line can be idle. Other UART Functions In addition to the basic job of converting data from parallel to serial for transmission and from serial to parallel on reception, a UART will usually provide additional circuits for signals that can be used to indicate the state of the transmission media, and to regulate the flow of data in the event that the remote device is not prepared to accept more data. For example, when the device connected to the UART is a modem, the modem may report the presence of a carrier on the phone line while the computer may be able to instruct the modem to reset itself or to - not take calls by asserting or deasserting one more more of these + not take calls by asserting or disasserting one more more of these extra signals. The function of each of these additional signals is defined in the EIA RS232-C standard. The RS232-C and V.24 Standards In most computer systems, the UART is connected to circuitry that generates signals that comply with the EIA RS232-C specification. There is also a CCITT standard named V.24 that mirrors the specifications included in RS232-C. RS232-C Bit Assignments (Marks and Spaces) In RS232-C, a value of 1 is called a Mark and a value of 0 is called a Space. When a communication line is idle, the line is said to be Marking, or transmitting continuous 1 values. The Start bit always has a value of 0 (a Space). The Stop Bit always has a value of 1 (a Mark). This means that there will always be a Mark (1) to Space (0) transition on the line at the start of every word, even when multiple word are transmitted back to back. This guarantees that sender and receiver can resynchronize their clocks regardless of the content of the data bits that are being transmitted. The idle time between Stop and Start bits does not have to be an exact multiple (including zero) of the bit rate of the communication link, but most UARTs are designed this way for simplicity. In RS232-C, the "Marking" signal (a 1) is represented by a voltage between -2 VDC and -12 VDC, and a "Spacing" signal (a 0) is represented by a voltage between 0 and +12 VDC. The transmitter is supposed to send +12 VDC or -12 VDC, and the receiver is supposed to allow for some voltage loss in long cables. Some transmitters in low power devices (like portable computers) sometimes use only +5 VDC and -5 VDC, but these values are still acceptable to a RS232-C receiver, provided that the cable lengths are short. RS232-C Break Signal RS232-C also specifies a signal called a Break, which is caused by sending continuous Spacing values (no Start or Stop bits). When there is no electricity present on the data circuit, the line is considered to be sending Break. The Break signal must be of a duration longer than the time it takes to send a complete byte plus Start, Stop and Parity bits. Most UARTs can distinguish between a Framing Error and a Break, but if the UART cannot do this, the Framing Error detection can be used to identify Breaks. In the days of teleprinters, when numerous printers around the country were wired in series (such as news services), any unit could cause a Break by temporarily opening the entire circuit so that no current flowed. This was used to allow a location with urgent news to interrupt some other location that was currently sending information. In modern systems there are two types of Break signals. If the Break is longer than 1.6 seconds, it is considered a "Modem Break", and some modems can be programmed to terminate the conversation and go on-hook or enter the modems' command mode when the modem detects this signal. If the Break is smaller than 1.6 seconds, it signifies a Data Break and it is up to the remote computer to respond to this signal. Sometimes this form of Break is used as an Attention or Interrupt signal and sometimes is accepted as a substitute for the ASCII CONTROL-C character. Marks and Spaces are also equivalent to Holes and No Holes in paper tape systems. Breaks cannot be generated from paper tape or from any other byte value, since bytes are always sent with Start and Stop bit. The UART is usually capable of generating the continuous Spacing signal in response to a special command from the host processor. RS232-C DTE and DCE Devices The RS232-C specification defines two types of equipment: the Data Terminal Equipment (DTE) and the Data Carrier Equipment (DCE). Usually, the DTE device is the terminal (or computer), and the DCE is a modem. Across the phone line at the other end of a conversation, the receiving modem is also a DCE device and the computer that is connected to that modem is a DTE device. The DCE device receives signals on the pins that the DTE device transmits on, and vice versa. When two devices that are both DTE or both DCE must be connected together without a modem or a similar media translater between them, a NULL modem must be used. The NULL modem electrically re-arranges the cabling so that the transmitter output is connected to the receiver input on the other device, and vice versa. Similar translations are performed on all of the control signals so that each device will see what it thinks are DCE (or DTE) signals from the other device. The number of signals generated by the DTE and DCE devices are not symmetrical. The DTE device generates fewer signals for the DCE device than the DTE device receives from the DCE. RS232-C Pin Assignments The EIA RS232-C specification (and the ITU equivalent, V.24) calls for a twenty-five pin connector (usually a DB25) and defines the purpose of most of the pins in that connector. In the IBM Personal Computer and similar systems, a subset of RS232-C signals are provided via nine pin connectors (DB9). The signals that are not included on the PC connector deal mainly with synchronous operation, and this transmission mode is not supported by the UART that IBM selected for use in the IBM PC. Depending on the computer manufacturer, a DB25, a DB9, or both types of connector may be used for RS232-C communications. (The IBM PC also uses a DB25 connector for the parallel printer interface which causes some confusion.) Below is a table of the RS232-C signal assignments in the DB25 and DB9 connectors. DB25 RS232-C Pin DB9 IBM PC Pin EIA Circuit Symbol CCITT Circuit Symbol Common Name Signal Source Description 1 - AA 101 PG/FG - Frame/Protective Ground 2 3 BA 103 TD DTE Transmit Data 3 2 BB 104 RD DCE Receive Data 4 7 CA 105 RTS DTE Request to Send 5 8 CB 106 CTS DCE Clear to Send 6 6 CC 107 DSR DCE Data Set Ready 7 5 AV 102 SG/GND - Signal Ground 8 1 CF 109 DCD/CD DCE Data Carrier Detect 9 - - - - - Reserved for Test 10 - - - - - Reserved for Test 11 - - - - - Reserved for Test 12 - CI 122 SRLSD DCE Sec. Recv. Line Signal Detector 13 - SCB 121 SCTS DCE Secondary Clear to Send 14 - SBA 118 STD DTE Secondary Transmit Data 15 - DB 114 TSET DCE Trans. Sig. Element Timing 16 - SBB 119 SRD DCE Secondary Received Data 17 - DD 115 RSET DCE Receiver Signal Element Timing 18 - - 141 LOOP DTE Local Loopback 19 - SCA 120 SRS DTE Secondary Request to Send 20 4 CD 108.2 DTR DTE Data Terminal Ready 21 - - - RDL DTE Remote Digital Loopback 22 9 CE 125 RI DCE Ring Indicator 23 - CH 111 DSRS DTE Data Signal Rate Selector 24 - DA 113 TSET DTE Trans. Sig. Element Timing 25 - - 142 - DCE Test Mode Bits, Baud and Symbols Baud is a measurement of transmission speed in asynchronous communication. Because of advances in modem communication technology, this term is frequently misused when describing the data rates in newer devices. Traditionally, a Baud Rate represents the number of bits that are actually being sent over the media, not the amount of data that is actually moved from one DTE device to the other. The Baud count includes the overhead bits Start, Stop and Parity that are generated by the sending UART and removed by the receiving UART. This means that seven-bit words of data actually take 10 bits to be completely transmitted. Therefore, a modem capable of moving 300 bits per second from one place to another can normally only move 30 7-bit words if Parity is used and one Start and Stop bit are present. If 8-bit data words are used and Parity bits are also used, the data rate falls to 27.27 words per second, because it now takes 11 bits to send the eight-bit words, and the modem still only sends 300 bits per second. The formula for converting bytes per second into a baud rate and vice versa was simple until error-correcting modems came along. These modems receive the serial stream of bits from the UART in the host computer (even when internal modems are used the data is still frequently serialized) and converts the bits back into bytes. These bytes are then combined into packets and sent over the phone line using a Synchronous transmission method. This means that the Stop, Start, and Parity bits added by the UART in the DTE (the computer) were removed by the modem before transmission by the sending modem. When these bytes are received by the remote modem, the remote modem adds Start, Stop and Parity bits to the words, converts them to a serial format and then sends them to the receiving UART in the remote computer, who then strips the Start, Stop and Parity bits. The reason all these extra conversions are done is so that the two modems can perform error correction, which means that the receiving modem is able to ask the sending modem to resend a block of data that was not received with the correct checksum. This checking is handled by the modems, and the DTE devices are usually unaware that the process is occurring. By striping the Start, Stop and Parity bits, the additional bits of data that the two modems must share between themselves to perform error-correction are mostly concealed from the effective transmission rate seen by the sending and receiving DTE equipment. For example, if a modem sends ten 7-bit words to another modem without including the Start, Stop and Parity bits, the sending modem will be able to add 30 bits of its own information that the receiving modem can use to do error-correction without impacting the transmission speed of the real data. The use of the term Baud is further confused by modems that perform compression. A single 8-bit word passed over the telephone line might represent a dozen words that were transmitted to the sending modem. The receiving modem will expand the data back to its original content and pass that data to the receiving DTE. Modern modems also include buffers that allow the rate that bits move across the phone line (DCE to DCE) to be a different speed than the speed that the bits move between the DTE and DCE on both ends of the conversation. Normally the speed between the DTE and DCE is higher than the DCE to DCE speed because of the use of compression by the modems. Because the number of bits needed to describe a byte varied during the trip between the two machines plus the differing bits-per-seconds speeds that are used present on the DTE-DCE and DCE-DCE links, the usage of the term Baud to describe the overall communication speed causes problems and can misrepresent the true transmission speed. So Bits Per Second (bps) is the correct term to use to describe the transmission rate seen at the DCE to DCE interface and Baud or Bits Per Second are acceptable terms to use when a connection is made between two systems with a wired connection, or if a modem is in use that is not performing error-correction or compression. Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in reality still operate at or below 2400 baud, or more accurately, 2400 Symbols per second. High speed modem are able to encode more bits of data into each Symbol using a technique called Constellation Stuffing, which is why the effective bits per second rate of the modem is higher, but the modem continues to operate within the limited audio bandwidth that the telephone system provides. Modems operating at 28,800 and higher speeds have variable Symbol rates, but the technique is the same. The IBM Personal Computer UART Starting with the original IBM Personal Computer, IBM selected the National Semiconductor INS8250 UART for use in the IBM PC Parallel/Serial Adapter. Subsequent generations of compatible computers from IBM and other vendors continued to use the INS8250 or improved versions of the National Semiconductor UART family. National Semiconductor UART Family Tree There have been several versions and subsequent generations of the INS8250 UART. Each major version is described below. INS8250 -> INS8250B \ \ \-> INS8250A -> INS82C50A \ \ \-> NS16450 -> NS16C450 \ \ \-> NS16550 -> NS16550A -> PC16550D INS8250 This part was used in the original IBM PC and IBM PC/XT. The original name for this part was the INS8250 ACE (Asynchronous Communications Element) and it is made from NMOS technology. The 8250 uses eight I/O ports and has a one-byte send and a one-byte receive buffer. This original UART has several race conditions and other flaws. The original IBM BIOS includes code to work around these flaws, but this made the BIOS dependent on the flaws being present, so subsequent parts like the 8250A, 16450 or 16550 could not be used in the original IBM PC or IBM PC/XT. INS8250-B This is the slower speed of the INS8250 made from NMOS technology. It contains the same problems as the original INS8250. INS8250A An improved version of the INS8250 using XMOS technology with various functional flaws corrected. The INS8250A was used initially in PC clone computers by vendors who used clean BIOS designs. Because of the corrections in the chip, this part could not be used with a BIOS compatible with the INS8250 or INS8250B. INS82C50A This is a CMOS version (low power consumption) of the INS8250A and has similar functional characteristics. NS16450 Same as NS8250A with improvements so it can be used with faster CPU bus designs. IBM used this part in the IBM AT and updated the IBM BIOS to no longer rely on the bugs in the INS8250. NS16C450 This is a CMOS version (low power consumption) of the NS16450. NS16550 Same as NS16450 with a 16-byte send and receive buffer but the buffer design was flawed and could not be reliably be used. NS16550A Same as NS16550 with the buffer flaws corrected. The 16550A and its successors have become the most popular UART design in the PC industry, mainly due it its ability to reliably handle higher data rates on operating systems with sluggish interrupt response times. NS16C552 This component consists of two NS16C550A CMOS UARTs in a single package. PC16550D Same as NS16550A with subtle flaws corrected. This is revision D of the 16550 family and is the latest design available from National Semiconductor. The NS16550AF and the PC16550D are the same thing National reorganized their part numbering system a few years ago, and the NS16550AFN no longer exists by that name. (If you have a NS16550AFN, look at the date code on the part, which is a four digit number that usually starts with a nine. The first two digits of the number are the year, and the last two digits are the week in that year when the part was packaged. If you have a NS16550AFN, it is probably a few years old.) The new numbers are like PC16550DV, with minor differences in the suffix letters depending on the package material and its shape. (A description of the numbering system can be found below.) It is important to understand that in some stores, you may pay $15(US) for a NS16550AFN made in 1990 and in the next bin are the new PC16550DN parts with minor fixes that National has made since the AFN part was in production, the PC16550DN was probably made in the past six months and it costs half (as low as $5(US) in volume) as much as the NS16550AFN because they are readily available. As the supply of NS16550AFN chips continues to shrink, the price will probably continue to increase until more people discover and accept that the PC16550DN really has the same function as the old part number. National Semiconductor Part Numbering System The older NSnnnnnrqp part numbers are now of the format PCnnnnnrgp. The r is the revision field. The current revision of the 16550 from National Semiconductor is D. The p is the package-type field. The types are: "F" QFP (quad flat pack) L lead type "N" DIP (dual inline package) through hole straight lead type "V" LPCC (lead plastic chip carrier) J lead type The g is the product grade field. If an I precedes the package-type letter, it indicates an industrial grade part, which has higher specs than a standard part but not as high as Military Specification (Milspec) component. This is an optional field. So what we used to call a NS16550AFN (DIP Package) is now called a PC16550DN or PC16550DIN. Other Vendors and Similar UARTs Over the years, the 8250, 8250A, 16450 and 16550 have been licensed or copied by other chip vendors. In the case of the 8250, 8250A and 16450, the exact circuit (the megacell) was licensed to many vendors, including Western Digital and Intel. Other vendors reverse-engineered the part or produced emulations that had similar behavior. In internal modems, the modem designer will frequently emulate the 8250A/16450 with the modem microprocessor, and the emulated UART will frequently have a hidden buffer consisting of several hundred bytes. Because of the size of the buffer, these emulations can be as reliable as a 16550A in their ability to handle high speed data. However, most operating systems will still report that the UART is only a 8250A or 16450, and may not make effective use of the extra buffering present in the emulated UART unless special drivers are used. Some modem makers are driven by market forces to abandon a design that has hundreds of bytes of buffer and instead use a 16550A UART so that the product will compare favorably in market comparisons even though the effective performance may be lowered by this action. A common misconception is that all parts with 16550A written on them are identical in performance. There are differences, and in some cases, outright flaws in most of these 16550A clones. When the NS16550 was developed, the National Semiconductor obtained several patents on the design and they also limited licensing, making it harder for other vendors to provide a chip with similar features. Because of the patents, reverse-engineered designs and emulations had to avoid infringing the claims covered by the patents. Subsequently, these copies almost never perform exactly the same as the NS16550A or PC16550D, which are the parts most computer and modem makers want to buy but are sometimes unwilling to pay the price required to get the genuine part. Some of the differences in the clone 16550A parts are unimportant, while others can prevent the device from being used at all with a given operating system or driver. These differences may show up when using other drivers, or when particular combinations of events occur that were not well tested or considered in the Windows driver. This is because most modem vendors and 16550-clone makers use the Microsoft drivers from - Windows for Workgroups 3.11 and the Microsoft MSD utility as the + Windows for Workgroups 3.11 and the Microsoft MS-DOS utility as the primary tests for compatibility with the NS16550A. This over-simplistic criteria means that if a different operating system is used, problems could appear due to subtle differences between the clones and genuine components. National Semiconductor has made available a program named COMTEST that performs compatibility tests independent of any OS drivers. It should be remembered that the purpose of this type of program is to demonstrate the flaws in the products of the competition, so the program will report major as well as extremely subtle differences in behavior in the part being tested. In a series of tests performed by the author of this document in 1994, components made by National Semiconductor, TI, StarTech, and CMD as well as megacells and emulations embedded in internal modems were tested with COMTEST. A difference count for some of these components is listed below. Because these tests were performed in 1994, they may not reflect the current performance of the given product from a vendor. It should be noted that COMTEST normally aborts when an excessive number or certain types of problems have been detected. As part of this testing, COMTEST was modified so that it would not abort no matter how many differences were encountered. Vendor Part Number Errors (aka "differences" reported) National (PC16550DV) 0 National (NS16550AFN) 0 National (NS16C552V) 0 TI (TL16550AFN) 3 CMD (16C550PE) 19 StarTech (ST16C550J) 23 Rockwell Reference modem with internal 16550 or an emulation (RC144DPi/C3000-25) 117 Sierra Modem with an internal 16550 (SC11951/SC11351) 91 To date, the author of this document has not found any non-National parts that report zero differences using the COMTEST program. It should also be noted that National has had five versions of the 16550 over the years and the newest parts behave a bit differently than the classic NS16550AFN that is considered the benchmark for functionality. COMTEST appears to turn a blind eye to the differences within the National product line and reports no errors on the National parts (except for the original 16550) even when there are official erratas that describe bugs in the A, B and C revisions of the parts, so this bias in COMTEST must be taken into account. It is important to understand that a simple count of differences from COMTEST does not reveal a lot about what differences are important and which are not. For example, about half of the differences reported in the two modems listed above that have internal UARTs were caused by the clone UARTs not supporting five- and six-bit character modes. The real 16550, 16450, and 8250 UARTs all support these modes and COMTEST checks the functionality of these modes so over fifty differences are reported. However, almost no modern modem supports five- or six-bit characters, particularly those with error-correction and compression capabilities. This means that the differences related to five- and six-bit character modes can be discounted. Many of the differences COMTEST reports have to do with timing. In many of the clone designs, when the host reads from one port, the status bits in some other port may not update in the same amount of time (some faster, some slower) as a real NS16550AFN and COMTEST looks for these differences. This means that the number of differences can be misleading in that one device may only have one or two differences but they are extremely serious, and some other device that updates the status registers faster or slower than the reference part (that would probably never affect the operation of a properly written driver) could have dozens of differences reported. COMTEST can be used as a screening tool to alert the administrator to the presence of potentially incompatible components that might cause problems or have to be handled as a special case. If you run COMTEST on a 16550 that is in a modem or a modem is attached to the serial port, you need to first issue a ATE0&W command to the modem so that the modem will not echo any of the test characters. If you forget to do this, COMTEST will report at least this one difference: Error (6)...Timeout interrupt failed: IIR = c1 LSR = 61 8250/16450/16550 Registers The 8250/16450/16550 UART occupies eight contiguous I/O port addresses. In the IBM PC, there are two defined locations for these eight ports and they are known collectively as COM1 and COM2. The makers of PC-clones and add-on cards have created two additional areas known as COM3 and COM4, but these extra COM ports conflict with other hardware on some systems. The most common conflict is with video adapters that provide IBM 8514 emulation. COM1 is located from 0x3f8 to 0x3ff and normally uses IRQ 4 COM2 is located from 0x2f8 to 0x2ff and normally uses IRQ 3 COM3 is located from 0x3e8 to 0x3ef and has no standardized IRQ COM4 is located from 0x2e8 to 0x2ef and has no standardized IRQ. A description of the I/O ports of the 8250/16450/16550 UART is provided below. I/O Port Access Allowed Description +0x00 write (DLAB==0) Transmit Holding Register (THR).Information written to this port are treated as data words and will be transmitted by the UART. +0x00 read (DLAB==0) Receive Buffer Register (RBR).Any data words received by the UART form the serial link are accessed by the host by reading this port. +0x00 write/read (DLAB==1) Divisor Latch LSB (DLL)This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 0 thru 7 of the divisor. +0x01 write/read (DLAB==1) Divisor Latch MSB (DLH)This value will be divided from the master input clock (in the IBM PC, the master clock is 1.8432MHz) and the resulting clock will determine the baud rate of the UART. This register holds bits 8 thru 15 of the divisor. +0x01 write/read (DLAB==0) Interrupt Enable Register (IER)The 8250/16450/16550 UART classifies events into one of four categories. Each category can be configured to generate an interrupt when any of the events occurs. The 8250/16450/16550 UART generates a single external interrupt signal regardless of how many events in the enabled categories have occurred. It is up to the host processor to respond to the interrupt and then poll the enabled interrupt categories (usually all categories have interrupts enabled) to determine the true cause(s) of the interrupt. Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Enable Modem Status Interrupt (EDSSI). Setting this bit to "1" allows the UART to generate an interrupt when a change occurs on one or more of the status lines. Bit 2 Enable Receiver Line Status Interrupt (ELSI) Setting this bit to "1" causes the UART to generate an interrupt when the an error (or a BREAK signal) has been detected in the incoming data. Bit 1 Enable Transmitter Holding Register Empty Interrupt (ETBEI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has room for one or more additional characters that are to be transmitted. Bit 0 Enable Received Data Available Interrupt (ERBFI) Setting this bit to "1" causes the UART to generate an interrupt when the UART has received enough characters to exceed the trigger level of the FIFO, or the FIFO timer has expired (stale data), or a single character has been received when the FIFO is disabled. +0x02 write FIFO Control Register (FCR) (This port does not exist on the 8250 and 16450 UART.) Bit 7 Receiver Trigger Bit #1 Bit 6 Receiver Trigger Bit #0These two bits control at what point the receiver is to generate an interrupt when the FIFO is active. 7 6 How many words are received before an interrupt is generated 0 0 1 0 1 4 1 0 8 1 1 14 Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 DMA Mode Select. If Bit 0 is set to "1" (FIFOs enabled), setting this bit changes the operation of the -RXRDY and -TXRDY signals from Mode 0 to Mode 1. Bit 2 Transmit FIFO Reset. When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being transmitted will be sent intact. This function is useful in aborting transfers. Bit 1 Receiver FIFO Reset. When a "1" is written to this bit, the contents of the FIFO are discarded. Any word currently being assembled in the shift register will be received intact. Bit 0 16550 FIFO Enable. When set, both the transmit and receive FIFOs are enabled. Any contents in the holding register, shift registers or FIFOs are lost when FIFOs are enabled or disabled. +0x02 read Interrupt Identification Register Bit 7 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 6 FIFOs enabled. On the 8250/16450 UART, this bit is zero. Bit 5 Reserved, always 0. Bit 4 Reserved, always 0. Bit 3 Interrupt ID Bit #2. On the 8250/16450 UART, this bit is zero. Bit 2 Interrupt ID Bit #1 Bit 1 Interrupt ID Bit #0.These three bits combine to report the category of event that caused the interrupt that is in progress. These categories have priorities, so if multiple categories of events occur at the same time, the UART will report the more important events first and the host must resolve the events in the order they are reported. All events that caused the current interrupt must be resolved before any new interrupts will be generated. (This is a limitation of the PC architecture.) 2 1 0 Priority Description 0 1 1 First Received Error (OE, PE, BI, or FE) 0 1 0 Second Received Data Available 1 1 0 Second Trigger level identification (Stale data in receive buffer) 0 0 1 Third Transmitter has room for more words (THRE) 0 0 0 Fourth Modem Status Change (-CTS, -DSR, -RI, or -DCD) Bit 0 Interrupt Pending Bit. If this bit is set to "0", then at least one interrupt is pending. +0x03 write/read Line Control Register (LCR) Bit 7 Divisor Latch Access Bit (DLAB). When set, access to the data transmit/receive register (THR/RBR) and the Interrupt Enable Register (IER) is disabled. Any access to these ports is now redirected to the Divisor Latch Registers. Setting this bit, loading the Divisor Registers, and clearing DLAB should be done with interrupts disabled. Bit 6 Set Break. When set to "1", the transmitter begins to transmit continuous Spacing until this bit is set to "0". This overrides any bits of characters that are being transmitted. Bit 5 Stick Parity. When parity is enabled, setting this bit causes parity to always be "1" or "0", based on the value of Bit 4. Bit 4 Even Parity Select (EPS). When parity is enabled and Bit 5 is "0", setting this bit causes even parity to be transmitted and expected. Otherwise, odd parity is used. Bit 3 Parity Enable (PEN). When set to "1", a parity bit is inserted between the last bit of the data and the Stop Bit. The UART will also expect parity to be present in the received data. Bit 2 Number of Stop Bits (STB). If set to "1" and using 5-bit data words, 1.5 Stop Bits are transmitted and expected in each data word. For 6, 7 and 8-bit data words, 2 Stop Bits are transmitted and expected. When this bit is set to "0", one Stop Bit is used on each data word. Bit 1 Word Length Select Bit #1 (WLSB1) Bit 0 Word Length Select Bit #0 (WLSB0) Together these bits specify the number of bits in each data word. 1 0 Word Length 0 0 5 Data Bits 0 1 6 Data Bits 1 0 7 Data Bits 1 1 8 Data Bits +0x04 write/read Modem Control Register (MCR) Bit 7 Reserved, always 0. Bit 6 Reserved, always 0. Bit 5 Reserved, always 0. Bit 4 Loop-Back Enable. When set to "1", the UART transmitter and receiver are internally connected together to allow diagnostic operations. In addition, the UART modem control outputs are connected to the UART modem control inputs. CTS is connected to RTS, DTR is connected to DSR, OUT1 is connected to RI, and OUT 2 is connected to DCD. Bit 3 OUT 2. An auxiliary output that the host processor may set high or low. In the IBM PC serial adapter (and most clones), OUT 2 is used to tri-state (disable) the interrupt signal from the 8250/16450/16550 UART. Bit 2 OUT 1. An auxiliary output that the host processor may set high or low. This output is not used on the IBM PC serial adapter. Bit 1 Request to Send (RTS). When set to "1", the output of the UART -RTS line is Low (Active). Bit 0 Data Terminal Ready (DTR). When set to "1", the output of the UART -DTR line is Low (Active). +0x05 write/read Line Status Register (LSR) Bit 7 Error in Receiver FIFO. On the 8250/16450 UART, this bit is zero. This bit is set to "1" when any of the bytes in the FIFO have one or more of the following error conditions: PE, FE, or BI. Bit 6 Transmitter Empty (TEMT). When set to "1", there are no words remaining in the transmit FIFO or the transmit shift register. The transmitter is completely idle. Bit 5 Transmitter Holding Register Empty (THRE). When set to "1", the FIFO (or holding register) now has room for at least one additional word to transmit. The transmitter may still be transmitting when this bit is set to "1". Bit 4 Break Interrupt (BI). The receiver has detected a Break signal. Bit 3 Framing Error (FE). A Start Bit was detected but the Stop Bit did not appear at the expected time. The received word is probably garbled. Bit 2 Parity Error (PE). The parity bit was incorrect for the word received. Bit 1 Overrun Error (OE). A new word was received and there was no room in the receive buffer. The newly-arrived word in the shift register is discarded. On 8250/16450 UARTs, the word in the holding register is discarded and the newly- arrived word is put in the holding register. Bit 0 Data Ready (DR) One or more words are in the receive FIFO that the host may read. A word must be completely received and moved from the shift register into the FIFO (or holding register for 8250/16450 designs) before this bit is set. +0x06 write/read Modem Status Register (MSR) Bit 7 Data Carrier Detect (DCD). Reflects the state of the DCD line on the UART. Bit 6 Ring Indicator (RI). Reflects the state of the RI line on the UART. Bit 5 Data Set Ready (DSR). Reflects the state of the DSR line on the UART. Bit 4 Clear To Send (CTS). Reflects the state of the CTS line on the UART. Bit 3 Delta Data Carrier Detect (DDCD). Set to "1" if the -DCD line has changed state one more more times since the last time the MSR was read by the host. Bit 2 Trailing Edge Ring Indicator (TERI). Set to "1" if the -RI line has had a low to high transition since the last time the MSR was read by the host. Bit 1 Delta Data Set Ready (DDSR). Set to "1" if the -DSR line has changed state one more more times since the last time the MSR was read by the host. Bit 0 Delta Clear To Send (DCTS). Set to "1" if the -CTS line has changed state one more more times since the last time the MSR was read by the host. +0x07 write/read Scratch Register (SCR). This register performs no function in the UART. Any value can be written by the host to this location and read by the host later on. Beyond the 16550A UART Although National Semiconductor has not offered any components compatible with the 16550 that provide additional features, various other vendors have. Some of these components are described below. It should be understood that to effectively utilize these improvements, drivers may have to be provided by the chip vendor since most of the popular operating systems do not support features beyond those provided by the 16550. ST16650 By default this part is similar to the NS16550A, but an extended 32-byte send and receive buffer can be optionally - enabled. Made by Startech. + enabled. Made by StarTech. TIL16660 By default this part behaves similar to the NS16550A, but an extended 64-byte send and receive buffer can be optionally enabled. Made by Texas Instruments. Hayes ESP This proprietary plug-in card contains a 2048-byte send and receive buffer, and supports data rates to 230.4Kbit/sec. Made by Hayes. In addition to these dumb UARTs, many vendors produce intelligent serial communication boards. This type of design usually provides a microprocessor that interfaces with several UARTs, processes and buffers the data, and then alerts the main PC processor when necessary. Because the UARTs are not directly accessed by the PC processor in this type of communication system, it is not necessary for the vendor to use UARTs that are compatible with the 8250, 16450, or the 16550 UART. This leaves the designer free to components that may have better performance characteristics. Configuring the <devicename>sio</devicename> driver The sio 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 &man.sio.4; manual page for detailed technical documentation. Digi International (DigiBoard) PC/8 Contributed by &a.awebster;. 26 August 1995. Here is a config snippet from a machine with a Digi International PC/8 with 16550. It has 8 modems connected to these 8 lines, and they work just great. Do not forget to add options COM_MULTIPORT or it will not work very well! 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 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. Boca 16 Contributed by &a.whiteside;. 26 August 1995. The procedures to make a Boca 16 port board with FreeBSD are pretty straightforward, but you will need a couple things to make it work: 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 not come with multiport support enabled and you will need to add a device entry for each port anyways. 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. 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 Kernel Configuration for general procedures. The following are the specifics for the Boca 16 board and assume you are using the kernel name MYKERNEL and editing with vi. Add the line options COM_MULTIPORT to the config file. Where the current device sion lines are, you will need to add 16 more devices. Only the last device includes the interrupt vector for the board. (See the &man.sio.4; 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 hexadecimal from the previous port, thus the 100h, 108h, 110h... addresses. 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 The flags entry must be changed from this example unless you are using the exact same sio assignments. Flags are set according to 0xMYY where M indicates the minor number of the master port (the last port on a Boca 16) and YY 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, flags 0x1005 indicates that the master port is sio16. If I added another board and assigned sio17 through sio28, the flags for all 16 ports on that board would be 0x1C05, where 1C indicates the minor number of the master port. Do not change the 05 setting. 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) 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) If the messages go by too fast to see, &prompt.root; dmesg | more will show you the boot messages. Next, appropriate entries in /dev for the devices must be made using the /dev/MAKEDEV script. After becoming root: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tty1 &prompt.root; ./MAKEDEV cua1 (everything in between) &prompt.root; ./MAKEDEV ttyg &prompt.root; ./MAKEDEV cuag - If you do not want or need callout devices for some + If you do not want or need call-out devices for some reason, you can dispense with making the cua* devices. 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) &prompt.root; echo at > ttyd* for each device you have made. You should see the RX lights flash for each working port. Support for Cheap Multi-UART Cards Contributed by Helge Oldach hmo@sep.hamburg.com, September 1999 Ever wondered about FreeBSD support for your 20$ multi-I/O card with two (or more) COM ports, sharing IRQs? Here's how: Usually the only option to support these kind of boards is to use a distinct IRQ for each port. For example, if your CPU board has an on-board COM1 port (aka sio0–I/O address 0x3F8 and IRQ 4) and you have an extension board with two UARTs, you will commonly need to configure them as COM2 (aka sio1–I/O address 0x2F8 and IRQ 3), and the third port (aka sio2) as I/O - 0x3E8 and IRQ 5. Obviously this is a waste of IRQ ressources, as + 0x3E8 and IRQ 5. Obviously this is a waste of IRQ resources, as it should be basically possible to run both extension board ports using a single IRQ with the COM_MULTIPORT configuration described in the previous sections. Such cheap I/O boards commonly have a 4 by 3 jumper matrix for the COM ports, similar to the following: o o o * Port A | o * o * Port B | o * o o IRQ 2 3 4 5 Shown here is port A wired for IRQ 5 and port B wired for IRQ 3. The IRQ columns on your specific board may vary—other boards may supply jumpers for IRQs 3, 4, 5, and 7 instead. One could conclude that wiring both ports for IRQ 3 using a handcrafted wire-made jumper covering all three connection points in the IRQ 3 column would solve the issue, but no. You cannot duplicate IRQ 3 because the output drivers of each UART are wired in a totem pole fashion, so if one of the UARTs drives IRQ 3, the output signal will not be what you would expect. Depending on the implementation of the extension board or your motherboard, the IRQ 3 line will continuously stay up, or always stay low. You need to decouple the IRQ drivers for the two UARTs, so that the IRQ line of the board only goes up if (and only if) one of the UARTs asserts a IRQ, and stays low otherwise. The solution - was proposed by Jrg Wunsch + was proposed by Joerg Wunsch j@ida.interface-business.de: To solder up a wired-or consisting of two diodes (Germanium or Schottky-types strongly preferred) and a 1 kOhm resistor. Here is the schematic, starting from the 4 by 3 jumper field above: Diode +---------->|-------+ / | o * o o | 1 kOhm Port A +----|######|-------+ o * o o | | Port B `-------------------+ ==+== o * o o | Ground \ | +--------->|-------+ IRQ 2 3 4 5 Diode The cathodes of the diodes are connected to a common point, together with a 1 kOhm pull-down resistor. It is essential to connect the resistor to ground to avoid floating of the IRQ line on the bus. Now we are ready to configure a kernel. Staying with this example, we would configure: # standard on-board COM1 port device sio0 at isa? port "IO_COM1" tty flags 0x10 # patched-up multi-I/O extension board options COM_MULTIPORT device sio1 at isa? port "IO_COM2" tty flags 0x205 device sio2 at isa? port "IO_COM3" tty flags 0x205 irq 3 Note that the flags setting for sio1 and sio2 is - truely essential; refer to + truly essential; refer to &man.sio.4; for details. (Generally, the 2 in the "flags" attribute refers to sio2 which holds the IRQ, and you surely want a 5 low nibble.) With kernel verbose mode turned on this should yield something similar to this: sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff flags 0x205 on isa sio1: type 16550A (multiport) sio2: irq maps: 0x1 0x9 0x1 0x1 sio2 at 0x3e8-0x3ef irq 3 flags 0x205 on isa sio2: type 16550A (multiport master) Though /sys/i386/isa/sio.c is somewhat cryptic with its use of the irq maps array above, the basic idea is that you observe 0x1 in the first, third, and fourth place. This means that the corresponding IRQ was set upon output and cleared after, which is just what we - would expect. If your kernel does not display this behaviour, most + would expect. If your kernel does not display this behavior, most likely there is something wrong with your wiring. Configuring the <devicename>cy</devicename> driver Contributed by &a.alex;. 6 June 1996. The Cyclades multiport cards are based on the cy driver instead of the usual sio driver used by other multiport cards. Configuration is a simple matter of: Add the cy device to your kernel configuration (note that your irq and iomem settings may differ). device cy0 at isa? tty irq 10 iomem 0xd4000 iosiz 0x2000 vector cyintr Rebuild and install the new kernel. Make the device nodes by typing (the following example assumes an 8-port board): &prompt.root; cd /dev &prompt.root; for i in 0 1 2 3 4 5 6 7;do ./MAKEDEV cuac$i ttyc$i;done If appropriate, add dialup entries to /etc/ttys by duplicating serial device (ttyd) entries and using ttyc in place of ttyd. For example: ttyc0 "/usr/libexec/getty std.38400" unknown on insecure ttyc1 "/usr/libexec/getty std.38400" unknown on insecure ttyc2 "/usr/libexec/getty std.38400" unknown on insecure … ttyc7 "/usr/libexec/getty std.38400" unknown on insecure Reboot with the new kernel. Configuring the <devicename>si</devicename> driver Contributed by &a.nsayer;. 25 March 1998. The Specialix SI/XIO and SX multiport cards use the si driver. A single machine can have up to 4 host cards. The following host cards are supported: ISA SI/XIO host card (2 versions) EISA SI/XIO host card PCI SI/XIO host card ISA SX host card PCI SX host card Although the SX and SI/XIO host cards look markedly different, their functionality are basically the same. The host cards do not use I/O locations, but instead require a 32K chunk of memory. The factory configuration for ISA cards places this at 0xd0000-0xd7fff. - They also require an IRQ. PCI cards will, of course, autoconfigure + They also require an IRQ. PCI cards will, of course, auto-configure themselves. You can attach up to 4 external modules to each host card. The external modules contain either 4 or 8 serial ports. They come in the following varieties: SI 4 or 8 port modules. Up to 57600 bps on each port supported. XIO 8 port modules. Up to 115200 bps on each port supported. One type of XIO module has 7 serial and 1 parallel port. SXDC 8 port modules. Up to 921600 bps on each port supported. Like XIO, a module is available with one parallel port as well. To configure an ISA host card, add the following line to your kernel configuration file, changing the numbers as appropriate: device si0 at isa? tty iomem 0xd0000 irq 11 Valid IRQ numbers are 9, 10, 11, 12 and 15 for SX ISA host cards and 11, 12 and 15 for SI/XIO ISA host cards. To configure an EISA or PCI host card, use this line: device si0 After adding the configuration entry, rebuild and install your new kernel. After rebooting with the new kernel, you need to make the device nodes in /dev. The MAKEDEV script will take care of this for you. Count how many total ports you have and type: &prompt.root; cd /dev &prompt.root; ./MAKEDEV ttyAnn cuaAnn (where nn is the number of ports) If you want login prompts to appear on these ports, you will need to add lines like this to /etc/ttys: ttyA01 "/usr/libexec/getty std.9600" vt100 on insecure Change the terminal type as appropriate. For modems, dialup or unknown is fine. * Parallel ports * Modems * Network cards * Keyboards Mice Contributed by Joel Sutton jsutton@bbcon.com.au January 2000 FreeBSD supports a variety of different mice via the PS/2, serial and USB ports. Most users choose to use the mouse daemon to handle their mouse because it allows interaction in both X and on the system console. For more information on the mouse daemon refer to &man.moused.8;. The examples throughout this section assume that the mouse daemon is being used. This section contains the names of specific products that the author has confirmed will work with FreeBSD. Other similar devices not listed may also be supported. PS/2 System Configuration To ensure that your PS/2 mouse functions correctly with the mouse daemon you will need to include the following text in /etc/rc.conf moused_enable="YES" moused_type="ps/2" moused_port="/dev/psm0" Known Compatible Devices Logitech First Mouse - Three Button Microsoft Serial - PS/2 Compatible Mouse Serial System Configuration To ensure that your serial mouse functions correctly with the mouse daemon you will need to include the following text in /etc/rc.conf. This example assumes that the mouse is connected to COM1: and can be - automatically recognised by the mouse daemon. + automatically recognized by the mouse daemon. moused_enable="YES" moused_type="auto" moused_port="/dev/cuaa0" See the &man.moused.8; manual page for a detailed description of how to configure the mouse daemon to work with specific types of serial mice. Known Compatible Devices Generic Microsoft Compatible Mice Logitech First Mouse - Three Button Microsoft Serial - PS/2 Compatible Mouse USB System Configuration The USB device drivers are a relatively new addition to FreeBSD and have not yet been included in the GENERIC kernel. The - following prodecure is an example of how to setup the relevant + following procedure is an example of how to setup the relevant drivers on a typical system. Add the ums device to the usb section of your kernel configuration. For example: controller usb0 controller uhci0 device ums0 Rebuild and install the new kernel. Make the device node by typing: &prompt.root; cd /dev &prompt.root; sh MAKEDEV ums0 Include the following text in /etc/rc.conf to ensure correct operation of the mouse daemon: moused_enable="YES" moused_type="auto" moused_port="/dev/ums0" Reboot the system. &prompt.root; shutdown -r now Known Compatible Devices Logitech TrackMan - Marble Wheel * Other ]]> Storage Devices Using ESDI hard disks Copyright © 1995, &a.wilko;. 24 September 1995. ESDI is an acronym that means Enhanced Small Device Interface. It is loosely based on the good old ST506/412 interface originally devised by Seagate Technology, the makers of the first affordable 5.25" winchester disk. The acronym says Enhanced, and rightly so. In the first place the speed of the interface is higher, 10 or 15 Mbits/second instead of the 5 Mbits/second of ST412 interfaced drives. Secondly some higher level commands are added, making the ESDI interface somewhat 'smarter' to the operating system driver writers. It is by no means as smart as SCSI by the way. ESDI is standardized by ANSI. Capacities of the drives are boosted by putting more sectors on each track. Typical is 35 sectors per track, high capacity drives I have seen were up to 54 sectors/track. Although ESDI has been largely obsoleted by IDE and SCSI interfaces, the availability of free or cheap surplus drives makes them ideal for low (or now) budget systems. Concepts of ESDI Physical connections The ESDI interface uses two cables connected to each drive. One cable is a 34 pin flat cable edge connector that carries the command and status signals from the controller to the drive and vice-versa. The command cable is daisy chained between all the drives. So, it forms a bus onto which all drives are connected. The second cable is a 20 pin flat cable edge connector that carries the data to and from the drive. This cable is radially connected, so each drive has its own direct connection to the controller. To the best of my knowledge PC ESDI controllers are limited to using a maximum of 2 drives per controller. This is compatibility feature(?) left over from the WD1003 standard that reserves only a single bit for device addressing. Device addressing On each command cable a maximum of 7 devices and 1 controller can be present. To enable the controller to uniquely identify which drive it addresses, each ESDI device is equipped with jumpers or switches to select the devices address. On PC type controllers the first drive is set to address 0, the second disk to address 1. Always make sure you set each disk to an unique address! So, on a PC with its two drives/controller maximum the first drive is drive 0, the second is drive 1. Termination The daisy chained command cable (the 34 pin cable remember?) needs to be terminated at the last drive on the chain. For this purpose ESDI drives come with a termination resistor network that can be removed or disabled by a jumper when it is not used. So, one and only one drive, the one at the farthest end of the command cable has its terminator installed/enabled. The controller automatically terminates the other end of the cable. Please note that this implies that the controller must be at one end of the cable and not in the middle. Using ESDI disks with FreeBSD Why is ESDI such a pain to get working in the first place? People who tried ESDI disks with FreeBSD are known to have developed a profound sense of frustration. A combination of factors works against you to produce effects that are hard to understand when you have never seen them before. This has also led to the popular legend ESDI and FreeBSD is a plain NO-GO. The following sections try to list all the pitfalls and solutions. ESDI speed variants As briefly mentioned before, ESDI comes in two speed flavors. The older drives and controllers use a 10 Mbits/second data transfer rate. Newer stuff uses 15 Mbits/second. It is not hard to imagine that 15 Mbits/second drive cause problems on controllers laid out for 10 Mbits/second. As always, consult your controller and drive documentation to see if things match. Stay on track Mainstream ESDI drives use 34 to 36 sectors per track. Most (older) controllers cannot handle more than this number of sectors. Newer, higher capacity, drives use higher numbers of - sectors per track. For instance, I own a 670 Mb drive that has 54 + sectors per track. For instance, I own a 670 MB drive that has 54 sectors per track. In my case, the controller could not handle this number of sectors. It proved to work well except that it only used 35 sectors on each track. This meant losing a lot of disk space. Once again, check the documentation of your hardware for more info. Going out-of-spec like in the example might or might not work. Give it a try or get another more capable controller. Hard or soft sectoring Most ESDI drives allow hard or soft sectoring to be selected using a jumper. Hard sectoring means that the drive will produce a sector pulse on the start of each new sector. The controller uses this pulse to tell when it should start to write or read. Hard sectoring allows a selection of sector size (normally 256, 512 or 1024 bytes per formatted sector). FreeBSD uses 512 byte sectors. The number of sectors per track also varies while still using the same number of bytes per formatted sector. The number of unformatted bytes per sector varies, dependent on your controller it needs more or less overhead bytes to work correctly. Pushing more sectors on a track of course gives you more usable space, but might give problems if your controller needs more bytes than the drive offers. In case of soft sectoring, the controller itself determines where to start/stop reading or writing. For ESDI hard sectoring is the default (at least on everything I came across). I never felt the urge to try soft sectoring. In general, experiment with sector settings before you install FreeBSD because you need to re-run the low-level format after each change. Low level formatting ESDI drives need to be low level formatted before they are usable. A reformat is needed whenever you figgle with the number of sectors/track jumpers or the physical orientation of the drive (horizontal, vertical). So, first think, then format. The format time must not be underestimated, for big disks it can take hours. After a low level format, a surface scan is done to find and flag bad sectors. Most disks have a manufacturer bad block list listed on a piece of paper or adhesive sticker. In addition, on most disks the list is also written onto the disk. Please use the manufacturer's list. It is much easier to remap a defect now than after FreeBSD is installed. Stay away from low-level formatters that mark all sectors of a track as bad as soon as they find one bad sector. Not only does this waste space, it also and more importantly causes you grief with bad144 (see the section on bad144). Translations Translations, although not exclusively a ESDI-only problem, might give you real trouble. Translations come in multiple flavors. Most of them have in common that they attempt to work around the limitations posed upon disk geometries by the original IBM PC/AT design (thanks IBM!). First of all there is the (in)famous 1024 cylinder limit. For a system to be able to boot, the stuff (whatever operating system) must be in the first 1024 cylinders of a disk. Only 10 bits are available to encode the cylinder number. For the number of sectors the limit is 64 (0-63). When you combine the 1024 cylinder limit with the 16 head limit (also a design feature) you max out at fairly limited disk sizes. To work around this problem, the manufacturers of ESDI PC controllers added a BIOS prom extension on their boards. This BIOS extension handles disk I/O for booting (and for some operating systems all disk I/O) by using translation. For instance, a big drive might be presented to the system as having 32 heads and 64 sectors/track. The result is that the number of cylinders is reduced to something below 1024 and is therefore usable by the system without problems. It is noteworthy to know that FreeBSD does not use the BIOS after its kernel has started. More on this later. A second reason for translations is the fact that most older system BIOSes could only handle drives with 17 sectors per track (the old ST412 standard). Newer system BIOSes usually have a user-defined drive type (in most cases this is drive type 47). Whatever you do to translations after reading this document, keep in mind that if you have multiple operating systems on the same disk, all must use the same translation While on the subject of translations, I have seen one controller type (but there are probably more like this) offer the option to logically split a drive in multiple partitions as a BIOS option. I had select 1 drive == 1 partition because this controller wrote this info onto the disk. On power-up it read the info and presented itself to the system based on the info from the disk. Spare sectoring Most ESDI controllers offer the possibility to remap bad sectors. During/after the low-level format of the disk bad sectors are marked as such, and a replacement sector is put in place (logically of course) of the bad one. In most cases the remapping is done by using N-1 sectors on each track for actual data storage, and sector N itself is the spare sector. N is the total number of sectors physically available on the track. The idea behind this is that the operating system sees a 'perfect' disk without bad sectors. In the case of FreeBSD this concept is not usable. The problem is that the translation from bad to good is performed by the BIOS of the ESDI controller. FreeBSD, being a true 32 bit operating system, does not use the BIOS after it has been booted. Instead, it has device drivers that talk directly to the hardware. So: don't use spare sectoring, bad block remapping or whatever it may be called by the controller manufacturer when you want to use the disk for FreeBSD. Bad block handling The preceding section leaves us with a problem. The controller's bad block handling is not usable and still FreeBSD's filesystems assume perfect media without any flaws. To solve this problem, FreeBSD use the bad144 tool. Bad144 (named after a Digital Equipment standard for bad block handling) scans a FreeBSD slice for bad blocks. Having found these bad blocks, it writes a table with the offending block numbers to the end of the FreeBSD slice. When the disk is in operation, the disk accesses are checked against the table read from the disk. Whenever a block number is requested that is in the bad144 list, a replacement block (also from the end of the FreeBSD slice) is used. In this way, the bad144 replacement scheme presents 'perfect' media to the FreeBSD filesystems. There are a number of potential pitfalls associated with the use of bad144. First of all, the slice cannot have more than 126 bad sectors. If your drive has a high number of bad sectors, you might need to divide it into multiple FreeBSD slices each containing less than 126 bad sectors. Stay away from low-level format programs that mark every sector of a track as bad when they find a flaw on the track. As you can imagine, the 126 limit is quickly reached when the low-level format is done this way. Second, if the slice contains the root filesystem, the slice should be within the 1024 cylinder BIOS limit. During the boot process the bad144 list is read using the BIOS and this only succeeds when the list is within the 1024 cylinder limit. The restriction is not that only the root filesystem must be within the 1024 cylinder limit, but rather the entire slice that contains the root filesystem. Kernel configuration ESDI disks are handled by the same wddriver as IDE and ST412 MFM disks. The wd driver should work for all WD1003 compatible interfaces. Most hardware is jumperable for one of two different I/O address ranges and IRQ lines. This allows you to have two wd type controllers in one system. When your hardware allows non-standard strappings, you can use these with FreeBSD as long as you enter the correct info into the kernel config file. An example from the kernel config file (they live in /sys/i386/conf BTW). # First WD compatible controller controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 # Second WD compatible controller controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 Particulars on ESDI hardware Adaptec 2320 controllers I successfully installed FreeBSD onto a ESDI disk controlled by a ACB-2320. No other operating system was present on the disk. To do so I low level formatted the disk using NEFMT.EXE (ftpable from www.adaptec.com) and answered NO to the question whether the disk should be formatted with a spare sector on each track. The BIOS on the ACD-2320 was disabled. I used the free configurable option in the system BIOS to allow the BIOS to boot it. Before using NEFMT.EXE I tried to format - the disk using the ACB-2320 BIOS builtin formatter. This proved + the disk using the ACB-2320 BIOS built-in formatter. This proved to be a show stopper, because it did not give me an option to disable spare sectoring. With spare sectoring enabled the FreeBSD installation process broke down on the bad144 run. Please check carefully which ACB-232xy variant you have. The x is either 0 or 2, indicating a controller without or with a floppy controller on board. The y is more interesting. It can either be a blank, a A-8 or a D. A blank indicates a plain 10 Mbits/second controller. An A-8 indicates a 15 Mbits/second controller capable of handling 52 sectors/track. A D means a 15 Mbits/second controller that can also handle drives with > 36 sectors/track (also 52 ?). All variations should be capable of using 1:1 interleaving. Use 1:1, FreeBSD is fast enough to handle it. Western Digital WD1007 controllers I successfully installed FreeBSD onto a ESDI disk controlled by a WD1007 controller. To be precise, it was a WD1007-WA2. Other variations of the WD1007 do exist. To get it to work, I had to disable the sector translation and the WD1007's onboard BIOS. This implied I could not use the low-level formatter built into this BIOS. Instead, I grabbed WDFMT.EXE from www.wdc.com Running this formatted my drive just fine. Ultrastor U14F controllers According to multiple reports from the net, Ultrastor ESDI boards work OK with FreeBSD. I lack any further info on particular settings. Further reading If you intend to do some serious ESDI hacking, you might want to have the official standard at hand: The latest ANSI X3T10 committee document is: Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11] On Usenet the newsgroup comp.periphs is a noteworthy place to look for more info. The World Wide Web (WWW) also proves to be a very handy info source: For info on Adaptec ESDI controllers see http://www.adaptec.com/. For info on Western Digital controllers see http://www.wdc.com/. Thanks to... Andrew Gordon for sending me an Adaptec 2320 controller and ESDI disk for testing. What is SCSI? Copyright © 1995, &a.wilko;. July 6, 1996. SCSI is an acronym for Small Computer Systems Interface. It is an ANSI standard that has become one of the leading I/O buses in the computer industry. The foundation of the SCSI standard was laid by Shugart Associates (the same guys that gave the world the first mini floppy disks) when they introduced the SASI bus (Shugart Associates Standard Interface). After some time an industry effort was started to come to a more strict standard allowing devices from different vendors to work together. This effort was recognized in the ANSI SCSI-1 standard. - The SCSI-1 standard (approx 1985) is rapidly becoming obsolete. The + The SCSI-1 standard (approximately 1985) is rapidly becoming obsolete. The current standard is SCSI-2 (see Further reading), with SCSI-3 on the drawing boards. In addition to a physical interconnection standard, SCSI defines a logical (command set) standard to which disk devices must adhere. This standard is called the Common Command Set (CCS) and was developed more or less in parallel with ANSI SCSI-1. SCSI-2 includes the (revised) CCS as part of the standard itself. The commands are dependent on the type of device at hand. It does not make much sense of course to define a Write command for a scanner. The SCSI bus is a parallel bus, which comes in a number of variants. The oldest and most used is an 8 bit wide bus, with single-ended signals, carried on 50 wires. (If you do not know what single-ended means, do not worry, that is what this document is all about.) Modern designs also use 16 bit wide buses, with differential signals. This allows transfer speeds of 20Mbytes/second, on cables lengths of up to 25 meters. SCSI-2 allows a maximum bus width of 32 bits, using an additional cable. Quickly emerging are Ultra SCSI (also called Fast-20) and Ultra2 (also called Fast-40). Fast-20 is 20 million transfers per second (20 Mbytes/sec on a 8 bit bus), Fast-40 is 40 million transfers per second (40 Mbytes/sec on a 8 bit bus). Most hard drives sold today are single-ended Ultra SCSI (8 or 16 bits). Of course the SCSI bus not only has data lines, but also a number of control signals. A very elaborate protocol is part of the standard to allow multiple devices to share the bus in an efficient manner. In SCSI-2, the data is always checked using a separate parity line. In pre-SCSI-2 designs parity was optional. In SCSI-3 even faster bus types are introduced, along with a serial SCSI busses that reduces the cabling overhead and allows a higher maximum bus length. You might see names like SSA and - Fiberchannel in this context. None of the serial buses are currently + fibre channel in this context. None of the serial buses are currently in widespread use (especially not in the typical FreeBSD environment). For this reason the serial bus types are not discussed any further. As you could have guessed from the description above, SCSI devices are intelligent. They have to be to adhere to the SCSI standard (which is over 2 inches thick BTW). So, for a hard disk drive for instance you do not specify a head/cylinder/sector to address a particular block, but simply the number of the block you want. Elaborate caching schemes, automatic bad block replacement etc are all made possible by this 'intelligent device' approach. On a SCSI bus, each possible pair of devices can communicate. Whether their function allows this is another matter, but the standard does not restrict it. To avoid signal contention, the 2 devices have to arbitrate for the bus before using it. The philosophy of SCSI is to have a standard that allows older-standard devices to work with newer-standard ones. So, an old SCSI-1 device should normally work on a SCSI-2 bus. I say Normally, because it is not absolutely sure that the implementation of an old device follows the (old) standard closely enough to be acceptable on a new bus. Modern devices are usually more well-behaved, because the standardization has become more strict and is better adhered to by the device manufacturers. Generally speaking, the chances of getting a working set of devices on a single bus is better when all the devices are SCSI-2 or newer. This implies that you do not have to dump all your old stuff when you get that shiny 2GB disk: I own a system on which a pre-SCSI-1 disk, a SCSI-2 QIC tape unit, a SCSI-1 helical scan tape unit and 2 SCSI-1 disks work together quite happily. From a performance standpoint you might want to separate your older and newer (=faster) devices however. Components of SCSI As said before, SCSI devices are smart. The idea is to put the knowledge about intimate hardware details onto the SCSI device itself. In this way, the host system does not have to worry about things like how many heads are hard disks has, or how many tracks there are on a specific tape device. If you are curious, the standard specifies commands with which you can query your devices on their hardware particulars. FreeBSD uses this capability during boot to check out what devices are connected and whether they need any special treatment. The advantage of intelligent devices is obvious: the device drivers on the host can be made in a much more generic fashion, there is no longer a need to change (and qualify!) drivers for every odd new device that is introduced. For cabling and connectors there is a golden rule: get good stuff. With bus speeds going up all the time you will save yourself a lot of grief by using good material. So, gold plated connectors, shielded cabling, sturdy connector hoods with strain reliefs etc are the way to go. Second golden rule: do no use cables longer than necessary. I once spent 3 days hunting down a problem with a flaky machine only to discover that shortening the SCSI bus by 1 meter solved the problem. And the original bus length was well within the SCSI specification. SCSI bus types From an electrical point of view, there are two incompatible bus types: single-ended and differential. This means that there are two different main groups of SCSI devices and controllers, which cannot be mixed on the same bus. It is possible however to use special converter hardware to transform a single-ended bus into a differential one (and vice versa). The differences between the bus types are explained in the next sections. In lots of SCSI related documentation there is a sort of jargon in use to abbreviate the different bus types. A small list: FWD: Fast Wide Differential FND: Fast Narrow Differential SE: Single Ended FN: Fast Narrow etc. With a minor amount of imagination one can usually imagine what is meant. Wide is a bit ambiguous, it can indicate 16 or 32 bit buses. As far as I know, the 32 bit variant is not (yet) in use, so wide normally means 16 bit. Fast means that the timing on the bus is somewhat different, so that on a narrow (8 bit) bus 10 Mbytes/sec are possible instead of 5 Mbytes/sec for 'slow' SCSI. As discussed before, bus speeds of 20 and 40 million transfers/second are also emerging (Fast-20 == Ultra SCSI and Fast-40 == Ultra2 SCSI). The data lines > 8 are only used for data transfers and device addressing. The transfers of commands and status messages etc are only performed on the lowest 8 data lines. The standard allows narrow devices to operate on a wide bus. The usable bus width is negotiated between the devices. You have to watch your device addressing closely when mixing wide and narrow. Single ended buses A single-ended SCSI bus uses signals that are either 5 Volts or 0 Volts (indeed, TTL levels) and are relative to a COMMON ground reference. A singled ended 8 bit SCSI bus has approximately 25 ground lines, who are all tied to a single `rail' on all devices. A standard single ended bus has a maximum length of 6 meters. If the same bus is used with fast-SCSI devices, the maximum length allowed drops to 3 meters. Fast-SCSI means that instead of 5Mbytes/sec the bus allows 10Mbytes/sec transfers. Fast-20 (Ultra SCSI) and Fast-40 allow for 20 and 40 million transfers/second respectively. So, F20 is 20 Mbytes/second on a 8 bit bus, 40 Mbytes/second on a 16 bit bus etc. For F20 the max bus length is 1.5 meters, for F40 it becomes 0.75 meters. Be aware that F20 is pushing the limits quite a bit, so you will quickly find out if your SCSI bus is electrically sound. If some devices on your bus use 'fast' to communicate your bus must adhere to the length restrictions for fast buses! It is obvious that with the newer fast-SCSI devices the bus length can become a real bottleneck. This is why the differential SCSI bus was introduced in the SCSI-2 standard. For connector pinning and connector types please refer to the SCSI-2 standard (see Further reading) itself, connectors etc are listed there in painstaking detail. Beware of devices using non-standard cabling. For instance Apple uses a 25pin D-type connecter (like the one on serial ports and parallel printers). Considering that the official SCSI bus needs 50 pins you can imagine the use of this connector needs some 'creative cabling'. The reduction of the number of ground wires they used is a bad idea, you better stick to 50 pins cabling in accordance with the SCSI standard. For Fast-20 and 40 do not even think about buses like this. Differential buses A differential SCSI bus has a maximum length of 25 meters. Quite a difference from the 3 meters for a single-ended fast-SCSI bus. The idea behind differential signals is that each bus signal has its own return wire. So, each signal is carried on a (preferably twisted) pair of wires. The voltage difference between these two wires determines whether the signal is asserted or de-asserted. To a certain extent the voltage difference between ground and the signal wire pair is not relevant (do not try 10 kVolts though). It is beyond the scope of this document to explain why this differential idea is so much better. Just accept that electrically seen the use of differential signals gives a much better noise margin. You will normally find differential buses in use for inter-cabinet connections. Because of the lower cost single ended is mostly used for shorter buses like inside cabinets. There is nothing that stops you from using differential stuff with FreeBSD, as long as you use a controller that has device driver support in FreeBSD. As an example, Adaptec marketed the AHA1740 as a single ended board, whereas the AHA1744 was differential. The software interface to the host is identical for both. Terminators Terminators in SCSI terminology are resistor networks that are used to get a correct impedance matching. Impedance matching is important to get clean signals on the bus, without reflections or ringing. If you once made a long distance telephone call on a bad line you probably know what reflections are. With 20Mbytes/sec traveling over your SCSI bus, you do not want signals echoing back. Terminators come in various incarnations, with more or less sophisticated designs. Of course, there are internal and external variants. Many SCSI devices come with a number of sockets in which a number of resistor networks can (must be!) installed. If you remove terminators from a device, carefully store them. You will need them when you ever decide to reconfigure your SCSI bus. There is enough variation in even these simple tiny things to make finding the exact replacement a frustrating business. There are also SCSI devices that have a single jumper to enable or disable a built-in terminator. There are special terminators you can stick onto a flat cable bus. Others look like external connectors, or a connector hood without a cable. So, lots of choice as you can see. There is much debate going on if and when you should switch from simple resistor (passive) terminators to active terminators. Active terminators contain slightly more elaborate circuit to give cleaner bus signals. The general consensus seems to be that the usefulness of active termination increases when you have long buses and/or fast devices. If you ever have problems with your SCSI buses you might consider trying an active terminator. Try to borrow one first, they reputedly are quite expensive. Please keep in mind that terminators for differential and single-ended buses are not identical. You should not mix the two variants. OK, and now where should you install your terminators? This is by far the most misunderstood part of SCSI. And it is by far the simplest. The rule is: every single line on the SCSI bus has 2 (two) terminators, one at each end of the bus. So, two and not one or three or whatever. Do yourself a favor and stick to this rule. It will save you endless grief, because wrong termination has the potential to introduce highly mysterious bugs. (Note the potential here; the nastiest part is that it may or may not work.) A common pitfall is to have an internal (flat) cable in a machine and also an external cable attached to the controller. It seems almost everybody forgets to remove the terminators from the controller. The terminator must now be on the last external device, and not on the controller! In general, every reconfiguration of a SCSI bus must pay attention to this. Termination is to be done on a per-line basis. This means if you have both narrow and wide buses connected to the same host adapter, you need to enable termination on the higher 8 bits of the bus on the adapter (as well as the last devices on each bus, of course). What I did myself is remove all terminators from my SCSI devices and controllers. I own a couple of external terminators, for both the Centronics-type external cabling and for the internal flat cable connectors. This makes reconfiguration much easier. On modern devices, sometimes integrated terminators are used. These things are special purpose integrated circuits that can be - dis/en-abled with a control pin. It is not necessary to + enabled or disabled with a control pin. It is not necessary to physically remove them from a device. You may find them on newer host adapters, sometimes they are software configurable, using some sort of setup tool. Some will even auto-detect the cables attached to the connectors and automatically set up the termination as necessary. At any rate, consult your documentation! Terminator power The terminators discussed in the previous chapter need power to operate properly. On the SCSI bus, a line is dedicated to this purpose. So, simple huh? Not so. Each device can provide its own terminator power to the terminator sockets it has on-device. But if you have external terminators, or when the device supplying the terminator power to the SCSI bus line is switched off you are in trouble. The idea is that initiators (these are devices that initiate actions on the bus, a discussion follows) must supply terminator power. All SCSI devices are allowed (but not required) to supply terminator power. To allow for un-powered devices on a bus, the terminator power must be supplied to the bus via a diode. This prevents the backflow of current to un-powered devices. To prevent all kinds of nastiness, the terminator power is usually fused. As you can imagine, fuses might blow. This can, but does not have to, lead to a non functional bus. If multiple devices supply terminator power, a single blown fuse will not put you out of business. A single supplier with a blown fuse certainly will. Clever external terminators sometimes have a LED indication that shows whether terminator power is present. In newer designs auto-restoring fuses that 'reset' themselves after some time are sometimes used. Device addressing Because the SCSI bus is, ehh, a bus there must be a way to distinguish or address the different devices connected to it. This is done by means of the SCSI or target ID. Each device has a unique target ID. You can select the ID to which a device must respond using a set of jumpers, or a dip switch, or something similar. Some SCSI host adapters let you change the target ID from the boot menu. (Yet some others will not let you change the ID from 7.) Consult the documentation of your device for more information. Beware of multiple devices configured to use the same ID. Chaos normally reigns in this case. A pitfall is that one of the devices sharing the same ID sometimes even manages to answer to I/O requests! For an 8 bit bus, a maximum of 8 targets is possible. The maximum is 8 because the selection is done bitwise using the 8 data lines on the bus. For wide buses this increases to the number of data lines (usually 16). A narrow SCSI device can not communicate with a SCSI device with a target ID larger than 7. This means it is generally not a good idea to move your SCSI host adapter's target ID to - something higher than 7 (or your CD-ROM will stop + something higher than 7 (or your CDROM will stop working). The higher the SCSI target ID, the higher the priority the devices has. When it comes to arbitration between devices that want to use the bus at the same time, the device that has the highest SCSI ID will win. This also means that the SCSI host adapter usually uses target ID 7. Note however that the lower 8 IDs have higher priorities than the higher 8 IDs on a wide-SCSI bus. Thus, the order of target IDs is: [7 6 .. 1 0 15 14 .. 9 8] on a wide-SCSI system. (If you you are wondering why the lower 8 have higher priority, read the previous paragraph for a hint.) For a further subdivision, the standard allows for Logical Units or LUNs for short. A single target ID may have multiple LUNs. For example, a tape device including a tape changer may have LUN 0 for the tape device itself, and LUN 1 for the tape changer. In this way, the host system can address each of the functional units of the tape changer as desired. Bus layout SCSI buses are linear. So, not shaped like Y-junctions, star topologies, rings, cobwebs or whatever else people might want to invent. One of the most common mistakes is for people with wide-SCSI host adapters to connect devices on all three connecters (external connector, internal wide connector, internal narrow connector). Don't do that. It may appear to work if you are really lucky, but I can almost guarantee that your system will stop functioning at the most unfortunate moment (this is also known as Murphy's law). You might notice that the terminator issue discussed earlier becomes rather hairy if your bus is not linear. Also, if you have more connectors than devices on your internal SCSI cable, make sure you attach devices on connectors on both ends instead of using the connectors in the middle and let one or both ends dangle. This will screw up the termination of the bus. The electrical characteristics, its noise margins and ultimately the reliability of it all are tightly related to linear bus rule. Stick to the linear bus rule! Using SCSI with FreeBSD About translations, BIOSes and magic... As stated before, you should first make sure that you have a electrically sound bus. When you want to use a SCSI disk on your PC as boot disk, you must aware of some quirks related to PC BIOSes. The PC BIOS in its first incarnation used a low level physical interface to the hard disk. So, you had to tell the BIOS (using a setup tool or a BIOS built-in setup) how your disk physically looked like. This involved stating number of heads, number of cylinders, number of sectors per track, obscure things like precompensation and reduced write current cylinder etc. One might be inclined to think that since SCSI disks are smart you can forget about this. Alas, the arcane setup issue is still present today. The system BIOS needs to know how to access your SCSI disk with the head/cyl/sector method in order to load the FreeBSD kernel during boot. The SCSI host adapter or SCSI controller you have put in your AT/EISA/PCI/whatever bus to connect your disk therefore has its own on-board BIOS. During system startup, the SCSI BIOS takes over the hard disk interface routines from the system BIOS. To fool the system BIOS, the system setup is normally set to No hard disk present. Obvious, isn't it? The SCSI BIOS itself presents to the system a so called translated drive. This means that a fake drive table is constructed that allows the PC to boot the drive. This translation is often (but not always) done using a pseudo drive with 64 heads and 32 sectors per track. By varying the number of cylinders, the SCSI BIOS adapts to the actual drive size. It is useful to note that 32 * 64 / 2 = the size of your drive in megabytes. The division by 2 is to get from disk blocks that are normally 512 bytes in size to Kbytes. Right. All is well now?! No, it is not. The system BIOS has another quirk you might run into. The number of cylinders of a bootable hard disk cannot be greater than 1024. Using the translation above, this is a show-stopper for disks greater than 1 GB. With disk capacities going up all the time this is causing problems. Fortunately, the solution is simple: just use another translation, e.g. with 128 heads instead of 32. In most cases new SCSI BIOS versions are available to upgrade older SCSI host adapters. Some newer adapters have an option, in the form of a jumper or software setup selection, to switch the translation the SCSI BIOS uses. It is very important that all operating systems on the disk use the same translation to get the right idea about where to find the relevant partitions. So, when installing FreeBSD you must answer any questions about heads/cylinders etc using the translated values your host adapter uses. Failing to observe the translation issue might lead to un-bootable systems or operating systems overwriting each others partitions. Using fdisk you should be able to see all partitions. You might have heard some talk of lying devices? Older FreeBSD kernels used to report the geometry of SCSI disks when booting. An example from one of my systems: aha0 targ 0 lun 0: <MICROP 1588-15MB1057404HSP4> sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512 Newer kernels usually do not report this information. e.g. (bt0:0:0): "SEAGATE ST41651 7574" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors) Why has this changed? This info is retrieved from the SCSI disk itself. Newer disks often use a technique called zone bit recording. The idea is that on the outer cylinders of the drive there is more space so more sectors per track can be put on them. This results in disks that have more tracks on outer cylinders than on the inner cylinders and, last but not least, have more capacity. You can imagine that the value reported by the drive when inquiring about the geometry now becomes suspect at best, and nearly always misleading. When asked for a geometry , it is nearly always better to supply the geometry used by the BIOS, or if the BIOS is never going to know about this disk, (e.g. it is not a booting disk) to supply a fictitious geometry that is convenient. SCSI subsystem design FreeBSD uses a layered SCSI subsystem. For each different controller card a device driver is written. This driver knows all the intimate details about the hardware it controls. The driver has a interface to the upper layers of the SCSI subsystem through which it receives its commands and reports back any status. On top of the card drivers there are a number of more generic drivers for a class of devices. More specific: a driver for tape - devices (abbreviation: st), magnetic disks (sd), CD-ROMs (cd) etc. + devices (abbreviation: st), magnetic disks (sd), CDROMs (cd) etc. In case you are wondering where you can find this stuff, it all lives in /sys/scsi. See the man pages in section 4 for more details. The multi level design allows a decoupling of low-level bit banging and more high level stuff. Adding support for another piece of hardware is a much more manageable problem. Kernel configuration Dependent on your hardware, the kernel configuration file must contain one or more lines describing your host adapter(s). This includes I/O addresses, interrupts etc. Consult the man page for your adapter driver to get more info. Apart from that, check out /sys/i386/conf/LINT for an overview of a kernel config file. LINT contains every possible option you can dream of. It does not imply LINT will actually get you to a working kernel at all. Although it is probably stating the obvious: the kernel config file should reflect your actual hardware setup. So, interrupts, I/O addresses etc must match the kernel config file. During system boot messages will be displayed to indicate whether the configured hardware was actually found. Note that most of the EISA/PCI drivers (namely ahb, ahc, ncr and amd will automatically obtain the correct parameters from the host adapters themselves at boot time; thus, you just need to write, for instance, controller ahc0. An example loosely based on the FreeBSD 2.2.5-Release kernel config file LINT with some added comments (between []): # SCSI host adapters: `aha', `ahb', `aic', `bt', `nca' # # aha: Adaptec 154x # ahb: Adaptec 174x # ahc: Adaptec 274x/284x/294x # aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!) # amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T) # bt: Most Buslogic controllers # nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130 # ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards # uha: UltraStore 14F and 34F # sea: Seagate ST01/02 8 bit controller (slow!) # wds: Western Digital WD7000 controller (no scatter/gather!). # [For an Adaptec AHA274x/284x/294x/394x etc controller] controller ahc0 [For an NCR/Symbios 53c875 based controller] controller ncr0 [For an Ultrastor adapter] controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr # Map SCSI buses to specific SCSI adapters controller scbus0 at ahc0 controller scbus2 at ncr0 controller scbus1 at uha0 # The actual SCSI devices disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0] disk sd1 at scbus0 target 1 [implicit LUN 0 if omitted] disk sd2 at scbus1 target 3 [SCSI disk on the uha0] disk sd3 at scbus2 target 4 [SCSI disk on the ncr0] tape st1 at scbus0 target 6 [SCSI tape at target 6] -device cd0 at scbus? [the first ever CD-ROM found, no wiring] +device cd0 at scbus? [the first ever CDROM found, no wiring] The example above tells the kernel to look for a ahc (Adaptec 274x) controller, then for an NCR/Symbios board, and so on. The lines following the controller specifications tell the kernel to configure specific devices but only attach them when they match the target ID and LUN specified on the corresponding bus. Wired down devices get first shot at the unit numbers so the first non wired down device, is allocated the unit number one greater than the highest wired down unit number for that kind of device. So, if you had a SCSI tape at target ID 2 it would be configured as st2, as the tape at target ID 6 is wired down to unit number 1. Wired down devices need not be found to get their unit number. The unit number for a wired down device is reserved for that device, even if it is turned off at boot time. This allows the device to be turned on and brought on-line at a later time, without rebooting. Notice that a device's unit number has no relationship with its target ID on the SCSI bus. Below is another example of a kernel config file as used by FreeBSD version < 2.0.5. The difference with the first example is that devices are not wired down. Wired down means that you specify which SCSI target belongs to which device. A kernel built to the config file below will attach the first SCSI disk it finds to sd0, the second disk to sd1 etc. If you ever removed or added a disk, all other devices of the same type (disk in this case) would 'move around'. This implies you have to change /etc/fstab each time. Although the old style still works, you are strongly recommended to use this new feature. It will save you a lot of grief whenever you shift your hardware around on the SCSI buses. So, when you re-use your old trusty config file after upgrading from a pre-FreeBSD2.0.5.R system check this out. [driver for Adaptec 174x] controller ahb0 at isa? bio irq 11 vector ahbintr [for Adaptec 154x] controller aha0 at isa? port "IO_AHA0" bio irq 11 drq 5 vector ahaintr [for Seagate ST01/02] controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 device sd0 [support for 4 SCSI harddisks, sd0 up sd3] device st0 [support for 2 SCSI tapes] -[for the CD-ROM] +[for the CDROM] device cd0 #Only need one of these, the code dynamically grows Both examples support SCSI disks. If during boot more devices of a specific type (e.g. sd disks) are found than are configured in the booting kernel, the system will simply allocate more devices, incrementing the unit number starting at the last number wired down. If there are no wired down devices then counting starts at unit 0. Use man 4 scsi to check for the latest info on the SCSI subsystem. For more detailed info on host adapter - drivers use eg man 4 ahc for info on the + drivers use e.g., man 4 ahc for info on the Adaptec 294x driver. Tuning your SCSI kernel setup Experience has shown that some devices are slow to respond to INQUIRY commands after a SCSI bus reset (which happens at boot time). An INQUIRY command is sent by the kernel on boot to see - what kind of device (disk, tape, CD-ROM etc) is connected to a + what kind of device (disk, tape, CDROM etc.) is connected to a specific target ID. This process is called device probing by the way. To work around the 'slow response' problem, FreeBSD allows a tunable delay time before the SCSI devices are probed following a SCSI bus reset. You can set this delay time in your kernel configuration file using a line like: options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device This line sets the delay time to 15 seconds. On my own system - I had to use 3 seconds minimum to get my trusty old CD-ROM drive + I had to use 3 seconds minimum to get my trusty old CDROM drive to be recognized. Start with a high value (say 30 seconds or so) when you have problems with device recognition. If this helps, tune it back until it just stays working. Rogue SCSI devices Although the SCSI standard tries to be complete and concise, it is a complex standard and implementing things correctly is no easy task. Some vendors do a better job then others. This is exactly where the rogue devices come into view. Rogues are devices that are recognized by the FreeBSD kernel as behaving slightly (...) non-standard. Rogue devices are reported by the kernel when booting. An example for two of my cartridge tape units: Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600 -06:> Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005> Mar 29 21:16:37 yedi /kernel: st1: Archive Viper 150 is a known rogue For instance, there are devices that respond to all LUNs on a certain target ID, even if they are actually only one device. It is easy to see that the kernel might be fooled into believing that there are 8 LUNs at that particular target ID. The confusion this causes is left as an exercise to the reader. The SCSI subsystem of FreeBSD recognizes devices with bad habits by looking at the INQUIRY response they send when probed. Because the INQUIRY response also includes the version number of the device firmware, it is even possible that for different firmware versions different workarounds are used. See e.g. /sys/scsi/st.c and /sys/scsi/scsiconf.c for more info on how this is done. This scheme works fine, but keep in mind that it of course only works for devices that are known to be weird. If you are the - first to connect your bogus Mumbletech SCSI CD-ROM you might be + first to connect your bogus Mumbletech SCSI CDROM you might be the one that has to define which workaround is needed. After you got your Mumbletech working, please send the required workaround to the FreeBSD development team for inclusion in the next release of FreeBSD. Other Mumbletech owners will be grateful to you. Multiple LUN devices In some cases you come across devices that use multiple logical units (LUNs) on a single SCSI ID. In most cases FreeBSD only probes devices for LUN 0. An example are so called bridge boards that connect 2 non-SCSI harddisks to a SCSI bus (e.g. an Emulex MD21 found in old Sun systems). This means that any devices with LUNs != 0 are not normally found during device probe on system boot. To work around this problem you must add an appropriate entry in /sys/scsi/scsiconf.c and rebuild your kernel. Look for a struct that is initialized like below: { T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", "mx1", SC_ONE_LU } For you Mumbletech BRIDGE2000 that has more than one LUN, acts as a SCSI disk and has firmware revision 123 you would add something like: { T_DIRECT, T_FIXED, "MUMBLETECH", "BRIDGE2000", "123", "sd", SC_MORE_LUS } The kernel on boot scans the inquiry data it receives against the table and acts accordingly. See the source for more info. - Tagged command queueing + Tagged command queuing Modern SCSI devices, particularly magnetic disks, support what is called tagged command queuing (TCQ). In a nutshell, TCQ allows the device to have multiple I/O requests outstanding at the same time. Because the device is - intelligent, it can optimise its operations (like head + intelligent, it can optimize its operations (like head positioning) based on its own request queue. On SCSI devices like RAID (Redundant Array of Independent Disks) arrays the TCQ function is indispensable to take advantage of the device's inherent parallelism. Each I/O request is uniquely identified by a tag (hence the name tagged command queuing) and this tag is used by FreeBSD to see which I/O in the device drivers queue is reported as complete by the device. It should be noted however that TCQ requires device driver support and that some devices implemented it not quite right in their firmware. This problem bit me once, and it leads to highly mysterious problems. In such cases, try to disable TCQ. Busmaster host adapters Most, but not all, SCSI host adapters are bus mastering controllers. This means that they can do I/O on their own without putting load onto the host CPU for data movement. This is of course an advantage for a multitasking operating system like FreeBSD. It must be noted however that there might be some rough edges. For instance an Adaptec 1542 controller can be set to use different transfer speeds on the host bus (ISA or AT in this case). The controller is settable to different rates because not all motherboards can handle the higher speeds. Problems like - hangups, bad data etc might be the result of using a higher data + hang-ups, bad data etc might be the result of using a higher data transfer rate then your motherboard can stomach. The solution is of course obvious: switch to a lower data transfer rate and try if that works better. In the case of a Adaptec 1542, there is an option that can be put into the kernel config file to allow dynamic determination of the right, read: fastest feasible, transfer rate. This option is disabled by default: options "TUNE_1542" #dynamic tune of bus DMA speed Check the man pages for the host adapter that you use. Or better still, use the ultimate documentation (read: driver source). Tracking down problems The following list is an attempt to give a guideline for the most common SCSI problems and their solutions. It is by no means complete. Check for loose connectors and cables. Check and double check the location and number of your terminators. Check if your bus has at least one supplier of terminator power (especially with external terminators. Check if no double target IDs are used. Check if all devices to be used are powered up. Make a minimal bus config with as little devices as possible. If possible, configure your host adapter to use slow bus speeds. Disable tagged command queuing to make things as simple as - possible (for a NCR hostadapter based system see man + possible (for a NCR host adapter based system see man ncrcontrol) If you can compile a kernel, make one with the SCSIDEBUG option, and try accessing the device with debugging turned on for that device. If your device does not even probe at startup, you may have to define the address of the device that is failing, and the desired debug level in /sys/scsi/scsidebug.h. If it probes but just does not work, you can use the &man.scsi.8; command to dynamically set a debug level to it in a running kernel (if SCSIDEBUG is defined). This will give you copious debugging output with which to confuse the gurus. See man 4 scsi for more exact information. Also look at man 8 scsi. Further reading If you intend to do some serious SCSI hacking, you might want to have the official standard at hand: Approved American National Standards can be purchased from ANSI at
13th Floor 11 West 42nd Street New York NY 10036 Sales Dept: (212) 642-4900
You can also buy many ANSI standards and most committee draft documents from Global Engineering Documents,
15 Inverness Way East Englewood CO, 80112-5704 Phone: (800) 854-7179 Outside USA and Canada: (303) 792-2181 Fax: (303) 792- 2192
Many X3T10 draft documents are available electronically on the SCSI BBS (719-574-0424) and on the ncrinfo.ncr.com anonymous ftp site. Latest X3T10 committee documents are: AT Attachment (ATA or IDE) [X3.221-1994] (Approved) ATA Extensions (ATA-2) [X3T10/948D Rev 2i] Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved) Small Computer System Interface — 2 (SCSI-2) [X3.131-1994] (Approved) SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11] Other publications that might provide you with additional information are: SCSI: Understanding the Small Computer System Interface, written by NCR Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8 Basics of SCSI, a SCSI tutorial written by Ancot Corporation Contact Ancot for availability information at: Phone: (415) 322-5322 Fax: (415) 322-0455 SCSI Interconnection Guide Book, an AMP publication (dated 4/93, Catalog 65237) that lists the various SCSI connectors and suggests cabling schemes. Available from AMP at (800) 522-6752 or (717) 564-0100 Fast Track to SCSI, A Product Guide written by Fujitsu. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X The SCSI Bench Reference, The SCSI Encyclopedia, and the SCSI Tutor, ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642 Zadian SCSI Navigator (quick ref. book) and Discover the Power of SCSI (First book along with a one-hour video and tutorial book), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800 On Usenet the newsgroups comp.periphs.scsi and comp.periphs are noteworthy places to look for more info. You can also find the SCSI-Faq there, which is posted periodically. Most major SCSI device and host adapter suppliers operate ftp sites and/or BBS systems. They may be valuable sources of information about the devices you own. * Disk/tape controllers * SCSI * IDE * Floppy Hard drives SCSI hard drives Contributed by &a.asami;. 17 February 1998. As mentioned in the SCSI section, virtually all SCSI hard drives sold today are SCSI-2 compliant and thus will work fine as long as you connect them to a supported SCSI host adapter. Most problems people encounter are either due to badly designed cabling (cable too long, star topology, etc.), insufficient termination, or defective parts. Please refer to the SCSI section first if your SCSI hard drive is not working. However, there are a couple of things you may want to take into account before you purchase SCSI hard drives for your system. Rotational speed Rotational speeds of SCSI drives sold today range from around 4,500RPM to 10,000RPM. Most of them are either 5,400RPM or 7,200RPM. Even though the 7,200RPM drives can generally transfer data faster, they run considerably hotter than their 5,400RPM counterparts. A large fraction of today's disk drive malfunctions are heat-related. If you do not have very good cooling in your PC case, you may want to stick with 5,400RPM or slower drives. Note that newer drives, with higher areal recording densities, can deliver much more bits per rotation than older ones. Today's top-of-line 5,400RPM drives can sustain a throughput comparable to 7,200RPM drives of one or two model generations ago. The number to find on the spec sheet for bandwidth is internal data (or transfer) rate. It is usually in megabits/sec so divide it by 8 and you'll get the rough approximation of how much megabytes/sec you can get out of the drive. (If you are a speed maniac and want a 10,000RPM drive for your - cute little peecee, be my guest; however, those drives become + cute little PC, be my guest; however, those drives become extremely hot. Don't even think about it if you don't have a fan blowing air directly at the drive or a properly ventilated disk enclosure.) Obviously, the latest 10,000RPM drives and 7,200RPM drives can deliver more data than the latest 5,400RPM drives, so if absolute bandwidth is the necessity for your applications, you have little choice but to get the faster drives. Also, if you need low latency, faster drives are better; not only do they usually have lower average seek times, but also the rotational delay is one place where slow-spinning drives can never beat a faster one. (The average rotational latency is half the time it takes to rotate the drive once; thus, it's 3 milliseconds for 10,000RPM drives, 4.2ms for 7,200RPM drives and 5.6ms for 5,400RPM drives.) Latency is seek time plus rotational delay. Make sure you understand whether you need low latency or more accesses per second, though; in the latter case (e.g., news servers), it may not be optimal to purchase one big fast drive. You can achieve similar or even better results by using the ccd (concatenated disk) driver to create a striped disk array out of multiple slower drives for comparable overall cost. Make sure you have adequate air flow around the drive, especially if you are going to use a fast-spinning drive. You generally need at least 1/2" (1.25cm) of spacing above and below a drive. Understand how the air flows through your PC case. Most cases have the power supply suck the air out of the back. See where the air flows in, and put the drive where it will have the largest volume of cool air flowing around it. You may need to seal some unwanted holes or add a new fan for effective cooling. Another consideration is noise. Many 7,200 or faster drives generate a high-pitched whine which is quite unpleasant to most people. That, plus the extra fans often required for cooling, may make 7,200 or faster drives unsuitable for some office and home environments. Form factor Most SCSI drives sold today are of 3.5" form factor. They come in two different heights; 1.6" (half-height) or 1" (low-profile). The half-height drive is the same - height as a CD-ROM drive. However, don't forget the spacing rule + height as a CDROM drive. However, don't forget the spacing rule mentioned in the previous section. If you have three standard 3.5" drive bays, you will not be able to put three half-height drives in there (without frying them, that is). Interface The majority of SCSI hard drives sold today are Ultra or Ultra-wide SCSI. The maximum bandwidth of Ultra SCSI is 20MB/sec, and Ultra-wide SCSI is 40MB/sec. There is no difference in max cable length between Ultra and Ultra-wide; however, the more devices you have on the same bus, the sooner you will start having bus integrity problems. Unless you have a well-designed disk enclosure, it is not easy to make more than 5 or 6 Ultra SCSI drives work on a single bus. On the other hand, if you need to connect many drives, going for Fast-wide SCSI may not be a bad idea. That will have the same max bandwidth as Ultra (narrow) SCSI, while electronically it's much easier to get it right. My advice would be: if you want to connect many disks, get wide SCSI drives; they usually cost a little more but it may save you down the road. (Besides, if you can't afford the cost difference, you shouldn't be building a disk array.) There are two variant of wide SCSI drives; 68-pin and 80-pin SCA (Single Connector Attach). The SCA drives don't have a separate 4-pin power connector, and also read the SCSI ID settings through the 80-pin connector. If you are really serious about building a large storage system, get SCA drives and a good SCA enclosure (dual power supply with at least one extra fan). They are more electronically sound than 68-pin counterparts because there is no stub of the SCSI bus inside the disk canister as in arrays built from 68-pin drives. They are easier to install too (you just need to screw the drive in the canister, instead of trying to squeeze in your fingers in a tight place to hook up all the little cables (like the SCSI ID and disk activity LED lines). * IDE hard drives Tape drives Contributed by &a.jmb;. 2 July 1996. General tape access commands &man.mt.1; provides generic access to the tape drives. Some of the more common commands are rewind, erase, and status. See the &man.mt.1; manual page for a detailed description. Controller Interfaces There are several different interfaces that support tape drives. The interfaces are SCSI, IDE, Floppy and Parallel Port. A wide variety of tape drives are available for these interfaces. Controllers are discussed in Disk/tape controllers. SCSI drives The &man.st.4; driver provides support for 8mm (Exabyte), 4mm (DAT: Digital Audio Tape), QIC (Quarter-Inch Cartridge), DLT - (Digital Linear Tape), QIC Minicartridge and 9-track (remember the + (Digital Linear Tape), QIC Mini cartridge and 9-track (remember the big reels that you see spinning in Hollywood computer rooms) tape drives. See the &man.st.4; manual page for a detailed description. The drives listed below are currently being used by members of the FreeBSD community. They are not the only drives that will work with FreeBSD. They just happen to be the ones that we use. 4mm (DAT: Digital Audio Tape) Archive Python 28454 Archive Python 04687 HP C1533A HP C1534A HP 35450A HP 35470A HP 35480A SDT-5000 Wangtek 6200 8mm (Exabyte) EXB-8200 EXB-8500 EXB-8505 QIC (Quarter-Inch Cartridge) - Archive Ananconda + Archive Anaconda 2750 Archive Viper 60 Archive Viper 150 Archive Viper 2525 Tandberg TDC 3600 Tandberg TDC 3620 Tandberg TDC 3800 Tandberg TDC 4222 Wangtek 5525ES DLT (Digital Linear Tape) Digital TZ87 Mini-Cartridge Conner CTMS 3200 Exabyte 2501 Autoloaders/Changers Hewlett-Packard HP C1553A Autoloading DDS2 * IDE drives Floppy drives Conner 420R * Parallel port drives Detailed Information Archive Anaconda 2750 The boot message identifier for this drive is ARCHIVE ANCDA 2750 28077 -003 type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 1.35GB when using QIC-1350 tapes. This drive will read and write QIC-150 (DC6150), QIC-250 (DC6250), and QIC-525 (DC6525) tapes as well. Data transfer rate is 350kB/s using &man.dump.8;. Rates of 530kB/s have been reported when using Amanda Production of this drive has been discontinued. The SCSI bus connector on this tape drive is reversed from that on most other SCSI devices. Make sure that you have enough SCSI cable to twist the cable one-half turn before and after the Archive Anaconda tape drive, or turn your other SCSI devices upside-down. Two kernel code changes are required to use this drive. This drive will not work as delivered. If you have a SCSI-2 controller, short jumper 6. Otherwise, the drive behaves are a SCSI-1 device. When operating as a SCSI-1 device, this drive, locks the SCSI bus during some tape operations, including: fsf, rewind, and rewoffl. If you are using the NCR SCSI controllers, patch the file /usr/src/sys/pci/ncr.c (as shown below). Build and install a new kernel. *** 4831,4835 **** }; ! if (np->latetime>4) { /* ** Although we tried to wake it up, --- 4831,4836 ---- }; ! if (np->latetime>1200) { /* ** Although we tried to wake it up, Reported by: &a.jmb; Archive Python 28454 The boot message identifier for this drive is ARCHIVE Python 28454-XXX4ASB type 1 removable SCSI 2 density code 0x8c, 512-byte blocks This is a DDS-1 tape drive. Native capacity is 2.5GB on 90m tapes. Data transfer rate is XXX. This drive was repackaged by Sun Microsystems as model 595-3067. Reported by: Bob Bishop rb@gid.co.uk Throughput is in the 1.5 MByte/sec range, however this will drop if the disks and tape drive are on the same SCSI controller. Reported by: Robert E. Seastrom rs@seastrom.com Archive Python 04687 The boot message identifier for this drive is ARCHIVE Python 04687-XXX 6580 Removable Sequential Access SCSI-2 device This is a DAT-DDS-2 drive. Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Switch 4 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. Switch 4 off enables MRS, on disables MRS. Parity is controlled by switch 5. Switch 5 on to enable parity control. Compression is enabled with Switch 6 off. It is possible to override compression with the SCSI MODE SELECT command (see &man.mt.1;). Data transfer rate is 800kB/s. Archive Viper 60 The boot message identifier for this drive is ARCHIVE VIPER 60 21116 -007 type 1 removable SCSI 1 This is a QIC tape drive. Native capacity is 60MB. Data transfer rate is XXX. Production of this drive has been discontinued. Reported by: Philippe Regnauld regnauld@hsc.fr Archive Viper 150 The boot message identifier for this drive is ARCHIVE VIPER 150 21531 -004 Archive Viper 150 is a known rogue type 1 removable SCSI 1. A multitude of firmware revisions exist for this drive. Your drive may report different numbers (e.g 21247 -005. This is a QIC tape drive. Native capacity is 150/250MB. Both 150MB (DC6150) and 250MB (DC6250) tapes have the recording format. The 250MB tapes are approximately 67% longer than the 150MB tapes. This drive can read 120MB tapes as well. It can not write 120MB tapes. Data transfer rate is 100kB/s This drive reads and writes DC6150 (150MB) and DC6250 (250MB) tapes. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;). - Under FreeBSD 2.2-current, use mt blocksize + Under FreeBSD 2.2-CURRENT, use mt blocksize 512 to set the blocksize. (The particular drive had firmware revision 21247 -005. Other firmware revisions may behave differently) Previous versions of FreeBSD did not have this problem. Production of this drive has been discontinued. Reported by: Pedro A M Vazquez vazquez@IQM.Unicamp.BR - Mike Smith - msmith@atrad.adelaide.edu.au + &a.msmith; Archive Viper 2525 The boot message identifier for this drive is ARCHIVE VIPER 2525 25462 -011 type 1 removable SCSI 1 This is a QIC tape drive. Native capacity is 525MB. Data transfer rate is 180kB/s at 90 inches/sec. The drive reads QIC-525, QIC-150, QIC-120 and QIC-24 tapes. Writes QIC-525, QIC-150, and QIC-120. Firmware revisions prior to 25462 -011 are bug ridden and will not function properly. Production of this drive has been discontinued. Conner 420R The boot message identifier for this drive is Conner tape. - This is a floppy controller, minicartridge tape drive. + This is a floppy controller, mini cartridge tape drive. Native capacity is XXXX Data transfer rate is XXX The drive uses QIC-80 tape cartridges. Reported by: Mark Hannon mark@seeware.DIALix.oz.au Conner CTMS 3200 The boot message identifier for this drive is CONNER CTMS 3200 7.00 type 1 removable SCSI 2. - This is a minicartridge tape drive. + This is a mini cartridge tape drive. Native capacity is XXXX Data transfer rate is XXX The drive uses QIC-3080 tape cartridges. Reported by: Thomas S. Traylor tst@titan.cs.mci.com <ulink url="http://www.digital.com/info/Customer-Update/931206004.txt.html">DEC TZ87</ulink> The boot message identifier for this drive is DEC TZ87 (C) DEC 9206 type 1 removable SCSI 2 density code 0x19 This is a DLT tape drive. Native capacity is 10GB. This drive supports hardware data compression. Data transfer rate is 1.2MB/s. This drive is identical to the Quantum DLT2000. The drive firmware can be set to emulate several well-known drives, including an Exabyte 8mm drive. Reported by: &a.wilko; <ulink url="http://www.Exabyte.COM:80/Products/Minicartridge/2501/Rfeatures.html">Exabyte EXB-2501</ulink> The boot message identifier for this drive is EXABYTE EXB-2501 This is a mini-cartridge tape drive. Native capacity is 1GB when using MC3000XL - minicartridges. + mini cartridges. Data transfer rate is XXX This drive can read and write DC2300 (550MB), DC2750 (750MB), - MC3000 (750MB), and MC3000XL (1GB) minicartridges. + MC3000 (750MB), and MC3000XL (1GB) mini cartridges. WARNING: This drive does not meet the SCSI-2 specifications. The drive locks up completely in response to a SCSI MODE_SELECT command unless there is a formatted tape in the drive. Before using this drive, set the tape blocksize with &prompt.root; mt -f /dev/st0ctl.0 blocksize 1024 - Before using a minicartridge for the first time, the - minicartridge must be formated. FreeBSD 2.1.0-RELEASE and + Before using a mini cartridge for the first time, the + mini cartridge must be formated. FreeBSD 2.1.0-RELEASE and earlier: &prompt.root; /sbin/scsi -f /dev/rst0.ctl -s 600 -c "4 0 0 0 0 0" (Alternatively, fetch a copy of the scsiformat shell script from FreeBSD 2.1.5/2.2.) FreeBSD 2.1.5 and later: &prompt.root; /sbin/scsiformat -q -w /dev/rst0.ctl Right now, this drive cannot really be recommended for FreeBSD. Reported by: Bob Beaulieu ez@eztravel.com Exabyte EXB-8200 The boot message identifier for this drive is EXABYTE EXB-8200 252X type 1 removable SCSI 1 This is an 8mm tape drive. Native capacity is 2.3GB. Data transfer rate is 270kB/s. This drive is fairly slow in responding to the SCSI bus during boot. A custom kernel may be required (set SCSI_DELAY to 10 seconds). There are a large number of firmware configurations for this drive, some have been customized to a particular vendor's hardware. The firmware can be changed via EPROM replacement. Production of this drive has been discontinued. - Reported by: Mike Smith - msmith@atrad.adelaide.edu.au + Reported by: &a.msmith; Exabyte EXB-8500 The boot message identifier for this drive is EXABYTE EXB-8500-85Qanx0 0415 type 1 removable SCSI 2 This is an 8mm tape drive. Native capacity is 5GB. Data transfer rate is 300kB/s. Reported by: Greg Lehey grog@lemis.de <ulink url="http://www.Exabyte.COM:80/Products/8mm/8505XL/Rfeatures.html">Exabyte EXB-8505</ulink> The boot message identifier for this drive is EXABYTE EXB-85058SQANXR1 05B0 type 1 removable SCSI 2 This is an 8mm tape drive which supports compression, and is upward compatible with the EXB-5200 and EXB-8500. Native capacity is 5GB. The drive supports hardware data compression. Data transfer rate is 300kB/s. Reported by: Glen Foster gfoster@gfoster.com Hewlett-Packard HP C1533A The boot message identifier for this drive is HP C1533A 9503 type 1 removable SCSI 2. This is a DDS-2 tape drive. DDS-2 means hardware data compression and narrower tracks for increased data capacity. Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is 510kB/s. This drive is used in Hewlett-Packard's SureStore 6000eU and 6000i tape drives and C1533A DDS-2 DAT drive. The drive has a block of 8 dip switches. The proper settings for FreeBSD are: 1 ON; 2 ON; 3 OFF; 4 ON; 5 ON; 6 ON; 7 ON; 8 ON. switch 1 switch 2 Result On On Compression enabled at power-on, with host control On Off Compression enabled at power-on, no host control Off On Compression disabled at power-on, with host control Off Off Compression disabled at power-on, no host control Switch 3 controls MRS (Media Recognition System). MRS tapes have stripes on the transparent leader. These identify the tape as DDS (Digital Data Storage) grade media. Tapes that do not have the stripes will be treated as write-protected. Switch 3 OFF enables MRS. Switch 3 ON disables MRS. See HP SureStore Tape Products and Hewlett-Packard Disk and Tape Technical Information for more information on configuring this drive. Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 2 of these drives. Neither lasted more than 5 months. Reported by: &a.se; Hewlett-Packard HP 1534A The boot message identifier for this drive is HP HP35470A T503 type 1 removable SCSI 2 Sequential-Access density code 0x13, variable blocks. This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. Data transfer rate is 183kB/s. The same mechanism is used in Hewlett-Packard's SureStore 2000i tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive and HP C1536A DDS format DAT drive. The HP C1534A DDS format DAT drive has two indicator lights, one green and one amber. The green one indicates tape action: slow flash during load, steady when loaded, fast flash during read/write operations. The amber one indicates warnings: slow flash when cleaning is required or tape is nearing the end of its useful life, steady indicates an hard fault. (factory service required?) Reported by Gary Crutcher gcrutchr@nightflight.com Hewlett-Packard HP C1553A Autoloading DDS2 The boot message identifier for this drive is "". This is a DDS-2 tape drive with a tape changer. DDS-2 means hardware data compression and narrower tracks for increased data capacity. Native capacity is 24GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is 510kB/s (native). This drive is used in Hewlett-Packard's SureStore 12000e tape drive. The drive has two selectors on the rear panel. The selector closer to the fan is SCSI id. The other selector should be set to 7. There are four internal switches. These should be set: 1 ON; 2 ON; 3 ON; 4 OFF. At present the kernel drivers do not automatically change tapes at the end of a volume. This shell script can be used to change tapes: #!/bin/sh PATH="/sbin:/usr/sbin:/bin:/usr/bin"; export PATH usage() { echo "Usage: dds_changer [123456ne] raw-device-name echo "1..6 = Select cartridge" echo "next cartridge" echo "eject magazine" exit 2 } if [ $# -ne 2 ] ; then usage fi cdb3=0 cdb4=0 cdb5=0 case $1 in [123456]) cdb3=$1 cdb4=1 ;; n) ;; e) cdb5=0x80 ;; ?) usage ;; esac scsi -f $2 -s 100 -c "1b 0 0 $cdb3 $cdb4 $cdb5" Hewlett-Packard HP 35450A The boot message identifier for this drive is HP HP35450A -A C620 type 1 removable SCSI 2 Sequential-Access density code 0x13 This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 1.2GB. Data transfer rate is 160kB/s. - Reported by: mark thompson + Reported by: Mark Thompson mark.a.thompson@pobox.com Hewlett-Packard HP 35470A The boot message identifier for this drive is HP HP35470A 9 09 type 1 removable SCSI 2 This is a DDS-1 tape drive. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. Data transfer rate is 183kB/s. The same mechanism is used in Hewlett-Packard's SureStore 2000i tape drive, C35470A DDS format DAT drive, C1534A DDS format DAT drive, and HP C1536A DDS format DAT drive. Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 5 of these drives. None lasted more than 9 months. Reported by: David Dawes dawes@rf900.physics.usyd.edu.au (9 09) Hewlett-Packard HP 35480A The boot message identifier for this drive is HP HP35480A 1009 type 1 removable SCSI 2 Sequential-Access density code 0x13. This is a DDS-DC tape drive. DDS-DC is DDS-1 with hardware data compression. DDS-1 is the original DAT tape format. Native capacity is 2GB when using 90m tapes. It cannot handle 120m tapes. This drive supports hardware data compression. Please refer to the section on HP C1533A for the proper switch settings. Data transfer rate is 183kB/s. This drive is used in Hewlett-Packard's SureStore 5000eU and 5000i tape drives and C35480A DDS format DAT drive.. This drive will occasionally hang during a tape eject operation (mt offline). Pressing the front panel button will eject the tape and bring the tape drive back to life. WARNING: HP 35480-03110 only. On at least two occasions this tape drive when used with FreeBSD 2.1.0, an IBM Server 320 and an 2940W SCSI controller resulted in all SCSI disk partitions being lost. The problem has not be analyzed or resolved at this time. <ulink url="http://www.sel.sony.com/SEL/ccpg/storage/tape/t5000.html">Sony SDT-5000</ulink> There are at least two significantly different models: one is a DDS-1 and the other DDS-2. The DDS-1 version is SDT-5000 3.02. The DDS-2 version is SONY SDT-5000 327M. The DDS-2 version has a 1MB cache. This cache is able to keep the tape streaming in almost any circumstances. The boot message identifier for this drive is SONY SDT-5000 3.02 type 1 removable SCSI 2 Sequential-Access density code 0x13 Native capacity is 4GB when using 120m tapes. This drive supports hardware data compression. Data transfer rate is depends upon the model or the drive. The rate is 630kB/s for the SONY SDT-5000 327M while compressing the data. For the SONY SDT-5000 3.02, the data transfer rate is 225kB/s. In order to get this drive to stream, set the blocksize to 512 bytes (mt blocksize 512) reported by Kenneth - Merry ken@ulc199.residence.gatech.edu + Merry ken@ulc199.residence.gatech.edu. SONY SDT-5000 327M information reported by - Charles Henrich henrich@msu.edu + Charles Henrich henrich@msu.edu. Reported by: &a.jmz; Tandberg TDC 3600 The boot message identifier for this drive is TANDBERG TDC 3600 =08: type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 150/250MB. This drive has quirks which are known and work around code is present in the scsi tape device driver (&man.st.4;). Upgrading the firmware to XXX version will fix the quirks and provide SCSI 2 capabilities. Data transfer rate is 80kB/s. IBM and Emerald units will not work. Replacing the firmware EPROM of these units will solve the problem. - Reported by: Michael Smith - msmith@atrad.adelaide.edu.au + Reported by: &a.msmith; Tandberg TDC 3620 This is very similar to the Tandberg TDC 3600 drive. Reported by: &a.joerg; Tandberg TDC 3800 The boot message identifier for this drive is TANDBERG TDC 3800 =04Y Removable Sequential Access SCSI-2 device This is a QIC tape drive. Native capacity is 525MB. Reported by: &a.jhs; Tandberg TDC 4222 The boot message identifier for this drive is TANDBERG TDC 4222 =07 type 1 removable SCSI 2 This is a QIC tape drive. Native capacity is 2.5GB. The drive will read all cartridges from the 60 MB (DC600A) upwards, and write 150 MB (DC6150) upwards. Hardware compression is optionally supported for the 2.5 GB cartridges. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;) beginning with FreeBSD - 2.2-current. For previous versions of FreeBSD, use + 2.2-CURRENT. For previous versions of FreeBSD, use mt to read one block from the tape, rewind the tape, and then execute the backup program (mt fsr 1; mt rewind; dump ...) Data transfer rate is 600kB/s (vendor claim with compression), 350 KB/s can even be reached in start/stop mode. The rate decreases for smaller cartridges. Reported by: &a.joerg; Wangtek 5525ES The boot message identifier for this drive is WANGTEK 5525ES SCSI REV7 3R1 type 1 removable SCSI 1 density code 0x11, 1024-byte blocks This is a QIC tape drive. Native capacity is 525MB. Data transfer rate is 180kB/s. The drive reads 60, 120, 150, and 525MB tapes. The drive will not write 60MB (DC600 cartridge) tapes. In order to overwrite 120 and 150 tapes reliably, first erase (mt erase) the tape. 120 and 150 tapes used a wider track (fewer tracks per tape) than 525MB tapes. The extra width of the previous tracks is not overwritten, as a result the new data lies in a band surrounded on both sides by the previous data unless the tape have been erased. This drives quirks are known and pre-compiled into the scsi tape device driver (&man.st.4;). Other firmware revisions that are known to work are: M75D Reported by: Marc van Kempen marc@bowtie.nl REV73R1 Andrew Gordon Andrew.Gordon@net-tel.co.uk M75D Wangtek 6200 The boot message identifier for this drive is WANGTEK 6200-HS 4B18 type 1 removable SCSI 2 Sequential-Access density code 0x13 This is a DDS-1 tape drive. Native capacity is 2GB using 90m tapes. Data transfer rate is 150kB/s. Reported by: Tony Kimball alk@Think.COM * Problem drives - CD-ROM drives + CDROM drives Contributed by &a.obrien;. 23 November 1997. As mentioned in Jordan's Picks Generally speaking those in The FreeBSD Project prefer SCSI CDROM drives over IDE CDROM drives. However not all SCSI CDROM drives are equal. Some feel the quality of some SCSI CDROM drives have been deteriorating to that of IDE CDROM drives. Toshiba used to be the favored stand-by, but many on the SCSI mailing list have found displeasure with the 12x speed XM-5701TA as its volume (when playing audio CDROMs) is not controllable by the various audio player software. Another area where SCSI CDROM manufacturers are cutting corners is adherence to the SCSI specification. Many SCSI CDROMs will respond to multiple LUNs for its target address. Known violators include the 6x Teac CD-56S 1.0D. * Other * Other * PCMCIA