Re: netstat: no namelist

[O. Hartmann]

On 02/27/12 16:29, Jason Hellenthal wrote:
> 
> 
> On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote:
>> On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing
>> "netstat on console or in terminal doesn't give the usual netstat as
>> expected, instead I receive
>>
>> netstat: no namelist
>>
>> What's wrong?
>>
> 
> This usually happens when kernel and world are built out of sync.
> Attempt to rebuild ( kernel first & then world ) follow the steps near
> /usr/src/UPDATING
> 
> 

... and by the way: I build kernel and world with CLANG by default.

oh



signature.asc
Description: OpenPGP digital signature

Re: netstat: no namelist

[O. Hartmann]

On 02/27/12 16:29, Jason Hellenthal wrote:
> 
> 
> On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote:
>> On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing
>> "netstat on console or in terminal doesn't give the usual netstat as
>> expected, instead I receive
>>
>> netstat: no namelist
>>
>> What's wrong?
>>
> 
> This usually happens when kernel and world are built out of sync.
> Attempt to rebuild ( kernel first & then world ) follow the steps near
> /usr/src/UPDATING
> 
> 

I did. Three times now. When building, I build everything, world AND
kernel. I delete /usr/obj/ as well.

Strange ...


Oliver



signature.asc
Description: OpenPGP digital signature

Re: netstat: no namelist

[Jason Hellenthal]

On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote:
> On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing
> "netstat on console or in terminal doesn't give the usual netstat as
> expected, instead I receive
> 
> netstat: no namelist
> 
> What's wrong?
> 

This usually happens when kernel and world are built out of sync.
Attempt to rebuild ( kernel first & then world ) follow the steps near
/usr/src/UPDATING


-- 
;s =;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: netstat output changes in 8.0?

[Nick Rogers]

On Tue, Jan 26, 2010 at 12:49 PM, Nick Rogers  wrote:

> Thanks a lot. Thats a bummer. What are the chances of getting something
> like that worked into arp(8) permanently?
>
>
I recently noticed that arp(8) was changed a few months back to show when an
entry expires. Thanks!

http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c?rev=1.75
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: netstat output changes in 8.0?

[Nick Rogers]

Thanks a lot. Thats a bummer. What are the chances of getting something like
that worked into arp(8) permanently?

On Tue, Jan 26, 2010 at 4:41 AM, Ruslan Ermilov  wrote:

> On Mon, Jan 25, 2010 at 07:01:46PM -0800, Nick Rogers wrote:
> > Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for
> > each host on the network, along with its MAC address. For example ...
> >
> > 172.20.172.17  00:02:b3:2f:64:6a  UHLW1 105712   1500
> >  vlan172595
> > 172.20.172.20  00:1e:c9:bb:7c:a9  UHLW1   1002   1500
> >  vlan172598
> > 172.20.172.22  00:14:5e:16:bb:b6  UHLW1107   1500
> >  vlan172491
> >
> > This behavior seems to have changed in 8.0, where now only the
> > locally-assigned IP addresses and related CIDRs are displayed.
>
> From src/UPDATING:
>
> : 20081214:
> : __FreeBSD_version 800059 incorporates the new arp-v2 rewrite.
> : RTF_CLONING, RTF_LLINFO and RTF_WASCLONED flags are eliminated.
> : The new code reduced struct rtentry{} by 16 bytes on 32-bit
> : architecture and 40 bytes on 64-bit architecture. The userland
> : applications "arp" and "ndp" have been updated accordingly.
> : The output from "netstat -r" shows only routing entries and
> : none of the L2 information.
>
> > Is there any way to get this behavior back, perhaps with a new flag that
> I
> > am not able to find? Or some sysctl? I have a script that was relying on
> > each host's "expire" flag in the routing table to determine when the MAC
> > address first appeared on the network according to ARP.
>
> If you need to know when a particular ARP entry expires, a variation
> of the following patch can be used, perhaps hiding this output by the
> -v (verbose) option.
>
> %%%
> Index: arp.c
> ===
> --- arp.c   (revision 203016)
> +++ arp.c   (working copy)
> @@ -101,7 +101,8 @@
>  static int nflag;  /* no reverse dns lookups */
>  static char *rifname;
>
> -static int expire_time, flags, doing_proxy, proxy_only;
> +static time_t  expire_time;
> +static int flags, doing_proxy, proxy_only;
>
>  /* which function we're supposed to do */
>  #define F_GET  1
> @@ -594,6 +595,15 @@
>printf(" on %s", ifname);
>if (rtm->rtm_rmx.rmx_expire == 0)
>printf(" permanent");
> +   else {
> +   static struct timeval tv;
> +   if (tv.tv_sec == 0)
> +   gettimeofday(&tv, 0);
> +   if ((expire_time = rtm->rtm_rmx.rmx_expire - tv.tv_sec) >
> 0)
> +   printf(" expires %d", (int)expire_time);
> +   else
> +   printf(" expired");
> +   }
>if (addr->sin_other & SIN_PROXY)
>printf(" published (proxy only)");
>if (rtm->rtm_flags & RTF_ANNOUNCE)
> %%%
>
>
> Cheers,
> --
> Ruslan Ermilov
> r...@freebsd.org
> FreeBSD committer
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: netstat output changes in 8.0?

[Ruslan Ermilov]

On Mon, Jan 25, 2010 at 07:01:46PM -0800, Nick Rogers wrote:
> Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for
> each host on the network, along with its MAC address. For example ...
> 
> 172.20.172.17  00:02:b3:2f:64:6a  UHLW1 105712   1500
>  vlan172595
> 172.20.172.20  00:1e:c9:bb:7c:a9  UHLW1   1002   1500
>  vlan172598
> 172.20.172.22  00:14:5e:16:bb:b6  UHLW1107   1500
>  vlan172491
> 
> This behavior seems to have changed in 8.0, where now only the
> locally-assigned IP addresses and related CIDRs are displayed.

