Re: ports-mgmt/portconf – not src.conf(5) – to specify multiple flavours of a port for buildkernel purposes

[Graham Perrin]

On 22/08/2023 06:42, Graham Perrin wrote:


…
% cat /usr/local/etc/ports.conf
graphics/gpu-firmware-radeon-kmod: FLAVORS=btc sumo turks
%


Still, there's guesswork. I have /no/ idea whether the FLAVORS part of 
that last line is valid :-)


Time will tell.

/me tails /var/log/buildkernel.log, rocks with laughter at innumerable 
warnings, cancels,


…
make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5393: warning: duplicate 
script for target "sumo" ignored
make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using 
previous script for "sumo" defined here
make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5402: warning: duplicate 
script for target 
"/usr/obj/usr/src/amd64.amd64/sys/GENERIC/usr/ports/graphics/gpu-firmware-radeon-kmod/work-"btc" 
ignored
make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using 
previous script for 
"/usr/obj/usr/src/amd64.amd64/sys/GENERIC/usr/ports/graphics/gpu-firmware-radeon-kmod/work-"btc" 
defined here
make[4028]: "/usr/ports/Mk/bsd.port.mk" line 5402: warning: duplicate 
script for target "sumo" ignored
make[4028]: "/usr/ports/Mk/Uses/kmod.mk" line 74: warning: using 
previous script for "sumo" defined here

env: sumo: No such file or directory
^C
%


, begins a new build that excludes GPU firmware whilst ignoring the 
relevance of 
, intends to 
build the modules with poudriere-devel after the OS is updated, 
rebelliously  begins a paragraph with a comma and makes a whitespace 
error that should be barely visible in the HTML version of this email 
that will not be seen in an archive :-)

Re: ZFS deadlock in 14

[Martin Matuska]

Hi Alexander,

as 15107 is a prerequisite for 15122,
would it be possible to have https://github.com/openzfs/zfs/pull/15107  
merged into the OpenZFS zfs-2.2-release branch (and of course later  
15122)?


If the patches help I can cherry-pick them into main.

Cheers,
mm


Alexander Motin  wrote:


On 17.08.2023 15:41, Dag-Erling Smørgrav wrote:

Alexander Motin  writes:

Trying to run your test (so far without reproduction) I see it
producing a substantial amount of ZIL writes.  The range of commits
you reduced the scope to so far includes my ZIL locking refactoring,
where I know for sure are some deadlocks.  I am already waiting for 3
weeks now for reviews and tests for PR that should fix it:
https://github.com/openzfs/zfs/pull/15122 .  It would be good if you
could test it, though it seems to depend on few more earlier patches
not merged to FreeBSD yet.


Do you have a FreeBSD branch with your patch applied?


I don't have a FreeBSD branch, but these two patches apply clean and  
build on top of today's FreeBSD main branch:


https://github.com/openzfs/zfs/pull/15107
https://github.com/openzfs/zfs/pull/15122

And if you still experience the issue, please show all stacks, or at  
least include ZFS sync threads.


--
Alexander Motin

Re: building with llvm16 pkg fails in tests

[Ronald Klop]

On 8/19/23 22:28, Ronald Klop wrote:

On 8/17/23 21:33, Brooks Davis wrote:

On Thu, Aug 17, 2023 at 12:45:06PM +0200, Ronald Klop wrote:

Hi,

To save time on my Raspberry Pi I would like to build FreeBSD using a llvm pkg 
instead of llvm in the tree.

My /etc/make.conf:
WITHOUT_TOOLCHAIN=yes
LD=/usr/local/llvm16/bin/ld.lld
CC=/usr/local/llvm16/bin/clang
CXX=/usr/local/llvm16/bin/clang++
CPP=/usr/local/llvm16/bin/clang-cpp
OBJCOPY=/usr/local/llvm16/bin/llvm-objcopy

#WITHOUT_CLEAN=yes


This fails in:

