freebsd-stable Digest, Vol 186, Issue 2

Send freebsd-stable mailing list submissions to
freebsd-stable@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body ‘help’ to
freebsd-stable-request@freebsd.org

You can reach the person managing the list at
freebsd-stable-owner@freebsd.org

When replying, please edit your Subject line so it is more specific
than “Re: Contents of freebsd-stable digest…”

Today’s Topics:

1. Re: apache and php5 (Iassen Anadoliev)
2. bge Ierr rate increase from 5.3R -> 6.1R (Greg Eden)
3. Re: ggate still broken on 6.2-RC1 for amd64. (David Gilbert)
4. malloc(0) returns 0x800 on FreeBSD 6.2 ? (Luigi Rizzo)
5. Re: Zoneli State / Nttcp client. (LI Xin)
6. Re: deadlock in “zoneli” state on 6.2-PRERELEASE (Nikolay Pavlov)
7. Re: malloc(0) returns 0x800 on FreeBSD 6.2 ? (Dan Nelson)
8. Re: ggate still broken on 6.2-RC1 for amd64. (Ulrich Spoerlein)
9. Re: malloc(0) returns 0x800 on FreeBSD 6.2 ? (Dan Nelson)
10. Re: deadlock in “zoneli” state on 6.2-PRERELEASE (LI Xin)
11. Re: malloc(0) returns 0x800 on FreeBSD 6.2 ? (Luigi Rizzo)
12. Re: ggate still broken on 6.2-RC1 for amd64. (Ulrich Spoerlein)
13. Re: deadlock in “zoneli” state on 6.2-PRERELEASE (Nikolay Pavlov)
14. Re: bge Ierr rate increase from 5.3R -> 6.1R (Doug Barton)
15. Re: panic: sleeping thread (John Baldwin)

———————————————————————-

Message: 1
Date: Mon, 11 Dec 2006 15:02:59 +0200 (EET)
From: “Iassen Anadoliev”
Subject: Re: apache and php5
To: “RYAN M. vAN GINNEKEN”
Cc: freebsd-stable@freebsd.org
Message-ID:
Content-Type: text/plain;charset=windows-1251

On Mon, December 11, 2006 10:13 am, RYAN M. vAN GINNEKEN wrote:
>
> trying to get php5 to work with apache anyone got any tips i am lost. what
> ever happend to mod_php

cd /usr/ports/lang/php5 && make config – Do you have APACHE option
enabled here?

>
> —
> Computer King/CaNMail
>
> http://www.computerking.ca http://www.canmail.org
>
> Sales, Service, and Hosting
> Email, Data, and Web Packages
> Ask about web design specials
>
> Affiliates
> http://www.computerking.ca/pages/links/affiliates/affiliates.htm
>
> Maybe Computer Science should be in the College of Theology. — R. S.
> Barton
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to “freebsd-stable-unsubscribe@freebsd.org”
>


WWell by
Iassen Anadoliev

——————————

Message: 2
Date: Mon, 11 Dec 2006 14:08:00 +0000
From: Greg Eden
Subject: bge Ierr rate increase from 5.3R -> 6.1R
To: freebsd-stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Hello

I recently updated two production servers from 5.3 to 6.1 via cvsup
and buildworld. Since the upgrade I’ve seen an increase in the number
of Input packet errors reported on the bge cards in on both boxes.
One is a HP DL360g3, the other is a HP DL380g3. Both have a pair of
2.8GHz Xeons with a SMP kernel.

So – was the old driver previously underreporting, is the new one
over-reporting/causing the error rate or is it something else? Cables
and cabling have not changed and the pickup in number of errors is
quite distinct. I monitor the nightly ‘periodic daily’ phone homes
closely.

Example from the DL380g3.

The 5.3->6.1 upgrade was on 8 November. 58,000 errors in 1 month
compared to 2 errors in 1 year with 5.3.

Network interface status:
Name Mtu Network Address Ipkts Ierrs Opkts
Oerrs Coll
bge0 1500 00:0f:20:f6:**:** 1344182650 58292
2701993948 0 0
bge0 1500 192.168.**/25 ********** 1344176611 –
2701984851 – –
bge1* 1500 00:0f:20:f6:**:** 0 0
0 0 0
lo0 16384 69549 0
69549 0 0
lo0 16384 your-net localhost 69549 –
69549 – –

A couple of weeks ago I turned off tx and rx check summing on this
box as I gathered from googling it might be contributing. That had no
effect.

Upon further investigation it appears six other boxes with bge ports
(mostly HP DL360g4) running 6.1 started reporting errors when moved
to 6.1. As they do only a small fraction of the traffic that the
above box does I hadn’t noticed it.

This box (a UP HP DL360g4) is on a completely different network,
different switch, cabling etc. Again, prior to 6.1 it had never
reported an error in 18 months of service.

Network interface status:
Name Mtu Network Address Ipkts Ierrs Opkts
Oerrs Coll
bge0 1500 00:12:79:3b:**:** 781001814 1980
1056534485 0 0
bge0 1500 192.168.*** 192.168.***.*** 783877018 –
1061029115 – –

I don’t have a spare box with a bge interface to test 6.2 for the
same behaviour, but would be interested if anyone had an explanation.

Best wishes.

Greg.

——————————

Message: 3
Date: Mon, 11 Dec 2006 12:32:45 -0500
From: David Gilbert
Subject: Re: ggate still broken on 6.2-RC1 for amd64.
To: Craig Boston
Cc: freebsd-stable@freebsd.org, Ulrich Spoerlein
, David Gilbert
Message-ID:
Content-Type: text/plain; charset=us-ascii

>>>>> “Craig” == Craig Boston writes:

Craig> On Mon, Dec 11, 2006 at 02:47:41AM -0500, David Gilbert wrote:
>> That doesn’t square with my experience. Although bigger buffers
>> could be involved in a performance problem, what we’re dealing with
>> here is a _zero_ traffic situation. It seems that it works enough
>> for tasting to be successful, but any significant load wedges it
>> hard.

Craig> The problem I observed was also a zero traffic situation. A
Craig> quick way to test is to do something like this (assuming you
Craig> don’t care about the contents of the device!)

Craig> dd if=/dev/zero of=/dev/ggateX bs=1m

Craig> and watch the network traffic to see what happens. When I ran
Craig> into it, small block sizes worked fine, but anything bigger
Craig> than the send buffer size would cause the entire ggate device
Craig> to wedge with zero traffic. The ggatec logs in my mail archive
Craig> say 128k, which itself is a little odd because I thought GEOM
Craig> broke big transfers into 64k chunks.

Craig> In any case, ggatec got stuck in a loop getting EAGAIN from
Craig> send(), so the packets never made it out to the wire.

Craig> However checking my mail archive also indicates that was a year
Craig> ago so chances are this is a different problem. The symptoms
Craig> just sounded a little familiar.

Urm… what would be the transfersize that the filesystem prefers to use?
Also, what trasnfersize does the gmirror sync use?

Dave.


============================================================================
|David Gilbert, Independent Contractor. | Two things can be |
|Mail: dave@daveg.ca | equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=========================================================GLO================

