On 2021-Jan-22, at 01:45, Mark Millard wrote:
> Given an already built, installed and booted system version, I've
> noted a big difference for META_MODE in 2 rebuild contexts (no
> source updates involved):
>
> *) Prior buildworld buildkernel, installkernel, installworl
s to wait for free pages before retrying
the page fault handler
# sysctl -d vm.pfault_oom_attempts
vm.pfault_oom_attempts: Number of page allocation attempts in page fault
handler before it triggers OOM handling
I hope that helps.
===
Mark Millard
marklmi at yahoo.co
ndling of the "worker"
related context for the type of kernel call seems to be
what is at issue, likely no matter what process happens
to make the same basic kernel call that ends up with
"worker" in the context.
===
Mark Millard
marklmi at yahoo.com
one:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==14384==ABORTING
Files left in work directory after failure: mntpt, mounterr
===
Mark Millard
marklmi at yahoo.com
common.
usr.bin/sed/process.c:715:18 is more limited: just sed use.
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-7, at 03:49, Mark Millard wrote:
> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
On 2022-Jan-7, at 05:08, Mark Millard wrote:
> On 2022-Jan-7, at 03:49, Mark Millard wrote:
>
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use a
On 2022-Jan-7, at 04:31, Stefan Esser wrote:
> Am 07.01.22 um 12:49 schrieb Mark Millard:
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use and have
On 2022-Jan-7, at 03:39, Mark Millard wrote:
> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
> after finding what to control to allow the build, I installed
> it in a directory tree for chroot use and have
> "kyua test -k /usr/tests/Kyuafile" running.
>
On 2022-Jan-9, at 13:47, Mark Millard wrote:
> On 2022-Jan-7, at 03:39, Mark Millard wrote:
>
>> Having done a buildworld with both WITH_ASAN= and WITH_UBSAN=
>> after finding what to control to allow the build, I installed
>> it in a directory tree for chroot use a
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/main-src/contrib/traceroute/ifaddrlist.c:118:13 in
===
Mark Millard
marklmi at yahoo.com
zero
offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/main-src/lib/libc/stdlib/qsort.c:114:44 in
whatis: nothing appropriate
This seems to be only for the not-found case.
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-11, at 05:19, Stefan Esser wrote:
> Am 11.01.22 um 08:40 schrieb Mark Millard:
>> # whatis dog
>> /usr/main-src/lib/libc/stdlib/qsort.c:114:23: runtime error: applying
>> non-zero offset 48 to null pointer
>> SUMMARY: UndefinedBehaviorSanitizer: undefined
if (ref != NULL && p[i + j] != ref[i + j])
. . .
where ref points to the space for "pack.err" and l was
given a copy of the value of n in the previously shown
code.
The i + j < l constraint need not avoid the code doing
ref[i + j] in a way that reaches outside the space for
"pack.err" --because of the supplied value of n (a.k.a. l)
not being sufficient to respect the space for "pack.err".
===
Mark Millard
marklmi at yahoo.com
traint
violation" for qsort_s and to return a non-zero value --or to
not do so and return zero.
As qsort does not return a value, any rejection of such a
combination for qsort would be in a more drastic form, making
such an unlikely choice. (qsort is not documented to assign
errno either.)
So I would expect qsort to avoid involving undefined behavior
when nmemb==0 && (base==NULL||compar==NULL) but to not reject
the condition. I do not take doing a well-defined "no-op" as
a rejection for my wording here.
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-12, at 01:54, Mark Millard wrote:
> For the below it appears that the report from UBSAN is accurate.
>
> ==85511==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x010753ca at pc 0x01139bda bp 0x7fffc2b0 sp 0x7fffc2a8
> READ of size 1 at
d or store with a size
in Bytes.
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-12, at 14:59, Mark Millard wrote:
> # kyua report --verbose | grep _noabort
>#7 0x227 in __asan_report_load4_noabort
> /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_rtl.cpp:122:1
>#7 0x63a in __asan_report_store8_noabort
> /usr/main-s
046 1400046
===
Mark Millard
marklmi at yahoo.com
ts of ports from that /usr/local/ tree
get "Shared object not found" messages for one or more
/usr/local/lib/*.so* files (matching up with ldd reports
of not found).
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-14, at 01:50, Mark Millard wrote:
> # zpool status -x
> all pools are healthy
> /usr/main-src/sys/contrib/openzfs/module/nvpair/nvpair.c:3129:49: runtime
> error: applying non-zero offset 4 to null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
itself not have detect_container_overflow
disabled.
lldb suffers the libc++ Container overflow problems via its
libc++ use and fails to operate without the:
ASAN_OPTIONS=detect_container_overflow=0
===
Mark Millard
marklmi at yahoo.com
> On 2022-Jan-14, at 04:44, Mark Millard wrote:
>
> Looks like libc++ does the following sort of thing
> (from lldb list):
>
> . . .
> 1635
> 1636template
> 1637template
> 1638void
> 1639#ifndef _LIB
ion=) at log.c:272:37
269 key.data = &lcur;
270 key.size = sizeof(recno_t);
271 data.data = ep->l_lp;
-> 272 data.size = len * sizeof(CHAR_T) + CHAR_T_OFFSET;
273 if (ep->log->put(ep->log, &key, &data, 0) == -1)
274 LOG_ERR;
275
(lldb) thread info -s
thread #1: tid = 208533, 0x012c8ef0 view`::__ubsan_on_report() at
ubsan_monitor.cpp:39, name = 'view', stop reason = Null pointer use
{
"col": 37,
"description": "null-pointer-use",
"filename": "/usr/main-src/contrib/nvi/common/log.c",
"instrumentation_class": "UndefinedBehaviorSanitizer",
"line": 272,
"memory_address": 0,
"summary": "Member access within null pointer of type 'log_t'",
"tid": 208533,
"trace": []
}
===
Mark Millard
marklmi at yahoo.com
-r--r-- 1 root wheel149 Jan 14 14:14 sigaltstack_get.c
-rw-r--r-- 1 root wheel 50 Jul 16 2021 trivial.cpp
Unfortunately, running under lldb did not stop for the "unexpected format
specifier in printf interceptor" notice, so I do not have a backtrace for
this.
===
Mark
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
f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==87961==ABORTING
===
Mark Millard
marklmi at yahoo.com
01 if (jp >= jobtab + njobs) { /* no
running procs */
602 return 0;
603 }
604 if (jp->used && jp->state == 0)
(lldb) c
Process 66125 resuming
/usr/main-src/bin/sh/jobs.c:601:22: runtime error: applying zero offset to null
pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/usr/main-src/bin/sh/jobs.c:601:22 in
Process 66125 exited with status = 0 (0x)
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-15, at 15:25, Mark Millard wrote:
> ASAN is documented to not be able to deal reliably with vfork use
> (inaccurate results, result mixing interpretations of the old
> and new contexts, and so on). [There may be other routines
> sufficiently analogous to vfork to have th
ENT FreeBSD 14.0-CURRENT #30
main-n252475-e76c0108990b-dirty: Sat Jan 15 21:18:14 PST 2022
root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
amd64 amd64 1400047 1400047
# ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
branch: main
merge-base: e76c0108990b52a25f548cba4c0f1b8db59c6b8b
merge-base: CommitDate: 2022-01-16 00:32:36 +
e76c0108990b (HEAD -> main, freebsd/main, freebsd/HEAD) Fix inverse sleep logic
in buf_daemon().
n252475 (--first-parent --count for merge-base)
===
Mark Millard
marklmi at yahoo.com
On 2022-Jan-18, at 19:18, Mark Millard wrote:
> It will probably be some time before I get to trying to have a
> simpler context, but here is some information, including related
> backtraces:
>
> . . .
> "/usr/bin/ld.lld" --eh-frame-hdr -dynamic-linker /libexec/ld-e
char **rve)
51 {
. . .
65 union IEEEl2bits u;
. . .
69 u.e = *ld;
. . .
79 be = u.bits.exp - (LDBL_MAX_EXP - 1) - (LDBL_MANT_DIG - 1);
. . .
106 ret = gdtoa(&fpi, be, vbits, &kind, mode, ndigits, decpt, rve);
. . .
gdtoa then does (various line numbers & some white space omitted):
. . .
int bbits, . . .
. . .
b = bitstob(bits, nbits = fpi->nbits, &bbits);
be0 = be;
if ( (i = trailz(b)) !=0) {
rshift(b, i);
be += i;
bbits -= i;
}
. . .
-> 254 word0(&d) += (be + bbits - 1) << Exp_shift;
So, by the UBSAN report: be + bbits - 1 == -18
If be==-81, then bbits==64 at the time & place.
===
Mark Millard
marklmi at yahoo.com
e directory
names prefixed with text that would sort by a
date/time estimate when sorted by name. (Only using
the commit id/hash completely randomizes the naming.)
===
Mark Millard
marklmi at yahoo.com
ernel: Use `gpart commit mmcsd0s2` to save changes
> or `gpart undo mmcsd0s2` to revert them.
> Jan 27 10:38:48 generic kernel: lo0: link state changed to UP
Later material . . .
On 2022-Feb-2, at 01:40, Jesper Schmitz Mouridsen wrote:
>
> On 31.01.2022 22.20, Mark Millard
Requires W+X mappings
la48amd64: Limit user VA to 48bit
noaslrstkgapDisable ASLR stack gap
===
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
ic earlier in the week,
apparently not reported to the lists at the time.)
===
Mark Millard
marklmi at yahoo.com
kernel (912df91) still panics. See below.
>
> Do you have time to look into this? What can I provide in information to help?
>
> Regards,
> Ronald.
>
> Van: Ronald Klop
> Datum: maandag, 7 maart 2022 11:38
> Aan: Mark Millard
> CC: bob prohaska , freebsd-current
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-7, at 12:54, Ronald Klop wrote:
> Van: Mark Johnston
> Datum: maandag, 7 maart 2022 16:13
> Aan: Ronald Klop
> CC: bob prohaska , Mark Millard ,
> freebsd-...@freebsd.org, freebsd-current
> Onderwerp: Re: panic: data abort in critical section or under mutex
/freebsd-current/2022-April/001764.html
reports:
My problem machine is definately NVME based storage.
I can not tell about the other context.
===
Mark Millard
marklmi at yahoo.com
Allow zfs send to exclude datasets
#13190 module: zfs: zio_inject: zio_match_handler: don't << -1
#13219 FreeBSD: add missing replay check to an assert in zfs_xvattr_set
#13220 module: freebsd: avoid a taking a destroyed lock in zfs_zevent bits
#13221 Fix ACL c
On 2022-Apr-12, at 18:31, Mark Millard wrote:
> Most recent good of good->failed update step reported:
> (extracted from dev-commits-src-main but shown in increasing-time order)
>
> Monday, 28 March 2022
> • git: 1b3af110bcd5 - main - uudecode: add missing test files to
em is too
late.) (I just picked top as a way to get a bunch of
the information all together automatically.)
These sorts of things might help folks help you.
===
Mark Millard
marklmi at yahoo.com
On 2022-Apr-22, at 16:42, Pete Wright wrote:
> On 4/21/22 21:18, Mark Millard wrote:
>>
>> Messages in the console out would be appropriate
>> to report. Messages might also be available via
>> the following at appropriate times:
>
> that is what is frustrati
On 2022-Apr-23, at 10:26, Pete Wright wrote:
> On 4/22/22 18:46, Mark Millard wrote:
>> On 2022-Apr-22, at 16:42, Pete Wright wrote:
>>
>>> On 4/21/22 21:18, Mark Millard wrote:
>>>> Messages in the console out would be appropriate
>>>> to repor
sd.cpu.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/sys/conf/kern.opts.mk
/usr/main-src/sys/conf/kern.post.mk /usr/main-src/sys/conf/kern.mk'
.PATH='.
/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72'
1 error
===
Mark Millard
marklmi at yahoo.com
IGNORE.
On 2022-Apr-28, at 20:33, Mark Millard wrote:
> In attempting to update from main-n253904-4d1ba6febfa7 based to
> main-n255108-9fb40baf6043 based, targeting aarch64, the following
> code from sys/arm/broadcom/bcm2835/bcm2838_xhci.c was rejected:
>
> static int
&g
#x27;ll have to gather data and post it online for anyone who would be
> interested in seeing this in graph form. although, frankly i feel like it's
> a browser problem which i can work around by running them in jails with
> resource limits in place via rctl.
===
Mark Millard
marklmi at yahoo.com
105.html
[2]
https://lists.freebsd.org/archives/freebsd-arch/2021-June/16.html
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
END QUOTE
===
Mark Millard
marklmi at yahoo.com
On 2022-Apr-29, at 12:38, Mark Millard wrote:
> https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
> says the following (later), but first I quote the part tbat dirves the
> interpretation:
>
> QUOTE
> Clang's -pg support and mcount() remai
On 2022-Apr-29, at 13:41, Pete Wright wrote:
>
> On 4/29/22 11:38, Mark Millard wrote:
>> On 2022-Apr-29, at 11:08, Pete Wright wrote:
>>
>>> On 4/23/22 19:20, Pete Wright wrote:
>>>>> The developers handbook has a section debugging deadlocks that he
On 2022-Apr-29, at 13:12, Steve Kargl wrote:
> On Fri, Apr 29, 2022 at 12:51:12PM -0700, Mark Millard wrote:
>> On 2022-Apr-29, at 12:38, Mark Millard wrote:
>>
>>> https://cgit.freebsd.org/src/commit/?id=175841285e289edebb6603da39f02549521ce950
>>> says t
> > vm.pageout_oom_seq="4096"
> > vm.pfault_oom_attempts="120"
> > vm.pfault_oom_wait="20"
> >
> > Mark Millard made me aware of these parameters over the list.
And going back farther: Mark Johnston made us both
aware of vm.pageout_o
k
/usr/home/root/src.configs/src.conf.CA72-dbg-clang.aarch64-host
/usr/main-src/share/mk/bsd.mkopt.mk /usr/main-src/share/mk/src.sys.obj.mk
/usr/main-src/share/mk/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
rescue.mk'
.PATH='.
/usr/obj/BUILDs/main-CA72-dbg-clang/usr/main-src/arm64.aarch64/rescue/rescue'
1 error
===
Mark Millard
marklmi at yahoo.com
[Looks to be some form of build race.]
On 2022-May-3, at 15:38, Mark Millard wrote:
> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src/
> branch: main
> merge-base: 9a3583bfbd1740a158b3916432286190e0f2bf60
> merge-base: CommitDate: 2022-05-03 19:12:42 +
> 9a3583bfbd1
On 2022-Apr-29, at 13:57, Mark Millard wrote:
> On 2022-Apr-29, at 13:41, Pete Wright wrote:
>>
>>> . . .
>>
>> d'oh - went out for lunch and workstation locked up. i *knew* i shouldn't
>> have said anything lol.
>
> Any interesting
On 2022-May-10, at 08:47, Jan Mikkelsen wrote:
> On 10 May 2022, at 10:01, Mark Millard wrote:
>>
>> On 2022-Apr-29, at 13:57, Mark Millard wrote:
>>
>>> On 2022-Apr-29, at 13:41, Pete Wright wrote:
>>>>
>>>>> . . .
>>>>
On 2022-May-10, at 11:49, Mark Millard wrote:
> On 2022-May-10, at 08:47, Jan Mikkelsen wrote:
>
>> On 10 May 2022, at 10:01, Mark Millard wrote:
>>>
>>> On 2022-Apr-29, at 13:57, Mark Millard wrote:
>>>
>>&g
On 2022-May-10, at 17:49, Mark Millard wrote:
> On 2022-May-10, at 11:49, Mark Millard wrote:
>
>> On 2022-May-10, at 08:47, Jan Mikkelsen wrote:
>>
>>> On 10 May 2022, at 10:01, Mark Millard wrote:
>>>>
>>>> On 2022-Apr-29, at 13:57, Mar
On 2022-May-10, at 20:31, Mark Millard wrote:
> On 2022-May-10, at 17:49, Mark Millard wrote:
>
>> On 2022-May-10, at 11:49, Mark Millard wrote:
>>
>>> On 2022-May-10, at 08:47, Jan Mikkelsen wrote:
>>>
>>>> On 10 May 2022, at 10:01, Mark Mi
Pete Wright wrote on
Date: Fri, 13 May 2022 13:43:11 -0700 :
> On 5/11/22 12:52, Mark Millard wrote:
> >
> >
> > Relative to avoiding hang-ups, so far it seems that
> > use of vm.swap_enabled=0 with vm.swap_idle_enabled=0
> > makes hang-ups less likely/le
As
I remember, that agrees with the documentation for them.
===
Mark Millard
marklmi at yahoo.com
On 2022-May-29, at 10:07, Pete Wright wrote:
> On 5/14/22 01:09, Mark Millard wrote:
>>
>> One of the points is to see if I get any evidence of
>> vm.swap_enabled=0 with vm.swap_idle_enabled=0 ending up
>> contributing to any problems in my normal usage. So far: no.
&
but:
http://ampere3.nyi.freebsd.org/#latest_builds
and:
http://ampere3.nyi.freebsd.org/build.html?mastername=130arm64-default&build=b44e82e7d313
shows a currently active build (but with only 2 ports remaining).
===
Mark Millard
marklmi at yahoo.com
On 2022-Jun-13, at 22:14, Philip Paeps wrote:
> On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
>> ampere3's activity is not showing up on the page:
>> https://pkg-status.freebsd.org/?all=1&type=package
>>
>> but:
>>
>> http://ampere
On 2022-Jun-13, at 22:44, Mark Millard wrote:
> On 2022-Jun-13, at 22:14, Philip Paeps wrote:
>
>> On 2022-06-13 00:16:55 (+0800), Mark Millard wrote:
>>> ampere3's activity is not showing up on the page:
>>> https://pkg-status.freebsd.org/?all=1&t
n 2022
• git: 2049cc321815 - main - Correctly update fs_dsize in growfs(8)
Kirk McKusick
so there still is some form of error in the growfs
activity.
At least there is now a known, specific way to produce the
problem
===
Mark Millard
marklmi at yahoo.com
On 2022-Jul-5, at 15:59, Mark Millard wrote:
> I did a:
>
> # dd
> if=FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img
> of=/dev/da0 bs=1m conv=sync status=progress
> 3113222144 bytes (3113 MB, 2969 MiB) transferred 13.064s, 238 MB/s
> 3072+0 record
On 2022-Jul-5, at 18:19, Mark Millard wrote:
> On 2022-Jul-5, at 15:59, Mark Millard wrote:
>
>> I did a:
>>
>> # dd
>> if=FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img
>> of=/dev/da0 bs=1m conv=sync status=progress
&g
first):
cmake/config-ix.cmake:60 (check_include_file)
CMakeLists.txt:732 (include)
and so on.
But those are after the Ninja report and might be consequences
of whatever is going on for the Ninja reports.
===
Mark Millard
marklmi at yahoo.com
freebsd-src/tree/lx2160acex7-exp (branch is
> lx2160acex7-exp!)
>
> Any ideas or places to check would be really helpful.
===
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
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
kern_statat+0xa4
#10 0x005f976c at sys_fstatat+0x2c
#11 0x008c00c4 at do_el0_sync+0x634
#12 0x0089a1ac at handle_el0_sync+0x4c
^C
seemed to have been unable to make progress during the "rewriters"
activity.
===
Mark Millard
marklmi at yahoo.com
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
.
The lack of a device tree is the normal case for ACPI based booting.
I do find this part of the messaging for an ACPI-based boot
misleading.
===
Mark Millard
marklmi at yahoo.com
GiByte RAM system did not
reproduce the problem, despite being well below the
512 GiBytes for the files. (32 FreeBSD cpus.)
This context had Optane media via PCIe, not via USB3.
This AMD 7950X3D context is far faster generally.
===
Mark Millard
marklmi at yahoo.com
aded or otherwise mostly rebuilt. There can
be RAM+SWAP configuration tradeoffs.
Overall: more context reporting and information from the
likes of top might help folks formulate specific
suggestions. At this point I've no clue if the above
applies to your context or not.
===
Mark Millard
marklmi at yahoo.com
On Nov 8, 2024, at 04:49, Michal Meloun wrote:
> On 08.11.2024 4:15, Mark Millard wrote:
>> [I narrowed the artifact kernel range for the change in the type of
>> failure that happens.]
>> On Nov 7, 2024, at 17:43, Mark Millard wrote:
>>> [The change to LLVM 19
?
What version of clang/clang++ is the new system to be using?
It may be that LLVM 18 needs to build the bootstrap materials
for LLVM 19, which in turn do the normal build from that
partial context. You are not explicit about the upgrade
context that you are in or what toolchain that you are using.
===
Mark Millard
marklmi at yahoo.com
-src/*/lib/googletest/tests/*/*.o
END QUOTE
It is possible that my removes were not the minimal set needed. But every one
of those directories had an old, failing *.o file. No others did.
Note: My naming and such for "/usr/obj/BUILDs/main-*-*dbg-clang/usr/main-src/"
are not the defaults so take that part of the example text as just suggestive.
===
Mark Millard
marklmi at yahoo.com
operational for running
FreeBSD. Its output stops after the mask line for the efi
buffer reporting. (Hyper-V indicates 12% cpu usage. 1 core
of 8 busy?) I was looking for any extra instructions that
I'd not previously found. (I had remembered that eficom
activity had happened --but not all the detail.)
===
Mark Millard
marklmi at yahoo.com
2024-Oct-09
(I'm ignoring *-man-* and *-dev-* but still showing dates.)
Are the 2024-Oct-11 .pkg files as expected for an update that
involved LLVM18 -> LLVM19 ?
===
Mark Millard
marklmi at yahoo.com
there is no difference here if it's either access or
* R/W emulation abort, or if it's some other abort.
*/
PMAP_LOCK(pmap);
That "PMAP_LOCK(pmap);" line is line 6455 of sys/arm/arm/pmap-v6.c .
FYI: Running the prior kernel.GENERIC-NODEBUG/ ( called
kernel.GENERIC-NODEBUG.good/ ) continues to operate
normally. I do not have the older PkgBase kernel/ around
to try, unfortunately.
===
Mark Millard
marklmi at yahoo.com
[I narrowed the artifact kernel range for the change in the type of
failure that happens.]
On Nov 7, 2024, at 17:43, Mark Millard wrote:
> [The change to LLVM 19 is what leads to the Alignment
> Fault' on write failure. Details later below.]
>
> On Nov 7, 2024, at 01:42, Ma
[The change to LLVM 19 is what leads to the Alignment
Fault' on write failure. Details later below.]
On Nov 7, 2024, at 01:42, Mark Millard wrote:
> Note: Unfortunately, the panics here are too early for a
> dump device to be available.
>
> Context started PkgBase upgrade f
analogous and get the libsass.so
<http://libsass.so/>.1.0.0
.got.plt corruption that I've reported on the lists anyway.
===
Mark Millard
marklmi at yahoo.com
On Nov 25, 2024, at 13:27, Guido Falsi wrote:
> On 25/11/24 22:18, Dag-Erling Smørgrav wrote:
>> Mark Millard writes:
>>> Guido Falsi writes:
>>>> On 25/11/24 09:17, Dag-Erling Smørgrav wrote:
>>>>> Dimitry Andric writes:
>>>>>>
by appending variable sized
records to a file. There are no seeks or overwrites.": Am
I to interpret that as:
) New file with just sequential writes that are variable
sized?
vs.
) Appending to a pre-existing file? (That would involve
seeking and typically merging new data with old data
from the original last-page-with-data and writing that
update back out.)
===
Mark Millard
marklmi at yahoo.com
ompressed, 3.39:1 Ratio
> Swap: 32G Total, 32G Free
>
> THR USERNAME THR PRI NICE SIZE RES STATE C TIME CPU
> COMMAND
> 13 root 40 187 ki31 0B 640K RUN 0 486.9H 792.70%
> [idle]
> 103554 root 1 156 i0 786M 632M CPU37 37 0:44 99.82%
> /usr/bi
> 101148 root 1 156 i0 1317M 822M CPU2 2 2:20 99.82%
> /usr/bi
I do not understand what about the above indicates any
problem. May be more context about the prior activity
that lead to the above needs to be reported?
===
Mark Millard
marklmi at yahoo.com
On Nov 28, 2024, at 19:54, Sean C. Farley wrote:
> On Thu, 28 Nov 2024, Mark Millard wrote:
>
>> . . .
>
>>> System setup:
>>> - FreeBSD 14.2-STABLE
>>
>> The context that I investigated --and what was fixed by a commit only
>>
Sean C. Farley wrote on
Date: Thu, 28 Nov 2024 18:16:16 UTC :
> On Mon, 25 Nov 2024, Mark Millard wrote:
>
> > On Nov 25, 2024, at 18:05, Mark Millard wrote:
> >
> >> Top posting going in a different direction that
> >> established a way to con
On Nov 26, 2024, at 05:38, Konstantin Belousov wrote:
> On Tue, Nov 26, 2024 at 01:58:19PM +0100, Dimitry Andric wrote:
>> On 26 Nov 2024, at 13:32, Dimitry Andric wrote:
>>>
>>> On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote:
>>>>
>>>>
s.
-a, --sass Treat input as indented syntax.
-v, --version Display compiled versions.
-h, --help Display this help message.
> On 11/26/24 09:52, Mark Millard wrote:
>> On Nov 26, 2024, at 05:38, Konstantin Belousov wrote:
>>
>>> On Tue, N
t gotten the failure from any official build from
FreeBSD that I've installed.
Unfortunately, my personal build is not an example of having
just one specific thing that is different and I've yet to
issolate anything that controls the variation in behavior.
===
Mark Millard
marklmi at yahoo.com
On Nov 24, 2024, at 14:59, Mark Millard wrote:
> Dimitry Andric wrote on
> Date: Sun, 24 Nov 2024 17:18:51 UTC :
>
>> On 24 Nov 2024, at 18:07, Guido Falsi wrote:
>>>
>>> . . .
>>
>> Probably best to create a bugzilla ticket, but as I said befo
On Nov 25, 2024, at 22:10, Mark Millard wrote:
> On Nov 25, 2024, at 18:05, Mark Millard wrote:
>
>> Top posting going in a different direction that
>> established a way to control the behavior in my
>> context . . .
>
> For folks new to the discoveries: the co
1101 - 1200 of 1389 matches
Mail list logo
