Displaying 4 results from an estimated 4 matches for "uipc_usrreq".
Did you mean:
udp_usrreq
2005 May 08
0
FreeBSD Security Advisory FreeBSD-SA-05:08.kmem [REVISED]
...VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_4
src/sys/kern/uipc_usrreq.c 1.54.2.11
src/sys/kern/vfs_subr.c 1.249.2.32
src/sys/net/if_mib.c 1.8.2.3
src/sys/netinet/ip_divert.c 1.42.2.8
src/sys/netinet/raw_ip.c...
2005 May 08
0
FreeBSD Security Advisory FreeBSD-SA-05:08.kmem [REVISED]
...VI. Correction details
The following list contains the revision numbers of each file that was
corrected in FreeBSD.
Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_4
src/sys/kern/uipc_usrreq.c 1.54.2.11
src/sys/kern/vfs_subr.c 1.249.2.32
src/sys/net/if_mib.c 1.8.2.3
src/sys/netinet/ip_divert.c 1.42.2.8
src/sys/netinet/raw_ip.c...
2005 May 05
1
FreeBSD Security Advisory FreeBSD-SA-05:08.kmem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
FreeBSD-SA-05:08.kmem Security Advisory
The FreeBSD Project
Topic: Local kernel memory disclosure
Category: core
Module: sys
Announced: 2005-05-06
2012 Nov 13
1
thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC
Hi there
We have a pair of servers running FreeBSD 9.1-RC3 that act as transparent layer 7 loadbalancer (relayd) and pop/imap proxy (dovecot). Only one of them is active at a given time, it's a failover setup. From time to time the active one gets in a state in which the 'thread taskq' thread uses up 100% of one cpu on its own, like here:
----
PID USERNAME PRI NICE SIZE