/usr/local/llvm16/bin/clang++ -O2 -pipe -fno-common -fPIE -Wno-format-zero-length -nobuiltininc -idirafter /usr/local/llvm16/lib/clang/16/include -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wdate-time -Wmissing-variable-declarations -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -O0 -g0 -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private -I/usr/src/contrib/googletest/googlemock/include -I/usr/src/contrib/googletest/googlemock -I/usr/src/contrib/googletest/googletest/include -I/usr/src/contrib/googletest/googletest -I/usr/obj/usr/src/amd64.amd64/tmp/usr/include/private -DGTEST_HAS_POSIX_RE=1 -DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti -Wno-deprecated-copy -Wno-signed-unsigned-wchar -DGTEST_HAS_POSIX_RE=1 
-DGTEST_HAS_PTHREAD=1 -DGTEST_HAS_STREAM_REDIRECTION=1 -frtti -Wno-deprecated-copy -Wno-signed-unsigned-wchar -fPIE -std=c++14 -Wno-deprecated-copy -Wno-error=inconsistent-missing-override -Wno-error=missing-variable-declarations -Wno-error=sign-compare -Wno-error=unused-parameter -Wno-c++11-extensions  -Wl,-zrelro -pie  --ld-path=/usr/local/llvm16/bin/ld.lld -o gmock-actions_test  gmock-actions_test.o -lprivategmock_main -lprivategmock -lprivategtest

ld.lld: error: undefined symbol: testing::internal::DeathTest::Create(char const*, 
testing::Matcher, 
std::__1::allocator> const&>, char const*, int, testing::internal::DeathTest**)

referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForReferences_Test::TestBody())
referenced by gmock-actions_test.cc
   gmock-actions_test.o:(testing::(anonymous 
namespace)::BuiltInDefaultValueDeathTest_IsUndefinedForNonDefaultConstructibleType_Test::TestBody())
referenced 4 more times


ld.lld: error: undefined symbol: 
testing::Expectation::Expectation(std::__1::shared_ptr
 const&)


Any thoughts on how to fix this?
Compiling with the in tree llvm does work properly.


Did it work with exactly this git revision?  I suspect an issue with the
recent google test update rather than an llvm16 issue.  Note that for
every sync to github we build the tree with the llvm16 port (all be it
on amd64 by default).

It's worth noting one difference between your configuration and the
CI one:  We don't set CC and friends directly.  Instead we use
CROSS_TOOLCHAIN=llvm16.

-- Brooks



Hi,

What I would like to accomplish is this:

CROSS_TOOLCHAIN=llvm16
WITHOUT_TOOLCHAIN=yes

yes | make delete-old delete-old-libs
make buildworld buildkernel

So I can run a system with only external toolchain.
But doing this quickly errors out because /usr/bin/cc does not exist and the 
build uses that even though CROSS_TOOLCHAIN is set. To circumvent that I set 
CC, etc. instead of CROSS_TOOLCHAIN.

Regards,
Ronald.




Hi,

I found what was going on. Passing CC=/usr/local/llvm16/bin/clang does not pass 
the -target, --sysroot and -B option. If I set those in CFLAGS everything 
compiles fine.

What I do now is this:

pkg -j ${JAIL_NAME} install -y ${CROSS_TOOLCHAIN} byacc

jexec ${JAIL_NAME} sh -c "yes | /usr/bin/make CC=${LLVM_DIR}/bin/clang 
LD=${LLVM_DIR}/bin/ld.lld -C /usr/src delete-old delete-old-libs"

cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang cc
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang CC
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang++ c++
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/clang-cpp cpp
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/llvm-objcopy objcopy
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/llvm16/bin/ld
cd ${JAIL_PATH}/usr/bin && ln -fs ../local/bin/yacc

jexec ${JAIL_NAME} /usr/bin/make -C /usr/src -j${NUM_CPUS} 
CROSS_TOOLCHAIN=llvm16 WITHOUT_TOOLCHAIN=yes buildworld buildkernel


