.
. .
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>>>
>>&
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
specific cache/nocache option.
END QUOTE
That is evidence of the vintage of materials.
===
Mark Millard
marklmi at yahoo.com
[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
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
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
eeBSD-13.0-RELEASE-amd64-disc1.iso
(so: just adding a "-" before xvf).
===
Mark Millard
marklmi at yahoo.com
On 2022-Mar-24, at 04:05, Daniel Ebdrup Jensen wrote:
> On Thu, Mar 24, 2022 at 12:53:19AM -0700, Mark Millard wrote:
>> Not objecting, just noting that for:
>>
>> -.Dl tar xvf -C release-media FreeBSD-13.0-RELEASE-amd64-disc1.iso
>> +.Dl tar -C release-media -xvf
at handle_el1h_sync+0x10
--- exception, esr 0x9607
efirt_modevents() at efirt_modevents+0x84
module_register_init() at module_register_init+0xc4
mi_startup() at mi_startup+0x130
virtdone() at virtdone+0x7c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at kdb_enter+0x44: undefined f902011f
===
Mark Millard
marklmi at yahoo.com
s producing just one overall Boolean for if the
count of non-matching Booleans in an XOR would be
positive (TRUE) vs. zero (FALSE).
Food for thought.
===
Mark Millard
marklmi at yahoo.com
port :
https://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
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
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:
>>>>
OTE
I've no clue if that is/will--be different for FreeBSD for some reason.
===
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
ONLINE 0 0 0
errors: 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
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
[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
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
s/pull/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
//github.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
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
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 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
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 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
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
sting? 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.)
=
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.)
>>>
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 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 b
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:
>>
>>
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'
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
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
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
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:
>>>>
>>>&
_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
00079 [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
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 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
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:
>>>>>
>>>&
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
mented for the names
that do not get the property.
===
Mark Millard
marklmi at yahoo.com
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
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:
>>>
>>>
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 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
[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 :
>>
>>> Th
[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,
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 end
from 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 c
2
> +#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
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
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
>
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
status.
> 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
LIMIT_ON)) == 0);
> +#endif
> }
> #endif
>
It looks like the above:
+#ifdef SWAP_RESERVE_FORCE_ON
+ return ((vm_overcommit & (SWAP_RESERVE_FORCE_ON |
+ SWAP_RESERVE_RLIMIT_ON)) == 0);
+#endif
means that there is a path through the routine that does not
execute a return . . . ; statment when
!defined(SWAP_RESERVE_FORCE_ON) .
(Otherwise the #ifdef and #endif would not be necessary.)
===
Mark Millard
marklmi at yahoo.com
ev/${mddev}s1
> . . .
> + echo "/dev/msdosfs/EFI /boot/efi msdosfs
> rw,noatime 0 0" \
> . . .
Does the "-L efi" vs. "/dev/msdosfs/EFI" case mismatch for
efi vs. EFI matter?
===
Mark Millard
marklmi at yahoo.com
: generic.
Setting up harvesting:
[CALLOUT],[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
There might be more required context to your report than has
been reported.
===
Mark Millard
marklmi at yahoo.com
On 2022-Sep-24, at 00:16, Mark Millard wrote:
> John Baldwin wrote on
> Date: Fri, 23 Sep 2022 21:29:03 UTC :
>
>> On 8/26/22 9:18 PM, Warner Losh wrote:
>>> The branch main has been updated by imp:
>>>
>>> URL:
&
an build successfully.
For reference (long output line split for readability):
# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #63
main-n258610-ba7319e9091b-dirty: Fri Oct 14 14:29:14 PDT 2022
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400072 1400072
/usr/obj/DESTDIRs/main-CA7-poud has the same FreeBSD vintage,
but for armv7. (poudriere is still running.)
===
Mark Millard
marklmi at yahoo.com
t.
Long ago I helped someone work out having an alternate
kernel to boot for such armv6 chroot/jail use, not that I
remember any detail at this point. The detail should be in
my E-mail archive and/or in comments for a bugzilla
submittal that the person had used to report the lack of
armv6 chroot/jail support.)
===
Mark Millard
marklmi at yahoo.com
gt; newly installed or provisioned VM or cloud instance.
>
> Reviewed by: markj
> Sponsored by: The FreeBSD Foundation
> Differential Revision: https://reviews.freebsd.org/D37283
===
Mark Millard
marklmi at yahoo.com
be the best of examples for the general
question.)
Does each RELEASE and release-update get its own,
documented zpool feature list for its loaders?
(There might be a question for a zfs vs. zpool
feature distinction as well?)
> "org.openzfs:blake3",
> NULL
> };
The overall list definitely goes beyond what is
listed in:
/usr/share/zfs/compatibility.d/openzfs-2.1-freebsd
> Any feature not on this list will cause the boot loader to reject the pool.
>
> Whether or not it should do that by default, always, or never is an open
> question. I've thought there should be a 'shoot footing' override that isn't
> there today.
===
Mark Millard
marklmi at yahoo.com
On Nov 7, 2022, at 16:34, Mark Millard wrote:
> Warner Losh wrote on
> Date: Mon, 07 Nov 2022 21:23:11 UTC :
>
>> On Mon, Nov 7, 2022 at 4:15 AM Alexander Leidinger
>> wrote:
>>
>>>
>> . . .
>>>
>>> And this brings me to a second
in the
>same way as growfs and zpoolreguid rc scripts. I've been thinking
>renaming these to firstboot_* as others provided by
>sysutils/firstboot-* from ports, but I think it's also fine to keep
>the consistency for now.
>
> Ah! I completely missed the &#
eport that, I have updated rc.conf a to add "the
> NONE" value.
Also, from the commit:
QUOTE
-sendmail_enable="NONE" # Run the sendmail inbound daemon (YES/NO).
+sendmail_enable="NONE" # Run the sendmail inbound daemon (YES/NO/NONE).
END QUOTE
My guess is Matteo was
unsigned long long "expected
argument type"
From what I can tell, FreeBSD tends to avoid the "Format macro
constants" (not listed here) for trying to have system independent
notation and tends to use intmax_t/uintmax_t with %j . This
might (eventually) survive better than use of %j with int64_t and
u_int64_t . Technically intmax_t/uintmax_t could each be 128 bits
or some such, even now.
I'll also note that u_int64_t is not from C99. uint64_t is from
C99. I've no clue if that is important for this code. int64_t is
from C99.
===
Mark Millard
marklmi at yahoo.com
esn't recognize
libc++ headers being an implementation of the standard"
issue?
> GCC 12 also warns about clang-specific pragmas in .
>
> Disabling these warnings globally for all C++ code is not ideal, but
> is a better option than patching libc++ headers to ignore these
> warnings.
===
Mark Millard
marklmi at yahoo.com
.
You might need to ask folks with systems that you do not have examples
of to do some testing of non-explicit native builds.
===
Mark Millard
marklmi at yahoo.com
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 of this patch and this time I'll make sure to run make universe
>&
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
frags, 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 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
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:
>>>
>>
ing root Mike Karels
. . .
. . .
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 s
swap space"? Would either
one show the swap space as (nearly?) all used in, say, top?
Or might one of them still end up looking like a misnomer
from just a top (or whatever) display?
===
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
MILY=rpi
+U_BOOT_SLAVE_PORTREVISION_2021.04= 1
+
DEPENDS=
${LOCALBASE}/share/rpi-firmware/bootcode.bin:sysutils/rpi-firmware
CONFIG_FRAGMENT= ${.CURDIR}/files/rpi2_fragment
===
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
k/bsd.suffixes.mk
/usr/home/root/src.configs/make.conf /usr/main-src/share/mk/local.sys.mk
/usr/main-src/share/mk/src.sys.mk /dev/null
/usr/main-src/usr.sbin/blacklistd/Makefile /usr/main-src/share/mk/bsd.prog.mk
/usr/main-src/share/mk/bsd.init.mk /usr/main-src/share/mk/bsd.opts.mk
/usr/main-src/share/mk/bsd.cpu.mk /usr/main-src/share/mk/local.init.mk
/usr/main-src/share/mk/src.init.mk
/usr/main-src/usr.sbin/blacklistd/../Makefile.inc
/usr/main-src/share/mk/bsd.own.mk /usr/main-src/share/mk/bsd.compiler.mk
/usr/main-src/share/mk/bsd.endian.mk /usr/main-src/share/mk/bsd.linker.mk
/usr/main-src/share/mk/bsd.sanitizer.mk /usr/main-src/share/mk/bsd.libnames.mk
/usr/main-src/share/mk/src.libnames.mk /usr/main-src/share/mk/src.opts.mk
/usr/main-src/share/mk/bsd.nls.mk /usr/main-src/share/mk/bsd.confs.mk
/usr/main-src/share/mk/bsd.files.mk /usr/main-src/share/mk/bsd.dirs.mk
/usr/main-src/share/mk/bsd.incs.mk /usr/main-src/share/mk/bsd.links.mk
/usr/main-src/share/mk/bsd.man.mk /usr/main-src/share/mk/bsd.dep.mk
/usr/main-src/share/mk/bsd.clang-analyze.mk /usr/main-src/share/mk/bsd.obj.mk
/usr/main-src/share/mk/bsd.subdir.mk /usr/main-src/share/mk/bsd.sys.mk'
.PATH='. /usr/main-src/usr.sbin/blacklistd /usr/main-src/contrib/blacklist/bin
/usr/main-src/contrib/blacklist/port'
1 error
===
Mark Millard
marklmi at yahoo.com
On 2022-May-14, at 20:32, Mark Millard wrote:
> After building, installing, and booting based on 0817c8dc2a48 I
> attempted a self updating buildworld buildkernel, both non-debug
> debug (via a script). The non-debug build got the following but
> the debug b
On 2022-May-14, at 20:40, Mark Millard wrote:
> On 2022-May-14, at 20:32, Mark Millard wrote:
>
>> After building, installing, and booting based on 0817c8dc2a48 I
>> attempted a self updating buildworld buildkernel, both non-debug
>> debug (via a script). The non-debug
oryMap in a loop.
Reviewed by:imp, tsoome, kevans
Differential Revision:
https://reviews.freebsd.org/D19341
Notes
Notes:
svn path=/head/; revision=344839
END QUOTE
So, I end up with the question:
MFC to avoid depending on details of various toolchains'
handling of the Undefined Behav
1 - 100 of 238 matches
Mail list logo