——————————

Message: 4
Date: Mon, 11 Dec 2006 09:44:23 -0800
From: Luigi Rizzo
Subject: malloc(0) returns 0x800 on FreeBSD 6.2 ?
To: stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

i was debugging a program on FreeBSD 6, and much to my
surprise, i noticed that malloc(0) returns 0x800, as shown
by this program:

> more a.c
#include
int main(int argc, char *argv[])
{
char *p = malloc(0);
printf(” malloc 0 returns %p\n”, p);
}
> cc -o a a.c
> ./a
malloc 0 returns 0x800

if you look at the source this is indeed clear – internally
the 0x800 is ZEROSIZEPTR and is set when a zero length is
passed to malloc() unless you have malloc_sysv set.

The thing is, i don’t know if this behaviour is intentional or not,
but certainly is not documented — the manpage documents
something totally different (in the section for the ‘V’
MALLOC_OPTION, see below).

TUNING

V Attempting to allocate zero bytes will return a NULL pointer
instead of a valid pointer. (The default behavior is to make a
minimal allocation and return a pointer to it.) This option is
provided for System V compatibility. This option is incompatible
with the “X” option.

So what should we do with this ? Just fix the manpage or fix the
code ? This behaviour is likely to break quite a few things…

cheers
luigi

——————————

Message: 5
Date: Tue, 12 Dec 2006 01:46:17 +0800
From: LI Xin
Subject: Re: Zoneli State / Nttcp client.
To: sivakumar.subramani@wipro.com
Cc: freebsd-stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=”iso-8859-1″

sivakumar.subramani@wipro.com wrote:
> Hi,
>
> I have a script where we start a nttcp for some 500 nttcp client in back
> ground. After some time I could see the nttcp clients are listed in the
> TOP command as “Zoneli” state. Can any one please let me know what is
> meant by Zoneli state?
>
> Test Script:
> =========
> count=1
> while [ $count -le 2000 ]
> do
> ifconfig xge1 17.1.1.25 promisc up
> ./nttcp -t -l65536 -w227 -P120 17.1.1.152 &
> echo “count is $count”
> count=`expr $count + 1`
> done

Would you please help to test whether the patch located at:

http://people.freebsd.org/~delphij/misc/patch-zonelim-drain

To see if there is change?

Cheers,

Xin LI http://www.delphij.net/
FreeBSD – The Power to Serve!

————– next part ————–
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061211/852544ca/signature-0001.pgp

——————————

Message: 6
Date: Mon, 11 Dec 2006 20:08:17 +0200
From: Nikolay Pavlov
Subject: Re: deadlock in “zoneli” state on 6.2-PRERELEASE
To: LI Xin
Cc: Robert Watson , freebsd-stable@FreeBSD.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

On Monday, 11 December 2006 at 15:59:03 +0800, LI Xin wrote:
> Hi,
>
> Would you please give the following patch a try?
>
> http://people.freebsd.org/~delphij/misc/patch-zonelim-drain
>
> Note: Please revert my previous patch against sys/kern/kern_mbuf.c.
>
> This patch should be applied against sys/vm/ [RELENG_6 or RELENG_6_2],
> it schedules a drain of uma zones when they are low on memory.

This time things worked out a bit better, there was no Kernel panic and
my server managed to overcome the “magic” number 65550 mbufs. But very
soon the server reached another limit – 131072 mbuf clusters
(This is my limit for kern.ipc.nmbclusters).
And server started to drop the packets. After I’ve
removed the overload I found my server responding but when I actually
accessed it I found out that although the number of connections has
reduces considerably, the memory allocated for the net did not become
free. So I believe that there is still a mbufs leak somewhere.

root@accel1:~# sockstat -4 | wc -l
17

root@accel1:~# netstat -m
1082/131578/132660 mbufs in use (current/cache/total)
1080/129992/131072/131072 mbuf clusters in use (current/cache/total/max)
^^^^^^^^^^^^^^^^^^^^^^^^^^
1080/128712 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
2430K/292878K/295309K bytes allocated to network (current/cache/total)
^^^^^^^^^^^^^^^^^^^^^
0/1058420/529208 requests for mbufs denied
(mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
156 calls to protocol drain routines

root@accel1:~# vmstat -z
ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 904, 40, 31603
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 23, 33, 46
128 Bucket: 524, 0, 1423, 5, 1590808
VM OBJECT: 132, 0, 18094, 147, 43780
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 17, 151, 151954
MAP ENTRY: 68, 0, 718, 290, 182847
PV ENTRY: 24, 2228360, 124232, 4528, 861505
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 2828, 1435, 273492
32: 32, 0, 1769, 491, 116114
64: 64, 0, 3199, 2701, 181154
128: 128, 0, 1813, 1517, 273347
256: 256, 0, 365, 415, 13230
512: 512, 0, 1006, 10, 35578
1024: 1024, 0, 49, 83, 72385
2048: 2048, 0, 170, 38, 40942
4096: 4096, 0, 129, 22, 89367
Files: 72, 0, 100, 5624, 227230
MAC labels: 20, 0, 20726, 15778, 368518
PROC: 536, 0, 71, 27, 1441
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 28, 24, 1398
mbuf_packet: 256, 0, 1080, 128712, 6714669
mbuf: 256, 0, 2, 2866, 7912768
mbuf_cluster: 2048, 131072, 129792, 1280, 166272
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 783, 194850
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 20116, 3, 22965
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 16387, 77, 18383
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 166126
DIRHASH: 1024, 0, 1688, 128, 3307
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 6, 21, 595
KNOTE: 68, 0, 0, 112, 64
socket: 356, 131076, 31, 5766, 111627
unpcb: 140, 131096, 12, 44, 171
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 164
inpcb: 180, 131076, 13, 6081, 111291
tcpcb: 464, 131072, 13, 5555, 111291
tcptw: 48, 8268, 0, 858, 68707
syncache: 100, 15366, 0, 312, 92731
hostcache: 76, 15400, 4989, 61, 4989
tcpreass: 20, 8281, 0, 338, 3819
sackhole: 20, 0, 0, 338, 191981
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 19, 39, 29
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 7, 10568, 92462
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 20074, 52, 22922
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 20074, 41, 22922

Should i add this to my PR?
http://www.freebsd.org/cgi/query-pr.cgi?pr=106317

>
> Cheers,
> —
> Xin LI http://www.delphij.net/
> FreeBSD – The Power to Serve!
>


======================================================================
– Best regards, Nikolay Pavlov.
Subject: Re: malloc(0) returns 0x800 on FreeBSD 6.2 ?
To: Luigi Rizzo
Cc: stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

In the last episode (Dec 11), Luigi Rizzo said:
> i was debugging a program on FreeBSD 6, and much to my surprise, i
> noticed that malloc(0) returns 0x800, as shown by this program:
>
> > more a.c
> #include
> int main(int argc, char *argv[])
> {
> char *p = malloc(0);
> printf(” malloc 0 returns %p\n”, p);
> }
> > cc -o a a.c
> > ./a
> malloc 0 returns 0x800
>
> if you look at the source this is indeed clear – internally the 0x800
> is ZEROSIZEPTR and is set when a zero length is passed to malloc()
> unless you have malloc_sysv set.

Right, it passed you a pointer to which you may write 0 bytes to;
exactly what the program asked for :)

