On Mon, May 06, 2013 at 01:37:01AM +0200, Sofian Brabez wrote:
> This patch uses do_cpuid function to fetch CPU Physical
> and Virtual address sizes and adds 2 new sysctl machine
> dependant OIDs (machdep.cpu_physical_address_bits and
> machdep.cpu_virtual_address_bits).
>
> In
This patch uses do_cpuid function to fetch CPU Physical and Virtual address
sizes
and adds 2 new sysctl machine dependant OIDs (machdep.cpu_physical_address_bits
and machdep.cpu_virtual_address_bits).
In order to retrieve the information, it calls do_cpuid by setting eax register
to 0x8008
On 26 Jun 2012, at 15:42, m...@freebsd.org wrote:
> While I understand the problems you allude to, the sysctl(8) binary
> can protect itself from them. IMO the biggest problem with sysctls
> not being files is that it makes no sense from the core UNIX
> philosophy that everythi
On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson wrote:
> On Tue, 26 Jun 2012, Chris Rees wrote:
>
>>> as well as we don't depend of /proc for normal operation we shouldn't for
>>
>> say /proc/sysctl
>>>
>>>
>>> improvements are welco
and/or get it wrong. sysctl has some file-system like properties, but on the
whole, it's not a file system -- it's much more like an SNMP MIB.
While you can map anything into anything (including Turing machines), I think
the sysctl command line tool and API, despite its limitat
On Tue, 26 Jun 2012, Chris Rees wrote:
as well as we don't depend of /proc for normal operation we shouldn't for
say /proc/sysctl
improvements are welcome, better documentation is welcome, changes to
what is OK - isn't.
/proc/sysctl might be useful. Just because Linux uses
>
> as well as we don't depend of /proc for normal operation we shouldn't for say
/proc/sysctl
>
> improvements are welcome, better documentation is welcome, changes to what is
OK - isn't.
/proc/sysctl might be useful. Just because Linux uses it doesn't mak
On Jun 26, 2012 7:07 AM, "Wojciech Puchar"
wrote:
>
> as well as we don't depend of /proc for normal operation we shouldn't for
say /proc/sysctl
>
> improvements are welcome, better documentation is welcome, changes to
what is OK - isn't.
/proc/sysctl might b
as well as we don't depend of /proc for normal operation we shouldn't for
say /proc/sysctl
improvements are welcome, better documentation is welcome, changes to what
is OK - isn't.
___
freebsd-hackers@freebsd.org ma
Hi,
On Mon, Jun 25, 2012 at 10:51 PM, Boris Popov wrote:
> On 26.06.2012 6:56, Arnaud Lacombe wrote:
>> purpose. However, if I can avoid to re-design that wheel too, by
>> getting access to scfs(4) code, I will.
>
> It is interesting, that the old drive with this code are still alive.
> Most lik
On 26.06.2012 6:56, Arnaud Lacombe wrote:
> purpose. However, if I can avoid to re-design that wheel too, by
> getting access to scfs(4) code, I will.
It is interesting, that the old drive with this code are still alive.
Most likely, FS related part will need serious attention because of
numerou
On Mon, Jun 25, 2012 at 8:13 PM, Garrett Cooper wrote:
> On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote:
>> Hi folks,
>>
>> I find myself in a situation where I need to directly explore the
>> sysctl(8) tree from my program. The tricky part is this:
&g
Hi,
On Mon, Jun 25, 2012 at 8:30 PM, Adam Vande More wrote:
> On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote:
>>
>> Hi folks,
>>
>> I find myself in a situation where I need to directly explore the
>> sysctl(8) tree from my program. The tricky part is
On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote:
> Hi folks,
>
> I find myself in a situation where I need to directly explore the
> sysctl(8) tree from my program. The tricky part is this:
>
There is this:
http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/
--
On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe wrote:
> Hi folks,
>
> I find myself in a situation where I need to directly explore the
> sysctl(8) tree from my program. The tricky part is this:
>
> from `src/sbin/sysctl.c':
> /*
> * These functions uses a presen
Hi folks,
I find myself in a situation where I need to directly explore the
sysctl(8) tree from my program. The tricky part is this:
from `src/sbin/sysctl.c':
/*
* These functions uses a presently undocumented interface to the kernel
* to walk the tree and get the type so it can prin
deed.
> IMO, kenv != sysctl, so we not need to match sysctl. But backwards
> 'compatibility' is good reason to select second way.
Which is what I figured; I favored the latter course at first and
developed my patch based on that mindset, because I know people hate
it when backwards
> grunt work in a shell one-liner instead of introducing a bug prone
> tunable parser) I have written up a patch which would make kenv
> function a bit more like sysctl, wrt the fact that sysctl -n
> suppresses suffixing a value with the variable name when executed
> like so:
>
>
nable parser) I have
written up a patch which would make kenv function a bit more like sysctl, wrt
the fact that sysctl -n suppresses suffixing a value with the variable name
when executed like so:
# kenv LINES
LINES="24"
# kenv -n LINES
24
I've also considered keeping the fun
On 5/2/2012 1:39 PM, Trent Nelson wrote:
[Resending from non-broken MTA.]
Hi Matt,
isp(4) mentions the following sysctl options:
dev.isp.N.loop_down_limit
This value says how long to wait in seconds after loop has gone
down before giving up and expiring
On Thu, 22 Mar 2012 22:38:15 +0200 Mikolaj Golub wrote:
MG> Actually I don't see reasons why this may not be p_cansee, so I
MG> updated the patch and going to commit it if there is no objections.
The updated patch:
http://people.freebsd.org/~trociny/kern_proc_osrel.2.patch
--
Mikolaj Golub
On Sat, Mar 17, 2012 at 9:30 PM, Mikolaj Golub wrote:
> Hi,
>
> Currently we can check and change binary osreldate of another process via
> procfs(5).
>
> Kostik suggested to add a new sysctl for the same purpose and also extend
> procstat to show osrel.
>
> Here are p
On Sat, 17 Mar 2012 22:29:01 +0100 Jilles Tjoelker wrote:
JT> On Sat, Mar 17, 2012 at 09:30:05PM +0200, Mikolaj Golub wrote:
>> I added osrel output to procstat -b option:
>> kopusha:~% procstat -b 2975
>> PID COMMOSREL PATH
>> 2975 emacs 101 /usr/local/bi
On Sat, Mar 17, 2012 at 11:38:22PM +0200, Mikolaj Golub wrote:
>
> On Sat, 17 Mar 2012 23:26:53 +0200 Konstantin Belousov wrote:
>
> KB> On Sat, Mar 17, 2012 at 11:07:24PM +0200, Mikolaj Golub wrote:
> >>
> >> On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
> >>
> >> JH> Woul
On Sat, 17 Mar 2012 23:26:53 +0200 Konstantin Belousov wrote:
KB> On Sat, Mar 17, 2012 at 11:07:24PM +0200, Mikolaj Golub wrote:
>>
>> On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
>>
>> JH> Would this be a planned MFC to stable/N as well specifcially 8 ?
>>
>> I plan to M
On Sat, Mar 17, 2012 at 09:30:05PM +0200, Mikolaj Golub wrote:
> I added osrel output to procstat -b option:
> kopusha:~% procstat -b 2975
> PID COMMOSREL PATH
> 2975 emacs 101 /usr/local/bin/emacs-23.3
> Would this be ok or someone see a better way?
Hmm, this
On Sat, Mar 17, 2012 at 11:07:24PM +0200, Mikolaj Golub wrote:
>
> On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
>
> JH> Would this be a planned MFC to stable/N as well specifcially 8 ?
>
> I plan to MFC to stable/9 if there is no objections.
I do not see why the merge to stable/8
On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
JH> Would this be a planned MFC to stable/N as well specifcially 8 ?
I plan to MFC to stable/9 if there is no objections.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http:/
On Sat, Mar 17, 2012 at 08:51:25PM +, Robert N. M. Watson wrote:
>
> On 17 Mar 2012, at 19:30, Mikolaj Golub wrote:
>
> > Currently we can check and change binary osreldate of another process via
> > procfs(5).
> >
> > Kostik suggested to add a new sys
On 17 Mar 2012, at 19:30, Mikolaj Golub wrote:
> Currently we can check and change binary osreldate of another process via
> procfs(5).
>
> Kostik suggested to add a new sysctl for the same purpose and also extend
> procstat to show osrel.
>
> Here are patches I am going t
On Sat, Mar 17, 2012 at 09:30:05PM +0200, Mikolaj Golub wrote:
> Hi,
>
> Currently we can check and change binary osreldate of another process via
> procfs(5).
>
> Kostik suggested to add a new sysctl for the same purpose and also extend
> procstat to show osrel.
>
Hi,
Currently we can check and change binary osreldate of another process via
procfs(5).
Kostik suggested to add a new sysctl for the same purpose and also extend
procstat to show osrel.
Here are patches I am going to commit if there are no objections or
suggestions.
http://people.freebsd.org
>>
>> this is dangerous as there are some places in the kernel where processes
>> are referenced by pid, so changing it may break kernel assumptions.
>
> Sorry, i think i didn't explain it clearly. The "pid" variable is static in
> my module and it is used j
El 18/12/2011 22:12, "Julian Elischer" escribió:
>
> On 12/18/11 12:18 PM, Fernando Apesteguía wrote:
>>
>> Hi all,
>>
>> I'm writing a small module just for fun. I would like to have two
variables:
>>
>> - "pid" of type unsigned int and RW so the user can set a pid
>> - "process_name" as a string
On 12/18/11 12:18 PM, Fernando Apesteguía wrote:
Hi all,
I'm writing a small module just for fun. I would like to have two variables:
- "pid" of type unsigned int and RW so the user can set a pid
- "process_name" as a string RD that will display the process name
associated to that pid (or a mes
Hi all,
I'm writing a small module just for fun. I would like to have two variables:
- "pid" of type unsigned int and RW so the user can set a pid
- "process_name" as a string RD that will display the process name
associated to that pid (or a message if the pid doesn't exist anymore)
My problem
on 02/12/2011 19:13 Steven Hartland said the following:
[snip]
> Given this starting point the following links provided me with addtional
> information:-
> http://www.freebsd.org/doc/en/books/arch-handbook/vm.html
> http://www.freebsd.org/doc/en/books/design-44bsd/overview-memory-management.html
>
On Fri, Dec 02, 2011 at 05:13:05PM -, Steven Hartland wrote:
> - Original Message -
> From: "Andriy Gapon"
>
> >> Totalling up RSS from ps axo "rss" gives a total in the region of that if
> >> the vm stats are out by a factor of 4, in this case it should be: 8132557
> >> which is 7
- Original Message -
From: "Andriy Gapon"
Totalling up RSS from ps axo "rss" gives a total in the region of that if
the vm stats are out by a factor of 4, in this case it should be: 8132557
which is 7.75GB a much more realistic value.
Am I totally missing something or is there problem
- Original Message -
From: "Jason Hellenthal"
Just to put some visuals to this...
.
`-- DIE
|-- Core1 [Idle]
|-- Core2 [35% ]
| `-- thread127
|-- Core3 [40% ]
| `-- thread127
`-- Core4 [100%]
`-- thread127
In this case you would say the DIE should be
On 12/1/11 1:05 PM, Jason Hellenthal wrote:
On Thu, Dec 01, 2011 at 10:44:58AM -, Steven Hartland wrote:
- Original Message -
From: "Jason Hellenthal"
This goes along with the thoughts I had about 4 months ago tending to some
zfs statistics as well top showing greater than 100% ac
on 30/11/2011 14:39 Steven Hartland said the following:
> We're seeing some impossible memory usage stats reported on machines
> here from vmstat and sysctl vm.vmtotal.
>
> We have machines reporting to be using 31GB total when they only have
> 8GB physical and are not using a
Yeah
On Fri, Dec 02, 2011 at 03:19:53PM +0800, Adrian Chadd wrote:
> .. where are these statistics coming from? top?
>
>
> Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, se
.. where are these statistics coming from? top?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Thu, Dec 01, 2011 at 01:23:35PM -, Steven Hartland wrote:
> - Original Message -
> From: "Damien Fleuriot"
>
> >> I could understand a bit of overflow as stats are snapshots which may not
> >> be instuntanious, but 31GB instead of under 8GB is hardly a rounding
> >> issue /
> >>
On Thu, Dec 01, 2011 at 10:44:58AM -, Steven Hartland wrote:
> - Original Message -
> From: "Jason Hellenthal"
>
> > This goes along with the thoughts I had about 4 months ago tending to some
> > zfs statistics as well top showing greater than 100% actual CPU usage. This
> > is a bi
- Original Message -
From: "RW"
To:
Sent: Thursday, December 01, 2011 1:58 PM
Subject: Re: Invalid memory stats from vmstat and sysctl vm.vmtotal?
On Wed, 30 Nov 2011 12:39:10 -
Steven Hartland wrote:
We're seeing some impossible memory usage stats reported o
d someone might want
> > > to
> > take a look.
> > >
> > > Pay close attention to the output and behavior.
> > >
> > > sysctl net.inet.udp.blackhole=0
> > > sysctl net.inet.udp.blackhole
> > > sysctl -d net.inet.udp.blackh
On Wed, 30 Nov 2011 12:39:10 -
Steven Hartland wrote:
> We're seeing some impossible memory usage stats reported on machines
> here from vmstat and sysctl vm.vmtotal.
>
> We have machines reporting to be using 31GB total when they only have
> 8GB physical and ar
- Original Message -
From: "Damien Fleuriot"
I could understand a bit of overflow as stats are snapshots which may not
be instuntanious, but 31GB instead of under 8GB is hardly a rounding
issue /
overflow.
With respect to top showing greater than 100% by how much are you talking?
Do y
On 12/1/11 11:44 AM, Steven Hartland wrote:
> - Original Message - From: "Jason Hellenthal"
>
>> This goes along with the thoughts I had about 4 months ago tending to
>> some
>> zfs statistics as well top showing greater than 100% actual CPU usage.
>> This
>> is a big pet peave of mine.
- Original Message -
From: "Jason Hellenthal"
This goes along with the thoughts I had about 4 months ago tending to some
zfs statistics as well top showing greater than 100% actual CPU usage. This
is a big pet peave of mine. Its like saying you ate 134% of a bannanna when
in all realli
On Wed, Nov 30, 2011 at 12:39:10PM -, Steven Hartland wrote:
> We're seeing some impossible memory usage stats reported on machines
> here from vmstat and sysctl vm.vmtotal.
>
> We have machines reporting to be using 31GB total when they only have
> 8GB physical and ar
t to
>> take a look.
>>>
>>> Pay close attention to the output and behavior.
>>>
>>> sysctl net.inet.udp.blackhole=0
>>> sysctl net.inet.udp.blackhole
>>> sysctl -d net.inet.udp.blackhole=1
>>> sysctl net.inet.udp.blackhole
>&g
t to
>> take a look.
>>>
>>> Pay close attention to the output and behavior.
>>>
>>> sysctl net.inet.udp.blackhole=0
>>> sysctl net.inet.udp.blackhole
>>> sysctl -d net.inet.udp.blackhole=1
>>> sysctl net.inet.udp.blackhole
>&g
ion to the output and behavior.
> >
> > sysctl net.inet.udp.blackhole=0
> > sysctl net.inet.udp.blackhole
> > sysctl -d net.inet.udp.blackhole=1
> > sysctl net.inet.udp.blackhole
> >
> >
> > Is this expected ? should it not just display the description instead
On Friday, November 25, 2011 2:36:30 am Jason Hellenthal wrote:
>
> Found a troubling result of the following and figured someone might want to
take a look.
>
> Pay close attention to the output and behavior.
>
> sysctl net.inet.udp.blackhole=0
> sysctl net.inet.udp.
We're seeing some impossible memory usage stats reported on machines
here from vmstat and sysctl vm.vmtotal.
We have machines reporting to be using 31GB total when they only have
8GB physical and are not using any swap.
Here's an output from one of our machines:-
vmstat -c 2 -w 1 -
Found a troubling result of the following and figured someone might want to
take a look.
Pay close attention to the output and behavior.
sysctl net.inet.udp.blackhole=0
sysctl net.inet.udp.blackhole
sysctl -d net.inet.udp.blackhole=1
sysctl net.inet.udp.blackhole
Is this expected ? should it
; (if I
can call them that way), and I would like to modify that array from the
userland. So, I guess the best way to do so would be sysctl(3). This is
what I've created, after reading mac_bsdextended source:
kernel module:
static int
sysctl_rule(SYSCTL_HANDLER_ARGS)
{
// ... so
On Mon, Jul 18, 2011 at 7:47 AM, Uffe Jakobsen wrote:
> On 2011-07-18 15:54, m...@freebsd.org wrote:
>> On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote:
>>>
>>> Please consider this patch - it unifies sysctls: vm.kvm_size and
>>> vm.kvm_free.
>>>
>>> Currently these sysctls are only found un
On 2011-07-18 15:54, m...@freebsd.org wrote:
On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote:
Please consider this patch - it unifies sysctls: vm.kvm_size and
vm.kvm_free.
Currently these sysctls are only found under i386 and amd64:
sys/i386/i386/pmap.c
sys/i386/xen/pmap.c
sys/amd64/am
On Mon, Jul 18, 2011 at 5:32 AM, Uffe Jakobsen wrote:
> Please consider this patch - it unifies sysctls: vm.kvm_size and
> vm.kvm_free.
>
> Currently these sysctls are only found under i386 and amd64:
>
> sys/i386/i386/pmap.c
> sys/i386/xen/pmap.c
> sys/amd64/amd64/pmap.c
>
> It seems logical (to
Please consider this patch - it unifies sysctls: vm.kvm_size and
vm.kvm_free.
Currently these sysctls are only found under i386 and amd64:
sys/i386/i386/pmap.c
sys/i386/xen/pmap.c
sys/amd64/amd64/pmap.c
It seems logical (to me) to move them into a generic location suce as
sys/vm/vm_kern.c
P
On Mon, Apr 18, 2011 at 08:24:57AM -0400, John Baldwin wrote:
> On Saturday, April 16, 2011 10:24:44 am rank1see...@gmail.com wrote:
> > After compilation of kernel and world in MUM, kernel is installed in MUM,
> > but to install world, we reboot into SUM, then install world. (HANDBOOK)
> > Now, i
On Saturday, April 16, 2011 10:24:44 am rank1see...@gmail.com wrote:
> After compilation of kernel and world in MUM, kernel is installed in MUM,
> but to install world, we reboot into SUM, then install world. (HANDBOOK)
> Now, in case of GELI usage AND if upgrading is taking place, i.e; 8.2 ->
>
(/sbin/init --), which also remains
> upon drop to SUM.
> So init state can only be used, to determine, how sys has been booted/started.
>
> To cut it even shorter (skipping tried sysctl vars, env, etc ...)
>
>
> Solution, which passed my requirement, was one from J. H
after exiting into MUM, from SUM:
SUM->MUM (/sbin/init -s) 'init -s' remained.
If sys booted directly into MUM, I see (/sbin/init --), which also remains upon
drop to SUM.
So init state can only be used, to determine, how sys has been booted/started.
To cut it even shorter (skipping t
On Sun, 17 Apr 2011 15:11:03 +0300
Daniel Braniss wrote:
> when something gets too complicated, it's usualy helpful to look for other
> ways
> out:
> the /(root) + /usr + kernel-debuging + src is less than 1GB, so what I
> do (when diskless is not an option), I have a 2 partitions, both bootable,
>
> --Kj7319i9nmIyA2yE
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sat, Apr 16, 2011 at 04:46:53PM -0600, Warren Block wrote:
> >On Sat, 16 Apr 2011, dieter...@engineer.com wrote:
> >
> >>Suggestion 2: The kernel
On Sat, Apr 16, 2011 at 04:46:53PM -0600, Warren Block wrote:
>On Sat, 16 Apr 2011, dieter...@engineer.com wrote:
>
>>Suggestion 2: The kernel may not have an official flag for single
>>vs multi user mode but you can fake it. Try something like
>>"pgrep syslogd". If syslogd is running assume mul
On Sat, 16 Apr 2011, dieter...@engineer.com wrote:
Suggestion 2: The kernel may not have an official flag for single
vs multi user mode but you can fake it. Try something like
"pgrep syslogd". If syslogd is running assume multiuser mode. If
syslogd is not running assume single user mode.
A
> once you reboot into SUM to install world, you are doomed, BECAUSE
> ...
> Kernel will bitch (GELI part), about world->kernel mismatch and you
> won't be able to install world as you cant decrypt geom providers!!
Suggestion 1: Install the new stuff into different disk partition(s),
leaving the
On Sat, Apr 16, 2011 at 8:41 AM, Daniel O'Connor wrote:
>
> On 16/04/2011, at 17:31, Freddie Cash wrote:
>>> DO YOU KNOW, what to look for, in sys that will indicate to my function,
>>> that it is in SUM?
>>
>> No network configured, no daemons running, just a single shell
>> running. IOW, everyt
On 16/04/2011, at 17:31, Freddie Cash wrote:
>> DO YOU KNOW, what to look for, in sys that will indicate to my function,
>> that it is in SUM?
>
> No network configured, no daemons running, just a single shell
> running. IOW, everything can be done manually in MUM to "simulate"
> SUM.
My point
On Sat, Apr 16, 2011 at 7:24 AM, wrote:
> After compilation of kernel and world in MUM, kernel is installed in MUM,
> but to install world, we reboot into SUM, then install world. (HANDBOOK)
Note: You do not have to be in SUM to install the world and/or the
kernel. You can install them just fi
On 16/04/2011, at 16:24, rank1see...@gmail.com wrote:
>>
>> In that case you don't need to reboot into single user mode, you just
> make sure there aren't any non-kernel processes (besides sh) which are
> running.
>
> I know all this!!!
> I KNEW chatter would start to go this way!
> After co
> Yes, because there is no concept of single user mode to the kernel.
That's why there is no sysctl for it.
I've already accepted that as a fact, so let's not pull that cat, with
rope, around, ...anymore.
> > I truly prefer focusing on a goal and finding a way o
y, why, why ...?
> God told me!
> Why Did the Chicken Cross the Road?
> Why ...
> Is it really a relevant for this discussion?!
Yes, because there is no concept of single user mode to the kernel. That's why
there is no sysctl for it.
> I truly prefer focusing on a goal and f
> On 15/04/2011, at 19:12, rank1see...@gmail.com wrote:
> >> Oh oops, I guess the kernel runs init -s which then asks you..
> >
> > So, what is solution?
> > Currently I need to mess with lookup, in env variables.
> >
> > It must cover cases of rebooting into SUM and drop from MUM (# shutdown
>
On 15/04/2011, at 19:12, rank1see...@gmail.com wrote:
>> Oh oops, I guess the kernel runs init -s which then asks you..
>
> So, what is solution?
> Currently I need to mess with lookup, in env variables.
>
> It must cover cases of rebooting into SUM and drop from MUM (# shutdown
> now) in SUM.
> On 15/04/2011, at 17:49, rank1see...@gmail.com wrote:
> >> On 15/04/2011, at 17:03, rank1see...@gmail.com wrote:
> >>> I would like implementation of boolean sysctl var, that would show,
is
> > system in a single user mode.
> >>> I would like it fro
On 15/04/2011, at 17:49, rank1see...@gmail.com wrote:
>> On 15/04/2011, at 17:03, rank1see...@gmail.com wrote:
>>> I would like implementation of boolean sysctl var, that would show, is
> system in a single user mode.
>>> I would like it from 8.3 onwards.
>>
&
> On 15/04/2011, at 17:03, rank1see...@gmail.com wrote:
> > I would like implementation of boolean sysctl var, that would show, is
system in a single user mode.
> > I would like it from 8.3 onwards.
>
> AFAIK the kernel doesn't have a "single user" mode.
&g
On 15/04/2011, at 17:03, rank1see...@gmail.com wrote:
> I would like implementation of boolean sysctl var, that would show, is system
> in a single user mode.
> I would like it from 8.3 onwards.
AFAIK the kernel doesn't have a "single user" mode.
It's just that w
I would like implementation of boolean sysctl var, that would show, is system
in a single user mode.
I would like it from 8.3 onwards.
Domagoj Smolčić
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
> >
> > $ cat /boot/loader.conf | grep hw.physmem
> > hw.physmem="500M"
> > $
> >
> > However, according to sysctl, the system sees
> >
> > $ sysctl hw.physmem
> > hw.physmem: 507445248
> > $
> >
> > The differen
t; > $ cat /boot/loader.conf | grep hw.physmem
> > hw.physmem="500M"
> > $
> >
> > However, according to sysctl, the system sees
> >
> > $ sysctl hw.physmem
> > hw.physmem: 507445248
> > $
> >
> > The difference is (500 * 2**
on 04/03/2011 16:36 Dmitry Krivenok said the following:
> Hello Hackers,
> I've limited the amount of physical memory visible for my FreeBSD-8.2 by
> adding
> the following in loader.conf:
>
> $ cat /boot/loader.conf | grep hw.physmem
> hw.physmem="500M"
&
Hello Hackers,
I've limited the amount of physical memory visible for my FreeBSD-8.2 by adding
the following in loader.conf:
$ cat /boot/loader.conf | grep hw.physmem
hw.physmem="500M"
$
However, according to sysctl, the system sees
$ sysctl hw.physmem
hw.physmem: 507445248
$
Th
;m using a little shell script to capture selected sysctl OID
>>>> values periodically, in an attempt to get a better idea how the
>>>> resources of a system are being used during a long-running (usually
>>>> measured in hours), mission-critical workload.
&g
On Thu, Mar 3, 2011 at 3:34 PM, Matthew Fleming wrote:
> On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch
> wrote:
>> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill
>> wrote:
>>> I'm using a little shell script to capture selected sysctl OID
>>> va
On Thu, Mar 3, 2011 at 1:03 PM, Brandon Gooch
wrote:
> On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill wrote:
>> I'm using a little shell script to capture selected sysctl OID
>> values periodically, in an attempt to get a better idea how the
>> resources of a syst
On Thu, Mar 3, 2011 at 11:49 AM, David Wolfskill wrote:
> I'm using a little shell script to capture selected sysctl OID
> values periodically, in an attempt to get a better idea how the
> resources of a system are being used during a long-running (usually
> measured in hours),
I'm using a little shell script to capture selected sysctl OID
values periodically, in an attempt to get a better idea how the
resources of a system are being used during a long-running (usually
measured in hours), mission-critical workload.
In the process of testing this, I've seen s
he appropiate list to ask this.
> > Could you point me the correct list if so?
> >
> > I'm writing a small program to capture the temperature reported by the
> > coretemp kernel module. I'm doing this by using the sysctl API. However,
> I'm
> > fa
correct list if so?
>
> I'm writing a small program to capture the temperature reported by the
> coretemp kernel module. I'm doing this by using the sysctl API. However, I'm
> facing a problem when reading that value (dev.cpu.0.temperature, for
> example).
>
&g
p kernel module. I'm doing this by using the sysctl API. However, I'm
> facing a problem when reading that value (dev.cpu.0.temperature, for
> example).
>
> man 3 sysctl has an example (labeled as "To retrieve the standard search
> path for the system utilities:"
Hello,
First of all, forgive if this is not the appropiate list to ask this.
Could you point me the correct list if so?
I'm writing a small program to capture the temperature reported by the
coretemp kernel module. I'm doing this by using the sysctl API. However, I'm
facing
Mark Johnston writes:
> Aren't the dev.cpu.X and the coretemp sysctls matched up by the use of
>
> SYSCTL_CHILDREN(device_get_sysctl_tree(pdev))
>
> in coretemp's sysctl definition? What does the sysctl context have to do
> with identifying the parent oid?
They'r
1 - 100 of 538 matches
Mail list logo
