by > Posted-By: auto-faq 3.1.1.2
> Archive-name: 386bsd-faq/part6
> Section 5. (Kernel Replacements)
> 5.0 Introduction
> This section is supposed to document the unusual or optional
> kernel add-ons that are available from various places. As
> they are included in the mainstream of the various Berkeley
> Net Release systems, they will slowly come out of here.
> If you know of any replacement parts for the kernel, please
> send Dave Burgess (burg...@cynjut.neonramp.com) a message
> detailing the package (possibly include a README), where it
> can be found, and what version of the OS (ie. NetBSD or
> FreeBSD) it was designed to run under.
> 5.1 Available Kernel Replacements
> 5.1.2 pcvt
> A superset of pccons, this driver supports virtual consoles,
> and some form of database oriented keyboard mappings. It was
> also designed to emulate a vt220 terminal as best as possible.
> (This section originally identified Joerg Wuensch as the
> author. Hellmuth Michealis is the author of pcvt. Joerg was the
> author of the original post. This update is from Hellmuth
> himself. Apologies from the FAQ staff...)
> The last release of pcvt is version 3.00 and was done on March
> 1st 1994 to the newsgroup comp.sources.misc, Volume 41, Issue
> 140-152 (part 1-13). Future releases and upgrades will be done
> as patches or new releases to that newsgroup.
> pcvt was recently put into the kernel sourcetree of
> NetBSD-current (pre 1.0) into /sys/arch/i386/isa/pcvt.
> pcvt is also available in the FreeBSD contributed tree at
> location /usr/ports/util/pcvt.
> The pcvt package consists of:
> - the driver itself
> - complete documentation for installation and operation
> - termcap/terminfo, pcvt.el, rc.local, /etc/ttys, xmodmap examples
> - cursor, utility to set the cursor size and shape
> - fed, a curses-based EGA/VGA character set editor
> - fontedit, utility to edit the VT220 downloadable character set
> - ispcvt, utility to display the drivers compile time configuration
> - kcon, utility to setup national keyboard layouts and remap keys
> - keycap, keyboard mapping database library similar to termcap
> - loadfont, utility to load up to 4/8 fonts into an EGA/VGA board
> - mcon, utility to control/configure a keyboard based mouse emulator
> - scon, utility to runtime configure the video part of pcvt
> - userkeys, utility to set the VT220 user programmable function keys
> - vttest, VT100 compatibility torture test program
> - demo, color- characterset- and attribute demos
> and more ....
> See the README-file for the latest release (3.00) of pcvt for
> lots more information and a complete list of the contributors
> to this project.
> 5.1.3 syscons
> Another superset of pccons that was designed to emulate SCO as
> well as possible. Many of the ioctls from SysV have been
> implemented. XFree86 2.0 no longer requires special patches
> to be run with kernels using this console driver.
> 5.1.9 A replacement curses program/library.
> It is generally accepted that the NetBSD curses can be easily
> replaced by the ncurses package. It is more complete and offers
> much better support for shared libraries and other advanced
> features. The current (early 1995 version) is 1.8.5 and is
> available from ftp://netcom.com:/pub/zmbenhal/ncurses/1.8.5.tgz
> 5.2 Floppy Disk problems.
> 5.2.1 How do I get a bootable floppy?
> Several ways, ranging from brain-dead-but-works to simplest.
> Classification into categories is left to the reader (is there
> really a difference between 'brain-dead' and 'simple'?:')
> 1) rawrite (or dd) dist.fs (or fixit.fs) to a disk,
> mount it, cd to the mount point, and execute:
> rm -rf .
> you now have a bootable floppy!;^}
> 2) Take your existing dist.fs or fixit.fs boot disk and
> diskcopy it on a DOS machine. Mount and rm as in 1)
> above. Again, you have a bootable floppy!;^}
> 3) Run disklabel on the floppy, e.g.:
> disklabel -w -r fd0a floppy5
> where 'floppy5' is a 'name' for an entry in the /etc/disktab
> file. You'll get a couple of ioctl errors because writing a
> label to a floppy isn't supported (yet?), but the boot blocks
> have indeed been written.
> 4) Write the boot blocks to the floppy:
> cat /usr/mdec/fdboot /usr/mdec/bootfd | dd of=/dev/rfd0a
> or, more simply:
> cat /usr/mdec/fdboot /usr/mdec/bootfd > /dev/rfd0a
> Methods 3) and 4) require you to run newfs on the floppy, e.g.:
> newfs /dev/rfd0a floppy5
> If you have a floppy that was originally bootable, but the boot
> blocks were somehow damaged, you can use method 3) or 4) to
> restore boot-ability (do _NOT_ run newfs). You _could_, through
> the convolutions of copying a floppy whose boot blocks are damaged
> to a temporary location and then re-copying to a bootable floppy,
> use method 1) or 2) (if you really want to!;^})
> 5) If the disk is already newfs'ed and is otherwise ready to use,
> disklabel will write the boot blocks on the disk. Read the man page
> for disklabel.
> 5.2.2 How do I maximize the space on a mountable floppy disk.
> As you all know, when you are working with a floppy, it is usually
> more important that the floppy have a lot of room, rather than a
> lot of other 'stuff'. Here is the magic incantation that will
> maximize the amount of free space on the disk.
> newfs -Tfloppy[35] -i[4096 | 8192] -c 80 /dev/fd[0|1]a
> This leaves the disk with fewer inodes and only one cylinder group.
> 5.3 Character Device Driver info
> These devices are also often referred to as character devices.
> 5.3.1 Printers
> NetBSD and FreeBSD both include both an interrupt and
> non-interrupt driven parallel driver in their stock
> manifestations.
> It is possible to connect a serial printer to either. This brief
> tutorial is provided by Daryl Berryhill
> (djber...@b25info.b25.ingr.com)
> The way I got my printer to work.
> 1) connect a 25 pin to 9 pin null modem cable to printer and
> computer.
> 2) set printer to 9600 baud, 7 data bits, even parity.
> 3) configure /dev/com1 (DOS COM2) port the same way as the printer
> 4) add a line to /etc/printcap that says:
> lp|local line printer:\
> :lp=/dev/com2:wq:sd=/var/spool/lpd:lf=/var/log/lpd-errs:\
> :br#9600
> 5) type "lpr <add filename here>"
> 6) type "lpd"
> and it should start printing.
> An obvious point, but make sure that you do NOT start a getty on
> on the com port. Check the /etc/ttys file and make sure that
> the com port you select is not active.
> There have been many reports in the past of people not being able
> to get their parallel port printer working. One of the problems
> seems to be cables. Another problem may be with the hardware.
> A seemingly stupid suggestion is to replace your printer card with
> the cheapest parallel port card you can find. I am using a $10
> single parallel, two serial port card that I got from Altex.
> Works great.
> In addition, there are people that want to set up multiple printer
> queues using the BSD queueing mechanism. Here is a brief tutorial:
> Lpf is mainly intended for processing text and nroffed output...it
> isn't anything clean...it will do certain games that will mess up
> PCL output.
> If you're producing straight PCL or Postscipt (assuming your LJ
> takes it), then you want to print directly to the printer w/o any
> processing.
> What you really want is a "physical" queue that does no processing,
> and several logical queues that map back to the physical queue and
> do processing...or one "smart" queue that does file content
> recognition and then maps to the raw queue.
> I do something like this for my DeskJet. There is one raw queue
> and several logical queues (some postscript that do different
> resoultions and color depth, some text that do various formatting,
> etc). When I get the time I'll be trying to set up a "smarter"
> queue using aps and maybe some bits from flexfax.
> To map logical to physical queues either use a filter that pipes
> back into lpr -P<rawqueue> itself, or just point it at the "raw"
> queue using something like:
> textlp|Text Printing:\
> :lp=/dev/null:\
> :if=/usr/libexec/lpr/lpf:\
> :rm=localhost:\
> :rp=lj.raw:
> And other entries as needed, you get the idea...to use an output
> filter instead of the rm/rp approach (more efficent), you can get
> away with something like:
> :of=/usr/local/bin/printraw:
> where /usr/local/bin/printraw looks like this:
> #!/bin/sh
> cat | lpr -h -Plj.raw
> 5.3.2 Terminals/Keyboards
> Terminals are relatively simple to add. It involves making sure the
> /etc/ttys file identifies the com port (com0, com00, or tty00
> depending on your configuration) as an active port and a getty is
> running. The man page for ttys and getty help explain this.
> Many people report that there are sometimes problems running some
> programs on a remote terminal. There are some known bugs in the
> terminal handler where the parity and bits per character are
> concerned. They are being worked on.
> 5.3.3 Modems/FAX Modems
> 5.3.3.1 How do I add a modem to *BSD:
> The first part that confused me was assuming that /dev/com1 is
> the same as DOS com1, they're not. /dev/com0 is connected to
> COM1 and (I think) /dev/com1 is connected to COM2.
> The switch settings for my modem were the same as what I had
> under DOS, CTS CD RTS et al were set to follow the actual line
> (i.e. my modem can force them high, which I turn off)
> Ok that's not too bad.
> Now you need to edit the /etc/remote file to include a reference
> to the com port. I have only used NetBSD-0.8, so I'm not sure
> what the default files are like that come with the other rev's
> of *BSD.
> I added the last line (with com0).
> --------------------------------------------------------
> # @(#)remote 5.2 (Berkeley) 6/30/90
> #
> ...stuff deleted...
> # UNIX system definitions
> unix1200|1200 Baud dial-out to another UNIX system:\
> :el=^U^C^R^O^D^S^Q:ie=%$:oe=^D:tc=dial1200:
> unix300|300 Baud dial-out to another UNIX system:\
> :el=^U^C^R^O^D^S^Q:ie=%$:oe=^D:tc=dial300:
> ...stuff deleted...
> dial2400|2400 Baud Hayes attributes:\
> :dv=/dev/tty19:br#2400:cu=/dev/tty19:at=hayes:du:
> dial1200|1200 Baud Hayes attributes:\
> :dv=/dev/tty19:br#1200:cu=/dev/tty19:at=hayes:du:
> # Hardwired line
> com1c|com1:dv=/dev/com1:br#9600:
> com1b:dv=/dev/com1:br#2400:
> com0:com0:dv=/dev/com0:br#9600:at=hayes:
> ------------------------------------------------
> Ok, now if you are running as root you can use type 'tip com0'
> and you should then be talking to your modem. I use kermit to
> transfer files, and it wants to create a lock file in (not sure
> about the exact path) /var/spool/uucp/lock or something along
> those lines. I made the directory world writeable so I could
> run kermit with my own uid, rather than root.
> Also, you may need to add an entry in /etc/remote for com0.
> Thanks also to thom...@liciren.li.co.uk for information on how
> to do this.
> New problems have surfaced with the latest releases of NetBSD.
> It seems that the paradigm that the com port used to use was
> 'less than complte' and much of the code has been replaced.
> This provides for some interesting new problems. The first is
> that the Carrier Detect line is no longer ignored, as it was
> before. This means that programs like kermit and tip/cu either
> have to be told explicitly to ignore the CD line (in kermit,
> for example, you would use the 'set carrier off' in your .kermrc)
> or you need to use the 'stty -f /dev/com? clocal' command before
> you open the port.
> If you have trouble getting the settings to 'stick' it is because
> the ports are now initialized to known settings on the last close
> of the port. A workaround for this is to use the command:
> sleep 1000 < /dev/com?
> tip ...
> { or }
> kermit ...
> This will keep the port open for about 12 minutes while you do
> whatever it is you need to do. Once the port is open and your
> connection established, the port will not reset until the final
> close.
> Another symptom of this malady is described below.
> When I 'set line' in kermit, it hangs until I hit my escape
> character (^\). It *does* set the line (and the rest of my session
> is normal), but it's annoying because I can't put 'set line' in
> my .kermrc.
> The answer is available in the kermit documentation as well as
> here (now). The following commands are MY .kermrc file:
> set carrier off
> set line /dev/com2
> set speed 38400
> set modem hayes
> set dial speed on
> set dial timeout 60
> The 'set carrier off' tells kermit to ignore the Carrier Detect
> line from the modem, and to proceed as if the command were
> there. This will (as far as I have ever been able to find
> out) fix the specific problem with not being able to set the
> line.
> 5.3.3.2 Adding a modem to NetBSD.
> 5.3.3.3 Adding a modem to FreeBSD.
> 5.3.3.4 Adding a Dial-in/Dial-out FAX to NetBSD or FreeBSD.
> First, here is the known working configuration for these
> instructions:
> - HylaFAX 3.0 beta 100.
> - Zoom VFX V.32bis Faxmodem;
> - Rockwell datapump.
> 1: Start faxq from rc.local, no options on the command line.
> Add a line to your /etc/rc.local which starts up the faxq
> program. Do not include any options on the command line.
> 2: Stary faxgetty from init, i.e. a line in /etc/ttys.
> I use the non modem control device; however, it's nonstandard
> hardware and I've modified the driver to always return sighup
> on lost carrier to solve some sticky problems with non modem
> control devices never getting SIGHUP's.
> Basically, I just did as the directions said to do. I ran
> 'faxaddmodem' script to configure the type of modem. I did
> have to simplify some lines in the script (the ones executed
> in a subshell) since I think my version of bash doesn't handle
> subshells correctly.
> RTFM and you should be OK unless your modem is braindead and
> stupid, not too unlikely tho given the current state of Fax
> modems... B^(.
> 5.3.4 What is the trick for getting Kermit to work with rz and sz?
> Add these lines to your .kermrc file. They should do the trick.
> define sz !sz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
> define rz !rz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
> 5.4 Tape Drives
> This section should help out for those of you that have either
> never used tape drives before, or only have experience with them
> as non-Unix devices.
> 5.4.1 Does the tape need to be formatted?
> It depends, but I think usually not. And when it is necessary,
> I don't know how it would be done. One thing is for certain,
> though, first.... NEVER use the block devices.. erase them and
> forget you ever saw them. All operations on tape should be to
> the character device (rst0).
> 5.4.2 If I execute the command 'st -f /dev/st0 status', I get:
> Archive/Tandberg? tape drive, residual=0, blocksize=512
> Density: high = 16 (0x10), medium = 15 (0xf), low = 5 (0x5)
> ds=0
> er=0
> so to write to tape at high-density (QIC-150), presumably I want
> to use a device with minor number +4 (in st.c, density is computed as
> minor >> 2 & 0x03, where low density == 3 and high == 1):
> You have the idea.. density is controlled by bits 2 and 3
> 00 = default
> 01 = hi density
> 10 = medium density
> 11 = low density,
> Unless the driver knows about you kind of drive the density values
> may need to be set by hand before they make any sense.
> 5.4.3 When is erst0 used?
> e stands for 'eject' and is bit 1 of the minor..
> e.g. eject on close.. many devices can't actually do this.
> There is actually a method to this whole thing:
> r = raw (rst0)
> e = eject (erst0)
> n = No rewind (nrst0 or maybe nerst0)
> 5.4.4 How is density (bpi) computed? I am using 3M DC 6250 cassettes
> which have a 250MB capacity on the Viper 150. But computing the
> bits/inch based on 250MB/tape-length (1020 ft.), I get a density
> of 171335 bpi, which is nowhere near the 10000 bpi associated
> with QIC-150 in the st(1) man page. Why the discrepancy?
> These cartridge tapes are written in narrow tracks which
> alternately begin at opposite ends of the tape. Track 0 starts
> at the beginning of the tape, and Track 1 starts at the other
> end, etc.
> So, how many times does the tape go backwards and forwards? If
> there are 17 tracks, your density is 170000 bpi if it is 10000
> bpi per track. The more tracks, the lower the bpi/track.
> 5.4.5 How is an appropriate block size determined (and in what units
> are they specified in the st(1) command)?
> QIC 150 and below should stick to 512 byte blocks a write of
> 1024 bytes from the program will be written as 2 512 byte blocks
> with no speed penalty. dd will think it's writing a 1024 byte
> block but on tape it's 2 x 512.
> Stick to 512 on QIC 150 or less if you ever hope to swap data
> with anyone else.
> 5.4.6 From the 4.3BSD mtio(4) man page, it sounds like data is typically
> (traditionally?) stored on tape in eof-terminated sequences of
> 1K records.
> 5.4.6.1 Is st's notion of "file" the record sequence between two eof marks?
> 5.4.6.2 What about a "record"?
> 5.4.6.3 Is a "record" one "block", as determined by st's "blocksize" command?
> If not, what is the connection between them?
> 5.4.6.4 Can I change the "record" size?
> 5.4.6.5 When would I want a block size that is different from the default?
> 1KB is the size of writes used by dd or whatever. QIC specifies
> 512 byte records (well at least its what people use..) Whatever
> you write in will be broken into 512 byte sections. They must be
> multiples of 512 though.
> If you have written to a tape, a close will automatically append a
> filemark (eof mark). You may read the 512 byte blocks back as
> 512 byte records or as 1024 byte records (in which case you'll
> get 2 at once). The bigger the unit, the more efficient.
> 5.4.7.1 How do I write several archives to a single tape? I tried without
> success:
> $ st -f /dev/rst4 rewind
> $ tar cf /dev/nst4 archive1
> $ st -f /dev/nrst4 weof
> $ tar cf /dev/nst4 archive2
> $ st -f /dev/nrst4 weof
> First: throw away the block devices.
> 'n' stands for 'No-Rewind-on-close' and will leave the tape
> positioned ready for another file e.g.
> tar -cf /dev/nrst0 archive1
> tar -cf /dev/nrst0 archive2
> 5.4.7.2 Later, I would expect to be able to access, say, archive3 via the fsf
> directive to skip over the first two archives. What is the correct
> sequence?
> st -f /dev/nrst0 rewind
> st -f /dev/nrst0 fsf 2
> tar -xf /dev/rst0 {files}
> 5.4.8 Since the Viper 150 writes on QIC-150/120, I guess I don't need
> to worry about writing variable-length records? How about reading
> a tape written with variable-length records. Is this possible
> with the Viper? If so, what's involved?
> Who would have written it? :-)
> Presently you can't. You`re right. Don't worry about it.
> The new 'st' changes will change this somewhat, though.
> 5.4.9 The very scant documentation that came with my drive mentions
> a "selectable buffer disconnect size," whose default is 16K.
> This is evidently the "maximum number of bytes that can be
> sent over the SCSI bus during a single data transfer phase."
> What's that? How is it connected st's "blocksize" command?
> Do I want to use 16K blocks, or might I even want to set the
> disconnect size to a higher value?
> This suggests that 32 512 blocks will be written at a time.
> This jives with the tape format for some of the lower density
> cartridges (QIC-40 and 80, for example). The tape is written
> in blocks of 32 512-byte blocks, with the last three being used
> for Error Correction Codes.
> Use dd or tar with 16 k blocks and 32 x 512 byte blocks will be
> written.
> 5.4.10 What is "streaming"? When I tar a directory of files to tape,
> I notice that the tape often stops. Streaming means it doesn't
> stop? How would I get the viper 150 to stream using tar or cpio
> or dump?
> Use a bigger write size... (more efficient) Try 16k blocks.
> 5.4.11 Where are all the answers to the above and related questions
> written down? Neither on the net nor in the 4.3BSD manuals
> nor Administration text which I have could I find this stuff
> covered!
> They are in the FAQ :-)...
> 5.4.12 What else should I know? For example, it seems that a new tape
> must stretched. How is this done?
> Use a blowtorch and a pair of pliers; or you can use the
> non-destructive method and run the tape through a complete fast
> forward/rewind cycle to get it tight on the spindles.
> 5.4.13 My tape drive doesn't work.
> OK. There are lots of reasons why it may not. The most obvious is
> that there are no devices associated with the device in the kernel.
> You can check this through the use of the 'dmesg' command. Look
> for tape drives.
> If your tape drive is connected to your floppy controller, it may
> or may not be supported. Several manufacturers of QIC-40/QIC-80
> minicartridge drives are supported natively in FreeBSD and
> experimentatlly in NetBSD. Some aren't (mine for example, is not).
> If your tape drive is a SCSI based drive, your guess is as good as
> mine. I don't have one.
> 5.4.14 I am trying to restore a tape from a FreeBSD machine on a Sun.
> What kinds of problems should I expect?
> The default blocksize should not be a problem, since they are
> both 20K. You may need to use "dd if=/dev/rst0 conv=swab |
> <archiver>" instead of extracting directly from tape, just
> in case the byte order causes a problem. This is especially
> true if you don't use the 'a' and 'c' options in cpio, for
> example.
> 5.5 Network
> Network devices for NetBSD and FreeBSD include many types of
> Ethernet cards, as well as Serial Line IP and Point to Point
> Protocol.
> 5.5.1 How can I get my system to work as a network router?
> The first hurdle to overcome is that the default kernels do not
> have the GATEWAY option compiled in. Without this, it is very
> nearly impossible to use the kernel as a router.
> Once you have the GATEWAY option compiled in, all sorts of things
> magically start to work. If you haven't got the GATEWAY option
> enabled, you can also use 'sysctl -w net.inet.ip.forwarding=1'
> if you are using FreeBSD or NetBSD versions that support that.
> Remember, once you build the new kernel, you will need to
> install it in the root directory and reboot.
> Once you have the forwarding option set, you will need to make
> certain that you have not included the '-q' option to routed.
> This should be in the routed_flags keyword in /etc/netstart. If
> you are using multiple internal LANs, you may also want to
> invest in gated instead.
> For those folks that are not using routed, you will need to make
> certain that you have a static route to your network provider
> established.
> To test your network capability, try running the following
> command:
> trceroute -s YOUR_ETHERNET_ADDRESS 129.186.150.150
> Check to see where your packets are hanging up. It might be
> that someone upstream from you has something broken instead of
> simply assuming it is your fault.
> 5.5.2 I recently has a problem where I got a message that said "panic:
> kmem_malloc: mb_map too small". What is the solution to this
> problem?
> The second hurdle is that sometimes you run out of cluster
> allocation space in the kernel. This is probably network-related
> and usually shows up when something is being done using the
> network (like NFS). The way to get around this would be to
> change the value of NMBCLUSTERS in your config file. NMBCLUSTERS
> is set at 256 by default, and increased to 512 when the GATEWAY
> option is active. To be very safe, you could add
> options NMBCLUSTERS=1024
> to your config file, and recompile. This is reported to work
> with systems that crashed as soon as a large number of people
> (75+) were connected to it.
> 5.6 I want to use my ZIP drive. Are there any weird things I need
> to know?
> One of the things that "just work" are ZIP drives. The -current
> code for both FreeBSD and NetBSD handle ZIP drives very cleanly.
> One of the unusual things about ZIP drives is that most people
> don't know (and the man page is deliberately vague about) is
> once a pers