The FreeBSD 6.x behaviour is slightly against POSIX rules that state
all successful malloc calls must return unique pointers, so the 7.x
malloc silently rounds zero-size mallocs to 1. Ideally malloc would
return unique pointers to blocks of memory set to MPROT_NONE via
mprotect() (you could fit 8192 of these pointers in an 8k page), to
prevent applications from using that byte of memory.


Dan Nelson
dnelson@allantgroup.com

——————————

Message: 8
Date: Mon, 11 Dec 2006 19:37:28 +0100
From: Ulrich Spoerlein
Subject: Re: ggate still broken on 6.2-RC1 for amd64.
To: Craig Boston , David Gilbert
, freebsd-stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

Craig Boston wrote:
> Have you tried increasing the send/receive buffer size? In my local
> ggate setup I’m running both the client and server with the options
> “-R 196608 -S 196608″. I added it a while back after discovering that
> the default buffer size was inadequate in certain situations and would
> sometimes cause large block sized I/O to hang.

Heh, this is funny. I have reports from another source, who _decreases_
bufsize to 8kB, because that is giving him the most performance.

Since I’m using HPS’ USB stack I can’t use my uplcom device and
therefore cannot usefully test some more ggate/gmirror scenarios on
-CURRENT …

But I’ll whip up a ggate test case.

Ulrich Spoerlein

A: Yes.
>Q: Are you sure?
> >A: Because it reverses the logical flow of conversation.
> >>Q: Why is top posting frowned upon?

——————————

Message: 9
Date: Mon, 11 Dec 2006 12:54:11 -0600
From: Dan Nelson
Subject: Re: malloc(0) returns 0x800 on FreeBSD 6.2 ?
To: Luigi Rizzo
Cc: stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

In the last episode (Dec 11), Dan Nelson said:
> In the last episode (Dec 11), Luigi Rizzo said:
> > i was debugging a program on FreeBSD 6, and much to my surprise, i
> > noticed that malloc(0) returns 0x800, as shown by this program:
> >
> > > more a.c
> > #include
> > int main(int argc, char *argv[])
> > {
> > char *p = malloc(0);
> > printf(” malloc 0 returns %p\n”, p);
> > }
> > > cc -o a a.c
> > > ./a
> > malloc 0 returns 0x800
> >
> > if you look at the source this is indeed clear – internally the 0x800
> > is ZEROSIZEPTR and is set when a zero length is passed to malloc()
> > unless you have malloc_sysv set.
>
> Right, it passed you a pointer to which you may write 0 bytes to;
> exactly what the program asked for :)
>
> The FreeBSD 6.x behaviour is slightly against POSIX rules that state
> all successful malloc calls must return unique pointers, so the 7.x
> malloc silently rounds zero-size mallocs to 1. Ideally malloc would
> return unique pointers to blocks of memory set to MPROT_NONE via
> mprotect() (you could fit 8192 of these pointers in an 8k page), to
> prevent applications from using that byte of memory.

Also note that the 0x800 behaviour was added to malloc.c rev 1.60 back
in 2001, which means that all of the 5.x and 6.x releases did this.


Dan Nelson
dnelson@allantgroup.com

——————————

Message: 10
Date: Tue, 12 Dec 2006 02:59:37 +0800
From: LI Xin
Subject: Re: deadlock in “zoneli” state on 6.2-PRERELEASE
To: Nikolay Pavlov , LI Xin
, freebsd-stable@FreeBSD.org, Robert Watson

Message-ID:
Content-Type: text/plain; charset=”iso-8859-1″

Hi, Nikolay,

Nikolay Pavlov wrote:
> On Monday, 11 December 2006 at 15:59:03 +0800, LI Xin wrote:
>> Hi,
>>
>> Would you please give the following patch a try?
>>
>> http://people.freebsd.org/~delphij/misc/patch-zonelim-drain
>>
>> Note: Please revert my previous patch against sys/kern/kern_mbuf.c.
>>
>> This patch should be applied against sys/vm/ [RELENG_6 or RELENG_6_2],
>> it schedules a drain of uma zones when they are low on memory.
>
>
> This time things worked out a bit better, there was no Kernel panic and
> my server managed to overcome the “magic” number 65550 mbufs. But very
> soon the server reached another limit – 131072 mbuf clusters

Do you still get squid stuck in “zoneli” state and the server became
unresponsive?

> (This is my limit for kern.ipc.nmbclusters).
> And server started to drop the packets. After I’ve
> removed the overload I found my server responding but when I actually
> accessed it I found out that although the number of connections has
> reduces considerably, the memory allocated for the net did not become
> free. So I believe that there is still a mbufs leak somewhere.

This looks weird to me… Would you please try to add some load to the
server and remove afterwards, to see if the ‘current’ mbuf clusters
keeps increasing or not?

Cheers,

Xin LI http://www.delphij.net/
FreeBSD – The Power to Serve!

————– next part ————–
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061211/5c46153f/signature-0001.pgp

——————————

Message: 11
Date: Mon, 11 Dec 2006 11:03:05 -0800
From: Luigi Rizzo
Subject: Re: malloc(0) returns 0x800 on FreeBSD 6.2 ?
To: Dan Nelson
Cc: stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

On Mon, Dec 11, 2006 at 12:54:11PM -0600, Dan Nelson wrote:
> In the last episode (Dec 11), Dan Nelson said:
> > In the last episode (Dec 11), Luigi Rizzo said:
> > > i was debugging a program on FreeBSD 6, and much to my surprise, i
> > > noticed that malloc(0) returns 0x800, as shown by this program:
> > >
> > > > more a.c
> > > #include
> > > int main(int argc, char *argv[])
> > > {
> > > char *p = malloc(0);
> > > printf(” malloc 0 returns %p\n”, p);
> > > }
> > > > cc -o a a.c
> > > > ./a
> > > malloc 0 returns 0x800
> > >
> > > if you look at the source this is indeed clear – internally the 0x800
> > > is ZEROSIZEPTR and is set when a zero length is passed to malloc()
> > > unless you have malloc_sysv set.
> >
> > Right, it passed you a pointer to which you may write 0 bytes to;
> > exactly what the program asked for :)
> >
> > The FreeBSD 6.x behaviour is slightly against POSIX rules that state
> > all successful malloc calls must return unique pointers, so the 7.x
> > malloc silently rounds zero-size mallocs to 1. Ideally malloc would
> > return unique pointers to blocks of memory set to MPROT_NONE via
> > mprotect() (you could fit 8192 of these pointers in an 8k page), to
> > prevent applications from using that byte of memory.
>
> Also note that the 0x800 behaviour was added to malloc.c rev 1.60 back
> in 2001, which means that all of the 5.x and 6.x releases did this.

yep, just found out various threads on the mailing lists,
but i first looked at the manpage and was surprised of
not seeing it documented.

I haven’t figured out what the conclusion of the discussion was.
I am glad that 7.x changes the behaviour back to what it was on 4.x,