>From src/UPDATING:

: 20081214:
: __FreeBSD_version 800059 incorporates the new arp-v2 rewrite.
: RTF_CLONING, RTF_LLINFO and RTF_WASCLONED flags are eliminated.
: The new code reduced struct rtentry{} by 16 bytes on 32-bit
: architecture and 40 bytes on 64-bit architecture. The userland
: applications "arp" and "ndp" have been updated accordingly.
: The output from "netstat -r" shows only routing entries and
: none of the L2 information.

> Is there any way to get this behavior back, perhaps with a new flag that I
> am not able to find? Or some sysctl? I have a script that was relying on
> each host's "expire" flag in the routing table to determine when the MAC
> address first appeared on the network according to ARP.

If you need to know when a particular ARP entry expires, a variation
of the following patch can be used, perhaps hiding this output by the
-v (verbose) option.

%%%
Index: arp.c
===
--- arp.c   (revision 203016)
+++ arp.c   (working copy)
@@ -101,7 +101,8 @@
 static int nflag;  /* no reverse dns lookups */
 static char *rifname;
 
-static int expire_time, flags, doing_proxy, proxy_only;
+static time_t  expire_time;
+static int flags, doing_proxy, proxy_only;
 
 /* which function we're supposed to do */
 #define F_GET  1
@@ -594,6 +595,15 @@
printf(" on %s", ifname);
if (rtm->rtm_rmx.rmx_expire == 0)
printf(" permanent");
+   else {
+   static struct timeval tv;
+   if (tv.tv_sec == 0)
+   gettimeofday(&tv, 0);
+   if ((expire_time = rtm->rtm_rmx.rmx_expire - tv.tv_sec) > 0)
+   printf(" expires %d", (int)expire_time);
+   else
+   printf(" expired");
+   }
if (addr->sin_other & SIN_PROXY)
printf(" published (proxy only)");
if (rtm->rtm_flags & RTF_ANNOUNCE)
%%%


Cheers,
-- 
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: netstat -ni - A lot of collisions...

[Jeremy Chadwick]

On Mon, Nov 06, 2006 at 09:37:26PM +, Matthew Seaman wrote:
> We've had a series of Broadcomm bge(4) network interfaces that would
> arbitrarily stop working if hardwired to 100-full, but that are doing
> just fine when allowed to autoneg.  Switches are mostly HP Procurve if
> that makes any difference.

Interesting.  I've got a ProCurve 2524 in our co-lo with tons of
FreeBSD boxes hooked to it, all of which behave correctly via auto-neg.
The FreeBSD boxes use a slew of NICs; em, fxp, and xl.  The uplink
port on our 2524 to our ISP, however, has to be set to 100/full on
both ends (theirs and ours; theirs = Cisco, ours = HP) or else we
end up with framing errors and other nonsense.