This builds fine also. Because CC is not set SYSROOT is just the default.

Any advice on how to make set CC and use the proper sysroot instead of the 
(ugly) symlinking?
And why do parts of buildworld use CROSS_TOOLCHAIN and other parts don't?

Regards,
Ronald.

7addfafe73e0 early boot kernel panics

[Graham Perrin]

I could not get 7addfafe73e0 to boot.

 (2023-08-21, 
21 hours ago).


I reverted to a edacf4b4824a boot environment, which is fine.

Should I simply update to ? 
Assuming a known issue with 7addfafe73e0

Re: 7addfafe73e0 early boot kernel panics

[Juraj Lutter]

> On 22 Aug 2023, at 16:30, Graham Perrin  wrote:
> 
> I could not get 7addfafe73e0 to boot.
> 
>  (2023-08-21, 21 
> hours ago).
> 
> I reverted to a edacf4b4824a boot environment, which is fine.
> 
> Should I simply update to ? 
> Assuming a known issue with 7addfafe73e0

Recent c941b82e1c31 boots and runs fine (as a bhyve guest)

otis

—
Juraj Lutter
o...@freebsd.org

Re: 7addfafe73e0 early boot kernel panics

[Li-Wen Hsu]

On Tue, Aug 22, 2023 at 10:52 PM Juraj Lutter  wrote:

>
>
> > On 22 Aug 2023, at 16:30, Graham Perrin  wrote:
> >
> > I could not get 7addfafe73e0 to boot.
> >
> > 
> (2023-08-21, 21 hours ago).
> >
> > I reverted to a edacf4b4824a boot environment, which is fine.
> >
> > Should I simply update to ?
> Assuming a known issue with 7addfafe73e0
>
> Recent c941b82e1c31 boots and runs fine (as a bhyve guest)
>
> otis
>

You can also check the test status in our CI
https://ci.freebsd.org/job/FreeBSD-main-amd64-test/

There might be some failing test cases, or panic on running some test case,
but at least you can check if one revision boots or not, in a reference
system.

Best,
Li-Wen

Re: ZFS deadlock in 14

[Alexander Motin]

Hi Martin,

I am waiting for final test results from George Wilson and then will 
request quick merge of both to zfs-2.2-release branch.  Unfortunately 
there are still not many reviewers for the PR, since the code is not 
trivial, but at least with the test reports Brian Behlendorf and Mark 
Maybee seem to be OK to merge the two PRs into 2.2.  If somebody else 
have tested and/or reviewed the PR, you may comment on it.


On 22.08.2023 04:26, Martin Matuska wrote:

as 15107 is a prerequisite for 15122,
would it be possible to have https://github.com/openzfs/zfs/pull/15107 
merged into the OpenZFS zfs-2.2-release branch (and of course later 15122)?


If the patches help I can cherry-pick them into main.

Alexander Motin  wrote:


On 17.08.2023 15:41, Dag-Erling Smørgrav wrote:

Alexander Motin  writes:

Trying to run your test (so far without reproduction) I see it
producing a substantial amount of ZIL writes.  The range of commits
you reduced the scope to so far includes my ZIL locking refactoring,
where I know for sure are some deadlocks.  I am already waiting for 3
weeks now for reviews and tests for PR that should fix it:
https://github.com/openzfs/zfs/pull/15122 .  It would be good if you
could test it, though it seems to depend on few more earlier patches
not merged to FreeBSD yet.


Do you have a FreeBSD branch with your patch applied?


I don't have a FreeBSD branch, but these two patches apply clean and 
build on top of today's FreeBSD main branch:


https://github.com/openzfs/zfs/pull/15107
https://github.com/openzfs/zfs/pull/15122

And if you still experience the issue, please show all stacks, or at 
least include ZFS sync threads.


--
Alexander Motin

Re: src.conf(5) to specify multiple flavours of a port

[Enji Cooper]