cheers
luigi

——————————

Message: 12
Date: Mon, 11 Dec 2006 21:10:42 +0100
From: Ulrich Spoerlein
Subject: Re: ggate still broken on 6.2-RC1 for amd64.
To: Craig Boston , David Gilbert
, freebsd-stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

Ulrich Spoerlein wrote:
> But I’ll whip up a ggate test case.

Very strange … I thought I would work through different buffer sizes,
starting with some low value. Here’s what gives:

igor# ggated -a localhost -v -R8k -S8k /tmp/ggate_exports
igor# ggatec create -v -R8k -S8k localhost /tmp/ggate_test
info: Reading exports file (/tmp/ggate_exports).
info: Connected to the server: localhost:3080.
debug: Added 127.0.0.1/32 /tmp/ggate_test RW to exports list.
debug: Sending version packet.
info: Exporting 1 object(s).
info: Listen on port: 3080.
info: Connection from: 127.0.0.1.
debug: Receiving version packet.
debug: Version packet received.
debug: Receiving initial packet.

debug: Initial packet received.
debug: Sending initial packet.
debug: Connection created [127.0.0.1, /tmp/ggate_test].
debug: Receiving initial packet.
debug: New connection created (token=226910802).
debug: Received initial packet.
debug: Sending initial packet.
info: Connected to the server: localhost:3080.

debug: Sending version packet.

g_gate_send: EAGAIN
g_gate_send: EAGAIN
g_gate_send: EAGAIN
g_gate_send: EAGAIN
info: Connection from: 127.0.0.1. ^C
debug: Receiving version packet.
^C

Now try with 16k.

igor# ggated -a localhost -v -R16k -S16k /tmp/ggate_exports
igor# ggatec create -v -R16k -S16k localhost /tmp/ggate_test
info: Reading exports file (/tmp/ggate_exports).
info: Connected to the server: localhost:3080.
debug: Added 127.0.0.1/32 /tmp/ggate_test RW to exports list.
debug: Sending version packet.
info: Exporting 1 object(s).
info: Listen on port: 3080.
info: Connection from: 127.0.0.1.
debug: Receiving version packet.
debug: Version packet received.
debug: Receiving initial packet.

debug: Initial packet received.
debug: Sending initial packet.
debug: Connection created [127.0.0.1, /tmp/ggate_test].
debug: Receiving initial packet.
debug: New connection created (token=2294332471).
debug: Received initial packet.
debug: Sending initial packet.
info: Connected to the server: localhost:3080.
info: Connection from: 127.0.0.1.
debug: Sending version packet.
debug: Receiving version packet.
debug: Version packet received.
debug: Receiving initial packet.

debug: Initial packet received.
debug: Sending initial packet.
debug: Found existing connection (token=2294332471).
debug: Receiving initial packet.
debug: Connection added [127.0.0.1, /tmp/ggate_test].
debug: Received initial packet.
debug: Sending initial packet. ggate5
debug: Connection removed [127.0.0.1 /tmp/ggate_test].
notice: send_thread: started!
debug: Process created [/tmp/ggate_test].
notice: recv_thread: started!
notice: disk_thread: started [/tmp/ggate_test]!
notice: send_thread: started [/tmp/ggate_test]!
notice: recv_thread: started [/tmp/ggate_test]!
debug: Process 1140 exiting.
^C

I wanted to use something like the following, for first draft of a
benchmark, but I just I/O deadlocked the system (6.2 and CURRENT).
Simply by running ggated/ggatec in various combinations.

db> show alllocks
Process 1333 (ggatel) thread 0xc2767510 (100081)
exclusive sx sysctl lock r = 0 (0xc078c420) locked @
/vol/src/sys/kern/kern_sysctl.c:1376
db> trace 1333
Tracing pid 1333 tid 100081 td 0xc2767510
sched_switch(c2767510,0,1) at sched_switch+0xe7
mi_switch(1,0) at mi_switch+0x27c
sleepq_switch(c2b3e680,c078bdd0,0,c070e413,236,…) at sleepq_switch+0xc9
sleepq_timedwait(c2b3e680) at sleepq_timedwait+0x4a
msleep(c2b3e680,0,4c,c07028f3,64) at msleep+0x281
g_waitfor_event(c050d120,c2b6c300,2,0,0,0,0,1) at g_waitfor_event+0x73
sysctl_kern_geom_confxml(c07485e0,0,0,d1781b9c,c07485e0,…) at
sysctl_kern_geom_confxml+0x26
sysctl_root(0,d1781c1c,3,d1781b9c) at sysctl_root+0x12f
userland_sysctl(c2767510,d1781c1c,3,8300000,bfbfe3d8,0,0,0,d1781c18,0,c078bde8,0,c070bc1f,522)
at userland_sysctl+0xf4
__sysctl(c2767510,d1781d04) at __sysctl+0x77
syscall(3b,3b,3b,3,bfbfe3d8,…) at syscall+0x27e
Xint0x80_syscall() at Xint0x80_syscall+0x1f
— syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2816ba7f, esp =
0xbfbfe2bc, ebp = 0xbfbfe2f8 —
db> ps
pid ppid pgrp uid state wmesg wchan cmd
1348 800 800 0 S sysctl l 0xc078c444 cron
1347 800 800 0 S sysctl l 0xc078c444 cron
1346 800 800 0 S sysctl l 0xc078c444 cron
1345 795 795 0 S sysctl l 0xc078c444 sshd
1344 800 800 0 S sysctl l 0xc078c444 cron
1343 800 800 0 S sysctl l 0xc078c444 cron
1342 800 800 0 S sysctl l 0xc078c444 cron
1341 800 800 0 S sysctl l 0xc078c444 cron
1340 800 800 0 S sysctl l 0xc078c444 cron
1339 800 800 0 S sysctl l 0xc078c444 cron
1338 800 800 0 S sysctl l 0xc078c444 cron
1337 800 800 0 S sysctl l 0xc078c444 cron
1336 800 800 0 S sysctl l 0xc078c444 cron
1335 262 40 0 S sysctl l 0xc078c444 sh
1334 925 1334 0 S+ sysctl l 0xc078c444 ls
1333 1078 1333 0 S+ g_waitfo 0xc2b3e680 ggatel
1078 1077 1078 0 S+ pause 0xc2b06264 csh
1077 1068 1077 0 S+ wait 0xc2b05b40 su
1068 884 1068 1000 Ss+ pause 0xc2b07024 zsh
969 899 969 0 Ss+ ttyin 0xc24a2c10 csh
925 899 925 0 Ss+ pause 0xc2765da4 csh
900 899 900 0 Ss+ ttyin 0xc2479810 csh
899 898 899 0 Ss select 0xc07d69ec screen
898 895 898 0 S+ pause 0xc2b06da4 screen
895 894 895 0 S+ pause 0xc2765024 csh
894 885 894 1000 S+ wait 0xc27656c0 su
885 884 885 1000 Ss+ pause 0xc26e64a4 zsh
884 882 882 1000 S sysctl l 0xc078c444 sshd
882 795 882 0 Ss sbwait 0xc27591e8 sshd
864 1 864 0 Ss+ ttyin 0xc2491410 getty
863 1 863 0 Ss+ ttyin 0xc24a2810 getty

