On 2/10/24 2:09 PM, Michael Butler wrote:
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).
Reverting to 36efc64 seems to work
On 2/9/24 8:13 PM, Mark Millard wrote:
Summary:
pcib0: mem 0x7d50-0x7d50930f
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
. . .
rman_manage_region: request: start 0x6, end
0x6000f
panic: Failed to
Hi,
I just got a kernel panic on my 15.0-CURRENT machine, with an
Assertion in sys/netinet/tcp_subr.c 2386
full log:
https://people.freebsd.org/~wosch/tmp/kernel-panic-tcp_subr-line-2386.png
OS: 15.0-CURRENT main-3e9515846f (10-Feb-2024, github.com/freebsd/freebsd-src)
Should I worry?
> On Feb 12, 2024, at 10:36, Alexander Leidinger
> wrote:
>
> Hi,
>
> I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
Hi Alexander,
we are aware of this problem, but haven't found a way to reproduce it.
Do you know how to reproduce this?
Best regards
Michael
> ---snip---
>
Hi,
I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
---snip---
__curthread () at /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
57 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) #0 __curthread () at
Hi,
dovecot (and no other program I use on this machine... at least not that I
notice it) segfaults in ld-elf.so.1 after an update from 2024-01-18-092730
to 2024-02-10-144617 (and now 2024-02-11-212006 in the hope the issue would
have been fixed by changes to libc/libsys since 2024-02-10-144617).
I will do it as soon as I get all the necessary tools to turn on the
Raspberry Pi 4b. I was thinking that L4 worked like the old project
coLinux,where Linux ran as a list of processes under WIndows. In my sick
mind I'd thought that L4 allows FreeBSD to run as a list of processes with
the L4
On Feb 11, 2024, at 12:00, Mark Millard wrote:
> [Only replying to what I've subscribed to --and I dropped
> Warner as well.]
>
> On Feb 11, 2024, at 11:43, Mario Marietto wrote:
>
>> ok. But what does this mean ? That I can use whatever Linux distro I want ?
>> Or even the FreeBSD world ?
>
[Only replying to what I've subscribed to --and I dropped
Warner as well.]
On Feb 11, 2024, at 11:43, Mario Marietto wrote:
> ok. But what does this mean ? That I can use whatever Linux distro I want ?
> Or even the FreeBSD world ?
Only to build L4Re.
The LR4e built will not contain any
ok. But what does this mean ? That I can use whatever Linux distro I want ?
Or even the FreeBSD world ?
On Sun, Feb 11, 2024 at 7:59 PM Mark Millard wrote:
>
>
> On Feb 11, 2024, at 05:44, Mario Marietto wrote:
>
> > I'm trying to understand how to use the L4 Microkernel with a FreeBSD
>
On Feb 11, 2024, at 05:44, Mario Marietto wrote:
> I'm trying to understand how to use the L4 Microkernel with a FreeBSD
> userland. I've asked the same to a L4 developer,but he told me that he does
> not know FreeBSD,so I'm here to ask the same question. First of all I'm sure
> that it
Hello to everyone.
I'm trying to understand how to use the L4 Microkernel with a FreeBSD
userland. I've asked the same to a L4 developer,but he told me that he does
not know FreeBSD,so I'm here to ask the same question. First of all I'm
sure that it can be done,because it is written clearly on
I have stability problems with anything at or after this commit
(b377ff8) on an amd64 laptop. While I see the following panic logged, no
crash dump is preserved :-( It happens after ~5-6 minutes running in KDE
(X).
Reverting to 36efc64 seems to work reliably (after ACPI changes but
before
On Feb 9, 2024, at 23:44, Bakul Shah wrote:
> $ git bisect good
> b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit
>
>> On Feb 9, 2024, at 8:13 PM, Mark Millard wrote:
>>
>> Summary:
>>
>> pcib0: mem 0x7d50-0x7d50930f
>> irq 80,81 on simplebus2
>> pcib0: parsing FDT
$ git bisect good
b377ff8110e3489eb6e6b920b51a2384dfc4eb0b is the first bad commit
> On Feb 9, 2024, at 8:13 PM, Mark Millard wrote:
>
> Summary:
>
> pcib0: mem 0x7d50-0x7d50930f
> irq 80,81 on simplebus2
> pcib0: parsing FDT for ECAM0:
> pcib0: PCI addr: 0xc000, CPU addr:
Summary:
pcib0: mem 0x7d50-0x7d50930f
irq 80,81 on simplebus2
pcib0: parsing FDT for ECAM0:
pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size: 0x4000
. .
rman_manage_region: request: start 0x6, end
0x6000f
panic: Failed to add resource to rman
Detail:
. .
On Fri, Feb 9, 2024 at 10:23 AM Matthew L. Dailey
wrote:
>
> I had my first kernel panic with a KASAN kernel after only 01:27. This
> first panic was a "double fault," which isn't anything we've seen
> previously - usually we've seen trap 9 or trap 12, but sometimes others.
> Based on the
On Fri, Feb 09, 2024 at 10:11:14PM +, Matthew L. Dailey wrote:
> On 2/9/24 4:18 PM, Mark Johnston wrote:
> > [You don't often get email from ma...@freebsd.org. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On Fri, Feb 09, 2024 at 06:23:08PM +,
On Fri, Feb 9, 2024 at 2:04 PM Zaphod Beeblebrox wrote:
>
> Just in case it's relevant, I'm carrying around this patch on my fairly busy
> little RISC-V machine.
>
> diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c
> index 0b8c587a542c..85c0ebd7a10f 100644
> ---
On 2/9/24 4:18 PM, Mark Johnston wrote:
> [You don't often get email from ma...@freebsd.org. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote:
>> I had my first kernel panic with a KASAN
Just in case it's relevant, I'm carrying around this patch on my fairly
busy little RISC-V machine.
diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c
index 0b8c587a542c..85c0ebd7a10f 100644
--- a/sys/fs/nfsclient/nfs_clvnops.c
+++ b/sys/fs/nfsclient/nfs_clvnops.c
@@
On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote:
> I had my first kernel panic with a KASAN kernel after only 01:27. This
> first panic was a "double fault," which isn't anything we've seen
> previously - usually we've seen trap 9 or trap 12, but sometimes others.
> Based on
I had my first kernel panic with a KASAN kernel after only 01:27. This
first panic was a "double fault," which isn't anything we've seen
previously - usually we've seen trap 9 or trap 12, but sometimes others.
Based on the backtrace, it definitely looks like KASAN caught something,
but I don't
On 2/9/24 11:04 AM, Mark Johnston wrote:
> [You don't often get email from ma...@freebsd.org. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote:
>> Good morning all,
>>
>> Per Rick Macklem's
On Thu, Feb 08, 2024 at 03:34:52PM +, Matthew L. Dailey wrote:
> Good morning all,
>
> Per Rick Macklem's suggestion, I'm posting this query here in the hopes
> that other may have ideas.
>
> We did do some minimal testing with ufs around this problem back in
> August, but hadn't narrowed
Good morning all,
Per Rick Macklem's suggestion, I'm posting this query here in the hopes
that other may have ideas.
We did do some minimal testing with ufs around this problem back in
August, but hadn't narrowed the issue down to hdf5 workloads yet, so
testing was inconclusive. We'll do
On Tue, 06 Feb 2024 23:05:27 +0100, tue...@freebsd.org wrote:
>
> > On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
> >
> >> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
> >>
> >> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
> >>>
> On Jan 4, 2024, at 18:52,
> On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
>
>> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
>>
>> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>>
On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert
unsubscribe
[Closing the loop on this -- dhw]
On Tue, Jan 30, 2024 at 06:49:32AM -0800, David Wolfskill wrote:
> The machines where I track head (& stable/14) daily get powered off once
> they have finished their work for the day; this is done via "poweroff".
> ...
> |
> | The operating system has halted.
Hi
> On 5 Feb 2024, at 17:02, Brooks Davis wrote:
>
>
>>> 2. It simplifies the implementation of restrictions on system calls such
>>> as those implemented by OpenBSD's msyscall(2)
>>> (https://man.openbsd.org/msyscall.2).
>>
>> That's one to ignore for tools that make syscalls
On Sat, Feb 03, 2024 at 10:15:09AM +0100, Mateusz Guzik wrote:
> On 2/2/24, Brooks Davis wrote:
> > TL;DR: The implementation of system calls is moving to a seperate
> > library (libsys). No changes are required to existing software (except
> > to ensure that libsys is present when building
On Sat, Feb 03, 2024 at 05:11:42PM +0100, Paul Floyd wrote:
>
> On 02/02/2024 23:31, Brooks Davis wrote:
> > TL;DR: The implementation of system calls is moving to a seperate
> > library (libsys). No changes are required to existing software (except
> > to ensure that libsys is present when
On Sat, Feb 03, 2024 at 11:10:14AM -0700, Warner Losh wrote:
> On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov
> wrote:
>
> > On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > > Will this break binary compatibility with older programs expecting those
> > symbols in libc and
On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov
wrote:
> On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
>
> As was mentioned, libc filters libsys. This
On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
As was mentioned, libc filters libsys. This means that libc exports all
the same symbols as before, but forward
On Sat, Feb 03, 2024 at 12:12:35PM +0100, Mateusz Guzik wrote:
> On 2/3/24, David Chisnall wrote:
> > On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
> >>
> >> Binary startup is very slow, for example execve of a hello world
> >> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
On 02/02/2024 23:31, Brooks Davis wrote:
TL;DR: The implementation of system calls is moving to a seperate
library (libsys). No changes are required to existing software (except
to ensure that libsys is present when building custom disk images).
Will this break binary compatibility with older programs expecting those
symbols in libc and not linked to libsys?
> On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber wrote:
>
> On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
>> TL;DR: The implementation of system calls is moving to a seperate
Am Sat, Feb 03, 2024 at 10:15:09AM +0100 schrieb Mateusz Guzik:
> Do I read it correctly that everything dynamically linked will also be
> linked to libsys, as in executing such a binary will now require
> loading one extra .so?
>
> Binary startup is very slow, for example execve of a hello world
On 2/3/24, David Chisnall wrote:
> On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>>
>> Binary startup is very slow, for example execve of a hello world
>> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
>> compared to a native one. As such perf-wise this looks like a step in
On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>
> Binary startup is very slow, for example execve of a hello world
> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
> compared to a native one. As such perf-wise this looks like a step in
> the wrong direction.
Have you
On 2/2/24, Brooks Davis wrote:
> TL;DR: The implementation of system calls is moving to a seperate
> library (libsys). No changes are required to existing software (except
> to ensure that libsys is present when building custom disk images).
>
> Code:
On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> TL;DR: The implementation of system calls is moving to a seperate
> library (libsys). No changes are required to existing software (except
> to ensure that libsys is present when building custom disk images).
>
> Code:
Brooks Davis wrote in
:
|TL;DR: The implementation of system calls is moving to a seperate
|library (libsys). No changes are required to existing software (except
|to ensure that libsys is present when building custom disk images).
...
[]
|This change serves three primary purposes:
|
TL;DR: The implementation of system calls is moving to a seperate
library (libsys). No changes are required to existing software (except
to ensure that libsys is present when building custom disk images).
Code: https://github.com/freebsd/freebsd-src/pull/908
After nearly a decade of
On Fri, Feb 02, 2024 at 10:48:54PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote:
> >
> > Thanks for the explanation, but I think I now have a conundrum.
> > Suppose I have two shared libraries libfoo.so and libbar.so, and
> > suppose bah@@XXX_1.0
On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote:
> On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > > > On 27 Jan 2024, at
On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote:
> On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > > On 27 Jan 2024, at 18:08, Steve Kargl
> > > wrote:
> > > >
> > > > In an attempt to
As noted in UPDATING:
20240201:
sendmail 8.18.1 has been imported and merged. This version enforces
stricter RFC compliance by default, especially with respect to line
endings. This may cause issues with receiving messages from
non-compliant MTAs; please see the
On Wed, Jan 31, 2024, 6:53 AM Mike Karels wrote:
>
>
> On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote:
>
>
> On Tue, Jan 30, 2024 at 3:50 PM David Wolfskill
> wrote:
>
>> The machines where I track head (& stable/14) daily get powered off once
>> they have finished their work for the day;
On Tue, Jan 30, 2024 at 2:57 PM Mike Karels wrote:
>
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels
> >> wrot=
> >> e:
> >>>
> >>> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> >>>
>
On Wed, Jan 31, 2024 at 07:53:07AM -0600, Mike Karels wrote:
> On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote:
> ...
> > Same problem here.
>
> I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed
> shutdown ordering.
>
Yes; I have been corresponding with Andriy, and
On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote:
> On Tue, Jan 30, 2024 at 3:50 PM David Wolfskill
> wrote:
>
>> The machines where I track head (& stable/14) daily get powered off once
>> they have finished their work for the day; this is done via "poweroff".
>>
>> I noticed (this
On Tue, Jan 30, 2024 at 3:50 PM David Wolfskill
wrote:
> The machines where I track head (& stable/14) daily get powered off once
> they have finished their work for the day; this is done via "poweroff".
>
> I noticed (this morning) that one of them never actually powered off
> yesterday. After
In message <3f6cf45c-3d34-4da6-9b81-337eb70bb...@karels.net>, Mike Karels
write
s:
> On 30 Jan 2024, at 15:48, Cy Schubert wrote:
>
> > In message c
> > om>
> > , Rick Macklem writes:
> >> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wro
> t=
> >> e:
> >>>
> >>> On 30 Jan 2024, at 3:00,
On 30 Jan 2024, at 15:48, Cy Schubert wrote:
> In message om>
> , Rick Macklem writes:
>> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot=
>> e:
>>>
>>> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
>>>
Hi Warner,
> I strongly oppose this notion to control this from
In message
, Rick Macklem writes:
> On Tue, Jan 30, 2024 at 10:49=E2=80=AFAM Mike Karels wrot=
> e:
> >
> > On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> >
> > > Hi Warner,
> > >
> > >> I strongly oppose this notion to control this from loader.conf. Root i=
> s
> > >> mounted read-only, so
On Tue, Jan 30, 2024 at 10:49 AM Mike Karels wrote:
>
> On 30 Jan 2024, at 3:00, Olivier Certner wrote:
>
> > Hi Warner,
> >
> >> I strongly oppose this notion to control this from loader.conf. Root is
> >> mounted read-only, so it doesn't matter. That's why I liked Mike's
> >> suggestion: root
On 30 Jan 2024, at 3:00, Olivier Certner wrote:
> Hi Warner,
>
>> I strongly oppose this notion to control this from loader.conf. Root is
>> mounted read-only, so it doesn't matter. That's why I liked Mike's
>> suggestion: root isn't special.
>
> Then in fact there is nothing to oppose. You've
On Tue, 30 Jan 2024 08:12:23 -0800
David Wolfskill wrote:
> On Tue, Jan 30, 2024 at 03:49:54PM +, Gary Jennejohn wrote:
> > ...
> > I use 'shutdown -p now' and it's never failed to power down my computers.
> >
>
> I could say the same about "poweroff", up to the
On Tue, Jan 30, 2024 at 03:49:54PM +, Gary Jennejohn wrote:
> ...
> I use 'shutdown -p now' and it's never failed to power down my computers.
>
I could say the same about "poweroff", up to the main-n267808-197944948e62
-> main-n267841-0b3f9e435f2b transition. And I probably wouldn't
On Tue, 30 Jan 2024 07:10:45 -0800
David Wolfskill wrote:
> On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote:
> > On Tue, Jan 30, 2024 at 3:49?PM David Wolfskill wrote:
> > > The machines where I track head (& stable/14) daily get powered off once
> > > they have finished their work
On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote:
> On Tue, Jan 30, 2024 at 3:49 PM David Wolfskill wrote:
> > The machines where I track head (& stable/14) daily get powered off once
> > they have finished their work for the day; this is done via "poweroff".
> >
> > I noticed (this
On Tue, Jan 30, 2024 at 3:49 PM David Wolfskill wrote:
> The machines where I track head (& stable/14) daily get powered off once
> they have finished their work for the day; this is done via "poweroff".
>
> I noticed (this morning) that one of them never actually powered off
> yesterday. After
The machines where I track head (& stable/14) daily get powered off once
they have finished their work for the day; this is done via "poweroff".
I noticed (this morning) that one of them never actually powered off
yesterday. After today's exercises (including the reboot & subsequent
poweroff), I
> In the current situation, I can back using '/etc/fstab', or probably better,
> '/usr/local/etc/fstab' to hold default mount options, but I'm strongly
> opposing a pure userland implementation as long as my objections above are
> not addressed properly.
Typo, '/usr/local/etc/fstab' should
Hi Warner,
> I strongly oppose this notion to control this from loader.conf. Root is
> mounted read-only, so it doesn't matter. That's why I liked Mike's
> suggestion: root isn't special.
Then in fact there is nothing to oppose. You've just said yourself that root
is mounted first read-only.
Am 2024-01-30 01:21, schrieb Warner Losh:
On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner
wrote:
It also seems undesirable to add a sysctl to control a value that the
kernel doesn't use.
The kernel has to use it to guarantee some uniform behavior
irrespective of the mount being performed
On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner wrote:
> Hi Mike,
>
> I've re-ordered a bit your mail to group some of my comments more
> logically.
>
> > I am not sure a sysctl is a good mechanism for setting the mount default,
> > especially if it is to be set via the kernel environment from
>
Hi Mike,
I've re-ordered a bit your mail to group some of my comments more logically.
> I am not sure a sysctl is a good mechanism for setting the mount default,
> especially if it is to be set via the kernel environment from
> /boot/loader.conf. That's an obscure place to find file system
Hi,
> Let me start out by indicating that some bike shed sessions
> (snip)
> Much of the overall usage is in that "additional attempted span".
Ok, so it seems I've misunderstood what you were saying or your intent in this
regard.
> I will adjust and deal with whatever happens
> overall. That
On Jan 29, 2024, at 02:27, Olivier Certner wrote:
> Hi Mark,
Hello.
Let me start out by indicating that some bike shed sessions
are useful overall, even if not contributing to crucial
matters. I do not see withdrawing from continued participation
with new material as disqualifying of any of
Not responding to a specific message, but following up on the thread:
I am not sure a sysctl is a good mechanism for setting the mount default,
especially if it is to be set via the kernel environment from
/boot/loader.conf. That's an obscure place to find file system defaults.
It also seems
Hi Chris,
> Honestly!
Gosh... This doesn't start well.
> Why do we have to upend decades of usage and understanding? Just
> because it's old doesn't mean it's wrong.
Who says that exactly? Separately, in case you haven't noticed yet, some
things have changed in the past 50 years...
>
Hi Mark,
> I'm confused: I go to the trouble to produce the same end result
> as your suggested change of defaults would produce, ending up
> with no recording of access times.
That's nice of you, but unfortunately that's missing the point. First, you
claimed to "seriously care" about access
Hi Alexander,
> ZFS by default has atime=on. It is our installer which sets atime=off in
> the ZFS properties. I was understanding Warners comment about changing
> ZFS in the sense of changing the ZFS code to have a default of
> atime=off.
>
> I agree with Warner that we should not do that.
I'll add it to the gsoc list, unless someone submits a pull request to make
it so in the mean time :)
Warner
On Sun, Jan 28, 2024 at 11:29 AM Tomek CEDRO wrote:
> Yes! Installer is always used in emergency it would be great to provide
> some servicing tools there too :-)
>
> For years I was
Yes! Installer is always used in emergency it would be great to provide
some servicing tools there too :-)
For years I was using bootable Linux to fix people computers and it would
be nice to have that in FreeBSD :-)
+1 for memstick full with additional service utilities (fix partitions,
mount
On Fri, 26 Jan 2024, at 00:14, void wrote:
> In /usr/src # git rev-list --count --first-parent HEAD
> 26
in /usr/src, a 'git reset --hard' followed by 'git pull' and then 'git checkout
main'
fixed this.
For some reason, 'git pull --ff-only' didn't pull
On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > On 27 Jan 2024, at 18:08, Steve Kargl
> > wrote:
> > >
> > > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > > a small issue that I cannot explain at
On Fri, Jan 26, 2024, 7:32 PM Steve Kargl
wrote:
> I'm currently syncing src/lib/msun with my private libm
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags. For example, lib/msun/amd64/s_scalbnl.S
> contains
>
> /*
Hi Steve,
On Fri, Jan 26, 2024 at 06:32:26PM -0800, Steve Kargl wrote:
> I'm currently syncing src/lib/msun with my private libm
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags. For example,
On Sat, 27 Jan 2024 21:52:06 -0700
Warner Losh wrote:
> On Sat, Jan 27, 2024, 1:26 PM Cy Schubert wrote:
>
> > On January 26, 2024 7:13:15 PM PST, Ed Maste wrote:
> > >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
> > >>
> > >> Probably many do, clueless there's a proposal to remove
On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> On 27 Jan 2024, at 18:08, Steve Kargl
> wrote:
> >
> > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > a small issue that I cannot explain at the moment. If I have
> > /usr/bin/ld in my path prior to
On Sat, Jan 27, 2024, 1:26 PM Cy Schubert wrote:
> On January 26, 2024 7:13:15 PM PST, Ed Maste wrote:
> >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
> >>
> >> Probably many do, clueless there's a proposal to remove them,
> >> as many wont be tracking lists (I havent been tracking
> I use meta-mode in /etc/src-env.conf so that if (for example) a small
> change in the kernel config is made, the machine doesn't take hours
> recompiling.
> But, from time to time, one might be required to make
> cleanworld && make cleandir (to be sure) && make clean (to be *really* sure)
On 27 Jan 2024, at 18:08, Steve Kargl wrote:
>
> In an attempt to cleanup a bit of src/lib/msun, I ran into
> a small issue that I cannot explain at the moment. If I have
> /usr/bin/ld in my path prior to /usr/local/bin/ld everything
> works
>
> % which ld
> /usr/bin/ld
> % make clean && make
On January 26, 2024 7:13:15 PM PST, Ed Maste wrote:
>On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
>>
>> Probably many do, clueless there's a proposal to remove them,
>> as many wont be tracking lists (I havent been tracking lately,
>> focused on moving home, other will have other
In an attempt to cleanup a bit of src/lib/msun, I ran into
a small issue that I cannot explain at the moment. If I have
/usr/bin/ld in my path prior to /usr/local/bin/ld everything
works
% which ld
/usr/bin/ld
% make clean && make cleandepend
% make
and I have a libm.so.5. But if
On Sat, 27 Jan 2024, at 13:59, Warner Losh wrote:
> Approximately never. The only time I've had issues were when the
> machine crashed due to sudden power failure during the build which lead
> to the last few .o files to be zero length with UFS.
>
> Non clean normal builds have lots of issues
Hi,
On Sat, 27 Jan 2024, at 13:51, Lexi Winter wrote:
> the (easiest) fix for that is to do a full rebuild every time
> __FreeBSD_version changes.
>
> pkg(8) bug report: https://github.com/freebsd/pkg/issues/2162
>
> i don't know if meta mode will catch this and rebuild correctly, but
> since
On Sat, Jan 27, 2024, 6:12 AM void wrote:
> Hi,
>
> I use meta-mode in /etc/src-env.conf so that if (for example) a small
> change in the kernel config is made, the machine doesn't take hours
> recompiling.
>
> Also, (I *think* it works this way) if src gets updated by git and
> world/kernel
void:
> But, from time to time, one might be required to make
> cleanworld && make cleandir (to be sure) && make clean (to be *really* sure)
> What circumstances & notices in /usr/src/UPDATING would require it?
one case this is required in non-meta mode is if you use pkg(8) (e.g.,
with
Hi,
I use meta-mode in /etc/src-env.conf so that if (for example) a small
change in the kernel config is made, the machine doesn't take hours recompiling.
Also, (I *think* it works this way) if src gets updated by git and
world/kernel rebuilt it won't recompile already compiled files provided
I
On Fri, 26 Jan 2024 at 16:10, Rodney W. Grimes
wrote:
>
> You yet again seem to ignore what it was I said, UEFI/CSM != UEFI, and
> there are many buggy CSM's that roach on zeros in the CHS area.
I'm not sure what "zeros in the CHS area" is referring to -- gpart
writes values in the CHS fields,
On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey wrote:
>
> Probably many do, clueless there's a proposal to remove them,
> as many wont be tracking lists (I havent been tracking lately,
> focused on moving home, other will have other distractions)
As Rod suggested I'll have the tools emit a
I'm currently syncing src/lib/msun with my private libm
repository where I do much of my hacking on libm issues.
In looking at diffs, I see a few lingering RCS and
$FreeBSD$ tags. For example, lib/msun/amd64/s_scalbnl.S
contains
/* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw
add variation of this to stock image to get better rescue media. maybe
installer could even be updated a bit. if that is really big issue. cons is
that this requires network to be present. but where to get packages from anyway
without it, perhaps dvd1. i actually find it confusing that highly
> Am 26.01.24 um 17:09 schrieb Rodney W. Grimes:
> >> Am 25.01.24 um 16:38 schrieb Ed Maste:
> >>> On Wed, 24 Jan 2024 at 12:30, Warner Losh wrote:
> >>> sbin/growfs/tests/legacy_test.pl
> >>> tools/regression/msdosfs/msdosfstest-2.sh
> >>> tools/regression/tmpfs/t_vnd
> >>>
301 - 400 of 138128 matches
Mail list logo