For sake of comparison, I have sitting in my workroom a bge-based
box hooked up to a ProCurve 2626 which behaves properly via auto-neg
on both the 100mbit and the gigabit ports (I've tried both).  I
have not tried hard-setting them, since auto-neg seems to work.

However, the instant I hook that box up to my Hawking non-managed
gigabit switch (which is a switch where auto-neg has worked with
every NIC I've tried until now), the switch and NIC auto-neg
correctly to 1gb/full... except packets appear busted in some way:
packets make it to the switch (one can see the LEDs blinking), yet
the IP stack doesn't see anything in return.  ARP also does not show
anything.  The fact that auto-neg is working, and that the switch
indicates correct speed and duplex, makes me think this is some
weird bge driver problem.  Wiring is all CAT6, and obviously works
fine with another switch.

If I set `media 100baseTX mediaopt full-duplex` and reboot, everything
works (at 100mbit of course) with that box.

I'd love to give a kernel developer access to that box via serial
console so they could debug what the heck is going on with auto-neg
in that particular case.  :-)

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -ni - A lot of collisions...

[Matthew Seaman]

[EMAIL PROTECTED] wrote:
>> I've never paid much attention to what ifconfig says, or what
>> managed switches say, as far as speed or duplex negotiation go.
>> Most vendors do not play well together.  I'll repeat that because
>> it needs repeating: most vendors do not play well together.
>> Example: anyone familiar with Cisco Catalysts knows of the
>> long-standing problem with auto-neg which ultimately requires
>> both ends of the connection be set to 100/full.
> 
> I disagree. Autonegotiation used to be a problem, and we used to force
> all links to 100/full. But that was 3-4 years ago. These days, the
> situation is much improved - and in most cases autonegotiation "just
> works". That includes *lots* of Cisco Catalyst switches.

Actually, we used to do the same.  But nowadays it's gone completely
the other way.  Modern GigE capable ethernet interfaces seem to work
better if you let them autonegotiate.  That's even if they aren't
running at Gig speed where autoneg is required by design.

We've had a series of Broadcomm bge(4) network interfaces that would
arbitrarily stop working if hardwired to 100-full, but that are doing
just fine when allowed to autoneg.  Switches are mostly HP Procurve if
that makes any difference.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature

Re: netstat -ni - A lot of collisions...

[sthaug]

> I've never paid much attention to what ifconfig says, or what
> managed switches say, as far as speed or duplex negotiation go.
> Most vendors do not play well together.  I'll repeat that because
> it needs repeating: most vendors do not play well together.
> Example: anyone familiar with Cisco Catalysts knows of the
> long-standing problem with auto-neg which ultimately requires
> both ends of the connection be set to 100/full.

I disagree. Autonegotiation used to be a problem, and we used to force
all links to 100/full. But that was 3-4 years ago. These days, the
situation is much improved - and in most cases autonegotiation "just
works". That includes *lots* of Cisco Catalyst switches.

Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -ni - A lot of collisions...

[Wilko Bulte]

On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Well,
> the card is connected to a switch that is manageble and the port is set to
> 10Mbit Full duplex on purpose.

Your ifconfig output below shows halfduplex!

> I'm not setting the port speed manual - is that a problem when the port is 
> not 100mbit/fd?
> This is the ifconfig output:
> 
> fxp0: flags=18843 mtu 1500
> options=48
> inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255
> inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2
> ether 00:08:c7:5b:54:a5
> media: Ethernet autoselect (10baseT/UTP)

^^^ like here.

Wilko
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -ni - A lot of collisions...

[Jeremy Chadwick]

On Mon, Nov 06, 2006 at 11:31:57AM +0200, Anton - Valqk wrote:
> Well,
> the card is connected to a switch that is manageble and the port is set to
> 10Mbit Full duplex on purpose.
> 
> I'm not setting the port speed manual - is that a problem when the port is 
> not 100mbit/fd?
> This is the ifconfig output:
> 
> fxp0: flags=18843 mtu 1500
> options=48
> inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255
> inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2
> ether 00:08:c7:5b:54:a5
> media: Ethernet autoselect (10baseT/UTP)
> status: active

I've never paid much attention to what ifconfig says, or what
managed switches say, as far as speed or duplex negotiation go.
Most vendors do not play well together.  I'll repeat that because
it needs repeating: most vendors do not play well together.
Example: anyone familiar with Cisco Catalysts knows of the
long-standing problem with auto-neg which ultimately requires
both ends of the connection be set to 100/full.

Try the following configurations:

1.  FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex
Switch -- forced 10/full
Reboot FreeBSD box

2.  FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex
Switch -- auto-neg
Reboot FreeBSD box

3.  FreeBSD rc.conf -- media 10baseT/UTP media-opt full-duplex
Switch -- auto-neg
Reboot FreeBSD box

Regarding the reboots: changing duplex/speed via ifconfig once
the driver has already done its initial auto-negotiation appears
to behave differently with some switches than on an actual
boot-up.  I have no present-day evidence to back this claim up,
but it's something I've seen historically with xl and fxp.

Now, the transfer test I've used in the past:

* Make a "small" file (dd if=/dev/urandom of=test.bin bs=64k
  count=256) on the FreeBSD box
* Make a similar file (identical or otherwise) on another box,
  one that runs an FTP server
* From the FreeBSD box, FTP to the FTP server
* Do an FTP "PUT" of test.bin
* Make note if the transfer was slow, or quick (1MByte/sec)
* Now do an FTP "GET" of the file you made on the FTP server
* Make note if the transfer was slow, or quick (1MByte/sec)

My guess is that one of the above tests will show very fast
throughput in one direction (ex. PUT), while the other direction
(ex. GET) will be incredibly slow (something like 100 bytes a
second, maybe less).  This is what I've seen in the past in
environments where a switch is set to auto-neg and the FreeBSD
box claims to auto-neg to 100/full correctly... but obviously
doesn't (re: see above: Cisco).

You can make note of collision counts if you want, too.  Any
slow transfers you see will probably show up as collisions, since
somewhere along the lines things got confused and chose half-duplex
(even if ifconfig or the switch doesn't show it).

If all of the above tests seem OK (good speed, etc. -- yet the
collisions continue to increase), I recommend checking the
obvious: Ethernet cable wiring.  You're going to have to get a
RJ45/EIA-568 cable tester and verify that all 8 wires are connected
and have good continuity.  You're not going to get 10/full with a
Ethernet cable that's wired with only 4 wires, AFAIK.

Finally: why exactly are you using 10/full?  What's the purpose?
Are you trying to limit the actual maximum network throughput while
ensuring you have full-duplex capability?  If so: look into using
pf with queueing (see pf.conf man page, section QUEUEING/ALTQ),
or if that's not an option, use ipfw with dummynet.  Make that
box use 100/full, then simply limit the actual network I/O to
10mbit.

For what it's worth: I've never seen a 10/full network that
worked.  It was either 100/full (switches), 100/half (hubs),
or 10/half (hubs).  There's some discussions (use Google)
about why 10/full is essentially a bastard child and should be
avoided.

-- 
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator   Mountain View, CA, USA |
| Making life hard for others since 1977.   PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -ni - A lot of collisions...

[Oliver Fromme]

Anton - Valqk <[EMAIL PROTECTED]> wrote:
 > the card is connected to a switch that is manageble and the port is set
 > to 10Mbit Full duplex on purpose.
 > 
 > I'm not setting the port speed manual - is that a problem when the port
 > is not 100mbit/fd?

If you select the port parameters manually (i.e. disable
autoselect), then you must do that on _both_ sides.
Auto-negotiation only works correctly if both sides are
using it.

 > This is the ifconfig output:
 > 
 > fxp0: flags=18843 mtu 1500
 > options=48
 > inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255
 > inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2
 > ether 00:08:c7:5b:54:a5
 > media: Ethernet autoselect (10baseT/UTP)
 > status: active

That means autoselect is enabled, so you have to enable it
on your switch, too.  Otherwise disable it on the computer
and select the port parameters (speed and duplex mode)
manually there, too.

By the way, the above output indicates that your NIC's
auto-negotiation has selected half-duplex.  You said that
your switch is set to full-duplex.  So there is a mismatch
which explains why you are getting collisions.

Fix your port settings, then the collisions will go away.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -ni - A lot of collisions...

[Anton - Valqk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Well,
the card is connected to a switch that is manageble and the port is set to
10Mbit Full duplex on purpose.

I'm not setting the port speed manual - is that a problem when the port is not 
100mbit/fd?
This is the ifconfig output:

fxp0: flags=18843 mtu 1500
options=48
inet 112.15.128.88 netmask 0xff00 broadcast 112.15.128.255
inet6 fe80::208:c7ff:fe5b:54f2%fxp0 prefixlen 64 scopeid 0x2
ether 00:08:c7:5b:54:a5
media: Ethernet autoselect (10baseT/UTP)
status: active

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFTwENzpU6eaWiiWgRAjwgAJ4rfWbA5xDWmHE1MxWn36j2Njs/swCbBzJM
Hg+zdfQGMra50Rh7k290Ofw=
=DtBT
-END PGP SIGNATURE-

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -ni - A lot of collisions...

[Matthew Seaman]

Anton - Valqk wrote:

> netstat -ni
> NameMtu Network   Address  Ipkts IerrsOpkts
> Oerrs  Coll
> fxp0   1500   00:08:c7:5b:53:5f  4504986 0  2093233
> 0 185206

Hmmm... what's the output of 'ifconfig fxp0'?  Are you by any chance
running this card in half-duplex mode?

If you were connecting to a hub (rather than a switch) and all of your
network was running half-duplex, then that level of collisions wouldn't
be particularly remarkable.  However nowadays basic 100Mb switches are
cheap, so that would be rather unusual.  However, a card that fails to
autonegotiate with the switch will fall back to running at 100-half.

That's generally pretty obvious because performance will be abysmal.

Other alternatives are hardware problems -- try a different ethernet
cable.  Try plugging into a different port on the switch.  Try a different
computer on the cable etc. where you're seeing the problems.  If none of
that identifies a fault in the cabling, then it's looking more likely that
your network interface has gone fubar.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature

Re: netstat -m broken.

[Max Laier]

On Monday 11 April 2005 18:42, Maxim Konovalov wrote:
> On Mon, 11 Apr 2005, 12:07-0400, David Gilbert wrote:
> > I'm runing 5.4-STABLE on an dual processor amd64.  I'm using the
> > network pretty heavily (dual GigE interfaces doing 300 megabit each)
> > and my netstat -m is giving odd results:
>
> FAQ.  Documented in 5.3 errata:
> http://www.freebsd.org/releases/5.3R/errata.html

Maybe we should add that:
$vmstat -z | grep Mbuf
gives an idea of the actual memory usage for mbufs.

-- 
/"\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News


pgpqm9vSn0fiU.pgp
Description: PGP signature

Re: netstat -m broken.

[Maxim Konovalov]

On Mon, 11 Apr 2005, 12:07-0400, David Gilbert wrote:

> I'm runing 5.4-STABLE on an dual processor amd64.  I'm using the
> network pretty heavily (dual GigE interfaces doing 300 megabit each)
> and my netstat -m is giving odd results:

FAQ.  Documented in 5.3 errata:
http://www.freebsd.org/releases/5.3R/errata.html

-- 
Maxim Konovalov
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat fails with memory allocation error and error in kvm_read

[J. Martin Petersen]

Max Laier wrote:
On Wednesday 05 January 2005 18:26, J. Martin Petersen wrote:
 

We just had another hard hang, and this time I managed to break to the
debugger on the serial console. I got this stack trace
, which seems to indicate that pf is
messing up somehow.
   

This looks like pf.c, rev. 1.25 (HEAD) 1.18.2.6 (RELENG_5) and is an endless 
loop, not a deadlock. 
 

My bad.
I hope you can verify that updating to these revisions 
solves the issue. Please get back to me if not. Thanks in advance.
 

I'm checking sys/contrib/pf out from the releng_5 branch and will 
compile a new kernel. I'll get back to you if that doesn't help.

Thanks for the help
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat fails with memory allocation error and error in kvm_read

[Max Laier]

On Wednesday 05 January 2005 18:26, J. Martin Petersen wrote:
> > I just got another "netstat: kvm_read: Bad address".
> > vm.kvm_free was 675278848 two seconds earlier and a couple of
> > seconds later (and also currently).
>
> We just had another hard hang, and this time I managed to break to the
> debugger on the serial console. I got this stack trace
> , which seems to indicate that pf is
> messing up somehow.

This looks like pf.c, rev. 1.25 (HEAD) 1.18.2.6 (RELENG_5) and is an endless 
loop, not a deadlock. I hope you can verify that updating to these revisions 
solves the issue. Please get back to me if not. Thanks in advance.

> I of course didn't have the ddb man or the handbook section on kernel
> debugging at hand, so I've just printed it for the next time it happens.
>
> Both 'show witness' and 'show locks' came up empty. What's the most
> effective way to hunt down these deadlocks with the online kernel debugger?


-- 
/"\  Best regards,  | [EMAIL PROTECTED]
\ /  Max Laier  | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | [EMAIL PROTECTED]
/ \  ASCII Ribbon Campaign  | Against HTML Mail and News


pgpdtRXn4kKUV.pgp
Description: PGP signature

RE: netstat fails with memory allocation error and error in kvm_read

[J. Martin Petersen]

> I just got another "netstat: kvm_read: Bad address". 
> vm.kvm_free was 675278848 two seconds earlier and a couple of 
> seconds later (and also currently).

We just had another hard hang, and this time I managed to break to the
debugger on the serial console. I got this stack trace
, which seems to indicate that pf is
messing up somehow. 

I of course didn't have the ddb man or the handbook section on kernel
debugging at hand, so I've just printed it for the next time it happens.

Both 'show witness' and 'show locks' came up empty. What's the most
effective way to hunt down these deadlocks with the online kernel debugger? 

Best regards
Martin

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: netstat fails with memory allocation error and error in kvm_read

[techlists]

 
> > > You appear to be running out of kernel memory. Since you're 
> > > capturing the output of vmstat -m, you should check that for any 
> > > bins that are growing at a high rate of speed.
> > >
> > > Seems possible that its in pf :)
> >
> > I've checked the numbers from just before the freeze (it's 
> within 15 
> > secs) with two sets of data: From a fresh boot and five minutes 
> > minutes before the freeze.
> 
> You might also log 'sysctl vm.kvm_free' and 'sysctl vm.zone'.

sysctl vm.zone is identical to vmstat -z (according to man vmstat).

I've graphed the output from iostat (idle/user/...), vmstat -i (interrupt
rate), vmstat -m (in use), vmstat -z (used), sysctl vm.kvm_free (which is
constant) and the number of pfstates. The graphs are at
. The newest data are from just after a
deadlock. Are there something else I should graph?