As you see, the crons are slowly piling up, waiting on the sysctl lock.

—- cut here —-
#!/bin/sh

ge=”/tmp/ggate_exports”
tf=”/tmp/ggate_test”
ts=”64m”
u=6

if [ “$#” -lt 1 ]; then
set — 32k 64k 128k 256k 16k 8k
fi

kldload geom_gate
truncate -s $ts $tf
echo “localhost RW $tf” > $ge

for buf; do
ggated -a localhost -R $buf -S $buf $ge
sleep 3
ggatec create -u $u -R $buf -S $buf localhost $tf
sleep 3
dd if=/dev/ggate$u of=/dev/zero
ggatec destroy -fu$u
killall ggated
sleep 3
done
—- cut here —-

Too bad, I don’t have a 6.1 or 5.x system lying around that I could mess
with. Could you guys try the script above on your test systems?

Ulrich Spoerlein

A: Yes.
>Q: Are you sure?
> >A: Because it reverses the logical flow of conversation.
> >>Q: Why is top posting frowned upon?

——————————

Message: 13
Date: Mon, 11 Dec 2006 22:52:38 +0200
From: Nikolay Pavlov
Subject: Re: deadlock in “zoneli” state on 6.2-PRERELEASE
To: LI Xin
Cc: Robert Watson , freebsd-stable@FreeBSD.org
Message-ID:
Content-Type: text/plain; charset=us-ascii

On Tuesday, 12 December 2006 at 2:59:37 +0800, LI Xin wrote:
> Hi, Nikolay,
>
> Nikolay Pavlov wrote:
> > On Monday, 11 December 2006 at 15:59:03 +0800, LI Xin wrote:
> >> Hi,
> >>
> >> Would you please give the following patch a try?
> >>
> >> http://people.freebsd.org/~delphij/misc/patch-zonelim-drain
> >>
> >> Note: Please revert my previous patch against sys/kern/kern_mbuf.c.
> >>
> >> This patch should be applied against sys/vm/ [RELENG_6 or RELENG_6_2],
> >> it schedules a drain of uma zones when they are low on memory.
> >
> >
> > This time things worked out a bit better, there was no Kernel panic and
> > my server managed to overcome the “magic” number 65550 mbufs. But very
> > soon the server reached another limit – 131072 mbuf clusters
>
> Do you still get squid stuck in “zoneli” state and the server became
> unresponsive?

Yes. No panic, but still idle in zoneli and the server become
unresponsive via network.

last pid: 1990; load averages: 0.09, 0.30, 0.16 up 0+03:27:28 16:27:57
30 processes: 1 running, 29 sleeping

Mem: 497M Active, 600M Inact, 441M Wired, 12K Cache, 112M Buf, 2352M Free
Swap: 4070M Total, 4070M Free

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
684 squid 1 -16 0 480M 480M zoneli 11:41 0.00% squid
694 root 1 96 0 6636K 4800K select 0:06 0.00% snmpd
691 squid 1 -8 0 1224K 632K piperd 0:01 0.00% unlinkd
364 _pflogd 1 -58 0 1600K 1216K bpf 0:01 0.00% pflogd
1840 root 1 -8 0 7768K 7304K piperd 0:00 0.00% perl5.8.8
722 root 1 96 0 3464K 2796K select 0:00 0.00% sendmail
563 root 1 96 0 1352K 1048K select 0:00 0.00% syslogd
1878 root 1 5 -10 5072K 3056K ttyin 0:00 0.00% tcsh
1841 root 1 20 0 4976K 3036K pause 0:00 0.00% csh
1874 quetzal 1 96 0 6220K 3252K select 0:00 0.00% sshd
1877 root 1 20 0 5056K 3028K pause 0:00 0.00% tcsh
1872 root 1 4 0 6232K 3236K sbwait 0:00 0.00% sshd
732 root 1 8 0 1364K 1060K nanslp 0:00 0.00% cron
783 root 1 8 0 1692K 1396K wait 0:00 0.00% login
1875 quetzal 1 20 0 4736K 2964K pause 0:00 0.00% tcsh
668 root 1 96 0 1264K 804K select 0:00 0.00% usbd
706 root 1 96 0 3504K 2676K select 0:00 0.00% sshd
726 smmsp 1 20 0 3364K 2724K pause 0:00 0.00% sendmail

last pid: 1992; load averages: 0.06, 0.27, 0.16 up 0+03:27:50 16:28:19
75 processes: 2 running, 52 sleeping, 21 waiting

Mem: 497M Active, 600M Inact, 441M Wired, 12K Cache, 112M Buf, 2351M Free
Swap: 4070M Total, 4070M Free

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
10 root 1 171 52 0K 8K RUN 188:49 93.85% idle
22 root 1 -68 -187 0K 8K WAIT 1:54 3.56% irq29: em1
684 squid 1 -16 0 480M 480M zoneli 11:41 0.05% squid
13 root 1 -44 -163 0K 8K WAIT 3:08 0.00% swi1: net
11 root 1 -32 -151 0K 8K WAIT 0:27 0.00% swi4: clock sio
42 root 1 20 0 0K 8K syncer 0:09 0.00% syncer
694 root 1 96 0 6636K 4800K select 0:06 0.00% snmpd
14 root 1 -16 0 0K 8K – 0:04 0.00% yarrow
39 root 1 171 52 0K 8K pgzero 0:03 0.00% pagezero
3 root 1 -8 0 0K 8K – 0:02 0.00% g_up
4 root 1 -8 0 0K 8K – 0:02 0.00% g_down
37 root 1 -16 0 0K 8K psleep 0:02 0.00% pagedaemon
691 squid 1 -8 0 1224K 632K piperd 0:01 0.00% unlinkd
43 root 1 -16 0 0K 8K sdflus 0:01 0.00% softdepflush
20 root 1 -64 -183 0K 8K WAIT 0:01 0.00% irq48: amr0
2 root 1 -8 0 0K 8K – 0:01 0.00% g_event
44 root 1 -60 0 0K 8K – 0:01 0.00% schedcpu
364 _pflogd 1 -58 0 1600K 1216K bpf 0:01 0.00% pflogd

PID TT STAT TIME COMMAND
0 ?? WLs 0:00.00 [swapper]
1 ?? ILs 0:00.01 /sbin/init —
2 ?? DL 0:00.91 [g_event]
3 ?? DL 0:02.25 [g_up]
4 ?? DL 0:02.15 [g_down]
5 ?? DL 0:00.00 [kqueue taskq]
6 ?? DL 0:00.00 [acpi_task_0]
7 ?? DL 0:00.00 [acpi_task_1]
8 ?? DL 0:00.00 [acpi_task_2]
9 ?? DL 0:00.00 [thread taskq]
10 ?? RL 188:42.12 [idle]
11 ?? WL 0:26.95 [swi4: clock sio]
12 ?? WL 0:00.00 [swi3: vm]
13 ?? WL 3:08.22 [swi1: net]
14 ?? DL 0:04.36 [yarrow]
15 ?? WL 0:00.00 [swi5: +]
16 ?? WL 0:00.00 [swi2: cambio]
17 ?? WL 0:00.00 [swi6: task queue]
18 ?? WL 0:00.02 [swi6: Giant taskq]
19 ?? WL 0:00.00 [irq9: acpi0]
20 ?? WL 0:01.20 [irq48: amr0]
21 ?? WL 0:00.00 [irq28: em0]
22 ?? WL 1:53.84 [irq29: em1]
23 ?? WL 0:00.00 [irq16: uhci0]
24 ?? DL 0:00.00 [usb0]
25 ?? DL 0:00.00 [usbtask]
26 ?? WL 0:00.00 [irq19: uhci1]
27 ?? DL 0:00.00 [usb1]
28 ?? WL 0:00.00 [irq18: uhci2]
29 ?? DL 0:00.00 [usb2]
30 ?? WL 0:00.00 [irq14: ata0]
31 ?? WL 0:00.00 [irq15: ata1]
32 ?? WL 0:00.02 [irq1: atkbd0]
33 ?? WL 0:00.00 [irq12: psm0]
34 ?? WL 0:00.00 [swi0: sio]
35 ?? DL 0:00.07 [fdc0]
36 ?? WL 0:00.00 [irq7: ppc0]
37 ?? DL 0:01.87 [pagedaemon]
38 ?? DL 0:00.00 [vmdaemon]
39 ?? DL 0:02.81 [pagezero]
40 ?? DL 0:00.12 [bufdaemon]
41 ?? DL 0:00.09 [vnlru]
42 ?? DL 0:09.48 [syncer]
43 ?? DL 0:01.48 [softdepflush]
44 ?? DL 0:00.79 [schedcpu]
129 ?? Is 0:00.00 adjkerntz -i
361 ?? Is 0:00.01 pflogd: [priv] (pflogd)
364 ?? S 0:00.55 pflogd: [running] -s 116 -f /var/log/pflog (pflogd)
509 ?? Is 0:00.00 /sbin/devd
563 ?? Ss 0:00.20 /usr/sbin/syslogd -s
668 ?? Ss 0:00.02 /usr/sbin/usbd
682 ?? Is 0:00.00 /usr/local/sbin/squid -D
684 ?? D 11:41.06 (squid) -D (squid)
691 ?? Is 0:01.49 (unlinkd) (unlinkd)
694 ?? S 0:06.03 /usr/local/sbin/snmpd -p /var/run/snmpd.pid
706 ?? Is 0:00.01 /usr/sbin/sshd
722 ?? Ss 0:00.28 sendmail: accepting connections (sendmail)
726 ?? Is 0:00.01 sendmail: Queue runner@00:30:00 for
/var/spool/clientmqueue (sendmail)
732 ?? Ss 0:00.07 /usr/sbin/cron -s
1840 ?? Is 0:00.32 /usr/bin/perl /usr/local/sbin/brblocker (perl5.8.8)
1872 ?? Is 0:00.08 sshd: quetzal [priv] (sshd)
1874 ?? I 0:00.08 sshd: quetzal@ttyp0 (sshd)
782 v0 Is+ 0:00.00 /usr/libexec/getty Pc ttyv0
783 v1 Is 0:00.04 login [pam] (login)
1841 v1 S 0:00.10 -csh (csh)
1991 v1 R+ 0:00.00 ps awwx
784 v2 Is+ 0:00.00 /usr/libexec/getty Pc ttyv2
785 v3 Is+ 0:00.00 /usr/libexec/getty Pc ttyv3
786 v4 Is+ 0:00.00 /usr/libexec/getty Pc ttyv4
787 v5 Is+ 0:00.00 /usr/libexec/getty Pc ttyv5
788 v6 Is+ 0:00.00 /usr/libexec/getty Pc ttyv6
789 v7 Is+ 0:00.00 /usr/libexec/getty Pc ttyv7
1875 p0 Is 0:00.04 -tcsh (tcsh)
1877 p0 I 0:00.08 tcsh
1878 p0 I
> > (This is my limit for kern.ipc.nmbclusters).
> > And server started to drop the packets. After I’ve
> > removed the overload I found my server responding but when I actually
> > accessed it I found out that although the number of connections has
> > reduces considerably, the memory allocated for the net did not become
> > free. So I believe that there is still a mbufs leak somewhere.
>
> This looks weird to me… Would you please try to add some load to the
> server and remove afterwards, to see if the ‘current’ mbuf clusters
> keeps increasing or not?

I think no, but for sure here is a logs from netstat -m and vmstat -z commands
called one by one in time of load.

root@accel1:/root# cat net
131095/1407/132502 mbufs in use (current/cache/total)
131069/3/131072/131072 mbuf clusters in use (current/cache/total/max)
130942/3 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294911K/357K/295269K bytes allocated to network (current/cache/total)
0/1273541/636768 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
173 calls to protocol drain routines

130617/1885/132502 mbufs in use (current/cache/total)
130592/480/131072/131072 mbuf clusters in use (current/cache/total/max)
130465/480 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
293838K/1431K/295269K bytes allocated to network (current/cache/total)
0/1276741/638368 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
174 calls to protocol drain routines

131241/1261/132502 mbufs in use (current/cache/total)
131072/0/131072/131072 mbuf clusters in use (current/cache/total/max)
131072/0 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294954K/315K/295269K bytes allocated to network (current/cache/total)
0/1282542/641268 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
175 calls to protocol drain routines

131241/1261/132502 mbufs in use (current/cache/total)
131072/0/131072/131072 mbuf clusters in use (current/cache/total/max)
131072/0 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294954K/315K/295269K bytes allocated to network (current/cache/total)
0/1293762/646878 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
175 calls to protocol drain routines

131238/1264/132502 mbufs in use (current/cache/total)
131069/3/131072/131072 mbuf clusters in use (current/cache/total/max)
131069/3 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294947K/322K/295269K bytes allocated to network (current/cache/total)
0/1299402/649698 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
175 calls to protocol drain routines

131225/1277/132502 mbufs in use (current/cache/total)
131056/16/131072/131072 mbuf clusters in use (current/cache/total/max)
131056/16 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294918K/351K/295269K bytes allocated to network (current/cache/total)
0/1307582/653788 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
176 calls to protocol drain routines

131197/1305/132502 mbufs in use (current/cache/total)
131028/44/131072/131072 mbuf clusters in use (current/cache/total/max)
131028/44 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294855K/414K/295269K bytes allocated to network (current/cache/total)
0/1310942/655468 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
176 calls to protocol drain routines

131195/1307/132502 mbufs in use (current/cache/total)
131026/46/131072/131072 mbuf clusters in use (current/cache/total/max)
131026/46 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294850K/418K/295269K bytes allocated to network (current/cache/total)
0/1313942/656968 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
176 calls to protocol drain routines

131195/1307/132502 mbufs in use (current/cache/total)
131026/46/131072/131072 mbuf clusters in use (current/cache/total/max)
131026/46 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294850K/418K/295269K bytes allocated to network (current/cache/total)
0/1317362/658678 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
176 calls to protocol drain routines

131195/1307/132502 mbufs in use (current/cache/total)
131026/46/131072/131072 mbuf clusters in use (current/cache/total/max)
131026/46 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294850K/418K/295269K bytes allocated to network (current/cache/total)
0/1319862/659928 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
177 calls to protocol drain routines

131195/1307/132502 mbufs in use (current/cache/total)
131026/46/131072/131072 mbuf clusters in use (current/cache/total/max)
131026/46 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
294850K/418K/295269K bytes allocated to network (current/cache/total)
0/1323342/661668 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
177 calls to protocol drain routines

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32654
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 231, 602, 2008623
VM OBJECT: 132, 0, 24516, 76, 59916
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156003
MAP ENTRY: 68, 0, 849, 159, 244408
PV ENTRY: 24, 2228360, 136693, 767, 1183705
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342172
32: 32, 0, 1770, 490, 128501
64: 64, 0, 3205, 2400, 202149
128: 128, 0, 1819, 1721, 333281
256: 256, 0, 370, 515, 18012
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90078
Files: 72, 0, 2754, 2917, 284060
MAC labels: 20, 0, 40610, 964, 461050
PROC: 536, 0, 74, 24, 1975
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1932
mbuf_packet: 256, 0, 131015, 57, 10219838
mbuf: 256, 0, 169, 1261, 11854944
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261902
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226499
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4454, 1640, 138060
tcpcb: 464, 131072, 4454, 1114, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111417
hostcache: 76, 15400, 2074, 2976, 7065
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287462
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3184, 7091, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32655
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 231, 602, 2012853
VM OBJECT: 132, 0, 24516, 76, 59930
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156005
MAP ENTRY: 68, 0, 849, 159, 244519
PV ENTRY: 24, 2228360, 136693, 767, 1184103
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342179
32: 32, 0, 1770, 490, 128503
64: 64, 0, 3205, 2400, 202157
128: 128, 0, 1819, 1721, 333290
256: 256, 0, 370, 515, 18014
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90079
Files: 72, 0, 2754, 2917, 284067
MAC labels: 20, 0, 40610, 964, 461059
PROC: 536, 0, 74, 24, 1976
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1933
mbuf_packet: 256, 0, 131015, 57, 10221248
mbuf: 256, 0, 169, 1261, 11855170
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261902
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226516
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4454, 1640, 138060
tcpcb: 464, 131072, 4454, 1114, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111417
hostcache: 76, 15400, 2074, 2976, 7065
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287462
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3184, 7091, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32656
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 231, 602, 2016123
VM OBJECT: 132, 0, 24516, 76, 59944
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156007
MAP ENTRY: 68, 0, 849, 159, 244630
PV ENTRY: 24, 2228360, 136693, 767, 1184501
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342186
32: 32, 0, 1770, 490, 128506
64: 64, 0, 3205, 2400, 202165
128: 128, 0, 1819, 1721, 333299
256: 256, 0, 370, 515, 18016
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90080
Files: 72, 0, 2754, 2917, 284074
MAC labels: 20, 0, 40610, 964, 461068
PROC: 536, 0, 74, 24, 1977
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1934
mbuf_packet: 256, 0, 131015, 57, 10222338
mbuf: 256, 0, 169, 1261, 11855350
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261902
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226533
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4454, 1640, 138060
tcpcb: 464, 131072, 4454, 1114, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111417
hostcache: 76, 15400, 2074, 2976, 7065
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287462
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3184, 7091, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32657
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 231, 602, 2018703
VM OBJECT: 132, 0, 24516, 76, 59958
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156009
MAP ENTRY: 68, 0, 849, 159, 244741
PV ENTRY: 24, 2228360, 136693, 767, 1184899
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342193
32: 32, 0, 1770, 490, 128508
64: 64, 0, 3205, 2400, 202174
128: 128, 0, 1819, 1721, 333308
256: 256, 0, 370, 515, 18018
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90081
Files: 72, 0, 2754, 2917, 284081
MAC labels: 20, 0, 40610, 964, 461077
PROC: 536, 0, 74, 24, 1978
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1935
mbuf_packet: 256, 0, 131015, 57, 10223198
mbuf: 256, 0, 169, 1261, 11855483
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261902
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226550
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4454, 1640, 138060
tcpcb: 464, 131072, 4454, 1114, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111417
hostcache: 76, 15400, 2074, 2976, 7065
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287462
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3184, 7091, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32658
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 231, 602, 2021763
VM OBJECT: 132, 0, 24516, 76, 59972
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156011
MAP ENTRY: 68, 0, 849, 159, 244852
PV ENTRY: 24, 2228360, 136693, 767, 1185297
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342200
32: 32, 0, 1770, 490, 128510
64: 64, 0, 3205, 2400, 202182
128: 128, 0, 1819, 1721, 333317
256: 256, 0, 370, 515, 18020
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90082
Files: 72, 0, 2754, 2917, 284088
MAC labels: 20, 0, 40609, 965, 461086
PROC: 536, 0, 74, 24, 1979
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1936
mbuf_packet: 256, 0, 131013, 59, 10224218
mbuf: 256, 0, 169, 1261, 11855658
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261902
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226567
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4453, 1641, 138060
tcpcb: 464, 131072, 4453, 1115, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111417
hostcache: 76, 15400, 2075, 2975, 7066
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287462
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3130, 7145, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32659
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 233, 600, 2022365
VM OBJECT: 132, 0, 24516, 76, 59986
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156013
MAP ENTRY: 68, 0, 849, 159, 244963
PV ENTRY: 24, 2228360, 136693, 767, 1185695
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342207
32: 32, 0, 1770, 490, 128512
64: 64, 0, 3205, 2400, 202190
128: 128, 0, 1819, 1721, 333326
256: 256, 0, 370, 515, 18022
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90083
Files: 72, 0, 2754, 2917, 284095
MAC labels: 20, 0, 40605, 969, 461095
PROC: 536, 0, 74, 24, 1980
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1937
mbuf_packet: 256, 0, 130815, 257, 10225043
mbuf: 256, 0, 167, 1263, 11855924
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261922
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226584
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4449, 1645, 138060
tcpcb: 464, 131072, 4449, 1119, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111418
hostcache: 76, 15400, 2076, 2974, 7067
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287465
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3130, 7145, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32660
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 233, 600, 2022365
VM OBJECT: 132, 0, 24516, 76, 60000
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156015
MAP ENTRY: 68, 0, 849, 159, 245074
PV ENTRY: 24, 2228360, 136693, 767, 1186093
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342214
32: 32, 0, 1770, 490, 128514
64: 64, 0, 3205, 2400, 202198
128: 128, 0, 1819, 1721, 333335
256: 256, 0, 370, 515, 18024
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90084
Files: 72, 0, 2754, 2917, 284102
MAC labels: 20, 0, 40605, 969, 461104
PROC: 536, 0, 74, 24, 1981
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1938
mbuf_packet: 256, 0, 130815, 257, 10225075
mbuf: 256, 0, 167, 1263, 11856060
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261922
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226601
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4523, 1274, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4449, 1645, 138060
tcpcb: 464, 131072, 4449, 1119, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111418
hostcache: 76, 15400, 2076, 2974, 7067
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 1, 337, 287465
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3130, 7145, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

ITEM SIZE LIMIT USED FREE REQUESTS

UMA Kegs: 140, 0, 84, 12, 84
UMA Zones: 120, 0, 84, 6, 84
UMA Slabs: 64, 0, 910, 34, 32661
UMA RCntSlabs: 104, 0, 65536, 28, 65536
UMA Hash: 128, 0, 4, 26, 6
16 Bucket: 76, 0, 23, 27, 32
32 Bucket: 140, 0, 20, 8, 29
64 Bucket: 268, 0, 22, 34, 46
128 Bucket: 524, 0, 233, 600, 2022365
VM OBJECT: 132, 0, 24516, 76, 60014
MAP: 192, 0, 7, 33, 7
KMAP ENTRY: 68, 57456, 113, 55, 156017
MAP ENTRY: 68, 0, 849, 159, 245185
PV ENTRY: 24, 2228360, 136693, 767, 1186491
DP fakepg: 72, 0, 0, 0, 0
mt_zone: 64, 0, 182, 54, 182
16: 16, 0, 3853, 410, 342221
32: 32, 0, 1770, 490, 128517
64: 64, 0, 3205, 2400, 202206
128: 128, 0, 1819, 1721, 333344
256: 256, 0, 370, 515, 18026
512: 512, 0, 1038, 26, 38658
1024: 1024, 0, 49, 83, 73072
2048: 2048, 0, 147, 61, 41437
4096: 4096, 0, 132, 19, 90085
Files: 72, 0, 2754, 2917, 284109
MAC labels: 20, 0, 40602, 972, 461113
PROC: 536, 0, 74, 24, 1982
THREAD: 376, 0, 98, 22, 98
KSEGRP: 88, 0, 98, 62, 98
UPCALL: 44, 0, 0, 0, 0
VMSPACE: 296, 0, 31, 21, 1939
mbuf_packet: 256, 0, 130812, 260, 10225100
mbuf: 256, 0, 166, 1264, 11856222
mbuf_cluster: 2048, 131072, 131072, 0, 168576
mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0
mbuf_jumbo_9k: 9216, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 0, 0, 0, 0
ACL UMA zone: 388, 0, 0, 0, 0
g_bio: 132, 0, 0, 1102, 261938
ata_request: 204, 0, 0, 0, 0
ata_composite: 196, 0, 0, 0, 0
VNODE: 348, 0, 26567, 20, 29654
VNODEPOLL: 76, 0, 0, 0, 0
S VFS Cache: 68, 0, 20834, 54, 23210
L VFS Cache: 291, 0, 0, 0, 0
NAMEI: 1024, 0, 0, 12, 226618
DIRHASH: 1024, 0, 1675, 141, 3804
NFSMOUNT: 480, 0, 0, 0, 0
NFSNODE: 536, 0, 0, 0, 0
PIPE: 408, 0, 7, 20, 820
KNOTE: 68, 0, 0, 112, 76
socket: 356, 131076, 4522, 1275, 138513
unpcb: 140, 131096, 13, 43, 278
ipq: 32, 4181, 0, 0, 0
udpcb: 180, 131076, 6, 38, 174
inpcb: 180, 131076, 4448, 1646, 138060
tcpcb: 464, 131072, 4448, 1120, 138060
tcptw: 48, 8268, 0, 858, 75042
syncache: 100, 15366, 0, 312, 111418
hostcache: 76, 15400, 2076, 2974, 7067
tcpreass: 20, 8281, 0, 338, 5351
sackhole: 20, 0, 0, 338, 287465
ripcb: 180, 131076, 0, 0, 0
rtentry: 132, 0, 21, 37, 38
pfsrctrpl: 100, 15015, 0, 0, 0
pfrulepl: 604, 0, 9, 9, 9
pfstatepl: 260, 15000, 3130, 7145, 110162
pfaltqpl: 128, 0, 0, 0, 0
pfpooladdrpl: 68, 0, 2, 110, 2
pfrktable: 1240, 0, 4, 5, 8
pfrkentry: 156, 0, 5, 45, 5
pfrkentry2: 156, 0, 0, 0, 0
pffrent: 16, 203, 0, 0, 0
pffrag: 48, 0, 0, 0, 0
pffrcache: 48, 10062, 0, 0, 0
pffrcent: 12, 50141, 0, 0, 0
pfstatescrub: 28, 0, 0, 0, 0
pfiaddrpl: 92, 0, 0, 0, 0
pfospfen: 108, 0, 345, 51, 345
pfosfp: 28, 0, 188, 193, 188
SWAPMETA: 276, 121576, 0, 0, 0
Mountpoints: 740, 0, 6, 4, 6
FFS inode: 132, 0, 26525, 126, 29611
FFS1 dinode: 128, 0, 0, 0, 0
FFS2 dinode: 256, 0, 26525, 115, 29611

>
> Cheers,
> —
> Xin LI http://www.delphij.net/
> FreeBSD – The Power to Serve!
>


======================================================================
– Best regards, Nikolay Pavlov.
Subject: Re: bge Ierr rate increase from 5.3R -> 6.1R
To: Greg Eden
Cc: freebsd-stable@freebsd.org
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

Greg Eden wrote:
> Hello
>
> I recently updated two production servers from 5.3 to 6.1 via cvsup and
> buildworld. Since the upgrade I’ve seen an increase in the number of
> Input packet errors reported on the bge cards in on both boxes. One is a
> HP DL360g3, the other is a HP DL380g3. Both have a pair of 2.8GHz Xeons
> with a SMP kernel.

It would be quite useful at this point if you could update a box or
two to the RELENG_6_2 code base so that we can see if this problem is
solved in the latest release candidate. If it is, your problem is
solved, and if it’s not, you’re a lot closer to the point where we can
usefully assist you.

Doug

This .signature sanitized for your protection

——————————

Message: 15
Date: Mon, 11 Dec 2006 16:27:23 -0500
From: John Baldwin
Subject: Re: panic: sleeping thread
To: freebsd-stable@freebsd.org
Cc: “Marc G. Fournier”
Message-ID:
Content-Type: text/plain; charset=”iso-8859-1″

On Saturday 09 December 2006 03:30, Marc G. Fournier wrote:
>
> Without a core dump, does this mean anything to anyone?
>
> Sleeping thread (tid 101251, pid 38200) owns a non-sleepable lock
> panic: sleeping thread
> cpuid = 1
>
> The kernel was last upgraded:
>
> FreeBSD 6.2-PRERELEASE #1: Fri Nov 17 23:31:41 AST 2006
>
> I’m going to build in DDB stuff right now, as I know I’ve seen that one
before
> … but figured I’d ask and see if someone had an idea with so very little
> information :(

ddb will give a lot more useful information, can’t really debug it further w/o
that, sorry. :(


John Baldwin

——————————

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to “freebsd-stable-unsubscribe@freebsd.org”

End of freebsd-stable Digest, Vol 186, Issue 2
**********************************************