Re: git: 9d6eb30abb29 - stable/12 - x86: Add sysctl flag CTLFLAG_TUN to loader tunables

> 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

Re: 100% CPU time for sysctl command, not killable

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

Re: 100% CPU time for sysctl command, not killable

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

Re: 100% CPU time for sysctl command, not killable

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

Re: 100% CPU time for sysctl command, not killable

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 resu

Re: 100% CPU time for sysctl command, not killable

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 prog

Re: 100% CPU time for sysctl command, not killable

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. --

Re: 100% CPU time for sysctl command, not killable

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

100% CPU time for sysctl command, not killable

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

Re: Odd sysctl -d kern.bootfile result

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

Re: Odd sysctl -d kern.bootfile result

/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/

Odd sysctl -d kern.bootfile result

But . . . # 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

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Re: Chasing OOM Issues - good sysctl metrics to use?

. >> 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 > >

Re: Chasing OOM Issues - good sysctl metrics to use?

. 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 patch

Re: Chasing OOM Issues - good sysctl metrics to use?

t 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 been reporting the likes of

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Re: Chasing OOM Issues - good sysctl metrics to use?

>>>> >>>> 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_enabled=0, as you

Re: Chasing OOM Issues - good sysctl metrics to use?

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. >>

Re: Chasing OOM Issues - good sysctl metrics to use?

gt;> 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-

Re: Chasing OOM Issues - good sysctl metrics to use?

3.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 >> /etc/sysctl.conf

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Re: Chasing OOM Issues - good sysctl metrics to use?

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 )? >

Re: Chasing OOM Issues - good sysctl metrics to use?

ats.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 thanks Mark, based on th

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Re: Chasing OOM Issues - good sysctl metrics to use?

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). >>> >>>

Re: Chasing OOM Issues - good sysctl metrics to use?

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

RE: Chasing OOM Issues - good sysctl metrics to use?

: 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: >> &g

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Re: Chasing OOM Issues - good sysctl metrics to use?

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 added it to test

Re: Chasing OOM Issues - good sysctl metrics to use?

er 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 again for taking

Re: Chasing OOM Issues - good sysctl metrics to use?

e_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. > > nice, i will

Re: Chasing OOM Issues - good sysctl metrics to use?

suggestion 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 detecto

Re: Chasing OOM Issues - good sysctl metrics to use?

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 triggers OOM handling

Re: Chasing OOM Issues - good sysctl metrics to use?

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:

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Re: Chasing OOM Issues - good sysctl metrics to use?

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

Chasing OOM Issues - good sysctl metrics to use?

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

Re: Missing sysctl OID in RC4

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

RE: Missing sysctl OID in RC4

> -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

Re: Missing sysctl OID in RC4

> 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

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) Thanks ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current

Re: debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

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

Re: debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

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

Re: debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

eepable 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 ->

debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

lock order reversal: (sleepable after non-sleepable) 1st 0xa2b2cea0 ure0 (ure0, sleep mutex) @ /usr/src/sys/dev/usb/usb_request.c:714 2nd 0x000000dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0 fib 0: route alrr/src/sys/kern/kern_sysctl.c:836 lock order ure0 -> sysctl l

Re: time sysctl kstat.zfs.misc.dbufs | wc (was: OpenZFS and L2ARC)

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: > > > > >

Re: time sysctl kstat.zfs.misc.dbufs | wc (was: OpenZFS and L2ARC)

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 &

time sysctl kstat.zfs.misc.dbufs | wc (was: OpenZFS and L2ARC)

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

Re: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

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>: > >

Re: OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

> 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.

OpenZFS: sysctl: unknown oid 'vfs.zfs.arc_max'

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 'vfs.zfs.a

Re: kernel panic in wireless-related sysctl walk

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

Re: kernel panic in wireless-related sysctl walk

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 crash des

RE: kernel panic in wireless-related sysctl walk

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

Re: kernel panic in wireless-related sysctl walk

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? The syst

Re: kernel panic in wireless-related sysctl walk

; -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.rate_stats" &g

RE: kernel panic in wireless-related sysctl walk

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 reproduce it even if i

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.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 #8?

Re: kernel panic in wireless-related sysctl walk

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 kernel panic > of

kernel panic in wireless-related sysctl walk

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 = supervisor read

Re: Ryzen Threadripper 1950X based on head -r340287: sysctl dev.cpu: 0-30 but no 31? (top shows all 0-31 "CPU"s) [subject corrected]

[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

Ryzen Threadripper 1950X based on head -r340287: sysctl dev.cpu: 0-30 but no 31? (top shows all 31 "CPU"s)

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

Re: old top and new -current: missing arcstat sysctl

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

Re: old top and new -current: missing arcstat sysctl

>>>> 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. >>>>

Re: old top and new -current: missing arcstat sysctl

> > 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 >

Re: old top and new -current: missing arcstat sysctl

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 > expect u

Re: old top and new -current: missing arcstat sysctl

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 newer

Re: old top and new -current: missing arcstat sysctl

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

Re: old top and new -current: missing arcstat sysctl

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. > > > >

Re: old top and new -current: missing arcstat sysctl

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

old top and new -current: missing arcstat sysctl

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

Re: Changes to sysctl values

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

Changes to sysctl values

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

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

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) > +++

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

18 20:05:24 +0100 > > > "O. Hartmann" <o.hartm...@walstatt.org> schrieb: > > > > > > > > > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue > > > > Feb 20 23:06:15 CET > > >

Re: 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 > > > > > > > >

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

gt; 2018 amd64) I'm honored 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

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

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 > > I still can not use "top", it quits with the error mentioned above. Whats > is

Re: top: sysctl(vfs.bufspace...) expected 8, got 4

Am Wed, 21 Feb 2018 20:05:24 +0100 "O. Hartmann" <o.hartm...@walstatt.org> 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

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 Daten für

Re: order of executing MOD_LOAD and registering module sysctl-s

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. >

Re: order of executing MOD_LOAD and registering module sysctl-s

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 (so they

Re: order of executing MOD_LOAD and registering module sysctl-s

the > >>> module event handler. > >>> > >>> In linker_load_file() I see the following code: > >>> linker_file_register_sysctls(lf); > >>> linker_file_sysinit(lf); > >>> > >>> I

Re: order of executing MOD_LOAD and registering module sysctl-s

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 procedures as handlers and they might access data that is supposed to be initialized by the module event handler. So, for example

Re: order of executing MOD_LOAD and registering module sysctl-s

> > > 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

Re: order of executing MOD_LOAD and registering module sysctl-s

t; 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 procedures as

Re: order of executing MOD_LOAD and registering module sysctl-s

. 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

order of executing MOD_LOAD and registering module sysctl-s

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 sysctl-s

Re: sysctl -a hangs ?

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 qu

Re: sysctl -a hangs ?

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 just

Re: sysctl -a hangs ?

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

sysctl -a hangs ?

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

r303869: dmesg: sysctl kern.msgbuf: Operation not permitted

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: Ope

Re: Setting sysctl vfs.zfs.arc_max failed: 22

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 unfortunately

Re: Setting sysctl vfs.zfs.arc_max failed: 22

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

Re: Setting sysctl vfs.zfs.arc_max failed: 22

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

Re: Setting sysctl vfs.zfs.arc_max failed: 22

after all. >> I took 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.

Re: Setting sysctl vfs.zfs.arc_max failed: 22

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. > >

Re: Setting sysctl vfs.zfs.arc_max failed: 22

r.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: 1951729664 vfs.zfs

  1   2   3   4   5   >