IRQ 20 is the NIC on our internal network (800+ machines), IRQ 18 and IRQ21
are NICs connected to the internet. There are a lot of changes on the vmstat
-m graphs just before midnight last night that seems to correspond with the
increase in interrupts on IRQ 18. 

The only graphs I can see changing up to the deadlock are:
irq20 (internal NIC), 
irq21 (primary external NIC), 
the buckets (vmstat -z) all grow (I suppose this is normal?)
the Mbufs seems to grow, but nothing extreme
pffrag, pffrent (but not to levels they haven't been at before)

Most notably most of the pf graphs doesn't change. Where can I see memory
used by pf/altq? If it is pfaltqpl (in vmstat -z), it doesn't change at all.

I'm in the process of setting up a serial console in the hope that I can
break to the debugger with that. I'm also trying to provoke the deadlock so
it will happen more frequently.

/Martin

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: netstat fails with memory allocation error and error in kvm_read

[J. Martin Petersen]

 
> You might also log 'sysctl vm.kvm_free' and 'sysctl vm.zone'.

I just got another "netstat: kvm_read: Bad address". vm.kvm_free was
675278848 two seconds earlier and a couple of seconds later (and also
currently).



The output from vm.zone a couple of seconds after:
vm.zone:
ITEMSIZE LIMIT USEDFREE  REQUESTS

pfosfp:   28,0,155,226, 1085
pfospfen:108,0,293, 31, 2051
pfiaddrpl:92,0,  5, 79,   28
pfstatescrub:  8,0,  26676,  28540, 37487180
pffrcent: 12,50141,  0,  0,0
pffrcache:48,10062,  0,  0,0
pffrag:   48,0,  0,234,   378044
pffrent:  16, 5075,  0,203,   934804
pfrkentry:   152,0,  4, 48,8
pfrktable:   248,0,  4, 28,   12
pfpooladdrpl: 68,0, 21, 91,  126
pfaltqpl:128,0, 19, 71,  133
pfstatepl:   256,65010,  14396,  23014, 29835551
pfrulepl:560,0,248,221, 1693
pfsrctrpl:80,0,  0,  0,0
FFS2 dinode: 256,0,  32828,427,  1154768
FFS1 dinode: 128,0,  0,  0,0
FFS inode:   140,0,  32828,352,  1154768
SWAPMETA:276,63672,  9, 47,   40
rtentry: 132,0,219,187, 
unpcb:   140,17220,  9, 47, 5217
ripcb:   180, 8140,  0, 44,   15
sackhole: 16,0,  0,203, 3107
tcpreass: 20, 1183,  0,169,  134
hostcache:88,15400,  3, 85,   39
syncache:108,15372,  0, 72,  374
tcptw:56, 1675,  2,132,   48
tcpcb:   448, 8136,  4, 23,  489
inpcb:   180, 8140,  6, 38,  489
udpcb:   180, 8140, 11, 33,  6297398
socket:  324, 8136, 24, 36,  6303121
KNOTE:68,0,  0,112, 12538429
PIPE:384,0,  2, 78,   251051
DIRHASH:1024,0,   1621, 11, 4318
NAMEI:  1024,0,  3, 17, 131064562
L VFS Cache: 291,0, 38,456, 8482
S VFS Cache:  68,0,  29954,   5550,  1214821
VNODEPOLL:64,0,  0,118,2
VNODE:   264,0,  33205, 20,33205
ata_request: 200,0,  0, 38,  2322599
g_bio:   132,0,  0,   2204,  4301499
MbufClust:  2048,17216,906,124, 12121216
Mbuf:256,0,907,188, 2520398988
Packet:  256,0,740,355, 2728311990
VMSPACE: 300,0, 23, 81,   726569
UPCALL:   44,0,  0,  0,0
KSEGRP:  104,0,144, 31,  144
TID: 140,0,  1, 53,1
THREAD:  388,0,144,  6,  144
PROC:452,0, 73, 71,   726627
Files:68,0, 71,153, 122894112
4096:   4096,0,129, 60,   746477
2048:   2048,0,130, 30,24039
1024:   1024,0, 23, 61, 14341894
512: 512,0,244, 92,   656520
256: 256,0,256,   1094,  7153814
128: 128,0,   1842,318, 15428344
64:   64,0,   4481,   1183,  8923514
32:   32,0,   2595,682, 408850
16:   16,0,   1930,303, 22115093
DP fakepg:72,0,  0,  0,0
PV ENTRY: 24,   944530,   5540,  17080, 315728548
MAP ENTRY:68,0,439,   1241, 32683625
KMAP ENTRY:   68,32200, 40,464,  557
MAP: 192,0,  7, 33,5
VM OBJECT:   132,0,  32560,   1428, 14688659
128 Bucket:  524,0,966,  0,0
64 Bucket:   268,0, 30, 40,0
32 Bucket:   140,0, 30, 26,0
16 Bucket:76,0, 15, 35,0
UMA Hash:128,0,  2, 28,0
UMA RCntSlab:104,0,515,  3,0
UMA Slabs:64,0,793, 33,0
UMA Zones:88,0, 73,  7,0
UMA Kegs:136,0, 73, 23,0


vm.zone a couple of seconds before:
ITEMSIZE LIMIT USEDFREE  REQUESTS

pfosfp:   28,0,155,226, 1085
pfospfen:108,0,293, 31, 2051
pfiaddrpl:92,0,  5, 79,   28
pfstatescrub:  8,0,  27146,  28070, 37485813
pffrcent: 12,50141,  0,  0,   

RE: netstat fails with memory allocation error and error in kvm_read

[Doug White]

On Mon, 13 Dec 2004, J. Martin Petersen wrote:

> > > We are trying to gather some debug information for a problem that is
> > > difficult to diagnose, as the machine always ends up hard frozen
> > > (does not do anything, can not break to debugger, does not respond
> > > to keyboard, etc.), so we are dumping output from netstat, vmstat,
> > > iostat etc. quite often.
> > >
> > > The cron jobs fail ever so often with error messages I do not quite
> > > understand, and I can not find anything relevant in the archives.
> > > Can anyone shed some light on this?
> > >
> > > Command:  netstat -r
> > > Error message: netstat: kvm_read: Bad address Debug before:
> > > http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.34.41.gz
> > > Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.35.06.gz
> > > # errors: 7
> > >
> > > Command:  netstat -an
> > > Error message:netstat: sysctl: net.inet.udp.pcblist: Cannot allocate
> > > memory Debug before:
> > > http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.38.48.gz
> > > Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.39.04.gz
> > > # errors: 3
> >
> > You appear to be running out of kernel memory. Since you're capturing
> > the output of vmstat -m, you should check that for any bins that are
> > growing at a high rate of speed.
> >
> > Seems possible that its in pf :)
>
> I've checked the numbers from just before the freeze (it's within 15 secs)
> with two sets of data: From a fresh boot and five minutes minutes before the
> freeze.

