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 world on ampere2 and
>> >> enabling bu
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 world on ampere2 and
> >> enabling builds of main-armv7-default should no longer have
> >> m
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 graphviz installation (or
>> a
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 graphviz installation (or
analogous contexts). Hopefully, that means that
main-armv7-def
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 UTC
> The branch main has been
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 UTC
The branch main has been updated by mmel:
URL:
https://cgit.FreeBSD.org/src/commit/?id=5670
On Wed, Jul 24, 2024 at 11:34 AM m...@freebsd.org
wrote:
>
>
> On 24.07.2024 17:47, Konstantin Belousov wrote:
> > On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
> >>
> >>
> >>> On Jul 24, 2024, at 06:50, Konstantin Belousov
> wrote:
> >>>
> >>> On Wed, Jul 24, 2024 at 12:34:57PM +
On 24.07.2024 17:47, Konstantin Belousov wrote:
On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
On 24.07.2024 12:24, Konstantin Belousov wrote:
On Tue,
On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
>
>
> > On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
> >
> > On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
> >>
> >>
> >> On 24.07.2024 12:24, Konstantin Belousov wrote:
> >>> On Tue, Jul 23, 2024 at 08:
> On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
>
> On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>>
>>
>> On 24.07.2024 12:24, Konstantin Belousov wrote:
>>> On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal Melou
On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>
>
> On 24.07.2024 12:24, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> > > On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> > > >
> > > > On 23.07.2024 11:36, Konstantin Belousov
On 24.07.2024 12:24, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
On 23.07.2024 11:36, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
The good news is tha
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a wor
On Tue, Jul 23, 2024 at 2:11 PM John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a working/lock
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
>>> The good news is that I'm finally able to generate a working/locking
>>> test case. The culprit (at least for me) is if "-mcpu
On Tue, Jul 23, 2024 at 07:46:51PM +0200, Michal Meloun wrote:
>
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> > > The good news is that I'm finally able to generate a working/locking
> > > test case. The culprit (at leas
On 23.07.2024 11:36, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
The good news is that I'm finally able to generate a working/locking
test case. The culprit (at least for me) is if "-mcpu" is used when
compiling libthr (e.g. indirectly injected v
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> The good news is that I'm finally able to generate a working/locking
> test case. The culprit (at least for me) is if "-mcpu" is used when
> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf).
> If it is not us
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, Michal Meloun wrote:
> On 22.07.2024 13:46,
> On Jul 22, 2024, at 12:51, Mark Millard wrote:
>
> Another systematic difference in my personal builds vs.
> official pkgbase builds, snapshots, releases, etc. is
> that my armv7 builds are built on aarch64-as-armv7, not
> on amd64. Not that I have any specific evidence that
> such matters h
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:
> I don't want to hijack the original thre
Another systematic difference in my personal builds vs.
official pkgbase builds, snapshots, releases, etc. is
that my armv7 builds are built on aarch64-as-armv7, not
on amd64. Not that I have any specific evidence that
such matters here.
But Michal Meloun's report indicated not using builds
done o
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 current, has been running 24/7 by building kernel/wo
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 current, has been running 24/7 by building kernel/world and
> kde5 in a loop for a few years now. But I have never encountered the
> aforementioned loc
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
>> /libexec/ld-elf.so.1
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 shows distinctions bas
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 shows distinctions based on
the difference.
This is related to the code:
(gdb) li
[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:
>>
>>> [Everything and everybody in Cc: are stri
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 - 0x2014092c is .bss in /lib/libthr.so.3
>>>
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
>>
>> (gdb) bt
>> #0 0x201aeec0 in __pthread_map_stacks_exec
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
>>
>> (gdb) bt
>> #0 0x201aeec0 in __pthread_map_stacks_exec
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
>>
>> (gdb) bt
>> #0 0x201aeec0 in __pthread_map_stacks_exec
[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
>
> (gdb) bt
> #0 0x201aeec0 in __pthread_map_stacks_exec () from /lib/libc.so.7
> #1 0x2005d1e4 in ?? () from /libexec/ld
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, Mark Millard wrote:
> No longer is the pro
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 observed on ampere2! But this was with
a non-
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 built kernel that has some of my now patc
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 can replicate the issue with an off
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 replicated with the of
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.
FYI for the replication that I got:
/usr/local/sbin/pkg-static add -A /packages/
39 matches
Mail list logo
