Re: kernel 100% CPU, and ports-mgmt/poudriere-devel 'Inspecting ports tree for modifications to git checkout...' for an extraordinarily long time

On 03/09/2023 10:26, Michael Gmelin wrote: On Sat, 2 Sep 2023 09:53:38 +0100 Graham Perrin wrote: Some inspections are extraordinarily time-consuming. Others complete very quickly, as they should. One recent inspection took more than half an hour. Anyone else? Does `git clone

sysutils/panicmail and boot environments

For the penultimate panic: panicmail was received (in my Gmail Inbox). For the most recent panic: no panicmail in the same Inbox. Might this be, because the kernel panicked in a different boot environment? If so: will a temporary boot of the

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

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Sep 7, 2023, at 13:07, Alexander Motin wrote: > Thanks, Mark. > > On 07.09.2023 15:40, Mark Millard wrote: >> On Sep 7, 2023, at 11:48, Glen Barber wrote: >>> On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: When I next have time, should I retry based on a more recent

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Sep 7, 2023, at 11:48, Glen Barber wrote: > On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: >> When I next have time, should I retry based on a more recent >> vintage of main that includes 969071be938c ? >> > > Yes, please, if you can. As stands, I rebooted that machine into

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

Thanks, Mark. On 07.09.2023 15:40, Mark Millard wrote: On Sep 7, 2023, at 11:48, Glen Barber wrote: On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: When I next have time, should I retry based on a more recent vintage of main that includes 969071be938c ? Yes, please, if you

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

[Drat, the request to rerun my tests did not not mention the more recent change: vfs: copy_file_range() between multiple mountpoints of the same fs type and I'd not noticed on my own and ran the test without updating.] On Sep 7, 2023, at 11:02, Mark Millard wrote: > I was requested to do a

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote: > When I next have time, should I retry based on a more recent > vintage of main that includes 969071be938c ? > Yes, please, if you can. Glen signature.asc Description: PGP signature

main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

I was requested to do a test with vfs.zfs.bclone_enabled=1 and the bulk -a build paniced (having stored 128 *.pkg files in .building/ first): # more /var/crash/core.txt.3 . . . Unread portion of the kernel message buffer: panic: Solaris(panic): zfs: accessing past end of object 422/1108c16

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

[Today's main-snapshot kernel panics as well.] On Sep 7, 2023, at 16:32, Mark Millard wrote: > On Sep 7, 2023, at 13:07, Alexander Motin wrote: > >> Thanks, Mark. >> >> On 07.09.2023 15:40, Mark Millard wrote: >>> On Sep 7, 2023, at 11:48, Glen Barber wrote: On Thu, Sep 07, 2023 at