Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/answers/386bsd-faq/part5

Internet Message Format | 1993-12-26 | 16KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!usc.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: [e-mail] (Dave Burgess)
Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 5 of 10)
Followup-To: comp.os.386bsd.misc
Date: 27 Dec 1993 06:00:34 -0000
Organization: Armstrong Laboratory, Brooks AFB, TX
Lines: 397
Approved: [e-mail]
Distribution: world
Expires: 01/14/94
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (386bsd FAQ Maintainer)
NNTP-Posting-Host: hrd769.brooks.af.mil
Xref: senator-bedfellow.mit.edu comp.os.386bsd.announce:212 comp.answers:3170 news.answers:16209

Posted-By: auto-faq 2.4
Archive-name: 386bsd-faq/part5

Section 4.    (Kernel Additions)

  Thanks go to  Marc Wandschneider ([e-mail]) for putting this
  section of the FAQ together..

4.0    Introduction

    If you have written some addition to the kernel, or know of
    one that feel should be mentioned, send mail to Dave Burgess
    ([e-mail]) with all the relevant information,
    and it will be added for the next release.



4.1    Common Kernel-related problems

4.1.1    Where are the commands "rpcinfo" and "rpcgen"?

    Chris Flatters ([e-mail]) informs us in the following
    posting excerpt where we can find them:

    --------------------------------------------------------------------
    The sources for the Sun OS 4.0 RPC are on titan.rice.edu (I don't
    have the inet number handy) in directory sun-sources.  You will have
    to pick up all the shell archives and unpack them to get at rpcgen.
    --------------------------------------------------------------------

    These sources are also included in NetBSD and FreeBSD as part of the
    normal installation.

4.1.2    Where can I get a working "netstat"?

    netstat was released as a binary patch and source patch
    in the patchkit.  Netstat will be a part of the FreeBSD
    distribution currently under construction, and is already
    part of NetBSD.


4.1.3    How can I fix NFS to work with my NE2000 board?

    Ken Raeburn ([e-mail]) has both identified the
    problem and provided us with a work around:

    --------------------------------------------------------------------
    I reported previously that I was seeing problems reading files over
    NFS using the ne2000 driver; timeouts would eventually be reported, no
    data would be read.  Listing files and directories (small ones
    anyways) were not a problem.

    After playing with etherfind and kernel printfs, I've come to this
    conclusion: Fragmented 8K UDP packets from the NFS server are not
    reaching the UDP layer in 386bsd.  The Sun is sending them (according
    to another Sun spying on the network), but the UDP input routine is
    never called.  I don't know if the bug here is on the 386bsd or Sun
    side, and won't have time to look into it in the next couple of days.

    In the meantime, mounting NFS file systems with "rsize=1024" does get
    rid of this problem.

    (It does nothing about TCP being slow, though.)
    Ken
    --------------------------------------------------------------------

    Hopefully, the real solution (a UDP fix) will be forthcoming so
    that the slow TCP problem is fixed as well.

    See also:  Section 2.6.3.3c "I am getting lousy performance
           out of my network card.  What are some of the other
           possibilities?"

    Recent work in FreeBSD and NetBSD may have deprecated this problem.
    There is a new network card driver called the ed0 driver.  This
    replaces the original NE1000/NE2000 drivers, as well as replacing
    the we0 driver.  By combining the two, a more flexible driver has
    been developed and most of these types of problems have been fixed.
    Once again, upgrading to FreeBSD or NetBSD seems to be the answer.


4.1.4    How can I get "ps" and "w" to work?

    The patch-kit contains a fix for /src/lib/libutil/kvm.c, which,
    last we heard, was due to the work of Jim Paradis
    ([e-mail]).  New versions of the kernel should
    have this problem fixed.

    In order for users to be able to use certain flags with ps and
    the w/uptime commands, the kernel must have permissions 755.

    Also, in order to save space on the distribution, the kernel is
    'stripped' of all its labels.  Programs that rely on those labels
    will not work.  There are several in this category, including ps,
    w, and uptime.  Either ftp an un-stripped kernel, or recompile.


4.1.5    Where are re_comp and re_exec?

    These two functions are currently not in libc.a.  However, there
    are two related functions that seem to work exactly the same in
    all cases we've heard of---These are regcomp() and regexec().

    Thus, a pretty ugly fix for the problem would be to always compile
    as follows:

    $(CC) -Dre_comp=regcomp -Dre_exec=regexec ....

    There is a slightly nicer fix available for this, listed in 4.2


4.1.6    Where are stty() and gtty()?

    These functions are missing from libc.a.  To fix, add the following
    #defines to your program:

    #define stty(f, m)    ioctl((f), TIOCSETP, (m))
    #define gtty(f, m)    ioctl((f), TIOCGETP, (m))

    A more elegant solution is to apply the patchkit.  These routines
    are included in there.

