9859956049b5153b0e1b67f8f4a99622dc6f
merge-base: CommitDate: 2022-01-15 12:55:32 +
a5f698599560 (HEAD -> stable/13, freebsd/stable/13) Ignore debugger-injected
signals left after detaching
Bob's recent stable/13 context (kernel too) is
more recent than mine. So the problems has been
observed over a range of contexts.
But, as I said, I've given up on finding a
way to isolate whatever is going on.
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-15, at 07:55, Mark Johnston wrote:
> On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote:
>> Thanks. This will allow me to remove part of my personal additions
>> in this area --and my having to explain the misnomer when trying
>> to help someone analyze
On 2022-Feb-26, at 17:10, Mark Millard wrote:
> On 2022-Jan-15, at 07:55, Mark Johnston wrote:
>
>> On Fri, Jan 14, 2022 at 09:38:56PM -0800, Mark Millard wrote:
>>> Thanks. This will allow me to remove part of my personal additions
>>> in this area --and my
d up sensitivity to the get_pcpu
details in rmlock in:
https://cgit.freebsd.org/src/commit/?h=stable/13&id=543157870da5
(a 2022-03-04 commit) and stable/13 also has the get_pcpu
misdefinition in:
https://cgit.freebsd.org/src/commit/sys/arm64/include/pcpu.h?h=stable/13&id=63c858a04d56
. So an MFC would be appropriate in order for aarch64
to be reliable for any variations in get_pcpu in stable/13
(and for 13.1 to be so as well).
===
Mark Millard
marklmi at yahoo.com
On 2022-Mar-18, at 12:32, Mark Millard wrote:
> Looks like . . .
>
> /workspace/src/sys/contrib/openzfs/module/zstd/lib/common/error_private.h
> and:
> /workspace/src/sys/contrib/zstd/lib/common/error_private.h
>
> are both used in building in:
>
> /tmp/obj/works
x27;t been able to trigger any build failures on
> -p8. Any hints on a reproducer would be useful.
>
> We can simply push a -p9 which reverts EN-22:10 and :11, but of course
> it would be preferable to precisely identify the problem.
Anything about the types of hardware involved that is
different for those getting the problem vs. those that
do not get the problem? May be it would be appropriate
for folks getting the problem to detail their hardware
configurations, including storage hardware.
===
Mark Millard
marklmi at yahoo.com
On 2022-Mar-19, at 11:07, Thomas Zander wrote:
> On Sat, 19 Mar 2022 at 18:32, Mark Millard wrote:
>> May be report to Mark J. how to run the same test builds
>> that failed for -p8 but worked for -p7?
>
> Sure, good point.
> A build that reliably causes broken packages
em vs. before that point. May be the
history will help.
https://lists.freebsd.org/archives/freebsd-current/2021-November/001052.html
I've not had problems with the issue on main since then.
===
Mark Millard
marklmi at yahoo.com
On 2022-Mar-19, at 12:54, Mark Johnston wrote:
> On Sat, Mar 19, 2022 at 12:00:20PM -0700, Mark Millard wrote:
>> On 2022-Mar-19, at 11:07, Thomas Zander wrote:
>>
>>> On Sat, 19 Mar 2022 at 18:32, Mark Millard wrote:
>>>> May be report to Mark J. how t
On 2022-Mar-19, at 14:24, Mark Millard wrote:
> On 2022-Mar-19, at 12:54, Mark Johnston wrote:
>
>> On Sat, Mar 19, 2022 at 12:00:20PM -0700, Mark Millard wrote:
>>> On 2022-Mar-19, at 11:07, Thomas Zander wrote:
>>>
>>>> On Sat, 19 Mar 2022 a
On 2022-Mar-19, at 14:34, Mark Millard wrote:
> On 2022-Mar-19, at 14:24, Mark Millard wrote:
>
>> On 2022-Mar-19, at 12:54, Mark Johnston wrote:
>>
>>> On Sat, Mar 19, 2022 at 12:00:20PM -0700, Mark Millard wrote:
>>>> On 2022-Mar-19, at 11:07, Thoma
SD-EN-22:11.zfs
FreeBSD-EN-22:12.zfs
FreeBSD-SA-22:02.wifi
FreeBSD-SA-22:03.openssl
. . .
from the same commit.
This might make it more difficult for some to verify
what status they have for the zfs problem.
===
Mark Millard
marklmi at yahoo.com
esolved merge conflict".
That update will identify the commit built for the binary update.
===
Mark Millard
marklmi at yahoo.com
On 2022-Nov-4, at 11:37, Paul Mather wrote:
> On Nov 3, 2022, at 11:50 PM, Mark Millard wrote:
>
>> I downloaded and looked at:
>>
>> FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
>>
>> # mdconfig -u md0 -f FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img
&
thus using a more recent clang++
vintage as well.
Thus, it suggests that "LLVM 13.0.1 from ports" has
a problem that firefox's build ran into.
===
Mark Millard
marklmi at yahoo.com
S=no
avoids a problem for poudriere bulk builds on 13.1 amd64.
(Unclear if the note is for stable/13 vs. releng/13.1 vs. both.)
I'll note repeat the material here but it might be worth a look.
===
Mark Millard
marklmi at yahoo.com
On Dec 23, 2022, at 10:14, Mark Millard wrote:
> Jonathan Chen wrote on
> Date: Thu, 22 Dec 2022 19:21:37 UTC :
>
>> I recently updated my package builder machine to the
>> stable/13-n253297-fc15d5bf1109of (22-Dec-2022); and appear to be having
>> some unusual
Jonathan Chen wrote on
Date: Fri, 23 Dec 2022 18:40:27 UTC :
> On 24/12/22 07:14, Mark Millard wrote:
> > Jonathan Chen wrote on
> > Date: Thu, 22 Dec 2022 19:21:37 UTC :
> >
> >> I recently updated my package builder machine to the
> >> stable/13-n2
ce might not be preserved.)
===
Mark Millard
marklmi at yahoo.com
On Dec 26, 2022, at 19:54, Mark Millard wrote:
> Should the following have been MFC'd? (I ran into this while
> looking to see why I see a boot message oddity on 13.* that
> I do not see on main [so: 14]. There was a time when main
> also produced the odd messages. But I
/etc/rc.d/machine_id: startmsg -n "Creating ${machine_id_file} "
/etc/rc.d/machine_id: startmsg 'done.'
(No more matches found.)
The following was not found on stable/13:
/etc/rc.subr:# startmsg
/etc/rc.subr:startmsg()
/etc/rc.subr: startmsg "Sta
not aware of any other type of FreeBSD aarch64 context
broken via the use of 2023.01 U-Boot.
===
Mark Millard
marklmi at yahoo.com
:
https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078488.html
and:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257616 .
===
Mark Millard
marklmi at yahoo.com
On Feb 21, 2023, at 04:55, Peter wrote:
> On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote:
> ! Peter wrote on
> ! Date: Tue, 21 Feb 2023 03:45:12 UTC :
> !
> ! > on /some/ of my nodes, META_MODE seems not being honored anymore:
> ! > I had to build th
On Feb 21, 2023, at 11:56, Mark Millard wrote:
> On Feb 21, 2023, at 04:55, Peter wrote:
>
>> On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote:
>> ! Peter wrote on
>> ! Date: Tue, 21 Feb 2023 03:45:12 UTC :
>> !
>> ! > on /some/ of my n
On Feb 21, 2023, at 11:56, Mark Millard wrote:
> On Feb 21, 2023, at 04:55, Peter wrote:
>
>> On Mon, Feb 20, 2023 at 08:44:59PM -0800, Mark Millard wrote:
>> ! Peter wrote on
>> ! Date: Tue, 21 Feb 2023 03:45:12 UTC :
>> !
>> ! > on /some/ of my n
On Feb 21, 2023, at 18:10, Peter wrote:
> On Tue, Feb 21, 2023 at 11:56:13AM -0800, Mark Millard wrote:
> ! On Feb 21, 2023, at 04:55, Peter wrote:
> !
> ! > ! # cd /usr/src/
> ! > ! # env WITH_META_MODE=yes make buildworld
> ! > ! # env WITH_META_MODE=yes make
ler
> 230222000242.oper.std.jail.sst:real 149.51 jail w/o compiler
> 230222000242.rail.std.jail.sst:real 151.73 jail w/o compiler
> 230222000242.tele.std.jail.sst:real 150.52 jail w/o compiler
>
> pass4
> (10 vcore)
> 230222021535.edge.std.sst: real 1018.79 base w/ kernels
> 230222021535.admn.std.jail.sst:real 101.61 jail w/ compiler
> 230222021535.data.std.jail.sst:real 67.47 jail w/o compiler
> 230222021535.iamk.std.jail.sst:real 100.91 jail w/ compiler
> 230222021535.oper.std.jail.sst:real 66.52 jail w/o compiler
> 230222021535.rail.std.jail.sst:real 68.00 jail w/o compiler
> 230222021535.tele.std.jail.sst:real 66.54 jail w/o compiler
===
Mark Millard
marklmi at yahoo.com
On Feb 21, 2023, at 19:11, Peter wrote:
> On Tue, Feb 21, 2023 at 06:44:09PM -0800, Mark Millard wrote:
> ! On Feb 21, 2023, at 18:10, Peter wrote:
> !
> ! > On Tue, Feb 21, 2023 at 11:56:13AM -0800, Mark Millard wrote:
> ! > ! On Feb 21, 2023, at 04:55, Peter wrote:
>
On Feb 21, 2023, at 20:51, Mark Millard wrote:
> On Feb 21, 2023, at 19:11, Peter wrote:
>
>> On Tue, Feb 21, 2023 at 06:44:09PM -0800, Mark Millard wrote:
>> ! On Feb 21, 2023, at 18:10, Peter wrote:
>> !
>> ! > On Tue, Feb 21, 2023 at 11:56:13AM -0800, Ma
On Feb 21, 2023, at 21:53, Mark Millard wrote:
> On Feb 21, 2023, at 20:51, Mark Millard wrote:
>
>> On Feb 21, 2023, at 19:11, Peter wrote:
>>
>>> On Tue, Feb 21, 2023 at 06:44:09PM -0800, Mark Millard wrote:
>>> ! On Feb 21, 2023, at 18:10, Peter wrote:
sr/lib32/libcrypto.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib32/libc.so.7'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib32/Scrt1.o'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libssl.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libcxxrt.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libctf.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libcrypto.so'
is newer than the target...
1 file
'/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/lib/libc.so.7'
is newer than the target...
(The list is already short, so no subset listed.)
===
Mark Millard
marklmi at yahoo.com
On Feb 22, 2023, at 14:07, Mark Millard wrote:
> This is just an FYI about an experiment.
The experiment had a flaw: I did not do the builds as -j1
(or no -j at all) but the parallel activities changes
the sequencing of the lines from run to run.
Thus the "diff -u" part finds mor
csmapper mkdir mktemp mtree mv
nawk patch realpath rm sed sh sort touch tr truncate uudecode uuencode wc xargs
.MAKE.META.IGNORE_PATHS+=
${IGNORELEGACY_NOSYMLINKPREFIX}/sbin/${ignore_legacy_tool}
.endfor
#
.for ignore_other_tool in ctfconvert objcopy nm
.MAKE.META.IGNORE_PATHS+= ${IGNOREOTHER_NOSYMLINKPREFIX}/${ignore_other_tool}
.endfor
#
.MAKE.META.IGNORE_PATHS:= ${.MAKE.META.IGNORE_PATHS}
The . . ./tmp/usr/bin/* ones ( ctfconvert objcopy nm )
may be more questionable than the
. . ./tmp/legacy/usr/sbin/* ones.
This likely will not prevent the likes of a system with
clang14 -> system with clang15 transition having clang15
rebuild itself once the clang15 system is running and
another buildworld is started.
===
Mark Millard
marklmi at yahoo.com
ID or any part of it must not be used
directly. Instead the machine ID should be hashed with a
cryptographic, keyed hash function, using a fixed,
application-specific key. That way the ID will be properly
unique, and derived in a constant way from the machine ID but
there will be no way to retrieve the original machine ID from the
application-specific one.
END QUOTE
Is that at least recommended for handling FreeBSD's /etc/hostid
content?
Is FreeBSD going to document /etc/machine-id content properties
in a similar manor?
If FreeBSD ends up with a /etc/machine-id that does not have
the properties and recommended principles of use, it would
appear that the /etc/machine-id path would be highly misleading
and, so, inappropriate.
===
Mark Millard
marklmi at yahoo.com
On Mar 4, 2023, at 06:32, Tijl Coosemans wrote:
>
> On Fri, 3 Mar 2023 10:36:20 -0800 Mark Millard wrote:
>> What are the properties for the content of /etc/hostid
>> in FreeBSD? Where are they documented?
>>
>> /etc/machine-id has strong property guarnatee
>
kern.supported_archs
kern.supported_archs: aarch64 armv7
===
Mark Millard
marklmi at yahoo.com
've not been dealing with releng/13.2 but upgrades
from releng/13.1 and before likely have the same
questions for what the handling should be vs. what it
might actually be. Different ways of upgrading might
not be in agreement, for all I know.
===
Mark Millard
marklmi at yahoo.com
On Mar 16, 2023, at 15:55, Mark Millard wrote:
> # cat /etc/hostid /etc/machine-id /var/db/machine-id
> a4f7fbeb-f668-11de-b280-ebb65474e619
> a4f7fbebf66811deb280ebb65474e619
> 7227cd89727a462186e3ba680d0ee142
>
> (I'll not be keeping these values for the example syste
r possible prior
history sequences with /var/db/machine-id
and /etc/hostid ( but not /etc/machine-id ).
> Colin Percival
>
> On 3/16/23 15:55, Mark Millard wrote:
>> # cat /etc/hostid /etc/machine-id /var/db/machine-id
>> a4f7fbeb-f668-11de-b280-ebb65474e619
>> a4f7fbebf6
On Mar 16, 2023, at 17:27, Mark Millard wrote:
> On Mar 16, 2023, at 16:48, Colin Percival wrote:
>
>> I think the current situation should be sorted out aside from potential
>> issues
>> for people who upgraded to a "broken" version before updating to th
ing to the latest
>> code -- CCing bapt and tijl just in case since they're more familiar with
>> this
>> than I am.
>>
>> Colin Percival
>>
>> On 3/16/23 15:55, Mark Millard wrote:
>>> # cat /etc/hostid /etc/machine-id /var/d
blished via ntp, apparently. (I did not make such
adjustments to the snapshot before starting the
upgrade.)
I do not know if any of the "install: ///var/db/etcupdate/ . . . "
lines or the rmdir line are important.
It earlier indicated 5708 patches were fetched and that 377
files were a
On Mar 17, 2023, at 18:24, Mark Millard wrote:
> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
> upgrade sequence did not go well relative to my being
> prompted to do the right thing to establish /etc/machine-id .
> After the last reboot (kernel upgrade, pres
On Mar 17, 2023, at 19:04, Mark Millard wrote:
> On Mar 17, 2023, at 18:24, Mark Millard wrote:
>
>> The 13.1-RELEASE (snapshot) to 13.2-RC3 freebsd-update's
>> upgrade sequence did not go well relative to my being
>> prompted to do the right thing to establish /
al protection fault while in kernel mode
crash. The code was inside nfsd.
( Note: 18446741877726026240 == 0xfe00b52e9a00 )
The crash is not mine. It is a new type of example from
an ongoing crash-evidence gathering session. See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028#c147
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028#c148
===
Mark Millard
marklmi at yahoo.com
7;ve found --and some or all
of what I found missing may not be involved in the EFI
loader issue.)
===
Mark Millard
marklmi at yahoo.com
On Aug 18, 2023, at 19:09, Mark Millard wrote:
> Glen Barber wrote on
> Date: Sat, 19 Aug 2023 00:10:59 UTC :
>
>> I am somewhat inclined to look in the direction of ZFS here, as two
>> things changed:
>>
>> 1) the build machine in question was recentl
Has any more been learned about this? Is it still an issue?
===
Mark Millard
marklmi at yahoo.com
On Sep 5, 2023, at 08:58, Cy Schubert wrote:
> In message <20230830204406.24fd...@slippy.cwsent.com>, Cy Schubert writes:
>> In message <20230830184426.gm1...@freebsd.org>, Glen Barber writes:
>>>
>>>
>>> On Mon, Aug 28, 2023 at 06:06:09PM -
3
. . .
git: f789381671a3 - stable/14 - zfs: merge openzfs/zfs@32949f256
(zfs-2.2-release) into stable/14
that has required fixes for other issues.
===
Mark Millard
marklmi at yahoo.com
[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
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
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, s
[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
nftest.tmp conftest.nl conftest.out
. . . (history removed) . . .
# uname -apKU
FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT amd64 150 #0
main-n265205-03a7c36ddbc0: Thu Sep 7 03:10:34 UTC 2023
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
amd64 150 150
In my test environment with yesterday's snapshot kernel
in use and with vfs.zfs.bclone_enabled=1 :
# ~/bclone_panic.sh
count: 1
count: 2
count: 3
count: 4
count: 5
count: 6
count: 7
count: 8
then panic: no 9.
===
Mark Millard
marklmi at yahoo.com
Tobuild: 33800 Time: 00:30:41
So 414 and and still building.
More later. (It may be a while.)
===
Mark Millard
marklmi at yahoo.com
On Sep 8, 2023, at 17:03, Mark Millard wrote:
> On Sep 8, 2023, at 15:30, Martin Matuska wrote:
>
>> I can confirm that the patch fixes the panic caused by the provided script
>> on my test systems.
>> Mark, would it be possible to try poudriere on your system w
On Sep 8, 2023, at 18:19, Mark Millard wrote:
> On Sep 8, 2023, at 17:03, Mark Millard wrote:
>
>> On Sep 8, 2023, at 15:30, Martin Matuska wrote:
>>
>>> I can confirm that the patch fixes the panic caused by the provided script
>>> on my test systems.
&
On Sep 8, 2023, at 21:54, Mark Millard wrote:
> On Sep 8, 2023, at 18:19, Mark Millard wrote:
>
>> On Sep 8, 2023, at 17:03, Mark Millard wrote:
>>
>>> On Sep 8, 2023, at 15:30, Martin Matuska wrote:
>>>
>>>> I can confirm that the pat
lack of inspected testing on aarch64, powerpc64,
powerpc64le, armv7, powerpc, and powerpcspe. That, in
turn, suggests that kyua test inspection for the likes
of aarch64 is not historically a part of the release
process for openzfs or for operating systems that include
openzfs.
===
Mark Millard
marklmi at yahoo.com
On Sep 10, 2023, at 05:58, Mike Karels wrote:
> On 10 Sep 2023, at 2:31, Mark Millard wrote:
>
>> kyua tests that use the:
>>
>> /usr/tests/sys/cddl/zfs/bin/mkfile
>>
>> program like so (for example):
>>
>> mkfile 500M /testpool.1861/bigf
On Sep 10, 2023, at 00:31, Mark Millard wrote:
> kyua tests that use the:
>
> /usr/tests/sys/cddl/zfs/bin/mkfile
>
> program like so (for example):
>
> mkfile 500M /testpool.1861/bigfile.0
>
> (which should be valid) end up with mkfile
> instead reporting
On Sep 10, 2023, at 11:21, Warner Losh wrote:
> On Sun, Sep 10, 2023, 11:10 AM Mark Millard wrote:
>> On Sep 10, 2023, at 00:31, Mark Millard wrote:
>>
>> > kyua tests that use the:
>> >
>> > /usr/tests/sys/cddl/zfs/bin/mkfile
>> >
>>
On Sep 10, 2023, at 23:57, Dag-Erling Smørgrav wrote:
> Mark Millard writes:
>> I'm not aware of there being other documentation for what
>> is appropriate for setting up such for kyua runs.
>
> https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-
On Sep 11, 2023, at 00:03, Mark Millard wrote:
> On Sep 10, 2023, at 23:57, Dag-Erling Smørgrav wrote:
>
>> Mark Millard writes:
>>> I'm not aware of there being other documentation for what
>>> is appropriate for setting up such for kyua runs.
>>
reported vs. what code
involved using the value.
I will say that I've not managed to produce the crash with
14.0-BETA1. But I have produced the crash in my personal
non-debug kernel builds and with the main snapshots dd'd to
media and booted and used.
===
Mark Millard
marklmi at yahoo.com
See: https://lists.freebsd.org/archives/freebsd-arm/2023-September/003071.html
for details. (It is not my activity.)
===
Mark Millard
marklmi at yahoo.com
[Mitchell H.: I think this has exposed a possibly general issue
not specific to RPi*'s, despite the UEFI/ACPI booting of RPi*'s
not being officially supported. See the "BOOT -V RELATED MATERIAL"
section towards the end, skipping the earlier explorations.]
On Sep 22, 2023, at
e from 1.500 to 3.000 P.E.C. depending on NAND binning
END QUOTE
That "A Dual-plane Die with 2 sub-planes with 8 KiB pages", for a total
of 16 KB, does suggest to me that the new messages have a chance of
being correct about there being a tradeoff. (But I'm no expert in the
area.)
===
Mark Millard
marklmi at yahoo.com
his that looks inherently RPi*
specific for possibly ending up with an analogous panic. So
I expect the example is sufficient context to identify a
problem is present, despite EDK2 use not being normal for
RPi4B's and the like as far as FreeBSD is concerned.
===
Mark Millard
marklmi at yahoo.com
; freebsd-version -kru
> 13.2-STABLE
> 13.2-STABLE
> 13.2-STABLE
>
> clang --version
> FreeBSD clang version 16.0.6
> (https://github.com/llvm/llvm-project.git
> llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd13.2
> Thread model: posix
> InstalledDir: /usr/bin
===
Mark Millard
marklmi at yahoo.com
On Oct 2, 2023, at 15:56, Mark Millard wrote:
> Joel Bodenmann wrote on
> Date: Mon, 02 Oct 2023 20:00:29 UTC :
>
>> It seems like I finally managed to hose a FreeBSD system.
>> The machine in question is my workstation at home. It has been running
>> stable/13 with
ies.
There was no problem for my testing of monotonic_buffer_resource.cpp
via the recent official snapshot build of stable/13 .
I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller
context that you also report as failing in the odd context. I suggest
avoiding Qt5/Qt6 testing until you have a context with the
monotonic_buffer_resource.cpp test working.
===
Mark Millard
marklmi at yahoo.com
on fix, this time
involving TRIMs vs. metaslab allocations.
===
Mark Millard
marklmi at yahoo.com
sy to identify in history or test now.)
Depending on the results, my next question might have been: "What
happened for block cloning being disabled now to make it worse than
before block cloning existed?"
> He suggested a workaround of 'sysctl
> vfs.zfs.dmu_offset_next_sync=0' but we should probably sort this out
> for 14.0-RELEASE.
===
Mark Millard
marklmi at yahoo.com
nt is just temporary for that purpose.
===
Mark Millard
marklmi at yahoo.com
bclone_enabled=1.
END QUOTE
Just curiousity on my part about the default completeness of
openzfs-2.2 support, not an objection either way.
===
Mark Millard
marklmi at yahoo.com
On Nov 4, 2023, at 04:38, Mike Karels wrote:
> On 4 Nov 2023, at 4:01, Ronald Klop wrote:
>
>> On 11/4/23 02:39, Mark Millard wrote:
>>> It looks to me like releng/14.0 (as of 14.0-RC4) still has:
>>>
>>> int zfs_bclone_enabled;
>>> SYSCTL_INT(_
re around December 11, 2023.
>
> As of today I personally use block cloning on all my systems.
>
> mm
>
> On 04/11/2023 13:35, Mark Millard wrote:
>> On Nov 4, 2023, at 04:38, Mike Karels wrote:
>>
>>> On 4 Nov 2023, at 4:01, Ronald Klop wrote:
>>>
, just a figure that has proved
useful in various contexts.
Notes:
"failed to reclaim memory" can happen even with swap
space enabled but no swap in use: sufficiently active
pages are just not paged out to swap space.
There are some other parameters of possible use for some
other modern &qu
On Nov 15, 2023, at 08:58, mike tancsa wrote:
> On 11/14/2023 8:25 PM, Mark Millard wrote:
>> mike tancsa wrote on
>> Date: Tue, 14 Nov 2023 13:44:22 UTC :
>>
>>> While testing some new hardware on a recent RELENG_14 image (from Nov
>>> 10th), I noticed s
to have been commited into releng/13.2 . Was this deliberate?
By contrast, the other 2.1.14 notable upstream request merge commited into
stable/13:
QUOTE
#15571 77b0c6f04 dnode_is_dirty: check dnode and its data for dirtiness
END QUOTE
was also committed into releng/13.2 .
===
Mark Millard
ternatives did not work. I see that I
forgot various quote (") symbols.
This note was prompted by:
https://lists.freebsd.org/archives/freebsd-hackers/2023-December/002728.html
that mentions "the list of valid MACHINE_ARCH" that reminded me
of this old issue.
===
Mark Millard
marklmi at yahoo.com
On Dec 7, 2023, at 01:19, Dimitry Andric wrote:
> On 7 Dec 2023, at 05:31, Mark Millard wrote:
>>
>> man arch reports:
>>
>> QUOTE
>>Some machines support more than one FreeBSD ABI. Typically these are
>>64-bit machines, where the
On Jan 12, 2024, at 09:57, Doug Rabson wrote:
> On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote:
> ram_attach is based on regions_to_avail but that is a problem for
> its later bus_alloc_resource use --and that can lead to:
>
> panic("ram_attach: resource %d fa
some sources
make buildworld
For that the installworld may be the larger
change compared to the source updates as far
as contributions to rebuild activity go.
This sort of thing is likely what you had
happen.
===
Mark Millard
marklmi at yahoo.com
On Jan 28, 2024, at 07:46, David Wolfskill wrote:
> On Sun, Jan 28, 2024 at 07:30:53AM -0800, Mark Millard wrote:
>> ...
>> The following two sequences are very different:
>>
>> make buildworld
>> make buildworld
>>
>> vs.
>>
>>
[Note: your email is rejecting my E-mail:
554: 5.7.1 ]
On Jan 28, 2024, at 14:06, David Wolfskill wrote:
> On Sun, Jan 28, 2024 at 10:20:30AM -0800, Mark Millard wrote:
>> ...
>>> That said, one of the machines in question is my local "build machine" --
>>>
On Jan 28, 2024, at 14:34, Mark Millard wrote:
> [Note: your email is rejecting my E-mail:
> 554: 5.7.1 ]
>
> On Jan 28, 2024, at 14:06, David Wolfskill wrote:
>
>> On Sun, Jan 28, 2024 at 10:20:30AM -0800, Mark Millard wrote:
>>> ...
>>>> That s
On Jan 28, 2024, at 16:05, David Wolfskill wrote:
> On Sun, Jan 28, 2024 at 03:00:59PM -0800, Mark Millard wrote:
>> ...
>> To be clear, referencing details of your context:
>>
>> When you had the stable/14 machines at 1c090bf880bf:
>>
>> A) You built
-48.catwhisker.org
14.0-STABLE FreeBSD 14.0-STABLE #41 stable/14-n266554-2ee407b6068a: Sun Jan 28
23:26:10 UTC 2024
r...@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64
1400506 1400506
Yep, still 2ee407b6068a.
~/Downloads/build_typescript.txt:243294: >>> Removing old libraries
Overall this sequence fits what I expect. The above wording is
more detailed than my earlier quick summaries.
===
Mark Millard
marklmi at yahoo.com
On Jan 29, 2024, at 01:50, Alexander Leidinger wrote:
> Am 2024-01-29 00:00, schrieb Mark Millard:
>
>> I would have to see make -dM output from (D) to
>> find the specific timing relationships that lead
>> to that. There is way to much to analyze the
>> specific
ledge if you are to explore
tuning ZFS. I've no evidence that the specific
setting would be helpful.
There has been a effort to deal with arc_prune
problems/overhead. See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275594
===
Mark Millard
marklmi at yahoo.com
ith this).
The kernel has multiple, distinct OOM messages. Which type are you
seeing? :
"failed to reclaim memory"
"a thread waited too long to allocate a page"
"swblk or swpctrie zone exhausted"
"unknown OOM reason %d"
Also, but only for boot verbose:
&q
[I grabbed locally modify text for one of those messages.]
On Feb 29, 2024, at 08:02, Mark Millard wrote:
> Peter 'PMc' Much wrote on
> Date: Thu, 29 Feb 2024 13:40:05 UTC :
>
>> On 2024-02-27, Edward Sanford Sutton, III wrote:
>>> More recently looked
On Feb 29, 2024, at 08:21, Peter wrote:
> On Thu, Feb 29, 2024 at 08:02:42AM -0800, Mark Millard wrote:
> ! Peter 'PMc' Much wrote on
> ! Date: Thu, 29 Feb 2024 13:40:05 UTC :
> !
> ! > There is an updated patch in the PR 275594 (5 pieces), that works for
> ! &
On Feb 29, 2024, at 09:40, Mark Millard wrote:
> On Feb 29, 2024, at 08:21, Peter wrote:
>
>> On Thu, Feb 29, 2024 at 08:02:42AM -0800, Mark Millard wrote:
>> ! Peter 'PMc' Much wrote on
>> ! Date: Thu, 29 Feb 2024 13:40:05 UTC :
>> !
>> ! &
Summary consequence: I recommend only using swap partitions, not swap
files.
Yes, I have suffered deadlocks from attempted swap file use, with just
UFS over umass (USB SSD) being what held the the swap file in question.
===
Mark Millard
marklmi at yahoo.com
Also:
http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.1/
is empty. This prevents me from suggesting a test if a bug
report is reproducible from an official stable/14 snapshot
instead of just from someone's personal build of stable/14
(for a RPi3B failure context).
===
Mark Mi
1 - 100 of 137 matches
Mail list logo
