Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Dec 1996 16:10:41 +0000
From:      Paul Abraham Mullaseril <pabraham@PAbraham-S.mankato.msus.edu>
To:        bugs@freebsd.org
Subject:   Bug in Free BSD 2.1.6
Message-ID:  <32B02E81.41C67EA6@PAbraham-S.mankato.msus.edu>

next in thread | raw e-mail | index | archive | help
Sir(s),

I have been experiencing difficulties with my network when using FreeBSD 
2.1.5. Enclosed is some correspondence I received when this problem was 
posed at questions@freebsd.org . I do not know if the diagnosis is right 
because others do not experiece the same problem i.e. the m/c goes off 
the network if anyone tries to access the m/c via ftp or the web server 
or if mail a document with an enclosed file. However simple mail as well 
as telnet sessions are allowed. The diagnosis was that the vxdriver is 
faulty. Please advice.

Thanx
Paul Abraham




---------- Forwarded message ----------
Date: Thu, 5 Dec 1996 17:21:07 +0100 (MET)
From: Greg Lehey <grog@lemis.de>
To: Paul Abraham Mullaseril <pabraham@PAbraham-S.mankato.msus.edu>
Cc: FreeBSD Questions <questions@FreeBSD.org>
Subject: Re: Buffer

Paul Abraham Mullaseril writes:
> Hi Greg,
> My apologies for not being specific. The version of BSD is 2.1.5 (August
> 1996). I notice the problem occurs wheneever there is an external access
> to the machine via ftp or web server (apache) or I send a mail with an
> attachment like a large postscript file etc. The machine has a 3com
> Etherlink III network card (specifically 3C590-TPO). I have collected
> some statistics that may be usefull.
>
> The output from netstat -m is
> 145 mbufs in use:
>         69 mbufs allocated to data
>         16 mbufs allocated to packet headers
>         44 mbufs allocated to protocol control blocks
>         16 mbufs allocated to socket names and addresses
> 5/48 mbuf clusters in use
> 114 Kbytes allocated to network (24% in use)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines

So far, this looks fine.  Plenty of buffers available.

> The output from ping 134.29.1.1 (name server) is:
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> PING 134.29.1.1 (134.29.1.1): 56 data bytes
> ping: wrote 134.29.1.1 64 chars, ret=-1


> ping: wrote 134.29.1.1 64 chars, ret=-1
> ping: wrote 134.29.1.1 64 chars, ret=-1
> ping: wrote 134.29.1.1 64 chars, ret=-1
>
> --- 134.29.1.1 ping statistics ---
> 3 packets transmitted, 0 packets received, 100% packet loss

This is a different matter.  This is typical of a down link.  You send
off packets to the name server, and for some reason they don't get
sent.  After 50 packets accumulate, the driver refuses to accept any
more, and that's the message you get.

> The output from mailq (when stuck is ):
>                Mail Queue (3 requests)
> --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
> UAA12735       51 Tue Dec  3 20:09 pabraham
>                  (host map: lookup (canes.gsw.peachnet.edu): deferred)
>                                    Elizabeth Abraham
> <eabraham@canes.gsw.peachne
> TAA12414   351751 Tue Dec  3 19:24 pabraham
>                  (host map: lookup (epsilon.cs.mankato.msus.edu): deferred)
>                                    "David J. Haglin"
> <haglin@epsilon.cs.mankato.
> TAA12407   522300 Tue Dec  3 19:20 pabraham
>                  (host map: lookup (epsilon.cs.mankato.msus.edu): deferred)
>                                    "David J. Haglin"
> <haglin@epsilon.cs.mankato.

Yes, that's reasonable.  sendmail is attempting to look up the address
of the recipient machines, and it can't get the name server machine.

> I also note that this has instead of "lookup" "I/O error" after several
> attempts.

Interesting.  I haven't seen that one, but it doesn't look important
enough to follow up on yet.
> I guess if I can increase the buffer space I will be able to solve the
> problem. The output of df is:
> Filesystem  512-blocks     Used    Avail Capacity  Mounted on
> /dev/sd0a        63550    25682    32784    44%    /
> /dev/sd0s2f    3855822   745712  2801646    21%    /usr
> /dev/sd0s2e      59454    12948    41750    24%    /var
> procfs               8        8        0   100%    /proc

The buffer space is in memory, not on disk.  But you're not short of
buffer space (the netstat says you're only using 24%), so there's no
worry there.

The real problem is that your ethernet link appears to be going down.
There were problems with the vx driver in 2.1.5, and at a rough guess
I'd say that's what's biting you.  I don't know if 2.1.6 is any
better, but you could try it, or if you're prepared to try the 2.2
snapshot, that might help.  2.2 will be coming out in a month or two,
so if you can hold through until then, that might be a better
alternative.

Greg



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32B02E81.41C67EA6>