; (i.e., pkg -c ${BASEDIR} always fails as a non-root user).
>
> Reviewed by: des
> Fixes: 856e158dc4aa ("freebsd-update: improve pkgbase check")
> MFC after: 2 weeks
> Differential Revision: https://reviews.freebsd.org/D51770
===
Mark Millard
marklmi at yahoo.com
}
Note the "return (0);" (possibly *mdp==0 as well when mdp!=0 ?).
Then, for that return, showing the substitution:
+ *end = ptr + 0 - 1;
Simplifying for the specific case:
+ *end = ptr - 1;
That looks likely to be wrong to me.
===
Mark Millard
marklmi at yahoo.com
ITH_MITKBR5 (main: example, new suffix numbers):
/usr/lib/libkrb5.so.12
/usr/lib/libgssapi_krb5.so.11
/usr/lib/libcom_err.so.6
(I'll not list /usr/lib32/ ones.)
(I've never set up a WITH_MITKBR5 context.)
===
Mark Millard
marklmi at yahoo.com
> >> https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc14_build/1022/console:
> >>
> >> 10:32:02 /workspace/src/sys/kern/kern_descrip.c: In function
> >> 'open_to_fde_flags':
> >> 10:32:02 /workspace/src/sys/kern/kern_descrip.c:560:79: erro
bscripts or in points casts, as long as the expressions
in which they occur form integer constant expressions. In contrast,
names of other objects, even if const-qualified and with static storage
duration, are not valid.
END QUOTE
It looks to me like gcc is avoiding allowing use of an extension
to what the language definition provides as guarantees for what
is a valid integer constant expression.
===
Mark Millard
marklmi at yahoo.com
On Jul 7, 2025, at 07:29, Lexi Winter wrote:
> Mark Millard:
>> Lexi Winter wrote on
>>> clang: install clang-scan-deps
>
>> Would it be reasonable to also enable generation/installation of,
>>
>> /usr/lib/libc++.module.json (a guess about where it go
teststd.cpp
(My understanding is that clang++ 19.1.7 fixed the problem
it previously had with finding libc++.module.json when it
is part of the installed materials. But I'm not familiar
with the details.)
===
Mark Millard
marklmi at yahoo.com
On Jun 25, 2025, at 12:48, Bjoern A. Zeeb
wrote:
> On Wed, 25 Jun 2025, Mark Millard wrote:
>
>> Andrew Turner wrote on
>> Date: Wed, 25 Jun 2025 11:22:51 UTC :
>>
>>> The branch main has been updated by andrew:
>>>
>>>
s too
old to have a known status for handling things that
are now requested could be a good thing.
===
Mark Millard
marklmi at yahoo.com
(dm != NULL && dm->dm_type == DM_SYMLINK)
The above code would be sufficient for (B) but
would not be for (A).
If the context is an example of (A), it would
appear that the context needs to be changed to
be an example of (B). In other words: the new
if above would not be what needs to be changed.
> free(dm->dm_data, M_DFSINT);
>
> free(dm, M_DFSINT);
===
Mark Millard
marklmi at yahoo.com
packages .PHONY
>
> -real-update-packages: .PHONY create-packages
> +real-update-packages: .PHONY
> .if defined(PKG_VERSION_FROM_DIR)
> @echo "==> Checking for new packages (comparing ${PKG_VERSION} to
> ${PKG_VERSION_FROM})"
> @for pkg in ${PKG_VERSION_FROM_DIR}/${PKG_NAME_PREFIX}-*; do \
===
Mark Millard
marklmi at yahoo.com
c 100644
> --- a/sys/x86/include/tls.h
> +++ b/sys/x86/include/tls.h
> @@ -59,7 +59,7 @@ static __inline void
> _tcb_set(struct tcb *tcb)
> {
> #ifdef __amd64__
> - amd64_set_fsbase(tcb);
> + amd64_set_tlsbase(tcb);
> #else
> i386_set_gsbase(tcb);
> #endif
===
Mark Millard
marklmi at yahoo.com
ll enabled. That suggests that the document was generated
for, say, amd64.
The WITHOUT_CLANG section is like that as well.
===
Mark Millard
marklmi at yahoo.com
eed to be
changed or deleted?
===
Mark Millard
marklmi at yahoo.com
On Apr 22, 2025, at 11:40, John Baldwin wrote:
> On 4/11/25 13:14, Mark Millard wrote:
>> John Baldwin wrote on
>> Date: Fri, 11 Apr 2025 13:54:30 UTC :
>>> The branch main has been updated by jhb:
>>>
>>> URL:
&
use of
alternate -std=c++?? in ports that are using the c++
library. The libc++ headers will track but need not be
a good match to the above list in some respects?
This also applies to use of a g++* with -stdlib=libc++
(which various modern lang/gcc* support using).
===
Mark Millard
marklmi at yahoo.com
ges to maxlen that are still unsigned, without
needing editing.
These days (C23) there are parts of the language for which
implicit conversions are not involved:
QUOTE (from N3220):
The constraints for constexpr objects are intended to enforce
checks for portability at translation time.
torage device
> .It Pa mmcsd0s1
> @@ -168,7 +170,7 @@ infinite loop that accepts anything and contains nothing
> .It Pa nvd0
> first NVMe storage device using NVMe namespaces
> .It Pa pts/
> -pseduo-terminals; see
> +pseudo-terminals; see
> .Xr pts 4
> .It Pa random
> source of weak randomness; see
===
Mark Millard
marklmi at yahoo.com
_WORKERS_COUNT} repo \
PKG_WORKERS_COUNT vs. PKG_WORKERS_THREADS ?
> -m ${WSTAGEDIR}/meta \
> -o ${REPODIR}/${PKG_ABI}/${PKG_VERSION} \
> ${REPODIR}/${PKG_ABI}/${PKG_VERSION} \
===
Mark Millard
marklmi at yahoo.com
ently failing, starting with this commit, as
I remember. [Not that I can look and confirm any details as things
are.]
But, I'll note that:
https://pkg.freebsd.org/FreeBSD:15:armv7/base_latest/?C=M&O=D
indicates armv7 PkgBase has been managing to build. But may be its
builds do not check assertions for dtc's build. Or, maybe, there
is use of a now-bad file, per John's note.
===
Mark Millard
marklmi at yahoo.com
[I appearently never sent the below at the time.]
On Nov 20, 2024, at 08:03, Mark Millard wrote:
John Baldwin wrote on
Date: Wed, 20 Nov 2024 14:52:06 UTC :
> On 11/19/24 08:02, Michal Meloun wrote:
>>
>>
>> On 19.11.2024 16:15, John Baldwin wrote:
>>> On
On Nov 26, 2024, at 14:02, Mark Millard wrote:
> Doug Moore wrote on
> Date: Tue, 26 Nov 2024 18:15:33 UTC :
>
>> The branch main has been updated by dougm:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=40c1672e886b86f4956c1
iews.freebsd.org/D47767
. . .
MFC to stable/14 ? Should 14.2-RELEASE getting something related? 14.1-RELEASE ?
===
Mark Millard
marklmi at yahoo.com
On Nov 23, 2024, at 08:18, Poul-Henning Kamp wrote:
>
> Mark Millard writes:
>
>>> +When debugging the kernel on modern laptops, the screen is often
>>> +the only available console, and relevant information will scroll
>>> +out of view before
rminal *tm)
> }
> vd->vd_flags &= ~VDF_SPLASH;
> vt_flush(vd);
> + } else if (vt_slow_down > 0) {
That test treats < 0 the same as == 0, only > 0 is distinct.
> + int i, j;
> + for (i = 0; i < vt_slow_down; i++) {
> + for (j = 0; j < 1000; j++)
> + vt_flush(vd);
> + }
> } else if (!(vd->vd_flags & VDF_ASYNC)) {
> vt_flush(vd);
> }
===
Mark Millard
marklmi at yahoo.com
> > This gives me another question. Who generates the .rodata1 section? This
> > section appeared in gnu ld three decades ago, with no real description.
> > Do we still need it?
>
> I have no idea if we still need .rodata1 (or why it exists), I was just
> reading the diff of the linker script.
Looking around at examples on the web I'm seeing mostly the
likes of the following for analogous text:
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1: { *(.rodata1) }
(and somewhat similarly for .data.*)
I saw some examples of *(.rodata.str1.4) for examples that
lacked use of .rodata.* , giving some idea what would be
expected to match the .* part of the pattern.
===
Mark Millard
marklmi at yahoo.com
Cleaning up wrkdir
===> Cleaning for gcc13-13.3.0
build of lang/gcc13 | gcc13-13.3.0 ended at Sat Oct 26 09:37:21 UTC 2024
build time: 04:53:00
You are likely going to have to report more about how you tired to do the
build and such in order for anyone to have a chance to help.
===
Mark Millard
marklmi at yahoo.com
On Oct 31, 2024, at 17:53, Mark Millard wrote:
> On Oct 31, 2024, at 16:37, Ed Maste wrote:
>
>> On Thu, 31 Oct 2024 at 15:17, Mark Millard wrote:
>>>
>>>> + # Presence of FreeBSD-* package(s) indicates packaged base.
>>>> + if ! pkg -c ${BAS
On Oct 31, 2024, at 16:37, Ed Maste wrote:
> On Thu, 31 Oct 2024 at 15:17, Mark Millard wrote:
>>
>>> + # Presence of FreeBSD-* package(s) indicates packaged base.
>>> + if ! pkg -c ${BASEDIR} info -q -x '^FreeBSD' 2>/dev/null; then
>>
>
required?).
> + return
> + fi
> + cat < +FreeBSD-update is incompatible with the use of packaged base. Please see
> +https://wiki.freebsd.org/PkgBase for more information.
> +EOF
> + exit 1
> +}
. . .
===
Mark Millard
marklmi at yahoo.com
On Oct 24, 2024, at 20:00, Mark Millard wrote:
> Dimitry Andric wrote on
> Date: Wed, 23 Oct 2024 18:32:46 UTC :
>
>> The branch main has been updated by dim:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=f3dbef108212460489ae6
les allowed META_MODE to then be
able to complete the buildworld . The removes were (across multiple
trees):
# rm
/usr/obj/BUILDs/main-*-*dbg-clang/usr/main-src/*/cddl/usr.sbin/zfsd/tests/*.o
# rm
/usr/obj/BUILDs/main-*-*dbg-clang/usr/main-src/*/share/examples/tests/tests/googletest*/*.o
# rm /usr/obj/BUILDs/main-*-*dbg-clang/usr/main-src/*/tests/sys/capsicum*/*.o
# rm /usr/obj/BUILDs/main-*-*dbg-clang/usr/main-src/*/tests/sys/fs/fusefs*/*.o
# rm /usr/obj/BUILDs/main-*-*dbg-clang/usr/main-src/*/lib/googletest/tests/*/*.o
===
Mark Millard
marklmi at yahoo.com
f more modern devel/llvm* 's only get one the langauge
updates, not the libc++ library updates. But some things from
the C++23 and later standards involve both before support is
functional.]
===
Mark Millard
marklmi at yahoo.com
. (I've no clue if there is such code someplace.)
My notes in the PR about this may have the details wrong about
which changed vs. which did not: I only just noticed the
vm.stats.vm.v_laundry_count was something that I'd missed so
I'd thought there was only one laundry place and did not check
which at the time. So my details there should not be followed
but just be considered as suggestive types of wording that
might be involved.
===
Mark Millard
marklmi at yahoo.com
3c/logs/qt6-tools-6.7.3.log
which also reports:
Host OSVERSION: 1500023
Jail OSVERSION: 1500024
The vintage of 1500023 predates the 2024-Sep-20 pipebuf change
so the kernel is too old to provide support. (Not that it is
generally easy to know much detail about the Host vintage of
main within the 1500023 span.)
===
Mark Millard
marklmi at yahoo.com
On Oct 5, 2024, at 23:30, Konstantin Belousov wrote:
> On Sat, Oct 05, 2024 at 06:14:40PM -0700, Mark Millard wrote:
>> Konstantin Belousov wrote on
>> Date: Fri, 20 Sep 2024 21:09:29 UTC :
>>
>>> The branch main has been updated by kib:
>>>
>>&g
ROOT LOGIN
(root) ON ttyv0
2024-10-06T00:35:08.835269-07:00 aarch64-main-pbase login 1022 - - getting
pipebuf resource limit: Invalid argument
. . .
It seems related changes introducing incompatibility with even
recent older kernels should have had a __FreeBSD_version update
and might need to be documented for the now-existing
incompatibility with most of the 1500023 and older history?
===
Mark Millard
marklmi at yahoo.com
iscussion with 2 thumbs up, including one by ayrtonm.
A similar point goes for:
-void *arg, uint32_t rootnum)
+void *arg, uint32_t roottype)
with another ayrtonm thumbs up at the end. (I've not checked
if there are more distinctions.)
Such leaves me wondering if what was committed was actually
the final intended code: Is it?
===
Mark Millard
marklmi at yahoo.com
might mean just 14.2 officially now.
Interestingly, "Libc++ also supports common platforms and architectures"
lists:
arm64 for macOS 13+, Linux, and Android 5.0+ .
arm forFreeBSD12+, Linux, and Android 5.0+ .
But I do not expect this list is kept as up to date.
===
Mark Millard
marklmi at yahoo.com
urce-src-package: _pkgbootstrap .PHONY
rm -f ${SSTAGEDIR}/*.plist 2>/dev/null || :
. . .
. . . > ${SSTAGEDIR}/src.plist
. . .
create-source-src-sys-package: _pkgbootstrap .PHONY
rm -f ${SSTAGEDIR}/*.plist 2>/dev/null || :
. . .
. . . > ${SSTAGEDIR}/src-sys.plist
. . .
===
Mark Millard
marklmi at yahoo.com
s a duplicate of 16431 and 16431's fix
has been committed to the openzfs master branch:
https://github.com/openzfs/zfs/commit/244ea5c4881f92a9d7c1fb341a49b127fda7539d
===
Mark Millard
marklmi at yahoo.com
itx_metaslab_slog_alloc)!
pid 58 (zpool) is attempting to use unsafe AIO requests - not logging anymore
• [2:13 PM]Flox:
FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0
main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024
mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
===
Mark Millard
marklmi at yahoo.com
On Jul 26, 2024, at 20:28, Philip Paeps wrote:
> On 2024-07-27 07:57:38 (+0800), Mark Millard wrote:
>> Michal Meloun wrote on
>> Date: Thu, 25 Jul 2024 16:25:09 UTC :
>>
>>> The branch main has been updated by mmel:
>>>
>>> U
for selected EABI functions. These functions can be called
> with rtld bind lock write-locked, so they should be resolved in forward.
>
> Reported by:Mark Millard , John F Carr
>
> Reviewed by:kib, imp
> MFC after: 1 week
> Different
mv6
Such would be a bigger source code change.
I think such is part of what Warner is referring
to, even if the other aspects of any of
armv6/armv5/armv4/... kernel support were left in
place. (No claim such has or will be left in
place.)
===
Mark Millard
marklmi at yahoo.com
arner Losh 53 min. 1 -54/+0
2508372b7b46: * cdefs.h: Assume the compiler supports at least GNU C 3.0
extensions Warner Losh 53 min. 1 -78/+1
===
Mark Millard
marklmi at yahoo.com
.
. .
So, you are saying that the modern aarch64 Windows 11 on a system
that has an RTC would be based on storing UTC in the RTC, even for
booting Windows 11?
[I dual boot a Windows DevKit 2023 with Windows 11 (presupplied
internal media) and with FreeBSD (external USB3 media). Imagine
that it h
t;
> /* Define the POSIX.1 version we target for compliance. */
> -#define _POSIX_VERSION 200112L
> +#define _POSIX_VERSION 200808L
Subject and description list one of: 200809L vs. 200809
> /* access function */
> #define F_OK 0 /* test for existence of file */
===
Mark Millard
marklmi at yahoo.com
Sponsored by: Beckhoff Automation GmbH & Co. KG
> . . .
What of the /.profile vs. /root/.profile hard linking? Do those have
have the same issues and the same solution?
===
Mark Millard
marklmi at yahoo.com
ibutions do not use the linux mainstream *.dts*
files but build their own *.dts* files and distribute the resultant
*.dtb's directly.
For RPi*'s, FreeBSD uses the *.dtb files from some RPI* distribution
(via the rpi-firmware port). FreeBSD does not use the linux mainstream
*.dts* files for RPi*'s: RPi*'s have a a different compatibility
criteria applied compared to most of the Small Arm Boards.
So: not in tree.
===
Mark Millard
marklmi at yahoo.com
dev/sa0 on FreeBSD:
QUOTE
-f file, --file file
Read the archive from or write the archive to the specified file.
The filename can be - for standard input or standard output. The
default varies by system; on FreeBSD, the default is /dev/sa0; on
Linux, the default is /dev/st0.
END QUOTE
===
Mark Millard
marklmi at yahoo.com
successful.
#20303 .. #20306 are where the dts commits had things broken relative
to building. That was:
#20303 Thu Mar 21 20:51:55 GMT 2024
. .
#20306 Fri Mar 22 05:39:02 GMT 2024
with the prior successful build being:
#20302 Thu Mar 21 18:28:11 GMT 2024
===
Mark Millard
marklmi at yahoo.com
ternally
set before nullfs.ko is loaded.
There might need to be notes about the proper
handling for early (tunable) time frames.
Mark
> Best regards,
>
> --
> Seigo Tanimura
>
>
> On Sun, Mar 17, 2024 at 1:18 PM Mark Millard wrote:
> Both an official PkgBase install and
[Correcting a typo in the naming. Leads to discovering need to load nullfs.ko
first.]
On Mar 16, 2024, at 21:18, Mark Millard wrote:
> Both an official PkgBase install and a personal build do not find the new oid
> for this for main:
>
> # uname -apKU
> FreeBSD 7950X3D-Z
specific cache/nocache option.
END QUOTE
That is evidence of the vintage of materials.
===
Mark Millard
marklmi at yahoo.com
p->nullm_flags & NULLM_CACHE) != 0) {
> vfs_register_for_notification(xmp->nullm_vfs, mp,
> &xmp->notify_node);
Does the mount command report the cache vs. no cache status of the mounts
that it lists?
https://lists.freebsd.org/archives/freebsd-current/2024-March/005690.html
is is recent a report that it does not. A reply mentions that "ignore" vs.
not has a similar status of not being reported:
https://lists.freebsd.org/archives/freebsd-current/2024-March/005695.html
===
Mark Millard
marklmi at yahoo.com
On Jan 22, 2024, at 11:37, Mark Millard wrote:
>
> Baptiste Daroussin wrote on
> Date: Mon, 22 Jan 2024 13:23:37 UTC :
>
>> On Mon, Jan 22, 2024 at 07:15:22AM -0600, Mike Karels wrote:
>>> On 21 Jan 2024, at 21:48, Alexey Dokuchaev wrote:
>>>
>>&
o get
> lang/rust build in poudriere (USE_TMPFS=all) without setting
> vfs.tmpfs.memory_percent to 100.
I'm guessing this is implicitly: without having a huge
RAM+SWAP space.
> the poudriere dies with plenty of no space left on device.
I will note that I've not tested my configuration
with the change yet, holding back on updating FreeBSD
for other reasons. But I doubt that I'd run out of
RAM+SWAP, given the huge RAM+SWAP that I've
historically used for the context.
I do analogously on 2 other systems:
32 GiBytes of RAM and 8 hardware threads
192 GiBytes of RAM and 32 hardware threads
(Both having both ZFS and UFS media.)
On the various small RAM systems, I use
USE_TMPFS=data or USE_TMPFS=no and avoid
ZFS.
I also always avoid spinning rust.
===
Mark Millard
marklmi at yahoo.com
Forwarding for Kirk:
On Dec 3, 2023, at 23:52, Kirk McKusick wrote:
> From: Mark Millard
> Subject: RE: git: 35a301555bff - main - Increase UFS/FFS maximum link count
> from 32767 to 65530. [actually 65500]
> Date: Sun, 3 Dec 2023 14:42:47 -0800
> To: Kirk McKusick , dev-c
lk -a" behavior with.
===
Mark Millard
marklmi at yahoo.com
On Sep 23, 2023, at 17:28, Mark Millard wrote:
> On Sep 23, 2023, at 15:51, Simon J. Gerraty wrote:
>
>> Simon J. Gerraty wrote:
>>>> Looks like this broke lib32 builds via it ending up using
>>>> the default:
>>>>
>>>> -ta
+97,9 @@ META_DEPS+= ${META_NOPHONY}
>
> .if ${MACHINE:Nhost*:Ncommon} != "" && ${MACHINE} != ${HOST_MACHINE}
> # cross-building
> -CROSS_TARGET_FLAGS?= -target
> ${MACHINE_ARCH}-unknown-freebsd${FREEBSD_REVISION}
> +CROSS_TARGET.clang?= ${MACHINE_ARCH}-unknown-freebsd${FREEBSD_REVISION}
> +CROSS_TARGET_FLAGS.clang?= -target ${CROSS_TARGET.clang}
> +CROSS_TARGET_FLAGS?= ${CROSS_TARGET_FLAGS.${COMPILER_TYPE}}
> CFLAGS+= ${CROSS_TARGET_FLAGS}
> ACFLAGS+= ${CROSS_TARGET_FLAGS}
> .endif
I see that you have since disabled the new share/mk/local.sys.mk
code unless ${MK_DIRDEPS_BUILD} == "yes" --thus giving time
for considering alternatives.
===
Mark Millard
marklmi at yahoo.com
hows:
Changes
• Add support for host32 for DIRDEPS_BUILD (details / cgit)
• ng_eiface: switch VNETs when injecting mbufs into netgraph (details / cgit)
===
Mark Millard
marklmi at yahoo.com
===
Mark Millard
marklmi at yahoo.com
(no for_*_obj list matches in zhack output):
"com.intel:allocation_classes", // READ-ONLY COMPATIBLE yes
"org.zfsonlinux:allocation_classes",// READ-ONLY COMPATIBLE yes
I assume that these 7 are not harmful beyond being misleading
about what should be expected to be in the features_for_read
list.
(The comment notation is my addition for explicitness in this
note.)
===
Mark Millard
marklmi at yahoo.com
fs.per_txg_dirty_frees_percent=5 allowed more overall
progress on that aarch64 system. The big cleanout of all the
builders at the end is not the only consideration in setting
vfs.zfs.per_txg_dirty_frees_percent (for at least some systems).
===
Mark Millard
marklmi at yahoo.com
On Sep 5, 2023, at 00:00, Mark Millard wrote:
> On Sep 4, 2023, at 22:06, Mark Millard wrote:
>
>> . . .
>
> So I tried 30 for per_txg_dirty_frees_percent for 2 contexts:
> autotrim on
> vs.
> autotrim off
>
> where there was 100 GiByte+ to delete after a po
On Sep 4, 2023, at 22:06, Mark Millard wrote:
> On Sep 4, 2023, at 18:39, Mark Millard wrote:
>
>> On Sep 4, 2023, at 10:05, Alexander Motin wrote:
>>
>>> On 04.09.2023 11:45, Mark Millard wrote:
>>>> On Sep 4, 2023, at 06:09, Alexander Motin wrot
On Sep 4, 2023, at 18:39, Mark Millard wrote:
> On Sep 4, 2023, at 10:05, Alexander Motin wrote:
>
>> On 04.09.2023 11:45, Mark Millard wrote:
>>> On Sep 4, 2023, at 06:09, Alexander Motin wrote:
>>>> per_txg_dirty_frees_percent is directly related to the dele
On Sep 4, 2023, at 10:05, Alexander Motin wrote:
> On 04.09.2023 11:45, Mark Millard wrote:
>> On Sep 4, 2023, at 06:09, Alexander Motin wrote:
>>> per_txg_dirty_frees_percent is directly related to the delete delays we see
>>> here. You are forcing ZFS to com
On Sep 4, 2023, at 06:09, Alexander Motin wrote:
> On 04.09.2023 05:56, Mark Millard wrote:
>> On Sep 4, 2023, at 02:00, Mark Millard wrote:
>>> On Sep 3, 2023, at 23:35, Mark Millard wrote:
>>>> On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>>>>
On Sep 4, 2023, at 02:00, Mark Millard wrote:
> On Sep 3, 2023, at 23:35, Mark Millard wrote:
>
>> On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>>
>>>
>>> On 03.09.2023 22:54, Mark Millard wrote:
>>>> After that ^t produced
On Sep 3, 2023, at 23:35, Mark Millard wrote:
> On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>
>>
>> On 03.09.2023 22:54, Mark Millard wrote:
>>> After that ^t produced the likes of:
>>> load: 6.39 cmd: sh 4849 [tx->tx_quiesce_done_cv] 10047.33r 0.5
On Sep 3, 2023, at 19:54, Mark Millard wrote:
> ThreadRipper 1950X (32 hardware threads) doing bulk -J128
> with USE_TMPFS=no , no ALLOW_MAKE_JOBS , no
> ALLOW_MAKE_JOBS_PACKAGES , USB3 NVMe SSD storage/ZFS-boot-media,
> debug system build in use :
>
> [00:03:44] Building 34
On Sep 3, 2023, at 22:06, Alexander Motin wrote:
>
> On 03.09.2023 22:54, Mark Millard wrote:
>> After that ^t produced the likes of:
>> load: 6.39 cmd: sh 4849 [tx->tx_quiesce_done_cv] 10047.33r 0.51u 121.32s 1%
>> 13004k
>
> So the full state is not &
c/amd64.amd64/sys/GENERIC-DBG
amd64 amd64 150 150
Looks like I'll be forcing the machine to reboot or
to power off. The media was deliberately set up for
doing risky tests. It is not my normal environment.
===
Mark Millard
marklmi at yahoo.com
the number of hardware
threads being what matters for repeatability via poudriere.
A weakness in that evidence is that my test predates:
Sun, 27 Aug 2023
• git: 315ee00fa961 - main - zfs: merge openzfs/zfs@804414aad Martin Matuska
and so was for one stage earlier relative main's openzf
itionally, there can be no changes to the KBI
until main is branched to stable/14.
END QUOTE
I'd not know if the wording is stronger than the intent. It is
difficult to word things for a complicated intent. But, for
all I know, the wording could match the intent.
===
Mark Millard
marklmi at yahoo.com
198dcfc039 (16 June), albeit
after building ~1800 packages.
. . .
So the count seems to sometimes go well above 500 or so.
===
Mark Millard
marklmi at yahoo.com
On Aug 16, 2023, at 16:28, John Baldwin wrote:
> On 8/16/23 11:09 AM, Mark Millard wrote:
>> John Baldwin wrote on
>> Date: Wed, 16 Aug 2023 16:55:37 UTC :
>>> On 8/16/23 9:53 AM, John Baldwin wrote:
>>>> The branch main has been updated by jhb:
>>&g
branches as long as those branches are supported
+ by the ports system.
END QUOTE
reads to me like only "self hosted" building of ports and packages
is referenced. (That may be the intent for the wording, I was not
sure.)
===
Mark Millard
marklmi at yahoo.com
as tier 2. Even the somewhat
larger address space for native could easily end up being too much of a
constraint, for example, much like the process size build problems that
happen now for armv7 on aarch64 for port builds in poudriere(-devel)
jails.
For reference:
CPU: ARM Cortex-A7 r0p5 (ECO: 0x)
CPU Features:
Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7,
PXN, LPAE, Coherent Walk
Optional instructions:
SDIV/UDIV, UMULL, SMULL, SIMD(ext)
LoUU:2 LoC:3 LoUIS:2
Cache level 1:
32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
32KB/32B 2-way instruction cache Read-Alloc
Cache level 2:
512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc
real memory = 2113257472 (2015 MB)
avail memory = 2054692864 (1959 MB)
===
Mark Millard
marklmi at yahoo.com
On Jul 27, 2023, at 23:19, Mark Millard wrote:
> Warner Losh wrote on
> Date: Fri, 28 Jul 2023 04:31:30 UTC :
>
>> The branch main has been updated by imp:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=98d03dca9ac8e3eb5857c
mv6 if you desire, but
> it won't be built as part of 'make universe' without -DEXTRA_TARGETS.
Does this stop the automatic builds of FreeBSD-main-armv6-build
on ci.freebsd.org <http://ci.freebsd.org/> and/or the
https://ci.freebsd.org/tinderbox/
reporting for armv6 main?
===
Mark Millard
marklmi at yahoo.com
On Jul 27, 2023, at 17:22, Mark Millard wrote:
> Kirk McKusick wrote on
> Date: Thu, 27 Jul 2023 22:27:49 UTC :
>
>> The branch main has been updated by mckusick:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=831b1ff7913fb0b317a25
the
architectures where some sizes changed.
> MFC-after: 1 week
> Sponsored-by: The FreeBSD Foundation
. . .
===
Mark Millard
marklmi at yahoo.com
are sufficient to have the
problem. If there is a 3rd usage context as well, the VNET/DPCPU
use would still be problems.
In my view, having such a dependency on accidentally avoiding
some minor variations in the code generation is not
appropriate. Use of --no-relax (for now) at least appears to
ot
involve initializing the bytes that the first member does not
include.
===
Mark Millard
marklmi at yahoo.com
On Jul 5, 2023, at 11:10, Brooks Davis wrote:
> On Mon, Jul 03, 2023 at 04:20:41PM -0700, Mark Millard wrote:
>> On Jul 3, 2023, at 15:27, Mark Millard wrote:
>>
>>> Brooks Davis wrote on
>>> Date: Mon, 03 Jul 2023 21:24:11 UTC :
>>>
>>>&
On Jul 3, 2023, at 15:27, Mark Millard wrote:
> Brooks Davis wrote on
> Date: Mon, 03 Jul 2023 21:24:11 UTC :
>
>> On Sat, Jul 01, 2023 at 10:59:22PM +, Ka Ho Ng wrote:
>>> The branch main has been updated by khng:
>>>
>>> URL:
&
values in structures
or unions (6.2.6.1)
-- The values of bytes that correspond to union members other
than the one last stored into (6.2.6.1)
As long as those are true, initializer notation is not guaranteed
to avoid memory content leakage for the padding bytes and unused
bytes for smaller union fields.
(I'll not generate wording to deal with trap representations for such
issues, something C++ avoids.)
===
Mark Millard
marklmi at yahoo.com
On Jul 2, 2023, at 09:34, Mark Millard wrote:
> Ka Ho Ng wrote on
> Date: Sun, 02 Jul 2023 10:18:35 UTC :
>
> On Sun, Jul 2, 2023 at 6:03 AM Ka Ho Ng wrote:
>>
>>> On Sat, Jul 1, 2023 at 7:13 PM Konstantin Belousov
>>> wrote:
>>>
>>&g
source is to have
dual language use for some reason. (I see no indication
of such here. If such use is the intended context, please
be explicit about that.)
Also, using material from 2021 when FreeBSD is based on a
older C standard version can have its own problems. If I
remember right, FreeBSD is basically targeting C11 or
so for its C code.
An example quote from footnote 310 (for memcmp) in ISO/IEC
9899:2011 is:
QUOTE
The contents of "holes" used as padding for purposes of
alignment within structure objects are indeterminate.
Strings shorter than the allocated space and unions may
also cause problems in comparison.
END QUOTE
Initializing .intval and then accessing .ulongval resulting
in 0x as a possible result should be no
surprise for C as far as I can tell. Based on what I'm
reading, code that assumes otherwise is incorrect relative
to the C language standard.
It looks to me like the bzero use is trying to make changes
to allow non-standard C code "still work".
===
Mark Millard
marklmi at yahoo.com
On May 31, 2023, at 20:52, Mark Millard wrote:
> On May 31, 2023, at 20:30, Mark Millard wrote:
>
>> In a context of:
>>
>> # uname -apKU
>> FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90
>> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT
On May 31, 2023, at 20:30, Mark Millard wrote:
> In a context of:
>
> # uname -apKU
> FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90
> main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/
edia booted themselves just fine before
I tried this "try moutning via older system" activity.
===
Mark Millard
marklmi at yahoo.com
_LLVM_TARGET_ALL
Only build the required LLVM target support. This option is
preferred to specific target support options. When set, these
options are also in effect:
WITHOUT_LLVM_TARGET_AARCH64 (unless WITH_LLVM_TARGET_AARCH64 is
set explicitly)
WITHOUT_LLVM_TARGET_ARM (unless WITH_LLVM_TARGET_ARM is set
explicitly)
WITHOUT_LLVM_TARGET_POWERPC (unless WITH_LLVM_TARGET_POWERPC is
set explicitly)
WITHOUT_LLVM_TARGET_RISCV (unless WITH_LLVM_TARGET_RISCV is set
explicitly)
These might need some bundling such that AARCH64 being
enabled (no WITHOUT) ends up forcing ARM to also be
enabled (even if there is a WITHOUT). Or may be just
report an incoherent combination and stop.
===
Mark Millard
marklmi at yahoo.com
On May 21, 2023, at 10:14, Mark Millard wrote:
> Hans Petter Selasky wrote on
> Date: Sun, 21 May 2023 16:57:47 UTC :
>
>> On 5/21/23 18:33, Jessica Clarke wrote:
>>> On 21 May 2023, at 17:21, Hans Petter Selasky wrote:
>>>>
>>>&
t; won't work, based on what I currently know about C-programming. I tried,
> but clang gave me a warning about it.
>
>
>
> You can't declare global variables inside a function or it is not good
> style.
>
>
>
> From what I can see, this location is the only place I've come accross
> in the FreeBSD kernel, where a SYSINIT() is used inside a function, and
> I thought I would just move that outside the function instead.
>
> This change also allows for:
>
> https://reviews.freebsd.org/D40193
>
===
Mark Millard
marklmi at yahoo.com
all that != for Boolean
arguments by the name: "xor". That is not my favorite
name for it. I prefer: "Boolean inequality" or the like.
I've seen code in the past that expanded out the case
analysis based on the tests for specific values.
===
Mark Millard
marklmi at yahoo.com
le
*/
static inline boolean_t
zfs_neon_available(void)
{
return (elf_hwcap & HWCAP_NEON);
}
/*
* Check if SHA256 is available
*/
static inline boolean_t
zfs_sha256_available(void)
{
return (elf_hwcap2 & HWCAP2_SHA2);
}
===
Mark Millard
marklmi at yahoo.com
1 - 100 of 239 matches
Mail list logo
