From owner-freebsd-hackers  Fri Jun  7 20:12:46 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA27049
          for hackers-outgoing; Fri, 7 Jun 1996 20:12:46 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA27039;
          Fri, 7 Jun 1996 20:12:39 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id NAA15037; Sat, 8 Jun 1996 13:09:32 +1000
Date: Sat, 8 Jun 1996 13:09:32 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199606080309.NAA15037@godzilla.zeta.org.au>
To: davo@katy.apana.org.au, freebsd-bugs@freebsd.org,
        freebsd-hackers@freebsd.org
Subject: Re: Interface problem
Cc: sa-tech@tierzero.apana.org.au
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>Hmmm, I've just noticed some errors showing in the system message
>buffer that are not turning up in /var/log/messages at least
>not in full.  dmesg shows:

>arpresolve: can't allocate llinfo
>and 110 more lines the same :(

>I only found two similar lines in /var/log/messages*

>messages.1:May 30 00:50:19 pasa /kernel: ocate llinfo
>messages.1:May 30 00:50:19 pasa /kernel: ocate llinfo

It looks like the message buffer filled up.

>Note, the machine has only been up 12 hours at the moment so the
>current stuff shown in dmesg is not getting logged.  Is there any
>way of simulating tail -f `dmesg` :)

It should get logged.

>> > User ppp caused a problem at first with "device not configured"
>> > sometimes and "can't find ifindex" at others.  We got past that
>> > one with some mods to the ppp code but yesterday, a cslip
>> > connection failed rather strangely.  Sliplogin worked ok and
>> > configured the interface (sl8) but I could not get it to come
>> > up.

The SLIOCSUNIT ioctl is poorly implemented in 2.1R and -stable.  It
always allocates the specified unit even if this unit is in use or
doesn't exist.  Perhaps this causes some of your other problems.

>Can anyone tell me why open(/dev/tun0) would return ENOXIO when
>the device is in use?

ENXIO.  It just returned ENXIO when it should have returned EBUSY.  This
was recently fixed in -current.

Bruce