> On Oct 12, 2023, at 5:40 PM, Zhenlei Huang wrote:
>
>
>
>> On Oct 12, 2023, at 3:37 PM, Dewayne Geraghty
>> wrote:
>>
>> Thank-you so much for attending to AND correcting some of the weird
>> anomalies. Perhaps one day we can rely upon sysc
Am 2023-09-03 21:22, schrieb Alexander Leidinger:
Am 2023-09-02 16:56, schrieb Mateusz Guzik:
On 8/20/23, Alexander Leidinger wrote:
Hi,
sysctl kern.maxvnodes=1048576000 results in 100% CPU and a
non-killable
sysctl program. This is somewhat unexpected...
fixed here
https
Am 2023-09-02 16:56, schrieb Mateusz Guzik:
On 8/20/23, Alexander Leidinger wrote:
Hi,
sysctl kern.maxvnodes=1048576000 results in 100% CPU and a
non-killable
sysctl program. This is somewhat unexpected...
fixed here
https://cgit.freebsd.org/src/commit/?id
On 8/20/23, Alexander Leidinger wrote:
> Hi,
>
> sysctl kern.maxvnodes=1048576000 results in 100% CPU and a non-killable
> sysctl program. This is somewhat unexpected...
>
fixed here
https://cgit.freebsd.org/src/commit/?id=32988c1499f8698b41e15ed40a46d271e757bba3
employing
Am 2023-08-20 21:23, schrieb Alexander Leidinger:
Am 2023-08-20 18:55, schrieb Mina Galić:
procstat(1) kstack could be helpful here.
Original Message
On 20 Aug 2023, 17:29, Alexander Leidinger alexan...@leidinger.net>
wrote:
Hi, sysctl kern.maxvnodes=1048576000 results
Am 2023-08-20 18:55, schrieb Mina Galić:
procstat(1) kstack could be helpful here.
Original Message
On 20 Aug 2023, 17:29, Alexander Leidinger alexan...@leidinger.net>
wrote:
Hi, sysctl kern.maxvnodes=1048576000 results in 100% CPU and a
non-killable sysctl program. T
procstat(1) kstack could be helpful here.
Original Message
On 20 Aug 2023, 17:29, Alexander Leidinger wrote:
> Hi, sysctl kern.maxvnodes=1048576000 results in 100% CPU and a non-killable
> sysctl program. This is somewhat unexpected... Bye, Alexander. --
Sounds like a fork bomb discovered
Obter o Outlook para Android<https://aka.ms/AAb9ysg>
From: owner-freebsd-curr...@freebsd.org on
behalf of Alexander Leidinger
Sent: Sunday, August 20, 2023 1:29:40 PM
To: curr...@freebsd.org
Subject: 100% CPU time for
Hi,
sysctl kern.maxvnodes=1048576000 results in 100% CPU and a non-killable
sysctl program. This is somewhat unexpected...
Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF
4.0-CURRENT #55
>> main-n259064-f83db6441a2f-dirty: Sun Nov 6 16:31:55 PST 2022
>> root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
>> amd64 amd64 1400073 1400073
>>
>>
>> But . . .
>>
>> # sy
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
> amd64 amd64 1400073 1400073
>
>
> But . . .
>
> # sysctl -d kern.bootfile
> kern.bootfile: Name of kernel file booted
>
> # sysctl -W kern.bootfile
> kern.bootfile: /boot/ker
. . .
# sysctl -d kern.bootfile
kern.bootfile: Name of kernel file booted
# sysctl -W kern.bootfile
kern.bootfile: /boot/kernel.old/kernel
Looks wrong to me. (I've never explicitly assigned to kern.bootfile .)
===
Mark Millard
marklmi at yahoo.com
On 5/29/22 11:16, Mark Millard wrote:
FYI, the combination:
vm.pageout_oom_seq=120 # in /boot/loader.conf
vm.swap_enabled=0 # in /etc/sysctl.conf
vm.swap_idle_enabled=0 # in /etc/sysctl.conf
still has not caused me any additional problems
and helps avoid loss of access by avoiding the
gt;> vm.pageout_oom_seq=120 is in use for this, my normal
>> context since sometime in 2018.
>
> So to revive an old thread here.
>
> it looks like setting these two sysctl knobs have helped the situation:
> vm.swap_enabled=0
> vm.swap_idle_enabled=0
>
> i
.
So to revive an old thread here.
it looks like setting these two sysctl knobs have helped the situation:
vm.swap_enabled=0
vm.swap_idle_enabled=0
i've gone 7 days without any OOM events under normal work usage (as
opposed to about 4days previously). this includes the following patc
o
issues. Nor does it indicate how wide a range of activity
is fairly likely to reach the failing conditions.
You could see how vm.pageout_oom_seq=120 does for you with
the patch. I was never patient enough to wait long enough
for this to OOM kill or hang-up in my test context.
I've be
On 5/11/22 12:52, Mark Millard wrote:
Relative to avoiding hang-ups, so far it seems that
use of vm.swap_enabled=0 with vm.swap_idle_enabled=0
makes hang-ups less likely/less frequent/harder to
produce examples of. But is no guarantee of lack of
a hang-up. Its does change the cause of the han
heir lights when pressed.
>>>>
>>>> Using an ssh session, the system looked fine. USB events for the keyboard
>>>> being disconnected and reconnected appeared but the keyboard stayed
>>>> unresponsive.
>>>>
>>>> Setting vm.swap_e
ing vm.swap_enabled=0, as you did above, resolved this problem. After
>>> the process was killed a perfectly normal console returned.
>>>
>>> The interesting thing is that this test system is configured with no swap
>>> space.
>>>
>>> Thi
nsive.
>>
>> Setting vm.swap_enabled=0, as you did above, resolved this problem. After
>> the process was killed a perfectly normal console returned.
>>
>> The interesting thing is that this test system is configured with no swap
>> space.
>>
.
>
> This is on 13.1-RC5.
>
>> This disables swapping out of process kernel stacks. It
>> is just with that option removedfor gaining free RAM, there
>> fewer options tried before a kill is initiated. It is not a
>> loader-time tunable but is writable, thus the
On 10 May 2022, at 10:01, Mark Millard wrote:
>
> On 2022-Apr-29, at 13:57, Mark Millard wrote:
>
>> On 2022-Apr-29, at 13:41, Pete Wright wrote:
>>>
. . .
>>>
>>> d'oh - went out for lunch and workstation locked up. i *knew* i shouldn't
>>> have said anything lol.
>>
>> Any interest
On 2022-Apr-29, at 13:57, Mark Millard wrote:
> On 2022-Apr-29, at 13:41, Pete Wright wrote:
>>
>>> . . .
>>
>> d'oh - went out for lunch and workstation locked up. i *knew* i shouldn't
>> have said anything lol.
>
> Any interesting console messages ( or dmesg -a or /var/log/messages )?
>
;> vm.domain.0.stats.free_severe: Severe free pages
>> vm.domain.0.stats.free_min: Minimum free pages
>> vm.domain.0.stats.free_reserved: Reserved free pages
>> vm.domain.0.stats.free_target: Target free pages
>> vm.domain.0.stats.inactive_target: Target inactive pages
> ok than
my website and share them
publicly when i have time. i'll definitely take you input into account
when sharing this info.
Also, what value were you using for:
vm.pageout_oom_seq
$ sysctl vm.pageout_oom_seq
vm.pageout_oom_seq: 120
$
cheers,
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
On 2022-Apr-29, at 11:08, Pete Wright wrote:
> On 4/23/22 19:20, Pete Wright wrote:
>>
>>> The developers handbook has a section debugging deadlocks that he
>>> referenced in a response to another report (on freebsd-hackers).
>>>
>>> https://docs.freebsd.org/en/books/developers-handbook/kerneld
On 4/23/22 19:20, Pete Wright wrote:
The developers handbook has a section debugging deadlocks that he
referenced in a response to another report (on freebsd-hackers).
https://docs.freebsd.org/en/books/developers-handbook/kerneldebug/#kerneldebug-deadlocks
d'oh - thanks for the correcti
current
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?
On 2022-Apr-23, at 10:26, Pete Wright
mailto:p...@nomadlogic.org>> wrote:
> On 4/22/22 18:46, Mark Millard wrote:
>> On 2022-Apr-22, at 16:42, Pete Wright
>> mailto:p...@nomadlogic.org>> wrote
On 4/23/22 12:31, Mark Millard wrote:
I think you may have taken my suggestion backwards . . .
Unfortunately, vnode (file) based swap space should be *avoided*
and partitions are what should be used in order to avoid deadlocks:
On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wrote
on the fr
t; I use ZFS on systems with at least 8 GiBytes of RAM,
>> but I've never tuned ZFS. So I'm not much help for
>> that side of things.
>
> since we started this thread I've gone ahead and removed the zfs.arc.max
> setting since its cruft at this point. i initially ad
is both a loader tunable
and a writeable runtime tunable:
# sysctl -T vm.pageout_oom_seq
vm.pageout_oom_seq: 120
amd64_ZFS amd64 1400053 1400053 # sysctl -W vm.pageout_oom_seq
vm.pageout_oom_seq: 120
So you can use it to extend the time when the
machine is already running.
fantastic. thanks
update_period=0
> >
> > Since setting these here, OOM is a rarity. I don't profess to exactly
> > know
> > what they do in detail though. But my experience since these were set
> > is hardly any OOM and big users of memory like firefox don't crash.
>
>
estion that should allow delaying
such kills for a long time. That in turn may
help with investigating without actually
suffering the kills during the activity: more
time with low free RAM to observe.
Increase:
# sysctl -d vm.pageout_oom_seq
vm.pageout_oom_seq: back-to-back calls to oom detector to
ose a test next time i crash which will be by next
thurs if the pattern continues.
looking at the sysctl descriptions:
vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM
vm.pfault_oom_attempts: Number of page allocation attempts in page fault
handler before it trigge
On 4/21/22 21:18, Mark Millard wrote:
Messages in the console out would be appropriate
to report. Messages might also be available via
the following at appropriate times:
that is what is frustrating. i will get notification that the processes
are killed:
Apr 22 09:55:15 topanga kernel: pi
Hi,
On Thu, Apr 21, 2022 at 07:16:42PM -0700, Pete Wright wrote:
hello -
on my workstation running CURRENT (amd64/32g of ram) i've been running
into a scenario where after 4 or 5 days of daily use I get an OOM event
and both chromium and firefox are killed. then in the next day or so
the syste
Pete Wright wrote on
Date: Thu, 21 Apr 2022 19:16:42 -0700 :
> on my workstation running CURRENT (amd64/32g of ram) i've been running
> into a scenario where after 4 or 5 days of daily use I get an OOM event
> and both chromium and firefox are killed. then in the next day or so
> the system w
hello -
on my workstation running CURRENT (amd64/32g of ram) i've been running
into a scenario where after 4 or 5 days of daily use I get an OOM event
and both chromium and firefox are killed. then in the next day or so
the system will become very unresponsive in the morning when i unlock my
hursday, 1 April 2021 08:15
> > To: freebsd-current@freebsd.org
> > Subject: Missing sysctl OID in RC4
> >
> > Do you know if net.inet.sctp.blackhole has been removed from r13?
> > Sysctl says it is unknown though still described in blackhole(4)
>
> SCTP is not
> -Original Message-
> From: owner-freebsd-curr...@freebsd.org curr...@freebsd.org> On Behalf Of Athan Papadimitriou
> Sent: Thursday, 1 April 2021 08:15
> To: freebsd-current@freebsd.org
> Subject: Missing sysctl OID in RC4
>
> Do you know if net.inet.sctp.bl
> On 1 Apr 2021, at 09:15, Athan Papadimitriou wrote:
>
> Do you know if net.inet.sctp.blackhole has been removed from r13?
> Sysctl says it is unknown though still described in blackhole(4)
>
Did you load the module?
uname -r
13.0-RC4
# kldload sctp
# kldstat
Do you know if net.inet.sctp.blackhole has been removed from r13?
Sysctl says it is unknown though still described in blackhole(4)
Thanks
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To
On 2020-Dec-19, at 03:09, Hans Petter Selasky wrote:
> Please test:
>
> https://svnweb.freebsd.org/changeset/base/368799
> https://svnweb.freebsd.org/changeset/base/368801
>
> --HPS
I grabbed a debug -r368803 kernel from artifacts (first arm64
snapshot available containing the above 2 updat
Please test:
https://svnweb.freebsd.org/changeset/base/368799
https://svnweb.freebsd.org/changeset/base/368801
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail t
: (sleepable after non-sleepable)
> 1st 0xa2b2cea0 ure0 (ure0, sleep mutex) @
> /usr/src/sys/dev/usb/usb_request.c:714
> 2nd 0x00dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0
> fib 0: route alrr/src/sys/kern/kern_sysctl.c:836
> lock order ure0 -
gatelock order reversal: (sleepable after non-sleepable)
1st 0xa2b2cea0 ure0 (ure0, sleep mutex) @
/usr/src/sys/dev/usb/usb_request.c:714
2nd 0xffff00dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0
fib 0: route alrr/src/sys/kern/kern_sysctl.c:836
lock order ure0 -> sysctl
On Thu, Sep 10, 2020, at 11:50 PM, Brandon Bergren wrote:
> On Thu, Sep 10, 2020, at 11:17 PM, Graham Perrin wrote:
> > On 09/09/2020 07:46, Stefan Esser wrote:
> > > … an annoyance that I had noticed before but now have
> > > tracked down:
> > >
> >
On Thu, Sep 10, 2020, at 11:17 PM, Graham Perrin wrote:
> On 09/09/2020 07:46, Stefan Esser wrote:
> > … an annoyance that I had noticed before but now have
> > tracked down:
> >
> > $ time sysctl kstat.zfs.misc.dbufs | wc
> > 55327 2047031 16333472
&
On 09/09/2020 07:46, Stefan Esser wrote:
… an annoyance that I had noticed before but now have
tracked down:
$ time sysctl kstat.zfs.misc.dbufs | wc
55327 2047031 16333472
real 0m16,446s
user 0m0,055s
sys 0m16,397s
…
Here, I get much scrolling but no output from time:
root
On 2020-03-28 02:43, Graham Perrin wrote:
> This occurs when I enable OpenZFS:
>
> OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'
>
> Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?
>
> From <https://pastebin.com/hTCTWPW2>:
> This occurs when I enable OpenZFS:
>
> OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'
>
> Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?
>
> From <https://pastebin.com/hTCTWPW2>:
>
> grahamperrin@momh167-gjp4-8570p:~ % s
This occurs when I enable OpenZFS:
OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'
Is it to be deprecated? Or is it not yet a feature of OpenZFS for FreeBSD?
From <https://pastebin.com/hTCTWPW2>:
grahamperrin@momh167-gjp4-8570p:~ % sysctl vfs.zfs.arc_max
sysctl: unknown oid
On 1/12/19 5:12 AM, O. Hartmann wrote:
> Am Thu, 10 Jan 2019 22:22:05 +0100
> "O. Hartmann" schrieb:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>
>> Am Thu, 10 Jan 2019 12:02:15 -0800
>> Cy Schubert schrieb:
>
>>> I'm not able to reproduce this at the moment.
I can confirm that SV
this at the moment.
> >
> >
>
> I have a oldish Lenovo R500 Notebook running FreeBSD-12 STABLE. I'm not sure
> what WiFi
> Interface driver the system is using right now; the WiFi is combined with the
> NIC to
> form a lagg-interface. I can 100% reproduce the
Hi
I have a Lenovo T510 running FreeBSD-12 STABLE. After configuring for lagg
interface (combined from em - Intel gigabit ethernet adapter and iwn - intel
wireless adapter) I can cause the system to panic with sysctl -a.
Using either the em interface or the wireless I can safely use sysctl -a
is using right now; the WiFi is combined with the
NIC to form
a lagg-interface. I can 100% reproduce the crash described above via "sysctl
-a". Just in
case the phenomenon I discovered shortly after Christmas is of the same source
as the
initial poster has reported, how can I be of help
-
>
> -Original Message-
> From: Michael Zhilin
> Sent: 10/01/2019 08:00
> To: Michael Butler
> Cc: freebsd-current
> Subject: Re: kernel panic in wireless-related sysctl walk
>
> I'm not lucky to reproduce it even if i use iwn and "sysctl
> net.wlan.0
pports top post. Apologies.
Cy Schubert
or
The need of the many outweighs the greed of the few.
---
-Original Message-
From: Michael Zhilin
Sent: 10/01/2019 08:00
To: Michael Butler
Cc: freebsd-current
Subject: Re: kernel panic in wireless-related sysctl walk
I'm not lucky to reprodu
I'm not lucky to reproduce it even if i use iwn and "sysctl
net.wlan.0.rate_stats"
Problem is related to 802.11n, but all my networks are 11g.
BR
On Thu, Jan 10, 2019 at 6:53 PM Michael Zhilin wrote:
> Hi,
>
> Is it possible to print out any local variables of frame
Hi,
Is it possible to print out any local variables of frame #8?
Thx!
On Thu, Jan 10, 2019 at 6:31 PM Michael Butler
wrote:
> With 'device iwn' and all the related wireless bits compiled into a
> custom kernel for a laptop, executing 'sysctl -a' yields a
With 'device iwn' and all the related wireless bits compiled into a
custom kernel for a laptop, executing 'sysctl -a' yields a kernel panic
of the form ..
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x8
fault code
[Fixing dumb, confusing subject typo. No change below.]
On 2018-Nov-17, at 12:54, Mark Millard wrote:
> For some reason there is no .dev.cpu.31 listed for the 1950X that
> I use. This is a native boot, not use under Hyper-V. For
> illustration I list:
>
> # sysctl dev.c
For some reason there is no .dev.cpu.31 listed for the 1950X that
I use. This is a native boot, not use under Hyper-V. For
illustration I list:
# sysctl dev.cpu | grep "desc"
dev.cpu.30.%desc: ACPI CPU
dev.cpu.29.%desc: ACPI CPU
dev.cpu.28.%desc: ACPI CPU
dev.cpu.27.%desc: ACPI CPU
On Tue, Aug 28, 2018 at 08:40:15AM +0200, Alexander Leidinger wrote:
> Hi,
>
> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> 12.0-alpha3 with a top from an old-ish -current.
>
> Is/will this be handled via a compat-11 sysctl (my kernel is without
&g
>>>> On 2018-08-28 02:40, Alexander Leidinger wrote:
>>>>> Hi,
>>>>>
>>>>> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
>>>>> 12.0-alpha3 with a top from an old-ish -current.
>>>>>
>>>>
> > Hi,
> >> >
> >> > top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> >> > 12.0-alpha3 with a top from an old-ish -current.
> >> >
> >> > Is/will this be handled via a compat-11 sysctl (my kernel is without
>
Quoting Eitan Adler (from Tue, 28 Aug 2018
22:54:04 -0700):
On Tue, 28 Aug 2018 at 22:46, Alexander Leidinger
wrote:
>
> IIRC that would have been the inverted case of running a newer top(1)
> with an older kernel lacking the v_laundry_pages sysctl. In general I'd
> exp
On Tue, 28 Aug 2018 at 22:46, Alexander Leidinger
wrote:
> >
> > IIRC that would have been the inverted case of running a newer top(1)
> > with an older kernel lacking the v_laundry_pages sysctl. In general I'd
> > expect us to support running an older top(1) with
Quoting Mark Johnston (from Tue, 28 Aug 2018
10:48:42 -0400):
On Tue, Aug 28, 2018 at 10:25:39AM -0400, Allan Jude wrote:
On 2018-08-28 02:40, Alexander Leidinger wrote:
> Hi,
>
> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> 12.0-alpha3 with a top fro
On Tue, Aug 28, 2018 at 10:25:39AM -0400, Allan Jude wrote:
> On 2018-08-28 02:40, Alexander Leidinger wrote:
> > Hi,
> >
> > top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> > 12.0-alpha3 with a top from an old-ish -current.
> >
> >
On 2018-08-28 02:40, Alexander Leidinger wrote:
> Hi,
>
> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> 12.0-alpha3 with a top from an old-ish -current.
>
> Is/will this be handled via a compat-11 sysctl (my kernel is without
> compat-xx), or did this s
Hi,
top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
12.0-alpha3 with a top from an old-ish -current.
Is/will this be handled via a compat-11 sysctl (my kernel is without
compat-xx), or did this slip through?
Bye,
Alexander.
--
http://www.Leidinger.net alexan
On Thu, Jul 26, 2018 at 8:52 PM, Shane Ambler wrote:
> I use devel/py-sysctl in some scripts to get values, using a recent
> 12-current (r336728) I see at least two values that get a different
> value type than on 11-stable. Same version of python and port.
> ...
Hi Shane,
At som
I use devel/py-sysctl in some scripts to get values, using a recent
12-current (r336728) I see at least two values that get a different
value type than on 11-stable. Same version of python and port.
I have 12-current running in a bhyve on an 11-stable host.
Is there a recent change to sysctl
On Thu, Feb 22, 2018 at 8:34 PM, O. Hartmann wrote:
> Mateusz provided me with this patch, which solved the issue:
>
> Index: sys/kern/vfs_bio.c
> ===
> --- sys/kern/vfs_bio.c (revision 329832)
> +++ sys/kern/vfs_bio.c (working cop
uot; schrieb:
> > >
> > > >
> > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue
> > > > Feb 20 23:06:15 CET
> > > > 2018 amd64) I'm honored by this nice bug when calling top:
> > > >
> > > &g
RRENT #196 r329679: Tue
> > > Feb 20 23:06:15 CET
> > > 2018 amd64) I'm honored by this nice bug when calling top:
> > >
> > > top: sysctl(vfs.bufspace...) expected 8, got 4
> > >
> > >
> > > Regards,
> > >
> > > oh
by this nice bug when calling top:
> >
> > top: sysctl(vfs.bufspace...) expected 8, got 4
> >
> >
> > Regards,
> >
> > oh
> I still can not use "top", it quits with the error mentioned above.
> Whats is wrong with
> my setup?
>
It see
On Thu, Feb 22, 2018 at 6:41 PM, O. Hartmann wrote:
> Am Wed, 21 Feb 2018 20:05:24 +0100
> "O. Hartmann" schrieb:
>
> > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20
> 23:06:15 CET
> > 2018 amd64) I'm honored by this nice bu
Am Wed, 21 Feb 2018 20:05:24 +0100
"O. Hartmann" schrieb:
> On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20
> 23:06:15 CET
> 2018 amd64) I'm honored by this nice bug when calling top:
>
> top: sysctl(vfs.bufspace...) expected 8, got 4
>
On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20
23:06:15 CET 2018
amd64) I'm honored by this nice bug when calling top:
top: sysctl(vfs.bufspace...) expected 8, got 4
Regards,
oh
--
O. Hartmann
Ich widerspreche der Nutzung oder Übermittlung meiner Date
On Thursday, August 03, 2017 09:57:15 AM Andriy Gapon wrote:
> On 02/08/2017 18:49, John Baldwin wrote:
> > sysctl nodes are created explicitly via linker_file_register_sysctls, not
> > via
> > SYSINITs, so you can't order them with respect to other init functions.
On 02/08/2017 18:49, John Baldwin wrote:
> sysctl nodes are created explicitly via linker_file_register_sysctls, not via
> SYSINITs, so you can't order them with respect to other init functions.
>
> I think Andriy's suggestion of doing sysctls "inside" sysinits (s
the
> >>> module event handler.
> >>>
> >>> In linker_load_file() I see the following code:
> >>> linker_file_register_sysctls(lf);
> >>> linker_file_sysinit(lf);
> >>>
> >>> I
any statically declared sysctl-s in the module
would be registered before the module receives the MOD_LOAD event.
It's possible that some of the sysctl-s could have procedures as handlers and
they might access data that is supposed to be initialized by the module event
handler.
So, for ex
> > > module event handler.
> > >
> > > In linker_load_file() I see the following code:
> > > linker_file_register_sysctls(lf);
> > > linker_file_sysinit(lf);
> > >
> > > I think that this means that any statically declared sysctl-s in
&g
linker_file_sysinit(lf);
> >
> > I think that this means that any statically declared sysctl-s in the module
> > would be registered before the module receives the MOD_LOAD event.
> > It's possible that some of the sysctl-s could have procedure
.
In linker_load_file() I see the following code:
linker_file_register_sysctls(lf);
linker_file_sysinit(lf);
I think that this means that any statically declared sysctl-s in the module
would be registered before the module receives the MOD_LOAD event
code:
linker_file_register_sysctls(lf);
linker_file_sysinit(lf);
I think that this means that any statically declared sysctl-s in the module
would be registered before the module receives the MOD_LOAD event.
It's possible that some of the sys
Hi!
> >> I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro
> >> X11SSZ-TLN4F board, and
> >>
> >> pkg install intel-ixl-kmod
> >>
> >> and now:
> >>
> >> sysctl -a
> >>
> >> hangs. Any quick
On 03/21/17 17:14, hiren panchasara wrote:
On 03/21/17 at 05:04P, Kurt Jaeger wrote:
Hello,
I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro
X11SSZ-TLN4F board, and
pkg install intel-ixl-kmod
and now:
sysctl -a
hangs. Any quick ideas how to debug this ?
If it's jus
On 03/21/17 at 05:04P, Kurt Jaeger wrote:
> Hello,
>
> I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro
> X11SSZ-TLN4F board, and
>
> pkg install intel-ixl-kmod
>
> and now:
>
> sysctl -a
>
> hangs. Any quick ideas how to debug this ?
If
Hello,
I have a freshly installed/updated FreeBSD 11.0p8 on a supermicro
X11SSZ-TLN4F board, and
pkg install intel-ixl-kmod
and now:
sysctl -a
hangs. Any quick ideas how to debug this ?
--
p...@opsec.eu+49 171 3101372 3 years to go
On recent 12.0-CURRENT FreeBSD 12.0-CURRENT #36 r303869, I see apart from
serious performance issues and stuck ZFS rsync synchronisations this on the
console, when typing "dmesg" in theshell from a user which is member of group
"wheel":
dmesg: sysctl kern.msgbuf: Operation no
Thanks for testing Nathan, that is the expected behaviour it might be
nice if we had the concept of a sysctl which is at its auto value and
hence we could use that to determine if we should recalculate said
automatic values which hadn't been manually set but we don't have that
unf
so that I have the
default values after booting, and then use:
# sysctl vfs.zfs.arc_max="8589934592"
The result is:
vfs.zfs.arc_meta_limit: 2147483648
vfs.zfs.arc_min: 1951729664
vfs.zfs.arc_max: 8589934592
Max was set as requested.
meta_limit was set to max/4.
But min is still at the defa
On 06/07/2016 21:39, Eric van Gyzen wrote:
On 07/06/16 03:35 PM, Steven Hartland wrote:
The ARC settings and kmem aren't initialised when tunables are loaded
so the tests fail.
I've fixed this locally by blindly setting if ARC is not configured.
Request to commit the fix is with re@
In the mea
ok this:
>> "You can work around it temporarily by setting a lower arc_min first."
>>
>> To mean that I could do something like:
>> vfs.zfs.arc_min="1073741824"
>> vfs.zfs.arc_max="8589934592"
>>
>> in loader.conf, which would ci
On 07/06/16 03:35 PM, Steven Hartland wrote:
> The ARC settings and kmem aren't initialised when tunables are loaded
> so the tests fail.
>
> I've fixed this locally by blindly setting if ARC is not configured.
> Request to commit the fix is with re@
>
> In the mean time the patch is attached.
>
>
loader.conf, which would circumvent the problem.
But with the above, in that order, I still get:
Setting sysctl vfs.zfs.arc_max failed: 22
Setting sysctl vfs.zfs.arc_min failed: 22
As an FYI, WITHOUT any tunables set, my defaults are:
vfs.zfs.arc_meta_limit: 3903459328
vfs.zfs.arc_min: 19517296
1 - 100 of 525 matches
Mail list logo