> On Aug 21, 2023, at 10:01 PM, Bakul Shah  wrote:
> 
> On Aug 21, 2023, at 9:24 PM, Graham Perrin  wrote:
>> 
>> In a thread elsewhere, as an example that did not involve src.conf, Mark 
>> Johnston wrote:
>> 
>>> $ cd /usr/ports/graphics/gpu-firmware-intel-kmod
>>> $ sudo make reinstall FLAVOR=kabylake
>> 
>> How might I use /etc/src.conf to achieve much the same, with a different 
>> port?
> 
> Since /etc/src.conf is included from make, may be you can use some make 
> feature
> for conditional define?

I think there’s some confusion… /etc/make.conf is always included by bmake; 
/etc/src.conf is only included when building the base system.
FreeBSD ports doesn’t have a special systemwide config file like the base 
system for toggling build/install behavior, but it does have 
"${PORTSDIR}/Mk/bsd.local.mk” .
-Enji

$ grep -r /etc/src.conf share/mk/
share/mk/src.opts.mk:# Users define WITH_FOO and WITHOUT_FOO on the command 
line or in /etc/src.conf
share/mk/src.opts.mk:# to set via WITH_*/WITHOUT_* in /etc/src.conf and 
override in the
share/mk/bsd.port.mk:# Needed to keep bsd.own.mk from reading in /etc/src.conf
share/mk/bsd.opts.mk:# Users define WITH_FOO and WITHOUT_FOO on the command 
line or in /etc/src.conf
share/mk/bsd.opts.mk:# to set via WITH_*/WITHOUT_* in /etc/src.conf and 
override in the
share/mk/src.sys.mk:SRCCONF?=   /etc/src.conf
share/mk/src.sys.mk:(exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf") 
&& \


signature.asc
Description: Message signed with OpenPGP

Re: src.conf(5) to specify multiple flavours of a port

[Enji Cooper]

> On Aug 21, 2023, at 9:34 PM, Warner Losh  wrote:
> 
> On Mon, Aug 21, 2023, 10:24 PM Graham Perrin  > wrote:
>> In a thread elsewhere, as an example that did not involve src.conf, Mark 
>> Johnston wrote:
>> 
>>> $ cd /usr/ports/graphics/gpu-firmware-intel-kmod
>>> $ sudo make reinstall FLAVOR=kabylake
>> How might I use /etc/src.conf to achieve much the same, with a different 
>> port?
>> 
> 
> 
> 
> I thought stuff like this went in ports.conf…

ports.conf?

ports-mgmt/portconf/files/portconf.sh.in:_conf=%%PREFIX%%/etc/ports.conf
ports-mgmt/portconf/files/pkg-message.in:%%PREFIX%%/etc/ports.conf 
configuration file

Huh… TIL.
-Enji


signature.asc
Description: Message signed with OpenPGP

Re: Speed improvements in ZFS

[Mateusz Guzik]

On 8/22/23, Alexander Leidinger  wrote:
> Am 2023-08-21 10:53, schrieb Konstantin Belousov:
>> On Mon, Aug 21, 2023 at 08:19:28AM +0200, Alexander Leidinger wrote:
>>> Am 2023-08-20 23:17, schrieb Konstantin Belousov:
>>> > On Sun, Aug 20, 2023 at 11:07:08PM +0200, Mateusz Guzik wrote:
>>> > > On 8/20/23, Alexander Leidinger  wrote:
>>> > > > Am 2023-08-20 22:02, schrieb Mateusz Guzik:
>>> > > >> On 8/20/23, Alexander Leidinger  wrote:
>>> > > >>> Am 2023-08-20 19:10, schrieb Mateusz Guzik:
>>> > >  On 8/18/23, Alexander Leidinger 
>>> > >  wrote:
>>> > > >>>
>>> > > > I have a 51MB text file, compressed to about 1MB. Are you
>>> > > > interested
>>> > > > to
>>> > > > get it?
>>> > > >
>>> > > 
>>> > >  Your problem is not the vnode limit, but nullfs.
>>> > > 
>>> > >  https://people.freebsd.org/~mjg/netchild-periodic-find.svg
>>> > > >>>
>>> > > >>> 122 nullfs mounts on this system. And every jail I setup has
>>> > > >>> several
>>> > > >>> null mounts. One basesystem mounted into every jail, and then
>>> > > >>> shared
>>> > > >>> ports (packages/distfiles/ccache) across all of them.
>>> > > >>>
>>> > >  First, some of the contention is notorious VI_LOCK in order to
>>> > >  do
>>> > >  anything.
>>> > > 
>>> > >  But more importantly the mind-boggling off-cpu time comes from
>>> > >  exclusive locking which should not be there to begin with -- as
>>> > >  in
>>> > >  that xlock in stat should be a slock.
>>> > > 
>>> > >  Maybe I'm going to look into it later.
>>> > > >>>
>>> > > >>> That would be fantastic.
>>> > > >>>
>>> > > >>
>>> > > >> I did a quick test, things are shared locked as expected.
>>> > > >>
>>> > > >> However, I found the following:
>>> > > >> if ((xmp->nullm_flags & NULLM_CACHE) != 0) {
>>> > > >> mp->mnt_kern_flag |=
>>> > > >> lowerrootvp->v_mount->mnt_kern_flag &
>>> > > >> (MNTK_SHARED_WRITES | MNTK_LOOKUP_SHARED |
>>> > > >> MNTK_EXTENDED_SHARED);
>>> > > >> }
>>> > > >>
>>> > > >> are you using the "nocache" option? it has a side effect of
>>> > > >> xlocking
>>> > > >
>>> > > > I use noatime, noexec, nosuid, nfsv4acls. I do NOT use nocache.
>>> > > >
>>> > >
>>> > > If you don't have "nocache" on null mounts, then I don't see how
>>> > > this
>>> > > could happen.
>>> >
>>> > There is also MNTK_NULL_NOCACHE on lower fs, which is currently set
>>> > for
>>> > fuse and nfs at least.
>>>
>>> 11 of those 122 nullfs mounts are ZFS datasets which are also NFS
>>> exported.
>>> 6 of those nullfs mounts are also exported via Samba. The NFS exports
>>> shouldn't be needed anymore, I will remove them.
>> By nfs I meant nfs client, not nfs exports.
>
> No NFS client mounts anywhere on this system. So where is this exclusive
> lock coming from then...
> This is a ZFS system. 2 pools: one for the root, one for anything I need
> space for. Both pools reside on the same disks. The root pool is a 3-way
> mirror, the "space-pool" is a 5-disk raidz2. All jails are on the
> space-pool. The jails are all basejail-style jails.
>

While I don't see why xlocking happens, you should be able to dtrace
or printf your way into finding out.

-- 
Mateusz Guzik 

Re: Question about KBI change / new feature

[Warner Losh]

On Mon, Aug 21, 2023 at 9:42 AM Zhenlei Huang  wrote:

> Hi,
>
> The https://www.freebsd.org/releases/14.0R/schedule/ says CURRENT/14 's
> KBI is froze
> and new features should be avoided.
>
> I'm working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet
> sysctl variables be loader tunable)
> and I think it is new feature, but not quite sure whether the KBI changed.
>
> So,
>
> 1. Is it a KBI change ?
>

