On Feb 19, 2025, at 09:42, Olivier Cochard-Labbé wrote:
> On Wed, Feb 19, 2025 at 6:05 PM Mark Millard wrote:
>>
>> Another example might be if new VM contexts should be added,
>> such as UTM for macOS. What do kenv smbios.system.product ,
>> sysctl kern.vm_guest
On Feb 19, 2025, at 05:24, Jason Bacon wrote:
>
> On 2/18/25 20:13, Mark Millard wrote:
>> Something I possibly should have done --but did not do was to set:
>> kern.hz=100
>
> I stopped doing this under VirtualBox a few years ago, because it was causing
> clock skew
On Feb 18, 2025, at 16:04, Warner Losh wrote:
> On Tue, Feb 18, 2025 at 4:57 PM Mark Millard wrote:
>> On Feb 18, 2025, at 14:01, Warner Losh wrote:
>> >
>> > On Tue, Feb 18, 2025 at 2:56 PM Warner Losh wrote:
>> >>
>> >> On Sat, Feb 15,
On Feb 18, 2025, at 14:01, Warner Losh wrote:
>
> On Tue, Feb 18, 2025 at 2:56 PM Warner Losh wrote:
>>
>> On Sat, Feb 15, 2025 at 10:04 AM Mark Millard wrote:
>>> [This seems likely to not be limited to main [so: 15 as stands].
>>> But I'
nts
/usr/src/sys/arm/conf/GENERIC.hints
/usr/src/sys/riscv/conf/GENERIC.hints
with no aarch64 , armv7 , powerpc64* , powerpcspe , or
riscv64 examples?
===
Mark Millard
marklmi at yahoo.com
[I've now tried my UFS context as well.]
On Feb 12, 2025, at 18:24, Mark Millard wrote:
> I use pkg and poudriere-devel in areas that I've chroot'ed into. (This
> may be unusual and so is noted just in case it turns out to be involved.
> I've been doing that for
usr/obj/DESTDIRs/main-ZNV4-chroot-ports-local/
is a personal world build that was installed there. (The system boots
to an official PkgBase installed world.) So this is not just official
materials involved in the activity, unfortunately.
===
Mark Millard
marklmi at yahoo.com
On Wed, Jan 29, 2025 at 05:16:50PM +0200, Konstantin Belousov wrote:
> On Wed, Jan 29, 2025 at 05:29:35AM +, jenkins-ad...@freebsd.org wrote:
> > FreeBSD-main-amd64-test - Build #25976
> > (4da070ce6c015a994ec4ecf3d31ee94810ea19f1) - Still unstable
> >
> > Build information: https://ci.FreeBS
> kernel module old way, and that whole pipeline is broken if it's loaded at
> boot time or included in the kernel directly. There isn't a nice way to defer
> the firmware load attempt until /after/ rootfs is up.
>
Yep.
===
Mark Millard
marklmi at yahoo.com
On Jan 25, 2025, at 02:24, Mark Millard wrote:
> On Jan 25, 2025, at 02:10, Stefan Esser wrote:
>
>> Am 25.01.25 um 10:54 schrieb Mark Millard:
>>> Unfortunately, for now my reporting is based on my personal build
>>> environment,
>>> not on anoffici
On Jan 25, 2025, at 02:10, Stefan Esser wrote:
> Am 25.01.25 um 10:54 schrieb Mark Millard:
>> Unfortunately, for now my reporting is based on my personal build
>> environment,
>> not on anofficial FreeBSD build.
>> Context doing the building:
>
> Hi Mark,
>
'
.PATH='.
/usr/obj/BUILDs/main-amd64-dbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-DBG'
37.06 real 108.72 user 5.50 sys
make[1]: stopped making "buildkernel" in /usr/main-src
make: stopped making "buildkernel" in /usr/main-src
Script done, output file is
/usr/obj/BUILDs/main-amd64-dbg-clang/sys-typescripts/typescript-make-amd64-dbg-clang-amd64-host-2025-01-25:01:25:05
===
Mark Millard
marklmi at yahoo.com
o (1-deep or whatever), bare if src.txz was
> also unpacked.
> - add a simple script to download as above.
> - people can install whatever git client they want for further work.
>
> git9 doesn't require any kernel code but on freebsd you'd have to
> use plan9port. It is far simpler but has a different interface.
===
Mark Millard
marklmi at yahoo.com
I realise this takes me
> into uncharted waters, as the testing base for these non-default package
> builds is lower than for the default package builds. I am assuming that risk
> on myself by electing to build my own packages via Poudriere.
>
> Straying off the beaten path can sometimes take you to lonely places. :-)
===
Mark Millard
marklmi at yahoo.com
On Jan 17, 2025, at 10:30, Dennis Clarke wrote:
> On 1/15/25 21:20, Mark Millard wrote:
>> Dennis Clarke wrote on
>> Date: Wed, 15 Jan 2025 15:16:58 UTC :
>>> Over the past month or so I see endless fails in builds for the big
>>> three user facing window
webengine-5.15.18p5_1
x11-wm/xfcebeing blocked by vte3-0.70.2_5
x11/xfce4-goodies being blocked by vte3-0.70.2_5
x11/xfce4-terminal being blocked by vte3-0.70.2_5
But I did not see LXDE being blocked.
Note: So far, 134releng-armv7-default had a very early,
global build failure where nothing built.
But I've no clue if any of this matches your example
build failures.
===
Mark Millard
marklmi at yahoo.com
On Fri, Dec 27, 2024 at 08:30:37PM +0700, Yuri Pankov wrote:
> Getting the following debug notifications:
>
> hdacc0: at cad 0 on hdac0
> hdaa0: at nid 1 on hdacc0
> uma_zalloc_debug: zone "malloc-32" with the following non-sleepable
> locks held:
> exclusive sleep mutex hdac0 (HDA driver mutex)
On Tue, Dec 17, 2024 at 12:19:26PM -0700, Alan Somers wrote:
> According to namei(9), namei should return a shared lock when
> LOCKSHARED is specified. But in my experiments, it always seems to
> return an exclusive lock instead. For example:
>
> $ cd /usr/tests/sys/fs/fusefs
> $ sudo dtrace -i
On Dec 15, 2024, at 20:13, Daniel O'Connor wrote:
> Hi Mark,
Hello Daniel,
>> On 16 Dec 2024, at 10:33, Mark Millard wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 is for a crash
>> problem
>> someone has been having over more than 2 ye
rnel | grep "\-RELEASE"
@(#)FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
FreeBSD 13.4-RELEASE-p2 3f40d5821 M5P
13.4-RELEASE-p2
Because it is a rebuild, the kernel ends up with -p2 instead
of the official -p1 ( from -p2 not updating boot/kernel/kernel
in the official distributions ).
===
Ma
On Dec 14, 2024, at 06:21, Ed Maste wrote:
> On Fri, 13 Dec 2024 at 19:42, Mark Millard wrote:
>>
>> I tend to use https://artifact.ci.freebsd.org/snapshot/*/*/*/*/*.txz
>> for crude bisecting without needing to do builds.
>>
>> Are you saying that such will
We can separately consider
> compression on the release media images themselves.
>
> Feedback Requested:
>
> Is there support for this idea? Are there objections to pursuing this?
> Are there other factors I should consider, especially compatibility concerns?
===
Mark Millard
marklmi at yahoo.com
ntext of -current on Raspberry Pi2,-3 and -4
> if it matters.
===
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
>>
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
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
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
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
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:
>>>>
>>>>
On Nov 26, 2024, at 04:58, 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:
>>>
>>> Mark Millard writes:
>>>> From inside a bulk -i where I did a manual m
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
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 context here
is poudriere bulk builds, for USE_TMPFS=all vs.
USE_TMPFS=no . My test c
what I looked at before trying the
above . . .
On Nov 25, 2024, at 17:05, Mark Millard wrote:
> On Nov 25, 2024, at 15:21, Mark Millard wrote:
>
>> On Nov 25, 2024, at 14:23, Guido Falsi wrote:
>>
>>> On 25/11/24 23:15, Dimitry Andric wrote:
>>>> On 25
On Nov 25, 2024, at 15:21, Mark Millard wrote:
> On Nov 25, 2024, at 14:23, Guido Falsi wrote:
>
>> On 25/11/24 23:15, Dimitry Andric wrote:
>>> On 25 Nov 2024, at 23:12, Mark Millard wrote:
>>>>
>>>> On Nov 25, 2024, at 13:27, Guido Falsi wro
On Nov 25, 2024, at 14:23, Guido Falsi wrote:
> On 25/11/24 23:15, Dimitry Andric wrote:
>> On 25 Nov 2024, at 23:12, Mark Millard wrote:
>>>
>>> On Nov 25, 2024, at 13:27, Guido Falsi wrote:
>>>
>>>> On 25/11/24 22:18, Dag-Erling Smørgrav
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:
>>>>>>
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 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
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
ot a
load-time issue.
Not that I've any clue why yet.
===
Mark Millard
marklmi at yahoo.com
> On Nov 21, 2024, at 13:15, Mark Millard wrote:
>
> Summary:
>
> Turns out in my context: libsass.so <http://libsass.so/>.1.0.0 built for
> 1500026 fails and built for 1500027 works, at least
> when used via a 1500027 world.
So much for that idea: updating the p
, version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 (1500027),
stripped
/usr/local/lib/libsass.so.1.0.0.orig-stripped: ELF 64-bit LSB shared object,
x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 (1500026),
stripped
===
Mark Millard
marklmi at yahoo.com
gt; compiled by configure script dumping core.
> >
> > I suspect there are more around the ports tree.
>
> I cannot reproduce this at all. For me the sassc binary runs fine, and also
> the x11-themes/greybird-theme port builds fine. Then again, my base system is
> probably
[Just resending, including the original-sender's listing of
freebsd=ports.]
On Nov 21, 2024, at 02:22, Mark Millard wrote:
> I've noticed that recently some ports are dumping core during builds of
> dependencies in head in poudriere.
>
> I'm seeing this for exampl
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
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
[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
On Thu, Nov 07, 2024 at 09:43:50PM +0200, Oleksandr Kryvulia wrote:
> Hi, @current
>
> My laptop now panics while boot with [1].
> git bisect shows a97f683fe3c425b425cf8cc466319f54ea957c20 as offending
> commit.
>
> [1] https://imgur.com/a/Pb6eakW
I believe the patch below will fix the problem.
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
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
-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
?
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
.
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
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 Fri, Oct 25, 2024 at 11:12:48PM +0200, Guido Falsi wrote:
> On 25/10/24 22:49, Mark Johnston wrote:
> > On Fri, Oct 25, 2024 at 09:24:13PM +0200, Guido Falsi wrote:
> > > Hi,
> > >
> > > I've recently updated my current machines to git commit
> >
On Fri, Oct 25, 2024 at 09:24:13PM +0200, Guido Falsi wrote:
> Hi,
>
> I've recently updated my current machines to git commit
> 525a177c165740fc697df3de5b92e58b3b41477c (Sun Oct 20 22:43:41 2024 -0800)
> and just have Windows 10 VMs fail to start in bhyve with the error in the
> subject.
>
> I'v
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
Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
Fabrice Bacchella, Zhenghua Xue
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
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
FI is in use, then the ESP-ish partition is not from the guest
context but from some place else --unless the man pages are wildly
wrong about what is supported for the gpt*boot 's.
===
Mark Millard
marklmi at yahoo.com
void wrote on
Date: Sat, 07 Sep 2024 17:27:00 UTC :
> On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
>
> >I'm more interested in what is there than just what is not
> >there. May be show something analogous to:
> >
> ># gpart list | grep -E
void wrote on
Date: Sat, 07 Sep 2024 13:19:24 UTC :
> hello again,
>
> On Fri, Sep 06, 2024 at 03:13:59PM -0700, Mark Millard wrote:
> >
> >What shows if you do the likes of (showing an amd64 context example):
> >
> ># ls -lah /boot/efi/efi/*/*
> >-r-xr-xr
/boot/efi/efi/BOOT/bootx64.efi
-rwxr-xr-x 1 root wheel 643K Aug 24 05:32 /boot/efi/efi/FREEBSD/loader.efi
If one is old, then it is probably the one actually being used.
(The name bootx64.efi is amd64 specific: other platforms use
other names.)
In such a case, you might need something like:
# cp -a /boot/loader.efi /boot/efi/efi/BOOT/bootx64.efi
===
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
e done such on amd64
historically, not aarch64, other than possibly one prior
time. On amd64 the drive was internal PCI hardware and
no production of a VHDX file was required. On aarch64
with the USB based drive, direct use of the drive is
blocked, thus the use of a VHDX file produced from th
On Wed, Jul 31, 2024 at 10:48:15AM -0400, John Baldwin wrote:
> On 7/31/24 08:15, void wrote:
> > Hi,
> >
> > Looking at man 4 aesni it appears this pertains to intel and AMD only?
> > is its prescence on arm64 a bug?
> >
> > It seems to be added to /boot/loader.conf by default.
> >
> > The meth
On Jul 27, 2024, at 16:07, Mark Millard wrote:
> The following old files were in the historically incrementally
> updated directory tree but not in the installation to an empty
> directory tree (checked via diff -rq):
>
> /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde
> /usr/obj
-poud/usr/lib/include/machine/fiq.h
/usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz
===
Mark Millard
marklmi at yahoo.com
On Jul 26, 2024, at 21:58, Mark Millard wrote:
> On Jul 26, 2024, at 21:20, Mark Millard wrote:
>
>> The original mount was:
>>
>> mount -onoatime 192.168.1.140:/ /mnt
>>
>> For reference:
>> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-c
On Jul 26, 2024, at 21:20, Mark Millard wrote:
> The original mount was:
>
> mount -onoatime 192.168.1.140:/ /mnt
>
> For reference:
> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
> (nfs, noatime)
>
> gdb reports:
>
>
| grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
FreeBSD-.snap20240726112037
After exiting the chroot, the aarch64 environment did the unmount /mnt just
fine.
===
Mark Millard
marklmi at yahoo.com
On Jul 26, 2024, at 16:44, Warner Losh wrote:
> On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote:
>> On Jul 26, 2024, at 07:56, Philip Paeps wrote:
>>
>> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> >> So, it looks like updating the kernel and
On Jul 26, 2024, at 07:56, Philip Paeps wrote:
> On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
>> So, it looks like updating the kernel and world on ampere2 and
>> enabling builds of main-armv7-default should no longer have
>> main-armv7-default hang-up during grap
On Jul 25, 2024, at 09:48, Mark Millard wrote:
> Michal Meloun has committed a fix in main:
>
> See:
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html
>
> that starts with:
>
> From: Michal Meloun
> Date: Thu, 25 Jul 2024 16:25:09
architecture-specific EABI symbols and
use it on arm 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
Differential Revision: https
On Jul 22, 2024, at 12:36, Michal Meloun wrote:
> On 22. 7. 2024 19:27, Mark Millard wrote:
>> On Jul 22, 2024, at 09:41, meloun.mic...@gmail.com wrote:
>>
>>
>>> On 22.07.2024 18:26, Mark Millard wrote:
>>>
>>>> On Jul 22, 2024, at 06:40, Mi
On Jul 22, 2024, at 09:41, meloun.mic...@gmail.com wrote:
> On 22.07.2024 18:26, Mark Millard wrote:
>> On Jul 22, 2024, at 06:40, Michal Meloun wrote:
>>> On 22.07.2024 13:46, Mark Millard wrote:
>>>> On Jul 21, 2024, at 22:59, Michal Meloun wrote:
>>>
done on amd64 as well. ("Tegra" models and examples of
ARMv7-A and of ARMv8-A.)
For John Carr, I do not know if amd64 based builds of
the world were systematically in use, never in use,
or some mix in his tests.
===
Mark Millard
marklmi at yahoo.com
On Jul 22, 2024, at 06:40, Michal Meloun wrote:
> On 22.07.2024 13:46, Mark Millard wrote:
>> On Jul 21, 2024, at 22:59, Michal Meloun wrote:
>>> I don't want to hijack the original thread, so I'm replying in a new one.
>>>
>>> My tegra track cur
s that
DEBUG_FLAGS was defined. That in turn likely means that strip is not
being used. In such a case, I expect that the .symtab entry for
_rtld_get_stack_prot (and more) exists for such a context.
===
Mark Millard
marklmi at yahoo.com
On Jul 21, 2024, at 21:08, Mark Millard wrote:
> On Jul 21, 2024, at 20:58, Mark Millard wrote:
>
>> I found a significant difference in my failing vs. working
>> armv7 contexts as installed: Presence vs. Lack of a .symtab
>> entry for the symbol _rtld_get_stack_prot in
On Jul 21, 2024, at 20:58, Mark Millard wrote:
> I found a significant difference in my failing vs. working
> armv7 contexts as installed: Presence vs. Lack of a .symtab
> entry for the symbol _rtld_get_stack_prot in
> /libexec/ld-elf.so.1 .
>
> gdb inspection of operation
.symtab entry problems.
Nor have I figured out why the installed materials are
different for Symbol table '.symtab' . So this is not
yet root-cause information.
===
Mark Millard
marklmi at yahoo.com
[Correction to a rather misleading wording in
my description of the failure sequencing.]
On Jul 21, 2024, at 03:36, Mark Millard wrote:
> On Jul 20, 2024, at 16:42, Mark Millard wrote:
>
>> On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
>>
>>> [Everythi
On Jul 20, 2024, at 16:42, Mark Millard wrote:
> On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
>
>> [Everything and everybody in Cc: are stripped for good].
>>
>> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>>> 0x201375c0 - 0x201
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 20, 2024, at 01:57, Konstantin Belousov wrote:
> [Everything and everybody in Cc: are stripped for good].
>
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>
>> (g
On Jul 18, 2024, at 01:14, Mark Millard wrote:
> On Jul 16, 2024, at 23:45, Mark Millard wrote:
>
>> On Jul 16, 2024, at 18:41, Mark Millard wrote:
>>
>>> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>>>
>>>> On Jul 16, 2024, at 10:42, M
On Jul 16, 2024, at 23:45, Mark Millard wrote:
> On Jul 16, 2024, at 18:41, Mark Millard wrote:
>
>> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>>
>>> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>>>
>>>> No longer is the problem only o
On Jul 16, 2024, at 18:41, Mark Millard wrote:
> On Jul 16, 2024, at 11:37, Mark Millard wrote:
>
>> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>>
>>> No longer is the problem only observed on ampere2! But this was with
>>> a non-debug, personally
On Jul 16, 2024, at 11:37, Mark Millard wrote:
> On Jul 16, 2024, at 10:42, Mark Millard wrote:
>
>> No longer is the problem only observed on ampere2! But this was with
>> a non-debug, personally built kernel that has some of my now patches.
>> I'll see if I ca
5.0-CURRENT
main-n271137-d68d12481778 GENERIC arm64 aarch64 1500019 1500019
That is from: .snap20240711212638
The armv7 jail directory tree is from: .snap20240711211723
===
Mark Millard
marklmi at yahoo.com
On Jul 16, 2024, at 10:42, Mark Millard wrote:
> No longer is the problem only observed on ampere2! But this was with
> a non-debug, personally built kernel that has some of my now patches.
> I'll see if I can replicate the issue with an official pkgbase debug
> kernel.
It re
12 urdlck IJ0 0:00.02 | | |
`-- /usr/local/bin/dot -c
0 91907 91496 5 68 0 15760 4492 nanslp S 0 1:05.17 | | |--
sh: poudriere[main-armv7-poud-default]: html_json_main (sh)
0 99134 91496 1 40 0 15760 4740 piperd I 0 0:03.22 | | `--
1 - 100 of 2768 matches
Mail list logo
