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
o 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
a0 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
sful.
#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
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,
> >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:
>>>
>>&
iere (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
;bulk -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
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
nges
• 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
nd (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 w
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
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
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 &
d64/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
at 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 openzfs updates. It had:
Thu, 10 Aug 2023
. .
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
fter 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
ranches 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
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
=armv6 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
rchitectures where some sizes changed.
> MFC-after: 1 week
> Sponsored-by: The FreeBSD Foundation
. . .
===
Mark Millard
marklmi at yahoo.com
ient 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
systemati
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:
&
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
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/
es just fine before
I tried this "try moutning via older system" activity.
===
Mark Millard
marklmi at yahoo.com
ET_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
= 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
On Apr 16, 2023, at 10:40, Mark Millard wrote:
> On Apr 16, 2023, at 01:34, Mark Millard wrote:
>
>> On Apr 15, 2023, at 19:13, Mark Millard wrote:
>>
>>> A general question is all for this message.
>>>
>>> So far no commit to FeeeBSD's
On Apr 16, 2023, at 01:34, Mark Millard wrote:
> On Apr 15, 2023, at 19:13, Mark Millard wrote:
>
>> A general question is all for this message.
>>
>> So far no commit to FeeeBSD's main seems to be
>> analogous to the content of:
>>
>> https
On Apr 15, 2023, at 19:13, Mark Millard wrote:
> A general question is all for this message.
>
> So far no commit to FeeeBSD's main seems to be
> analogous to the content of:
>
> https://github.com/openzfs/zfs/pull/14739/files
>
> After my existing poudriere bulk t
On Apr 15, 2023, at 21:31, Mark Millard wrote:
> On Apr 15, 2023, at 17:27, Mark Millard wrote:
>
>> On Apr 15, 2023, at 15:49, Mark Millard wrote:
>>
>>> . . .
>>>>
>>>>
>>>> (Mostly written as I progressed but some mater
On Apr 15, 2023, at 17:27, Mark Millard wrote:
> On Apr 15, 2023, at 15:49, Mark Millard wrote:
>
>> . . .
>>>
>>>
>>> (Mostly written as I progressed but some material later
>>> inserted into/around previously written material.)
>>>
? Vs.: Should I keep
using the content of that change?
(The question is prompted by the 2 recent commits
that I will update my test environment to be using,
in part by fetching and updating to a new head,
avoiding the "no dnode_next_offset change" status
that my existing test has.)
===
Ma
On Apr 15, 2023, at 15:49, Mark Millard wrote:
> . . .
>>
>>
>> (Mostly written as I progressed but some material later
>> inserted into/around previously written material.)
>>
>> Summary:
>>
>> As stands, it looks like reverting the d
On Apr 15, 2023, at 15:33, Mark Millard wrote:
> On Apr 15, 2023, at 13:30, Mateusz Guzik wrote:
>
>> On 4/15/23, FreeBSD User wrote:
>>> Am Sat, 15 Apr 2023 07:36:25 -0700
>>> Cy Schubert schrieb:
>>>
>>>> In message <20230415115452.089
gt; er writes:
>>>> Am Thu, 13 Apr 2023 22:18:04 -0700
>>>> Mark Millard schrieb:
>>>>
>>>>> On Apr 13, 2023, at 21:44, Charlie Li wrote:
>>>>>
>>>>>> Mark Millard wrote:
>>>>>>> FYI: in my ori
On Apr 15, 2023, at 11:07, Cy Schubert wrote:
> In message <5a47f62d-0e78-4c3e-84c0-45eeb03c7...@yahoo.com>, Mark Millard
> write
> s:
>> On Apr 15, 2023, at 07:36, Cy Schubert =
>> wrote:
>>
>>> In message <20230415115452.08911...@thor.inter
On Apr 15, 2023, at 07:36, Cy Schubert wrote:
> In message <20230415115452.08911...@thor.intern.walstatt.dynvpn.de>,
> FreeBSD Us
> er writes:
>> Am Thu, 13 Apr 2023 22:18:04 -0700
>> Mark Millard schrieb:
>>
>>> On Apr 13, 2023, at 21:44, Charl
On Apr 13, 2023, at 21:44, Charlie Li wrote:
> Mark Millard wrote:
>> FYI: in my original report for a context that has never had
>> block_cloning enabled, I reported BOTH missing files and
>> file content corruption in the poudriere-devel bulk build
>> testi
hub.com/openzfs/zfs/pull/14739/files
The files were missing from packages installed to be used
during a port's build. No other types of examples of missing
files happened. (But only 11 ports failed.)
===
Mark Millard
marklmi at yahoo.com
ll/14739/files;
Cy reported the same in:
https://lists.freebsd.org/archives/dev-commits-src-main/2023-April/014519.html
"The EXDEV patch is applied. Block_cloning is disabled."
===
Mark Millard
marklmi at yahoo.com
On Apr 12, 2023, at 23:52, Alexander Leidinger wrote:
> Quoting Mark Millard (from Wed, 12 Apr 2023 22:28:13
> -0700):
>
>> A fair number of errors are of the form: the build
>> installing a previously built package for use in the
>> builder but later the bui
[This just puts my prior reply's material into Cy's
adjusted resend of the original. The To/Cc should
be coomplete this time.]
On Apr 12, 2023, at 22:52, Cy Schubert wrote:
> In message , Mark Millard
> write
> s:
>> From: Charlie Li wrote on
>> Date: Wed, 12
From: Cy Schubert wrote on
Date: Thu, 13 Apr 2023 05:47:33 UTC :
> On Wed, 12 Apr 2023 22:28:13 -0700
> Mark Millard wrote:
>
> > From: Charlie Li wrote on
> > Date: Wed, 12 Apr 2023 20:11:16 UTC :
> >
> > > Charlie Li wrote:
> > > > Ma
No known data errors
# zpool scrub zroot
# zpool status
pool: zroot
state: ONLINE
scan: scrub repaired 0B in 00:16:25 with 0 errors on Wed Apr 12 22:15:39 2023
config:
NAMESTATE READ WRITE CKSUM
zroot ONLINE 0 0 0
da0p8 ONLINE 0 0 0
errors: No known data errors
===
Mark Millard
marklmi at yahoo.com
eed, it goes back to the enabled state.
END QUOTE
I've no clue if that is/will--be different for FreeBSD for some reason.
===
Mark Millard
marklmi at yahoo.com
QUOTE
I've no clue if that is/will--be different for FreeBSD for some reason.
===
Mark Millard
marklmi at yahoo.com
On Apr 7, 2023, at 16:29, Kyle Evans wrote:
> On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
>>
>> On 4/7/23, Mark Millard wrote:
>>> On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>>>
>>>> On 4/7/23, Mateusz Guzik wrote:
>>
ore
time to do the build, install, and test. (I'm keeping
my normal environments completely before the mess.)
FYI:
I have used the artifact build just after your pair of zfs
related updates to confirm the VFP problem is still in
place as of that point:
https://artifact.ci.freebsd.org/snapshot/main/5e2e3615d91f9c0c688987915ff5c8de23c22bde/arm64/aarch64/kernel.txz
(No artifact build was exactly at either of your commits.)
===
Mark Millard
marklmi at yahoo.com
tps://artifact.ci.freebsd.org/snapshot/main/b98fbf3781df16f7797b2bbeabf205dc7d4985ae/arm64/aarch64/kernel.txz
See also:
https://lists.freebsd.org/archives/freebsd-current/2023-April/003417.html
===
Mark Millard
marklmi at yahoo.com
Same as adding a new function, just
> everything automatically uses it.
>
> It’s true that __FreeBSD_version needs bumping if it hasn’t already
> been though.
===
Mark Millard
marklmi at yahoo.com
d for interoperation or to limit behavior which
has potential for causing harm (e.g., limiting
retransmisssions) For example, they must not be used
to try to impose a particular method on implementors
where the method is not required for interoperability"
(the "sparingly" criteria).
===
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
>
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 Feb 26, 2023, at 19:33, Warner Losh wrote:
> On Sat, Feb 25, 2023 at 10:03 AM Mark Millard wrote:
> Warner Losh wrote on
> Date: Sat, 25 Feb 2023 06:26:00 UTC :
>
> > The branch main has been updated by imp:
> >
> > URL:
> > htt
; +#define KBD_DELAY2 100
> +#endif
[Just reporting Ximalas's Discord note.]
So opt_kbd.h must be included before kbdreg.h in
order to avoid: macro redefined in opt_kbd.h ?
Should something force the right order?
> unsigned long kb_count; /* # of processed key strokes */
> u_char kb_lastact[NUM_KEYS/2];
> struct cdev *kb_dev;
===
Mark Millard
marklmi at yahoo.com
the wrong thread are reported.]
On Feb 16, 2023, at 15:31, Mark Millard wrote:
> I start this message as independent of the prior crash reports:
> this is not a crash report. It is a messed-up floating point
> data report instead.
>
> I have a simple C++ program that create
I start this message as independent of the prior crash reports:
this is not a crash report. It is a messed-up floating point
data report instead.
I have a simple C++ program that creates 2 independent threads,
each working on just local variables, where it appears that
after a while one thread
[Adding: Small c++ program that leads to a FreeBSD crash when I
force a core-dump (using control-\) during runs .]
On Feb 16, 2023, at 00:09, Mark Millard wrote:
> [A very simple program gets the failure under gdb
> or lldb of example breakpoints.]
>
> On Feb 15, 2023, at 20:29,
[A very simple program gets the failure under gdb
or lldb of example breakpoints.]
On Feb 15, 2023, at 20:29, Mark Millard wrote:
> On Feb 15, 2023, at 16:08, Mark Millard wrote:
>
>> Kornel Dulęba wrote on
>> Date: Sat, 04 Feb 2023 19:22:23 UTC :
>>
>>>
On Feb 15, 2023, at 16:08, Mark Millard wrote:
> Kornel Dulęba wrote on
> Date: Sat, 04 Feb 2023 19:22:23 UTC :
>
>> The branch main has been updated by kd:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=6926e2699ae55080f8604
such are strictly limited to the floating point
values that show up vs. if there might be wider
memory handling problems that result in the process.
===
Mark Millard
marklmi at yahoo.com
On Feb 14, 2023, at 23:08, Mateusz Guzik wrote:
> On 2/15/23, Mark Millard wrote:
>> Mateusz Guzik wrote on
>> Date: Sat, 04 Feb 2023 17:51:27 UTC :
>>
>>> The branch main has been updated by mjg:
>>>
>>>
jailid | -p pid | -t tid | -s setid | -x irq]
cpuset -g [-cir]
[-d domain | -j jailid | -p pid | -t tid | -s setid | -x irq]
cpuset -g --count -p pid
By contrast, in my stable/13 context, so, showing the old behavior:
# cpuset echo "-text"
-text
===
Mark Millard
marklmi at yahoo.com
mented for the names
that do not get the property.
===
Mark Millard
marklmi at yahoo.com
On Feb 13, 2023, at 16:47, Mark Millard wrote:
> On Feb 12, 2023, at 22:05, Mark Millard wrote:
>
>> [Just a fixed TO: address.]
>>
>>>> On Sun, Feb 12, 2023 at 07:58:07PM +, Antoine Brodin wrote:
>>>>> On Sun, Feb 12, 2023 at 11:13 AM Dmitr
On Feb 12, 2023, at 22:05, Mark Millard wrote:
> [Just a fixed TO: address.]
>
>>> On Sun, Feb 12, 2023 at 07:58:07PM +, Antoine Brodin wrote:
>>>> On Sun, Feb 12, 2023 at 11:13 AM Dmitry Chagin
>>>> wrote:
>>>>>
>>>&
D) have problems? :
=>> Building math/py-numpy
build started at Fri Feb 10 11:40:51 UTC 2023
port directory: /usr/ports/math/py-numpy
package name: py39-numpy-1.24.1,1
building for: FreeBSD main-amd64-default-baseline-job-04 14.0-CURRENT FreeBSD
14.0-CURRENT 1400079 amd64
maintained by: pyt...@freebsd.org
Makefile ident:
Poudriere version: 3.2.8-23-ga7f8d188
Host OSVERSION: 1400073
Jail OSVERSION: 1400079
Job Id: 04
!!! Jail is newer than host. (Jail: 1400079, Host: 1400073) !!!
!!! This is not supported. !!!
!!! Host kernel must be same or newer than jail. !!!
!!! Expect build failures. !!!
>>>>>> https://pkg-status.freebsd.org/gohan02/data/13stable-amd64-quarterly-baseline/841610d9bfc6/logs/errors/py39-numpy-1.23.5_1,1.log
Similarly, can a 1400073 [2022-10-17..2022-12-09] HOST kernel running a
13.2-PRERELEASE 1301511 [2023-01-10..2023-02-10] jail that is using new
KBI material not in the older kernel (CPU_WHICH_TIDPID) have problems? :
=>> Building math/py-numpy
build started at Fri Feb 10 10:36:27 UTC 2023
port directory: /usr/ports/math/py-numpy
package name: py39-numpy-1.23.5_1,1
building for: FreeBSD 13stable-amd64-quarterly-baseline-job-01 13.2-PRERELEASE
FreeBSD 13.2-PRERELEASE 1301511 amd64
maintained by: pyt...@freebsd.org
Makefile ident:
Poudriere version: 3.2.8-23-ga7f8d188
Host OSVERSION: 1400073
Jail OSVERSION: 1301511
(Looks to me like CPU_WHICH_TIDPID use for 13.* has to
require 13.2+ .)
===
Mark Millard
marklmi at yahoo.com
[2023-02-08..2023-02-10] jail that is using new KBI
material not in the older kernel (CPU_WHICH_TIDPID) have problems? :
=>> Building math/py-numpy
build started at Fri Feb 10 11:40:51 UTC 2023
port directory: /usr/ports/math/py-numpy
package name: py39-numpy-1.24.1,1
building fo
. . .
. . .
Tue, 13 Dec 2022
. . .
• git: 8d0ed56646f0 - main - RELNOTES: Add mention of growfs addition of
swap partition. Mike Karels
. . .
. . .
Sun, 25 Dec 2022
. . .
• RE: git: d670a8f7c596 - main - growfs_fstab: add new /etc/rc.d script to
add swap to fstab Mark Mi
On Dec 26, 2022, at 06:57, Mike Karels wrote:
>
> On 25 Dec 2022, at 16:41, Mark Millard wrote:
>
>> Mike Karels wrote on
>> Date: Sat, 10 Dec 2022 19:41:14 UTC :
>>
>>> The branch main has been updated by karels:
>>>
>>
On Dec 25, 2022, at 14:41, Mark Millard wrote:
> Mike Karels wrote on
> Date: Sat, 10 Dec 2022 19:41:14 UTC :
>
>> The branch main has been updated by karels:
>>
>> URL:
>> https://cgit.FreeBSD.org/src/commit/?id=d670a8f7c596fd3878236
, 74908 blocks, 0.0%
fragmentation)
/etc/rc.d/growfs: 203: Syntax error: "(" unexpected (expecting "}")
Looks to be the ' in "Don't" in a supposed #comment that that instead matches a
prior awk use of ' unintentionally. Later in the line is: "(decimal)" that
supplies the "(" reported.
===
Mark Millard
marklmi at yahoo.com
On Dec 12, 2022, at 13:49, Mark Millard wrote:
> On Dec 12, 2022, at 11:51, Mark Millard wrote:
>
>> Piotr Kubaj wrote on
>> Date: Mon, 12 Dec 2022 14:48:57 UTC :
>>
>>> Reverted. Sorry for the breakage. I think will return with the next
>>> version
1 - 100 of 188 matches
Mail list logo
