2011/3/18 Mark Tinguely
> On 3/18/2011 10:11 AM, Mats Lindberg wrote:
>
>
>
> 2011/3/18 Mark Tinguely
>
>> On 3/18/2011 3:35 AM, Mats Lindberg wrote:
>>
>>> So - after a while I've made some observations.
>>> My problem is actually
-- Forwarded message --
From: Mats Lindberg
Date: 2011/3/18
Subject: Re: FreeBSD 6 vs 8.1
To: Mark Tinguely
2011/3/18 Mark Tinguely
> On 3/18/2011 3:35 AM, Mats Lindberg wrote:
>
>> So - after a while I've made some observations.
>> My problem is ac
No - I was not aware of this, I'll try it, thanks...
/Mats
2011/3/18 Pieter de Boer
> On 03/18/2011 09:35 AM, Mats Lindberg wrote:
>
> > So - after a while I've made some observations. My problem is
> > actually connected to arp.
> >
> > My config is ver
much higher or is "unlimited". With a set memory limit, the "dd" is
> killed before the kernel starts killing off the other program.
>
>
> On 3/14/2011 6:41 AM, Mats Lindberg wrote:
>
> No - not from what I understand
> in the vmware it looks like a real
y.
>
> Compare the /etc/login.conf on both systems. I bet in the FreeBSD 6.3
> system, the memory limit is set to a limit (8M) and on the FreeBSD 8.1 it
> is much higher or is "unlimited". With a set memory limit, the "dd" is
> killed before the kernel starts killing off th
, the memory limit is set to a limit (8M) and on the FreeBSD 8.1 it
> is much higher or is "unlimited". With a set memory limit, the "dd" is
> killed before the kernel starts killing off the other program.
>
>
> On 3/14/2011 6:41 AM, Mats Lindberg wrote:
>
>
No - not from what I understand
in the vmware it looks like a real disk device /dev/ad0s1e
in the nfsroot'ed system I actually have 'of=/opt/something' which is
definately to the nfs disk.
2011/3/14 Mark Tinguely
> On 3/14/2011 6:17 AM, Mats Lindberg wrote:
>
>>
All
I am migrating from FreeBSD 6.3 to FreeBSD 8.1 And I have noticed some, what
I think is, strange behaviour.
In FreeBSD 6.3 when I do
> swapoff -a
> dd if=/dev/zero of=/tmp/whatever bs=1G count=1
I get something like "out of memory - killed"
In FreeBSD 8.1 doing the same - processes around st
which of course gives me EPERM cause I'm out of range.
Again thanks
2011/2/18 Sergey Kandaurov
> On 17 February 2011 12:50, Mats Lindberg
> wrote:
> > All,
> > I have been using a small program /rt) that utilize the
> sched_setscheduler()
> > syscall to s
All,
I have been using a small program /rt) that utilize the sched_setscheduler()
syscall to set the scheduling policy of a process to SCHED_RR. Been running
it FBSD 5.x and 6.x. Now when migrating to FBSD 8.1 I get EPERM back at me.
used to be able to run it like e.g.
> ./rt -sr -p2 -- prog
which
Hi
I'm having a combination of linux and freebsd OSes running a reltime
system.
On linux I use the sched_setscheduler together with raised priority to get
realtime characteristics.
I see that the same system calls are implemented in freebsd can I use the
same approach or should the
rtprio(1) w
Hi All
When I try to catch SIGTERM and generate a core file the call stack is
corrupted on FreeBSD.
Yes I know that I do not have to catch the signal, a core is generated by
default. But the reason is that I need to do more at SIGTERM.
Example 1
In gdb backtrace, why is monitorSignalHandl
12 matches
Mail list logo
