My question now: why does the machine swap, is this normal
behaviour?
Why is wired at about 30 GB if ARC=23 GB and L2ARC-header=259 MB?
If I've understood it right from the mailing lists, ZFS returns memory
back to the OS from caches somewhat lazily, so in times of high memory
load ZFS system
-Original Message-
From: Daniel Kalchev
Sent: Thursday, May 31, 2012 1:01 PM
2) The BSD license. Contrary to popular belief, it has brought a lot of
high quality development to FreeBSD.
The salient point is that BSD license (and alike licenses)seem to bring in
more talented people than
Hmm, I wonder if possible culprit is this:
Process 12 (intr) thread 0xff00022693e0 (100016)
exclusive sleep mutex Giant (Giant) r = 1 (0x80c93dc0)
locked @ /usr/src/sys/dev/usb/usb_transfer.c:3023
Is the usb device used as main harddrive for the system, and have you
tried other u
One final comment - I still don't understand why FreeBSD "won't"
respond to pings
when it has an address like 169.254.1.1. I can ssh to the unit but
it won't
respond to pings. I tried setting up a linux box with an address
like
169.254.1.2 and it "would" respond to pings.
Linux is not really
I have a problem: ldapsearch results in "Segmentation fault" under
openldap-2.4.23 with cyrus-sasl-2.1.23
A thread for similar issues was started by George Mamalakis back in
february:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html
but I find no solution / conclusion f
I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd linked
against system kerberos.
(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat Jun 12 00:39:22 EEST 2010
r...@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386)
The problem manifested itself with pretty much
--
From: "Jeremy Chadwick"
Sent: Thursday, July 15, 2010 7:22 PM
To: "Reko Turja"
Cc: "Henrik /KaarPoSoft" ;
Subject: Re: openldap client GSSAPI authentication segfaults in
fbsd8stablei386
That said, can you p
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
Furthermore, relevant bug (PR 144754) indicates there's an easier
way to
induce this problem, so I'm going to see if I can reproduce it here
locally. It's almost certainly the same problem but induced via a
slightly different cont
This doesn't help. The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my
kernel
message buffer filling rapidly + all.log filling. So, there is
further
configuration of this daemon that's needed (meaning it does not work
"straight out of t
void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = &last_error_context;
239
240
Thanks. Most of this worked, except the following:
[SNIP]
Which worked. I hope this was the right thing to do.
My bad there, I was slightly pressed for time and did not check if
default cyrus documentation was sane in freebsd context - what you did
was quite correct.
However, upon start
I think we need the OP of the PR[1], Mikhail T., to chime in here
with his
setup.
While waiting, can you test the following: In the
/usr/local/etc/imapd.conf file comment out
#sasl_pwcheck_method: saslauthd
and add below it:
sasl_mech_list: gssapi pam plain
-Reko
__
I'll build an i386 version of my testbox and start the procedure
over
again.
Just installed cyrus for testing into another i386 system and hit the
same exact bug. I wonder if this is the reason for the problem we're
encountering:
http://www.freebsd.org/cgi/query-pr.cgi?pr=138929
"This patc
Can you try reproducing the issue on 8-STABLE?
I recently submitted a Heimdal patch against 8.1-STABLE and
9.0-CURRENT that resolves some libgssapi-related issues:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454
The patch breaks ABI, so you'll have to rebuild libgssapi-dependent
applic
Applying Benjamin's patch to RELENG_8 sources csupped yesterday stops
the buildworld in last library stage:
In file included from /usr/src/lib/libc/rpc/clnt_dg.c:55:
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:52: error: expected
specifier-qualifier-list before 'gss_cred_id_t'
/usr/src/lib
After manually changing the gssapi header used in
/usr/src/include/rpc/rpcsec_gss.h to somewhat klunky "#include
"/usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h"" system csupped
yesterday built okay and after rebuilding cyrus-sasl, saslauthd and
cyrus I get the following failures in log:
--
From: "Jan Henrik Sylvester"
Sent: Wednesday, September 01, 2010 7:33 PM
To: "stable-list freebsd"
Subject: GSSAPI (for OpenLDAP) on FreeBSD 8?
Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the
libgssapi patch? With the heimdal-1
From: "Zhihao Yuan"
Subject: Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
My world and kernel are sync. Is it possible that the dtrace-enabled
kernel
must be compiled with '-g'?
On Fri, Dec 3, 2010 at 5:29 PM, Andriy Gapon
wrote:
I suppose that you have some problem with either y
Strongly disagree.
Or if it cannot, the "base
system" needs to start using pkg_* (somehow) for use, and src.conf
WITHOUT_xxx (where xxx = some software) removed. Concept being: "I
don't need Kerberos; pkg_delete base-krb5. I also don't need
lib32;
pkg_delete base-lib32". Beautiful concept, h
Based on the inspection of the source tree, I want my bikeshed mauve.
I've not been had by AFD jokes in a while but Doug pulled this one
off...
-Reko
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stab
-Original Message-
From: Willem Jan Withagen
Sent: Monday, June 22, 2015 11:48 PM
To: Daniel Genis ; freebsd-stable@freebsd.org
Subject: Re: can the l2arc memory leak fix be pulled into 10.1-RELEASE ?
We are kind of new to FreeBSD, so we're wondering what are the plans to
merge these fi
I use OS Linux on my hosting for web-servers, base for all servers is
the same m/b S5000PAL ( SR1500), 2 quad kernel cpu Xeon E5320 or E5345,
8Gb RAM. I decided to install FreeBSD 6.2 i386 on one of the servers,
To be a bit mor specific with my previous reply, in order to use SCHED_ULE
you ne
On Sat, 01 Dec 2007 23:37:32 +0200, Alexey Vlasov <[EMAIL PROTECTED]> wrote:
kernel:
machine i386
cpu I686_CPU
ident F1RNT1
options PAE
One very probable culprit for slowness
options SMP
options SCHED_4BSD
Using _ULE might yield a bit
From: "Karl Denninger" <[EMAIL PROTECTED]>
To:
Sent: Sunday, September 10, 2006 9:39 PM
Yes it is, in the general case; in any event if you track RELENG_6_1
you will
get no bug fixes in general - security related items to filter back
down but
in general bug reports posted against a -RELEASE are
24 matches
Mail list logo