You might also log 'sysctl vm.kvm_free' and 'sysctl vm.zone'.


> Here are the stuff that changed significantly between the fresh boot and
> just before the freeze:
>
> Just before the freeze
> (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.59.01.gz):
>AR driver 2 1K268K  2922822  64,256,512,2048
>kqueue 0 0K 38K 13304405  128,1024
>   UFS dirhash   44488K107K 2559
> 16,32,64,128,256,512,1024,2048,4096
>  freeblks13 4K 29K   103030  256
>  freefrag 0 0K  1K   164217  32
>allocindir   28718K162K  1966413  64
>  indirdep 1 1K209K 9925  32
>   allocdirect27 4K 18K   301048  128
>  inodedep18   131K150K   164032  128,256
>  routetbl   56647K 67K   800649  16,32,64,128,256
>   subproc99   301K849K  1873146  32,4096
>
> Five minutes before the freeze
> (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.55.42.gz):
>  AR driver 2 1K268K  2921793  64,256,512,2048
>kqueue 0 0K 38K 13296556  128,1024
>   UFS dirhash   44488K107K 2559
> 16,32,64,128,256,512,1024,2048,4096
>  freeblks 1 1K 29K   102978  256
>  freefrag 0 0K  1K   164153  32
>allocindir 0 0K162K  1965284  64
>  indirdep 0 0K209K 9921  32
>   allocdirect 1 1K 18K   300886  128
>  inodedep14   130K150K   163954  128,256
>  routetbl   56246K 67K   800255  16,32,64,128,256
>   subproc99   301K849K  1872250  32,4096
>
> >From a fresh boot
> (http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-23.31.31.gz):
> AR driver 2 1K190K23450  64,256,512,2048
>kqueue 0 0K  3K 1062  128,1024
>   UFS dirhash3613K 13K   42  16,32,512,2048,4096
>  freeblks   11529K 29K  253  256
>  freefrag 0 0K  1K   51  32
>allocindir 2 1K135K 3332  64
>  indirdep10 1K173K  630  32
>   allocdirect 2 1K 40K  456  128
>  inodedep   137   145K168K  506  128,256
>  routetbl   30626K 27K  495  16,32,64,128,256
>   subproc   107   317K466K 1554  32,4096
>
> The numbers for pflog and pf_if does not change at all. I checked vmstat -z,
> and the highest pf-related entries we're actually decreasing at the time of
> the deadlock, but I noticed the following:
> VM OBJECT:   132,0,  31508,   2132, 14364021
> 128 Bucket:  524,0,727,  1,0
> 64 Bucket:   268,0, 23, 19,0
> 32 Bucket:   140,0, 34, 22,0
> 16 Bucket:76,0, 15, 35,0
>
> Can you or anyone else deduce anything from the numbers? If not, I'll whip
> something together that runs vmstat -m ever so often, parses the output and
> remove the non-increasing entries so it'll be easier to spot the trends.
>
> Thanks, Martin
>
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo

RE: netstat fails with memory allocation error and error in kvm_read

[J. Martin Petersen]

 

> > We are trying to gather some debug information for a problem that is 
> > difficult to diagnose, as the machine always ends up hard frozen 
> > (does not do anything, can not break to debugger, does not respond 
> > to keyboard, etc.), so we are dumping output from netstat, vmstat, 
> > iostat etc. quite often.
> >
> > The cron jobs fail ever so often with error messages I do not quite 
> > understand, and I can not find anything relevant in the archives. 
> > Can anyone shed some light on this?
> >
> > Command:netstat -r
> > Error message: netstat: kvm_read: Bad address Debug before: 
> > http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.34.41.gz
> > Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.35.06.gz
> > # errors:   7
> >
> > Command:netstat -an
> > Error message:netstat: sysctl: net.inet.udp.pcblist: Cannot allocate 
> > memory Debug before: 
> > http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.38.48.gz
> > Debug after: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.39.04.gz
> > # errors:   3
> 
> You appear to be running out of kernel memory. Since you're capturing 
> the output of vmstat -m, you should check that for any bins that are 
> growing at a high rate of speed.
> 
> Seems possible that its in pf :)

I've checked the numbers from just before the freeze (it's within 15 secs)
with two sets of data: From a fresh boot and five minutes minutes before the
freeze. 

