Jos Backus wrote:
On Thu, Nov 13, 2003 at 02:45:18AM -0800, Terry Lambert wrote:
Why use pid files at all if you could be using a process supervisor instead?
Who supervises the supervisor?
Heh. The supervisor should be small and robust, like init. Has init died on
you recently? Do you
On Wed, Nov 12, 2003 at 10:01:23AM -0800, FB wrote:
+ Before the patch was applied, the jail environment had no problem with dns.
+ After the patch was applied however (and userland rebuilt both on host and
+ jail), dns breaks in the jail environment. Basically, gethostbyname fails
+ and h_errno
Hi,
When is the GEN cache used ? My desktop machine never has mbufs in the
GEN pool but some other machine (acting as gateways in
small/medium-sized networks) do have them.
DESKTOP (no load at all)
mbuf usage:
GEN cache: 0/0 (in use/in pool)
CPU #0 cache: 1/128 (in
Daniel: It appears the patch which was comitted didn't include
everything it should. I blame myself because the patch below
contains both debugging code and is reversed. I will submit a PR
with a patch. In brief, what is missing is:
+ if (n == 0) {
+
On 14 Nov 2003 at 10:08, Dan Langille wrote:
Daniel: It appears the patch which was comitted didn't include
everything it should. I blame myself because the patch below
contains both debugging code and is reversed. I will submit a PR
with a patch. In brief, what is missing is:
+
On Friday 14 November 2003 01:45 am, Terry Lambert wrote:
Jos Backus wrote:
On Thu, Nov 13, 2003 at 02:45:18AM -0800, Terry Lambert wrote:
There are also the small issues of ordering (the reason you can't
just run everything out of /etc/ttys via init in the first place),
Sure. Hard
Hi,
I have just filed kern/59290 about an error in all usb ethernet drivers that
can crash a system and kern/59289 about small error in an ioctl in the bktr
driver. (Both with patch). Anyone interrested in fixing them?
grtz,
Daan
___
[EMAIL
On Fri, Nov 14, 2003 at 01:45:45AM -0800, Terry Lambert wrote:
Jos Backus wrote:
On Thu, Nov 13, 2003 at 02:45:18AM -0800, Terry Lambert wrote:
Why use pid files at all if you could be using a process supervisor instead?
Who supervises the supervisor?
Heh. The supervisor should
Hi,
I need a new MAJOR number for our new device.
How can I get it?
I've read that FreeBSD doesn't use them any more.
But we may need it to not interfere with other device
drivers in previous releases of FreeBSD.
??? ce Cronyx Tau-32 E1 adapter
___
Best regars,
Roman
On Fri, 14 Nov 2003, Dan Langille wrote:
Daniel: It appears the patch which was comitted didn't include
everything it should. I blame myself because the patch below
contains both debugging code and is reversed. I will submit a PR
with a patch. In brief, what is missing is:
+
Is this as good a list as any for observations on the FreeBSD make
release process? I can't see any other list that fits the subject.
I have some observations fairly fresh in my mind from trying to build
a version of FreeBSD 4.8.12 with the IBM Propolice anti-stack-smash
patch. This was
On Fri, Nov 14, 2003 at 11:37:05AM -1000, Clifton Royston wrote:
Is this as good a list as any for observations on the FreeBSD make
release process? I can't see any other list that fits the subject.
Did you dig into http://www.freebsd.org/releng/#docs ?
--
| / o / /_ _
Hello,
I am not sure if this is the right place to post this, but here it goes.
There seems to be problems with uthread_kern.c and maybe other parts of
libc/threads in FreeBSD-5.1-p10.
Here are some details about the system:
FreeBSD vorlon.swishmail.com 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10
On Fri, Nov 14, 2003 at 10:48:13PM +0100, Wilko Bulte wrote:
On Fri, Nov 14, 2003 at 11:37:05AM -1000, Clifton Royston wrote:
Is this as good a list as any for observations on the FreeBSD make
release process? I can't see any other list that fits the subject.
Did you dig into
On Saturday 15 November 2003 08:07, Clifton Royston wrote:
I have some observations fairly fresh in my mind from trying to build
a version of FreeBSD 4.8.12 with the IBM Propolice anti-stack-smash
patch. This was intended as a quick prelude to trying to build our own
internal release with a
I announced my BSD-licensed reimplementation of sort(1) on this list a few
months ago. Since then I've fixed many bugs found by my own testing and
the GNU textutils test suite, and vastly improved performance for many
common cases (e.g. the fast path is now qsort() - memcmp()).
The new version is
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc48c5aa8) locked @ kern/subr_trap.c:260
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc48c5aa8) locked @ kern/subr_trap.c:260
Lots
On 14 Nov, M. Warner Losh wrote:
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc48c5aa8) locked @ kern/subr_trap.c:260
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc48c5aa8)
In message: [EMAIL PROTECTED]
Don Lewis [EMAIL PROTECTED] writes:
: There have been an number of reports of this earlier today. I just
: upgraded and got bit by it as, too. The culprit is sys/sys/proc.h
: 1.359.
People on irc have since told me this is a known issue and is being
19 matches
Mail list logo