4.1.7    The system hangs with the HD light on after intense disk usage.

    Brett Lymn ([e-mail])  Provides us with a
    description of the problem and the steps that he had to take
    to fix it:

        It seems that, on some disk subsystems, the controller and the
    hard disk get out of synchronization when they are being used
    intensively.  The result of this is that the disk completes a
    command but the controller still believes the disk not to have
    completed the command, so the controller status register
    indicates the disk is busy when it is not really.  The standard
    wd drivers are too trusting of the hardware and expect it to do
    the right thing all the time.  There are a few while loops in
    the wd drivers that loop on a status change from the disk
    controller, however; if the problem I have described takes place
    then the wd driver will be stuck looping waiting for the disk to
    not be busy - which never happens, so you lock the machine because
    this is a kernel level wait.  To fix this problem I put a timeout
    into the while loops so that after a specified time the wd driver
    will give up waiting for the drive to become ready, reset the
    controller and retry the command.  In my experience the retry
    always succeeds.

    Ed.Note:  The retry doesn't ALWAYS work, but it IS better than
    just waiting for the drive to wake back up (which it never does).

    Dan Yergeau ([e-mail]) provides us with more
    insight into this problem.  The README accompanying the original
    sources used as a base for the NetBSD driver indicates that

    > There's also another problem still bothering me: There's some
    sort of timing/reentrancy error still lurking in here, that was
    there in the original 0.1 wd driver as well.  The symptom is that,
    on *some* controllers, doing the initial wdopen() (which will
    then call the readdisklabel() function) for two or more disks at
    the same time (so that wdopen() gets called again while it's
    already being executed), the controller gets hung.  I'm still
    looking for this, meanwhile I specify in my config file that I
    have swap on all disks.  This causes the kernel to wdopen() the
    drives nicely in order -- and once it's been done for each disk,
    the problem will, of course, not occur.  Without the "swap on ...
    and ... and ..." stuff, my wd1, wd2 and wd3 would be opened
    simultaneously by "fsck -p" forks, which would nicely hang up
    everything...  I note a "sleep(10)" in fsck, but it obviously
    doesn't do that.

    So, changing the appropriate config line to

    config        "386bsd"    root on wd0 swap on wd0 and wd1
                                                            ^^^^^^^
    may get around the problem.  I don't run NetBSD, but I do use a
    variation of the barsoom/NetBSD driver.  This works for me.
    Please let the NetBSD people know if it works for you.

    (Note: the sleep(10) in fsck is misplaced.  It does not keep fsck
    from opening multiple disks simultaneously.  A properly placed
    sleep() should also work around the wdopen problem.)

#include <std.disclaimer>



