AMIGA PD 1/AMIGA-PD-1.iso/NetBSD/docs-netbsd/386BSD-FAQ/BSD-FAQ-part06

Text File | 1994-11-27 | 22KB | 611 lines

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 ([e-mail]) a message
    detailing the package (possibly include a README), where it
    can be found, and what version of the OS (ie. NetBSD,
    386bsd 0.1 + pk 0.2, FreeBSD) it was designed to run under.

    When the exact directory is not listed for a package, the
    places to look on agate.berkeley.edu are in unofficial/drivers
    and unofficial/from-ref/sys.extras.

    Many a goodie can be found in these directories.


5.1    Available Kernel Replacements


5.1.1    keycap/codrv

    These server as replacements for the generic pccons driver
    that comes (by default) with 386bsd 0.1.

    Holger Veit (author of these) writes:

    "The same type of driver, but keycap has the version number 0.1.1
    and codrv has the version number 0.1.2.  The latter is much
    improved and downward compatible.  Codrv was developed to provide
    a universal way of mapping national keyboard layouts during
    runtime (ie, not by patching the kernel tables) and providing
    better X11 support.  Codrv uses a superset of the pc3 terminal
    emulation, and a termcap-like database for keymaps (therefore
    "keycap").  X11 is supported by two dedicated console raw devices
    /dev/kbd and /dev/vga, which avoids all the existing problems
    pccons has with X11.  The latest version has virtual consoles.
    Codrv will become part of patchkit 0.2.4"

    This package is available on agate.berkeley.edu.



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.

    Joerg Wunsch, the author of pcvt <[e-mail]>
    has sent us this update.

    I've arranged irz301.inf.tu-dresden.de [141.76.4.1] as the
    `official' ftp server for the pcvt console driver, as long as
    there are several different drivers.  The stuff is under
    ~ftp/pub/unix/386bsd/pcvt, along with some recent (still
    unofficial) patches to be compatible with XFree86.  Everything
    is scheduled with the author, Hellmuth Michaelis.

    I'm not the official maintainer of that ftp site, so I must ask
    the folks there to help me.  This might delay recent changes;
    before they're merged into the official server tree, they can
    be found in ~ftp/pub/incoming/unix/386bsd.

    The Dresden University has only a thin wire to outside.  Any
    mirroring site, especially in US, would be appreciated.  The
    space requirements are less, only 2 or 3 Meg.  Maybe I'll upload
    a `generic' kernel configured with pcvt there some day.

    all the best, J"org <[e-mail]>

    I heard a rumor that pcvt is now included in the source
    distribution for NetBSD.


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.  Available on
    agate.


5.1.4    Fast Symbolic Links

    The following is taken from the README for the fast sym-links
    patch:

    "This cruddy but complete hack answers one of the objections to
     symlinks: that they are slow, and cost an entire frag.  Symlinks
     of less than length 60 are stored in the inode itself.  Symlinks
     longer than this are still in the inode.  To make the illusion
     of normality complete, dump and fsck also need changing.
     Additionally, I made dumpfs verbose to excess."

    Available on agate.

    Fast Symbolic Links are supported natively in FreeBSD and NetBSD.


5.1.5    npx fixes

    There are problems with the floating point error handling
    routines, and there are fixes available for this problem provided
    by Bruce Evans (of Minix-386 fame)

    The code for these fixes is available on agate.berkeley.edu
    in unofficial/from-ref/sys.extras/bde-npx.

    Note that most of the code is applicable to floating point hardware
    as opposed to emulation.

    The newest version (and now official) fixes to this are in
    patchkit-0.2.4.

    There are still some nits in the npx emulation code in both FreeBSD
    and NetBSD.  They are being worked on.


5.1.6    CGD's COM drivers

    Chris G. Demetriou (cgd@blah blah blah) has written some COM drivers
    for 386bsd.  These, among other things, support multi-port serial
    packages.

    The latest (and last) version is 0.2, and is available on agate
    in unofficial/from-ref/sys.extras/cgd-com-ports.  Please note that
    this is not going be developed any further by the author, and no
    new versions will appear.  Users who do not absolutely need the
    features this provides are encouraged to use the newest drivers
    that come with the patch-kits.

    This driver was the basis for the FreeBSD com subsystem.  NetBSD
    does not use them.  There are patch files around (E-Mail me; I have
    them) that added some of the missing functionality to NetBSD.
    Multiport comm support is included in both FreeBSD and NetBSD.


5.1.7    Tom Ivar Helbekkmo's wd.c replacement

    Tom Ivar Helbekkmo ([e-mail]) has rewritten much of the
    386bsd 0.1 wd.c file that handles common hard disks, and added
    many new features to the code.

    The patches to use these can be obtained from barsoom.nhh.no
    in pub/386bsd.  Users should consult the README file for more
    information.

    Also, it should be noted that NetBSD uses these drivers as their
    stock drivers.

    FreeBSD uses similar changes.


5.1.8    Interruptless LPT Driver Kit

    An Interruptless lpr driver kit is available from agate.berkeley.edu
    in unofficial/drivers/lpt.

    This driver was designed with faster performance and lower system
    load in mind.  See the INSTALL-NOTES that come with the package
    for more details and installation information.

    This is also included in NetBSD and FreeBSD.  Note that with some
    printers, it may be prefereable to ignore the status port and rely
    on the data port.  If you have tried everything else and the
    interruptless printer driver still does not work for you, you may
    need to play with this.

    It has also been determined that the interruptless driver may be
    (or already has been) removed from the system.  A newer lpt driver
    has been developed that removes many of the overhead problems that
    the original 386bsd lpt driver had.


5.2    Floppy Disk problems.

    One of the most common problems in 386BSD involves working with
    new boot sector and/or reformatting a floppy.  Dave Silvia
    provided this section on using floppy disks.


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

    Configuring a parallel printer for 386bsd requires a working
    printer driver to be installed in the kernel.  386bsd 0.1 does
    not include a printer driver in the stock distribution kernel.
    NetBSD and FreeBSD both include this driver in their stock
    manifestations.

    It is possible to connect a serial printer to either.  This brief
    tutorial is provided by Daryl Berryhill
    ([e-mail])

    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.


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

    How to add a modem to 386BSD:

    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 386BSD.

    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 [e-mail] 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.


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.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.
--
------
TSgt Dave Burgess               | Dave Burgess
NCOIC, USSTRATCOM/J6444         | *BSD FAQ Maintainer
Offutt AFB, NE                  | [e-mail]