Here are the stuff that changed significantly between the fresh boot and
just before the freeze:

Just before the freeze
(http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.59.01.gz):
   AR driver 2 1K268K  2922822  64,256,512,2048
   kqueue 0 0K 38K 13304405  128,1024
  UFS dirhash   44488K107K 2559
16,32,64,128,256,512,1024,2048,4096
 freeblks13 4K 29K   103030  256
 freefrag 0 0K  1K   164217  32
   allocindir   28718K162K  1966413  64
 indirdep 1 1K209K 9925  32
  allocdirect27 4K 18K   301048  128
 inodedep18   131K150K   164032  128,256
 routetbl   56647K 67K   800649  16,32,64,128,256
  subproc99   301K849K  1873146  32,4096

Five minutes before the freeze
(http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-22.55.42.gz):
 AR driver 2 1K268K  2921793  64,256,512,2048
   kqueue 0 0K 38K 13296556  128,1024
  UFS dirhash   44488K107K 2559
16,32,64,128,256,512,1024,2048,4096
 freeblks 1 1K 29K   102978  256
 freefrag 0 0K  1K   164153  32
   allocindir 0 0K162K  1965284  64
 indirdep 0 0K209K 9921  32
  allocdirect 1 1K 18K   300886  128
 inodedep14   130K150K   163954  128,256
 routetbl   56246K 67K   800255  16,32,64,128,256
  subproc99   301K849K  1872250  32,4096

>From a fresh boot
(http://www.aub.dk/~jmp/fw/tmp/debug-2004.12.11-23.31.31.gz):
AR driver 2 1K190K23450  64,256,512,2048
   kqueue 0 0K  3K 1062  128,1024
  UFS dirhash3613K 13K   42  16,32,512,2048,4096
 freeblks   11529K 29K  253  256
 freefrag 0 0K  1K   51  32
   allocindir 2 1K135K 3332  64
 indirdep10 1K173K  630  32
  allocdirect 2 1K 40K  456  128
 inodedep   137   145K168K  506  128,256
 routetbl   30626K 27K  495  16,32,64,128,256
  subproc   107   317K466K 1554  32,4096

The numbers for pflog and pf_if does not change at all. I checked vmstat -z,
and the highest pf-related entries we're actually decreasing at the time of
the deadlock, but I noticed the following:
VM OBJECT:   132,0,  31508,   2132, 14364021
128 Bucket:  524,0,727,  1,0
64 Bucket:   268,0, 23, 19,0
32 Bucket:   140,0, 34, 22,0
16 Bucket:76,0, 15, 35,0

Can you or anyone else deduce anything from the numbers? If not, I'll whip
something together that runs vmstat -m ever so often, parses the output and
remove the non-increasing entries so it'll be easier to spot the trends.

Thanks, Martin

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat fails with memory allocation error and error in kvm_read

[Doug White]

On Fri, 10 Dec 2004, J. Martin Petersen wrote:

> We are trying to gather some debug information for a problem that is difficult
> to diagnose, as the machine always ends up hard frozen (does not do anything,
> can not break to debugger, does not respond to keyboard, etc.), so we are
> dumping output from netstat, vmstat, iostat etc. quite often.
>
> The cron jobs fail ever so often with error messages I do not quite 
> understand,
> and I can not find anything relevant in the archives. Can anyone shed some 
> light
> on this?
>
> Command:  netstat -r
> Error message:netstat: kvm_read: Bad address
> Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.34.41.gz
> Debug after:  http://www.aub.dk/~jmp/fw/debug-2004.12.09-21.35.06.gz
> # errors: 7
>
> Command:  netstat -an
> Error message:netstat: sysctl: net.inet.udp.pcblist: Cannot allocate 
> memory
> Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.38.48.gz
> Debug after:  http://www.aub.dk/~jmp/fw/debug-2004.12.09-07.39.04.gz
> # errors: 3

You appear to be running out of kernel memory. Since you're capturing the
output of vmstat -m, you should check that for any bins that are growing
at a high rate of speed.

Seems possible that its in pf :)

>
> Command:  netstat -an
> Error message:netstat: sysctl: net.inet.raw.pcblist: Cannot allocate 
> memory
> Debug before: http://www.aub.dk/~jmp/fw/debug-2004.12.10-22.19.50.gz
> Debug after:  http://www.aub.dk/~jmp/fw/debug-2004.12.10-22.20.10.gz
> # errors: 6
>
> The number of errors are in the last five days. Kernelconfig (FIREWALL), 
> dmesg,
> pf.conf etc. can be found at http://www.aub.dk/~jmp/fw/
>
> The commands we are running are:
>   netstat -i, netstat -m, netstat -s, netstat -an, netstat -r
>   vmstat, vmstat -i, vmstat -f, vmstat -m, vmstat -z
>   iostat
>   ps waux
> every 15 seconds. We are running the same commands (plus pfctl -vvsa) from
> root's cron every minute.
>
> The hard lockups seems to be connected to our use of pf and altq, that is at
> least the problem we're trying to gather debug information for.
>
> Thanks in advance
> Martin
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -finet not working after upgrading to 5.3-STABLE

[Brian Candler]

> On Sat, Nov 20, 2004 at 03:55:11PM +, Brian Candler wrote:
> > I started with a fresh 5.3-RELEASE install and then upgraded the kernel
> > source to 5.3-STABLE
> 
> Sorry, I meant to say 5-STABLE. The release tag is RELENG_5 (I just used
> /usr/share/examples/cvsup/stable-supfile)