4.1.8    How do you implement quotas on Net/2 derived BSD systems?

    From: [e-mail] (Mark Tinguely)

     maybe you did not complete the setup, here is a step-by-step
     instructions to get them to work:

    1)  make a kernel with "options quota" installed

    2)  edit /etc/fstab and include the kinds of quotas you want,
        below I used "userquota", you could also add "groupquota".

    /dev/wd0h        /usr        ufs    rw,userquota 1 2

    3)  for each filesystem that is in /etc/fstab that uses quota,
        create the file "quota.user" (and "quota.group if appropriate).
        Above I have user quotas in the /usr filesystem, so I would:

        # touch /usr/quota.user

    4)  scan filesystem for files ownership (and/or group ownership).

        # quotacheck -a

    5)  now you can add individual quota limits, if you want to add
        the same quotas to the many people, then make a template and
        replicate the template.  If they change for each user, then
        edit seperately.

        # edquota tinguely

     (an editor is kicked up and says something like:

    Quotas for user tinguely:
      /usr: blocks in use: 11876, limits (soft = 0, hard = 0)
            inodes in use: 891, limits (soft = 0, hard = 0)

     a limit of 0 means "unlimited".  Change these to the appropriate
     number of blocks.  A soft limit generates a warning, and can be
     exceed for period of time (7 days?), after which time a soft limit
     is treated like a hard limit.  A hard limit denies new writes.

     to replicate a template (for this example let us assume "tinguely"
     is the template):

        # edquota -p tinguely user1 user2 user3 ... userN

    6)  turn quotas on (usually done in the /etc/rc file, but turn it
        on manually so you do not have to reboot right now:

        # quotaon

    that should take care of setting up quotas.  You can look at the
    status of use of files with repquota, the -a option lists all
    filesystems with quotas.


4.2    Available kernel add-ons


4.2.1    The Patch-Kit

    Perhaps the most famous of all additions to the kernel, the Patch-Kit,
    currently coordinated by Rodney Grimes ([e-mail])
    contains numerous bug fixes, Julian's SCSI drivers, as well as fixes
    for other parts of the system.

    The patch-kit, as well as all relevant information, is available on
    agate.berkeley.edu (and mirrors) in unofficial/patch-kit, as well
    as bsd.co.montana.edu in /pub/patch-kit. (archie will likely list
    other sites as well)

    It is highly recommended that all users with space for the source code
    apply the patch-kits as many things that seem broken in 0.1 suddenly
    start working with the patch-kits.

4.2.2    Shared Libraries

    A basic and experimental implementation of shared libraries exists
    for 386bsd.  According to the author (Dr. Joerg Lohse,
    [e-mail]), features are as follows:

    -No kernel extension is necessary
    -Shared libraries use the approach used in SysV.

    Others are also working on different implementations of shared
    libraries.

    This code can be obtained from agate.berkeley.edu in
    ~/unofficial/from-ref/sys.extras.  The file is called ??????????.

    Bill and Lynne have adopted a shared-library implementation based
    on Dr. Lohse's original work.  It will be included in Version 0.2
    of 386bsd and should be included in NetBSD about the same time
    (Yes, I am guessing here).

4.2.3    Sound Blaster Drivers

    A driver for the Sound Blaster card has been written by Steve
    Haehnichen ([e-mail]) for BSD.  Steve Gerakines has
    provided us with the information necessary to get this driver
    working under 386bsd.

    Most features of the SB family of cards are supported save some
    stereo portions of the SBPro cards.

    The driver is available on agate.berkeley.edu in
    unofficial/drivers/misc/soundblaster-1.4


4.2.4    Bus Mouse Drivers

    Fred Cawthorne ([e-mail]) wrote a busmouse
    driver for 386bsd.  He recently wrote a short letter with this
    update:

    My busmouse driver is mentioned in the FAQ, but it is quite out of
    date.  I use Gene Stark's driver available from Freebsd.cdrom.com
    in /pub/XFree86/mice.  (It is well done and I did not have time to
    finish mine to make it more stable)  It is small, though, so it
    might be good for people who want to rewrite parts, etc...
    Several people have written about getting this to work with new
    versions, etc... and I have pointed them to the other driver.  It
    would seem that people found out about my busmouse driver through
    the FAQ, so could you please add something like the following to
    the FAQ??

    This is taken from the INDEX in the Freebsd.cdrom.com mice
    directory:

    "We currently have four bus mouse drivers for 386bsd available by
    anonymous ftp on XFree-86.cdrom.com in pub/XFree86/mice:

    ms-busmouse.tar.z

        Sandi Donno's <[e-mail].> port of
        Erik Forsberg's Microsoft bus mouse driver to 386bsd.

    logitech-busmouse-0.2.shar.z

        Fred Cawthorne's <[e-mail]> second version
        of a logitech Bus Mouse driver.

    busmouse.tar.z:

        Eugene Stark's port of Rick Macklem's driver to the
        Microsoft bus mouse.  Rick's driver supports the
        Logitech and ATI Inport Bus mice with 386bsd.  It's also
        available by e-mail to [e-mail] and by anon.
        ftp on cs.sunysb.edu in pub/386BSD/busmouse.tar.Z.

    psm.tar.z:

        Johan Solhed <[e-mail]> ported the
        Linux PS/2 mouse driver to 386BSD.  It includes a PS/2
        to Microsoft protocol converter in the driver so XFree86
        understands the mouse events.

    In addition we have busmouse.v3.z which is Erik Forsberg's original
    post of his device driver for BSDI/386 and Microsoft (and
    compatible) bus mice using the Microsoft InPort chip as well as a
    device driver for Logitech bus mice. "

    I prefer busmouse.tar.z, and that seems to be the one that
    supports the most mice.  It also drops into FreeBSD very easily.
    (all you have to do is copy com.c into /sys/i386/isa and add the
     device mse0 ... line to the system config file.)


4.2.5    PPP Support

    A package to add PPP support to 386bsd can be found on agate
    in unofficial/drivers/net.  It is included in NetBSD and FreeBSD.


4.2.6    re_comp and re_exec library functions

    As mentioned in section 4.1, re_comp and related functions, such
    as re_exec, are currently not in the library libc.a  Apart from
    using the rather crude fix listed above, there is another option.

    Kim Anderson ([e-mail]) has provided a patch that will add these
    to libc.a.  You can probably obtain this patch from the author, or
    you can ftp it from binkley.cs.mcgill.ca in pub/386bsd.

4.2.7    Intel i82586 Ethernet Controller driver

    Garrett A. Wollman has written a driver for the Intel i83586
    Ethernet Controller.  The driver is available from agate
    in unofficial/from-ref/sys.extras.

    The authors e-mail address is listed as [e-mail],
    attempts to send him mail there have failed.

4.2.8    PC Speaker driver for Nethack

    Andrew A. Chernov has ported the Nethack PC Speaker driver to
    386bsd.  It allows the speaker to be controlled by applications.

    Unfortunately, we are not aware of a site that distributes this,
    but this patch has been posted a couple of times to the various
    comp.os.386bsd groups, and the author can be contacted at
    [e-mail]

    This patch is included in the NetBSD source tree, although it is
    not included in the distribution kernels.

--
TSgt Dave Burgess
NCOIC Applications Programming Branch
US Strategic Command, Offutt AFB, NE
[e-mail]