IMHO, It's a KPI change, not a KBI breakage. So from that perspective, it's
OK.


> 2. It is a simple change ( while so far as I know currently only tested by
> myself on x86 and qemu riscv ), can
> it catch up with 14 ?


That I'm less sure of. I think it's good, but I'm gun shy about approving /
committing vnet things. The review suggests,
though, there's at least some consensus for having this in the tree.


> Best regards,
> Zhenlei
>
>
>

Re: ZFS deadlock in 14

[Mark Millard]

Alexander Motin  wrote on
Date: Tue, 22 Aug 2023 16:18:12 UTC :

> I am waiting for final test results from George Wilson and then will 
> request quick merge of both to zfs-2.2-release branch. Unfortunately 
> there are still not many reviewers for the PR, since the code is not 
> trivial, but at least with the test reports Brian Behlendorf and Mark 
> Maybee seem to be OK to merge the two PRs into 2.2. If somebody else 
> have tested and/or reviewed the PR, you may comment on it.

I had written to the list that when I tried to test the system
doing poudriere builds (initially with your patches) using
USE_TMPFS=no so that zfs had to deal with all the file I/O, I
instead got only one builder that ended up active, the others
never reaching "Builder started":

[00:01:34] [01] [00:00:00] Builder starting
[00:01:57] [01] [00:00:23] Builder started
[00:01:57] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.20.4
[00:03:09] [01] [00:01:12] Finished ports-mgmt/pkg | pkg-1.20.4: Success
[00:03:21] [01] [00:00:00] Building print/indexinfo | indexinfo-0.3.1
[00:03:21] [02] [00:00:00] Builder starting
[00:03:21] [03] [00:00:00] Builder starting
[00:03:21] [04] [00:00:00] Builder starting
[00:03:21] [05] [00:00:00] Builder starting
[00:03:21] [06] [00:00:00] Builder starting
[00:03:21] [07] [00:00:00] Builder starting
[00:03:22] [08] [00:00:00] Builder starting
[00:03:22] [09] [00:00:00] Builder starting
[00:03:22] [10] [00:00:00] Builder starting
[00:03:22] [11] [00:00:00] Builder starting
[00:03:22] [12] [00:00:00] Builder starting
[00:03:22] [13] [00:00:00] Builder starting
[00:03:22] [14] [00:00:00] Builder starting
[00:03:22] [15] [00:00:00] Builder starting
[00:03:22] [16] [00:00:00] Builder starting
[00:03:22] [17] [00:00:00] Builder starting
[00:03:22] [18] [00:00:00] Builder starting
[00:03:22] [19] [00:00:00] Builder starting
[00:03:22] [20] [00:00:00] Builder starting
[00:03:22] [21] [00:00:00] Builder starting
[00:03:22] [22] [00:00:00] Builder starting
[00:03:22] [23] [00:00:00] Builder starting
[00:03:22] [24] [00:00:00] Builder starting
[00:03:22] [25] [00:00:00] Builder starting
[00:03:22] [26] [00:00:00] Builder starting
[00:03:22] [27] [00:00:00] Builder starting
[00:03:22] [28] [00:00:00] Builder starting
[00:03:22] [29] [00:00:00] Builder starting
[00:03:22] [30] [00:00:00] Builder starting
[00:03:22] [31] [00:00:00] Builder starting
[00:03:22] [32] [00:00:00] Builder starting
[00:03:30] [01] [00:00:09] Finished print/indexinfo | indexinfo-0.3.1: Success
[00:03:31] [01] [00:00:00] Building devel/gettext-runtime | gettext-runtime-0.22
. . .