Well, the full buildworld / buildkernel / installkernel / installworld
sequence fixed it, so it's not a problem any more. I'd still like to know
what had changed underneath though :-)

Regards,

Brian.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat -finet not working after upgrading to 5.3-STABLE

[Brian Candler]

On Sat, Nov 20, 2004 at 03:55:11PM +, Brian Candler wrote:
> I started with a fresh 5.3-RELEASE install and then upgraded the kernel
> source to 5.3-STABLE

Sorry, I meant to say 5-STABLE. The release tag is RELENG_5 (I just used
/usr/share/examples/cvsup/stable-supfile)

Cheers,

Brian.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: netstat reports "kvm_read: bad address"

[Valentin Nechayev]

> kervorkian 187# netstat -rn
> [...]
> 10.10.220/24   link#2 UC  00  de1 =>
> netstat: kvm_read: Bad address
> 10.10.220.60   0:d0:b7:b9:1e:3a   UHLW0  167  de1496
> netstat: kvm_read: Bad address
> 10.10.220.70   0:d0:b7:b9:21:3e   UHLW0  210  de1496
> netstat: kvm_read: Bad address
> 10.10.220.73   0:d0:b7:b9:b4:e7   UHLW0  209  de1496
> netstat: kvm_read: Bad address
> 10.10.220.74   0:d0:b7:b9:1d:66   UHLW0  209  de1495
> netstat: kvm_read: Bad address

I observe occasionally such failings on our http proxy server with
`netstat -an'.  This host is dual-processor. AFAIU reading of /dev/kmem
does not lock Giant lock (or its equivalent on 4.x), and one process
can traverse kernel structures in userland mode while some kernel code
on another processor changes it. If reported problems with `netstat -rn'
are occasional and system is SMP, this can be diagnosed as non-serializable
access problem.

But possibly routing subsystem has some own flawnesses. My friend has
multihomed host with 3 restricted BGP feeds in receive-only mode.
Stable routing table size is ~900 routes.  Independently on UP/SMP,
3.x/4.x, minor system versions, zebra versions, running this BGP
speaker with zebra leads to crash in no more than 12 hours. We could not
obtain any sensitive information from crash dumps because kernel
structures was spoiled to unparseable mash. Without routing daemon
or with gated, this host stays for months. Analysis of zebra says that
it does not use kmem or any another nonstandard interface, only common
unix interfaces up to routing sockets.


/netch

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: netstat reports "kvm_read: bad address"

[David Malone]

I think Peter (roam not peter) posted a patch for this problem in
response to a PR earlier this week. I think he assigned the PR to
Ruslan, so I suspect it will be fixed soon.

David.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

re: netstat

[Galen Sampson]

Hello,
   Fixed my problem.  I was indeed not using a kernel that was built with the
updated source.  I compiled my new kernel with 'make -kernel=sampson' and
installed with 'make install -kernel=sampson' but did not set up boot.conf to
boot that kernel =P. Thanks to all that replied.

Couple of questions:
1) Is there any good reason why you would want to use the '-kernel=foo' other
   than customization?

2) I've noticed in the handbook that you can 'make all install' certain
   portions of the source tree and update your system.  This seems appealing
   since you don't have to build anything and can update only certain parts
   (ntpd for instance).  The question is should you go to single user mode
   (because of chflags being set or what not)?  When is it ok to not go to
   single user mode and how can you tell?

Galen Sampson

>On Tuesday 03 April 2001 02:13, you wrote:
>> Hi all,
>>I have been experiencing some strange behavior with netstat.  It only
>> displays UDP sockets for the inet family.  TCP sockets do not show up.  I
>> know it is listening on TCP sockets because I can ssh/telnet/ftp/etc to
>> the machine. Netstat has been exhibiting this behavior from a make world
>> 2 weeks ago. After updating my source tree today from cvsup10.freebsd.org
>> and rebuilding the world I am getting the same symptoms.  I'd love to put
>> up some debug info for someone to figure this out, but I have know idea
>> what to put.  Is this problem just me?
>>
>> pointers/tips welcome
>>
>> Galen Sampson
>>
>
>Hi Galen,
>
>Must be only you, I certainly don't have that problem.
>4.3-RC2 from the CD.  Sources have been upgraded, but haven't built world 
>yet.

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: netstat

[Galen Sampson]

Did that unfortunately...built and installed the new kernel while still in
single user mode after I installed the new world.

--- Gregory Bond <[EMAIL PROTECTED]> wrote:
> >I have been experiencing some strange behavior with netstat. 
> 
> First check: are you sure that your installed userland and running kernel are
> 
> built from the same set of sources?  IE you have built and installed a kernel
> 
> and rebooted when you last diod a make world?
> 
> 


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: netstat

[Gregory Bond]

>I have been experiencing some strange behavior with netstat. 

First check: are you sure that your installed userland and running kernel are 
built from the same set of sources?  IE you have built and installed a kernel 
and rebooted when you last diod a make world?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Re: netstat problem

[Maxime Henrion]

[EMAIL PROTECTED] wrote:
> 
> 
> On Sun, 4 Mar 2001, Maxime Henrion wrote:
> 
> > I didn't rebuild world, only the kernel, but I rebuilt netstat too to
> > be sure it wasn't a kernel/userland sync problem even if /usr/src/UPDATING
> > says nothing about this.
> 
> did you rebuild libkvm before netstat?
Now I did, and the output is still scrambled.

Maxime
-- 
Don't be fooled by cheap finnish imitations ; BSD is the One True Code
Key fingerprint = F9B6 1D5A 4963 331C 88FC  CA6A AB50 1EF2 8CBE 99D6
Public Key : http://www.epita.fr/~henrio_m/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message