I don't want a GUI for bhyve. I want to manage everything by creating a
script in bash.
On Mon, Aug 5, 2024 at 8:52 PM Dennis Clarke wrote:
> On 8/5/24 14:22, Miroslav Lachman wrote:
> > On 05/08/2024 18:50, Dennis Clarke wrote:
> >> On 8/5/24 12:12, Harry Schmalzbauer wrote:
> >>> Hello,
> >>>
On 8/5/24 14:22, Miroslav Lachman wrote:
On 05/08/2024 18:50, Dennis Clarke wrote:
On 8/5/24 12:12, Harry Schmalzbauer wrote:
Hello,
two years elapsed since I last deployed a FreeBSD machine that
utilizd bhyve(8), which already had bhyve_config(5) support back then.
This may feel
On 05/08/2024 18:50, Dennis Clarke wrote:
On 8/5/24 12:12, Harry Schmalzbauer wrote:
Hello,
two years elapsed since I last deployed a FreeBSD machine that utilizd
bhyve(8), which already had bhyve_config(5) support back then.
This may feel slightly off topic but I assure you that it is of
On 2024-08-05 19:04, Mario Marietto wrote:
Hello.
I'm also interested in writing a script to manage the bhyve vms. Even if
I suspect that my approach will be different. My idea is to ask the user
what he wants to do and then the script will configure the vm getting
the information provided
Hello.
I'm also interested in writing a script to manage the bhyve vms. Even if I
suspect that my approach will be different. My idea is to ask the user what
he wants to do and then the script will configure the vm getting the
information provided by the user.
I will give a look at
On 8/5/24 12:12, Harry Schmalzbauer wrote:
Hello,
two years elapsed since I last deployed a FreeBSD machine that utilizd
bhyve(8), which already had bhyve_config(5) support back then.
This may feel slightly off topic but I assure you that it is of great
benefit. Have a look at the
> Subject: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfe0127d22000
> 13.2 works. 13.3 and 14.x panic.
13.3 iso will work if load ispfw first (escape to loader, unload kernel, load ispfw, load kernel, boot)
also,
adding ispfw_load="YES"
On Wed, 31 Jul 2024 at 21:52, Kyle Evans wrote:
> On 7/31/24 14:31, Gleb Smirnoff wrote:
> > On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
> > K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
> > K> > > Author: Alfonso Siciliano
> > K> > > Date: Sat May 25 02:42:46 2024
Dag-Erling Smørgrav wrote:
> Loader I/O performance is much better these days so loading modules
> pre-boot doesn't slow the boot down much any more, but it's still more
That depends very much on the h/w, especially the storage attachment.
None of which applies to any machine likely to be using
On 7/31/24 14:31, Gleb Smirnoff wrote:
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
K> > > Author: Alfonso Siciliano
K> > > Date: Sat May 25 02:42:46 2024 +0200
K> > >
K> > > change: --form and --mixedgauge do not
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
K> > > Author: Alfonso Siciliano
K> > > Date: Sat May 25 02:42:46 2024 +0200
K> > >
K> > > change: --form and --mixedgauge do not print field input to output
if > > eldlen>
On 7/27/24 19:28, Mark Millard wrote:
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):
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
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 method I used to install is to boot to the latest snapshot at
the time, then plug in a usb3 disk,
> On 31. Jul 2024, at 15:01, void wrote:
>
> On Tue, Jul 30, 2024 at 08:55:22PM +0200, Dag-Erling Smørgrav wrote:
>> void writes:
>>> The arm64 device is headless and i connect to it via serial.
>>> I noticed the beastie menu come up with the option Video for
>>> console. Cycled it to
On Tue, Jul 30, 2024 at 08:55:22PM +0200, Dag-Erling Smørgrav wrote:
void writes:
The arm64 device is headless and i connect to it via serial.
I noticed the beastie menu come up with the option Video for
console. Cycled it to Serial, booted, all fine. [...]
man boot.config
Thank you for
Hello,
I've pushed 9333e1cbd028 ("include: ssp: hide ppoll redirect behind
> __BSD_VISIBLE") and audited a bit for similar issues in the other ssp
> headers, but didn't see any off-hand. With that change:
>
> 100% tests passed, 0 tests failed out of 267
>
> Thanks,
>
> Kyle Evans
>
Upgraded
On Tue, Jul 30, 2024 at 10:02:37PM -0600, Warner Losh wrote:
> On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote:
>
> > Miroslav Lachman <000.f...@quip.cz> writes:
> > > I'm a bit confused. If I understand it right, you say loader.conf
> > > causes less memory fragmentation, but DES said
On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote:
> Miroslav Lachman <000.f...@quip.cz> writes:
> > I'm a bit confused. If I understand it right, you say loader.conf
> > causes less memory fragmentation, but DES said "it still increases low
> > memory fragmentation". So what is true? And
> On Jul 31, 2024, at 2:54 AM, Dag-Erling Smørgrav wrote:
>
> Miroslav Lachman <000.f...@quip.cz> writes:
>> I'm a bit confused. If I understand it right, you say loader.conf
>> causes less memory fragmentation, but DES said "it still increases low
>> memory fragmentation". So what is true?
On 07/30/2024 9:25 am, Larry Rosenman wrote:
On 07/30/2024 9:22 am, Ed Maste wrote:
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning:
On 7/30/24 16:16, Cy Schubert wrote:
In message , Gleb Smirnoff writes:
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilizati
on week
T> T>
In message , Gleb Smirnoff writes:
> On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
> T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
> T> T> This is an automated email to inform you that the July 2024 stabilizati
> on week
> T> T> started with FreeBSD/main at
Shawn Webb writes:
> While probably less efficient than just running the tools outright, I
> usually just set up a tmpfs that I chroot into and install those kinds
> of packages.
Yeah, I do something similar, with the footnote that I more often than
not have no internet connection, so I
On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote:
"Poul-Henning Kamp" writes:
Dag-Erling Smørgrav writes:
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
Apart from the internals of
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilization
week
T> T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged
as
On Tue, Jul 30, 2024 at 07:07:51PM +, Poul-Henning Kamp wrote:
> I do not want want this to turn into a everything-and-Emacs bloat-party,
> but I would find it really helpful if our install-ISO images had two
> HW-spelunking ports installed:
>
> sysutils/smartmontools
>
> and
>
>
On 2024-07-30 19:07 +, Poul-Henning Kamp wrote:
> sysutils/smartmontools
>
> and
>
> sysutils/dmidecode
>
> Is that even possible ?
>
> Am I the only one who thinks so ?
I have missed having these tools numerous times over the years. Whether it's
installing on a new
void writes:
> The arm64 device is headless and i connect to it via serial.
> I noticed the beastie menu come up with the option Video for
> console. Cycled it to Serial, booted, all fine. [...]
man boot.config
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Miroslav Lachman <000.f...@quip.cz> writes:
> I'm a bit confused. If I understand it right, you say loader.conf
> causes less memory fragmentation, but DES said "it still increases low
> memory fragmentation". So what is true? And is this something to watch
> out for, or is memory fragmentation
On 7/29/24 18:04, Nuno Teixeira wrote:
Hello all,
At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with
`make test`.
I remember that tests were ok about 1 or 2 weeks ago.
I will update world soon and continue to monitor this tests failure.
Thanks,
Hi,
I've pushed
On Tue, Jul 30, 2024 at 11:57:07PM +0900, Tomoaki AOKI wrote:
Another aspect is that loading multiple too large modules easily makes
boots crash. Staging area (memory region which loader allocates to load
kernel and modules, and maybe configured buffers) is limited.
This is why I went looking
On 30/07/2024 16:30, Warner Losh wrote:
[..]
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any
problems
it used to solve are solved, and that the preferred way is to load
everything from
On Tue, 30 Jul 2024 19:22:31 +0800
Alastair Hogge wrote:
>
>
> On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
> >On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> >> Gary Jennejohn writes:
> >
> >[..]
> >
> >>> I also load it from /boot/loader.conf using
On Tue, Jul 30, 2024, 4:50 AM Poul-Henning Kamp wrote:
>
> Dag-Erling Smørgrav writes:
>
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
>
> Apart from the internals of
On Tue, Jul 30, 2024, 3:39 AM Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at boot time, but
On 07/30/2024 9:22 am, Ed Maste wrote:
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
archive
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
>
> I'm getting the following on an up2date checkout:
> Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
> ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
> archive member 'FaultMaps.o' is neither
On 30/07/2024 12:31, Dag-Erling Smørgrav wrote:
Miroslav Lachman <000.f...@quip.cz> writes:
Dag-Erling Smørgrav writes:
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation.
Does this also apply today? I recently
the first one to
w> load will claim the device, since there's no re-probe when the next
w> one loads. **You should never use it, unless the module you're
w> loading isn't supported by the boot loader (like drm-kmod)**. The old
w> advice was to put everything in kld_list and it w
org/archives/freebsd-current/2024-May/005953.html
w> Also, in this case, kld_list is a terrible place to load the files.
w> You're better off loading them with xxx_load=YES in loader.conf. The
w> reason is that both uhid and ums will match your mouse. kld_list
w> loads these in a rando
"Poul-Henning Kamp" writes:
> Dag-Erling Smørgrav writes:
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
> Apart from the internals of config(8) and it's input data, is there
>
On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
>On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
>> Gary Jennejohn writes:
>
>[..]
>
>>> I also load it from /boot/loader.conf using filemon_load="YES"
>>
>> This does cause the module to be loaded at boot time, but
Dag-Erling Smørgrav writes:
> There is very little difference between options and devices in kernel
> configuration files, but for what it's worth, filemon is a device, not
> an option.
Apart from the internals of config(8) and it's input data, is there
any actual difference left ?
--
On Tue, 30 Jul 2024 11:10:06 +0200
Dag-Erling Smørgrav wrote:
> Gary Jennejohn writes:
> > filemon is not a device, it's an option. So you can't have "device
> > filemon" in your kernel config file.
>
> There is very little difference between options and devices in kernel
> configuration
Miroslav Lachman <000.f...@quip.cz> writes:
> Dag-Erling Smørgrav writes:
> > This does cause the module to be loaded at boot time, but it's slower
> > than loading it later, and it increases memory fragmentation.
> Does this also apply today? I recently read from someone on a mailing
> list that
Hi,
On Tue, 30 Jul 2024, at 10:10, Dag-Erling Smørgrav wrote:
> void writes:
>> How would I go about remedying the issue that usage/examples
>> are not present in manpages for either the device line in kernel
>> config or filemon.ko ?
>
> https://reviews.freebsd.org/D46184
thank you!
On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
Gary Jennejohn writes:
[..]
I also load it from /boot/loader.conf using filemon_load="YES"
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation. A better
option
void writes:
> How would I go about remedying the issue that usage/examples
> are not present in manpages for either the device line in kernel
> config or filemon.ko ?
https://reviews.freebsd.org/D46184
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Gary Jennejohn writes:
> filemon is not a device, it's an option. So you can't have "device
> filemon" in your kernel config file.
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
> I compile
On 7/29/24 18:04, Nuno Teixeira wrote:
Hello all,
At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with
`make test`.
I remember that tests were ok about 1 or 2 weeks ago.
I will update world soon and continue to monitor this tests failure.
Thanks,
>
Hi,
Looking into it-
I understand the reason. Thanks for your investigation.
> 2024/07/30 12:37、Warner Losh のメール:
>
> That was my fault.
>
> Turns out I forgot to copy the menu version back from my laptop to my server
> before committing.
> My laptop is the only place I had the menu. I got this stuff working there
That was my fault.
Turns out I forgot to copy the menu version back from my laptop to my
server before committing.
My laptop is the only place I had the menu. I got this stuff working there
last week after I got it
working on my server... then forgot I'd done that and pushed the wrong
version...
Yes. My fault. I'll fix. I thought I'd tested the menu... but apparently
not. My apologies.
Warner
On Mon, Jul 29, 2024, 6:44 PM 内藤祐一郎 wrote:
> Hi, I updated my FreeBSD current machine to the following commit.
>
> FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
>
How would I go about remedying the issue that usage/examples
are not present in manpages for either the device line
in kernel config or filemon.ko ?
--
On Sat, 27 Jul 2024 19:31:37 +0100
void wrote:
> On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
>
> >filemon is not a device, it's an option. So you can't have "device
> >filemon" in your kernel config file.
> >
> >I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in
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
>
Marek Zarychta wrote:
>
> What about filesystem perfomnace ? Have you benchmarked your FS and
> whole system with and without filemon loaded ?
FWIW filemon does nothing unless make opens the device.
and then it only impacts syscalls done by that pid and its children.
> I am not questionining
slightly tangent question but does filemon and consequently
WITH_META_MODE=YES work, when /usr/obj is on tmpfs? In my test, it is not
and i tested without reboot, so /usr/obj is not removed. Reason is to avoid
disk use when building world/kernel.
On Sat, Jul 27, 2024 at 6:35 PM void wrote:
>
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
filemon is not a device, it's an option. So you can't have "device
filemon" in your kernel config file.
man 4 filemon has the following
NAME
filemon – the filemon device
[...]
DESCRIPTION
The filemon device allows a
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
filemon is not a device, it's an option. So you can't have "device
filemon" in your kernel config file.
I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my
kernel config file.
What's the actual line in your
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-chroot-ports-official/mnt
>> (nfs, noatime)
>>
>>
Dnia Sat, Jul 27, 2024 at 03:27:19PM +0100, Nuno Teixeira napisał(a):
> Hello,
>
> I use filemon for builds with WITH_META_MODE loaded from rc.conf:
> kld_list="... filemon" for some years on both amd64 and aarch64.
What about filesystem perfomnace ? Have you benchmarked your FS and
whole system
On Sat, 27 Jul 2024 15:27:19 +0100
Nuno Teixeira wrote:
> Hello,
>
> I use filemon for builds with WITH_META_MODE loaded from rc.conf:
> kld_list="... filemon" for some years on both amd64 and aarch64.
>
> Cheers,
>
> void escreveu (sábado, 27/07/2024 à(s) 14:50):
>
> > Is it better to load
Hello,
I use filemon for builds with WITH_META_MODE loaded from rc.conf:
kld_list="... filemon" for some years on both amd64 and aarch64.
Cheers,
void escreveu (sábado, 27/07/2024 à(s) 14:50):
> Is it better to load filemon as kldload filemon, or to
> have it set as a device via 'device
> On Jul 27, 2024, at 9:49 PM, void wrote:
>
> Is it better to load filemon as kldload filemon, or to
> have it set as a device via 'device filemon' in the kernel config file? or to
> just load it when rebuilding the system?
>
> There is man 4 filemon but nothing there to describe usage as
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:
>
> Reading symbols from /sbin/umount...
>
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
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
> >>
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
>>
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
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
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:
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
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
> 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
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
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
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
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
On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the July 2024 stabilization
week
T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as
T> main-stabweek-2024-Jul.
Testing at Netflix didn't discover any
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
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
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
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
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
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
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
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
First, sorry for late response.
cglogic, thank you for bringing up this issue again since I nearly forgot that
this issue was still open.
Warner, as I can't access to my FreeBSD instance until the end of August, but I
can still edit and push the code through my Arm Mac. This means that I can't
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
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
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)
[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
On Sun, Jul 21, 2024 at 2:03 PM cglogic wrote:
>
> On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh wrote:
>
>
>
> On Sat, Jul 20, 2024 at 1:59 AM cglogic wrote:
>
>> Hello FreeBSD community,
>>
>> After Jason Evans stepped aside from maintaining jemalloc in FreeBSD,
>> it's not updating in
On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh wrote:
> On Sat, Jul 20, 2024 at 1:59 AM cglogic wrote:
>
>> Hello FreeBSD community,
>>
>> After Jason Evans stepped aside from maintaining jemalloc in FreeBSD, it's
>> not updating in time anymore.
>> Version 5.3.0 was released May 6, 2022
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
>>>
1 - 100 of 106087 matches
Mail list logo