Top was showing lots of "vlruwk" for the cpdup's. For example:

. . .
 362 0 root 400  27076Ki   13776Ki CPU19   19   4:23   0.00% 
cpdup -i0 -o ref 32
 349 0 root 530  27076Ki   13776Ki vlruwk  22   4:20   0.01% 
cpdup -i0 -o ref 31
 328 0 root 680  27076Ki   13804Ki vlruwk   8   4:30   0.01% 
cpdup -i0 -o ref 30
 304 0 root 370  27076Ki   13792Ki vlruwk   6   4:18   0.01% 
cpdup -i0 -o ref 29
 282 0 root 420  33220Ki   13956Ki vlruwk   8   4:33   0.01% 
cpdup -i0 -o ref 28
 242 0 root 560  27076Ki   13796Ki vlruwk   4   4:28   0.00% 
cpdup -i0 -o ref 27
. . .

But those processes did show CPU?? on occasion, as well as
*vnode less often. None of the cpdup's was stuck in

Removing your patches did not change the behavior.

So far I've not seen any similar reports to these
resuls that I got the ThreadRipper 1950X that I
have access to.

I normally use USE_TMPFS=all but that hides the
problem and is why I've no clue when the behavior
would have started if I'd been using USE_TMPFS=no
instead.

I never got so far as testing for the kinds of
reports I've seen about the deadlock issue.

No one has commented one what I reported or if
they have done any USE_TMPFS=no style of testing.
(I also use ALLOW_MAKE_JOBS=yes .)

The ZFS context is a simple single partition context.
I use ZFS in order to use bectl BE's, not other
reasons.

===
Mark Millard
marklmi at yahoo.com

273297 – BOOT time panic after preloading TSLOG data (was: 7addfafe73e0 early boot kernel panics)

[Graham Perrin]

Thanks, people.

I couldn't attach a photograph to the opening post (entire emails, not 
just attachments, disappear in the ether).


Instead, a photo here:

Re: ps(1) bugs and problems

[Piotr P. Stefaniak]

On 2023-08-15 13:28:07, Jamie Landeg-Jones wrote:

The old -d and the new -D'$^' would be the best in that -d would go back
to what it was and -D would provide the much needed feature in two
variants (possibly more in the future, if needed) while only taking one
option-letter. The only problem is that it looks ugly.


I see why you chose "$" and "^", but wouldn't it look more friendly if
you instead used "up" and "down" or "A" and "D" or "forwards" and "backwards",
for example?


Thank you, in the phab review I went with -D up, -D down, and -D both if
you don't want to type -D twice. I don't think we need -D none to clear
the flags so it's currently not supported, but it'd be easy to
implement if we wanted to.

I also tried to update the manual page, but it may require some
wordsmith.

Piotr

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Graham Perrin  wrote:

> If I recall correctly, a few hours ago etcupdate -B resulted in removal 
> of two files:
>
> /.cshrc
> /.profile
>
> Is this degree of checking/removal a novelty?
>
> (I can't recall the files' contents, or when I created them. I guess 
> that I carelessly created them as dot files months ago without realising 
> that I wasn't at ~, I don't mourn their loss.)

For as long as I can remember, (as far back as FreeBSD 2.2.7 in 1998) all
FreeBSD installs have /.cshrc and /profile as hardlinks to /root/.cshrc and
/root/.profile .

Removing them both is one of the first things I do when I install a new
system from install-media.

If etcupdate is now removing them, maybe there has been an update to the src
distribution / mntree so that this historical weirdness has finally been 
removed?

If you have a /root/.cshrc and /root/.profile, try doing an ls -c on them to
see if their changed-date is when you did the etcupdate.

Jamie

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Mike Karels  wrote:

> Both sets have been present since 4.3-Reno in 1990, although they were
> apparently not links.

Well before my time!
>
> > Removing them both is one of the first things I do when I install a new
> > system from install-media.
>
> Why?

Because I don't use them

> > If etcupdate is now removing them, maybe there has been an update to the src
> > distribution / mntree so that this historical weirdness has finally been 
> > removed?
>
> It is not weird.  /.profile and /.cshrc are used in single-user mode, the ones
> in /root are used for root logins.

Ah yeah, that would make sense, I guess. I remember my first unix systems,
the default home for the root login was / so there was no /root duplication of
those files.

> > If you have a /root/.cshrc and /root/.profile, try doing an ls -c on them to
> > see if their changed-date is when you did the etcupdate.
>
> They were modified by the removal of $FreeBSD$ a few days ago at the next
> etcupdate.

A. That idea won't work then!

Cheers

Re: etcupdate -B, /.cshrc and /.profile

[Sulev-Madis Silber]

on why removing those, i for example only use /etc/csh.cshrc so i don't need 
others

Re: etcupdate -B, /.cshrc and /.profile

[Jamie Landeg-Jones]

Sulev-Madis Silber  wrote:

> on why removing those, i for example only use /etc/csh.cshrc so i don't need 
> others

Exactly the same here!