>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN
>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP
>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to DOWN
>> Nov 30 03:23:18 7950X3D-UFS kernel: ue0: link state changed to UP
>> Nov 30 03:23:18
On Mon, Mar 04, 2024 at 09:54:14AM -0800, Mark Millard wrote:
> bob prohaska wrote on
> Date: Mon, 04 Mar 2024 16:35:52 UTC :
>
> > An armv7 (Pi2 v1.1) -current system stopped buildworld with
> >
> > c++: error: linker command failed with exit code 1 (use -v to see
> > invocation)
> > ***
On Mar 3, 2024, at 23:25, Jakob Alvermark wrote:
> On 12/4/23 09:16, Mark Millard wrote:
>> The following sort of thing is happening a lot:
>>
>> Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically
>> used on occasion, sometimes for long periods . . .
>>
>> Example contexts for
bob prohaska wrote on
Date: Mon, 04 Mar 2024 16:35:52 UTC :
> An armv7 (Pi2 v1.1) -current system stopped buildworld with
>
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [capsicum-test.full] Error code 1
There might have been more error messages at some
An armv7 (Pi2 v1.1) -current system stopped buildworld with
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [capsicum-test.full] Error code 1
make[6]: stopped in /usr/src/tests/sys/capsicum
.ERROR_TARGET='capsicum-test.full'
On 12/4/23 09:16, Mark Millard wrote:
The following sort of thing is happening a lot:
Ryzen 9 7950X3D using a USB Ethernet dongle that I've historically
used on occasion, sometimes for long periods . . .
Example contexts for the issue have been:
FreeBSD 15.0-CURRENT #126
Hi folks
Could those folks interested in the math.h library please review
https://reviews.freebsd.org/D44168 ?
It is a fix for 128-bit (IEEE float) tgammal(3), which has been a "stub"
implementation using the 80-bit version to date. The above patch fixes that.
Thanks!
M
--
Mark R V Murray
Dear FreeBSD Community,
The deadline for the next FreeBSD Status Report update is
March, 31st 2024 for work done since the last round of quarterly reports:
January 2024 - March 2024.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during the
Hi everyone,
we have a Lenovo Thinkpad P16s Gen2 (Type 21K9) here with an AMD Ryzen 7
CPU which we would like to install FreeBSD on. Alas, it won't boot.
The FreeBSD 15-CURRENT amd64 snapshot from February 22 hangs after:
[...]
acpi_acad0: on acpi0
battery0: on acpi0
A verbose boot
Yes, sorry for the inconvinience;
It turns out that for some reason, the three different compilers used
across various platforms (gcc12, gcc13 and clang) are not all similarly
strict with enum vs. int32 types, or are forgiving in slightly different
ways.
What happend was that I forgot a
> On Feb 25, 2024, at 11:38 PM, Michael Butler
> wrote:
>
> Building
> /usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/machine
> machine -> /usr/src/sys/amd64/include
> Building
> /usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/x86
> x86
Building
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/machine
machine -> /usr/src/sys/amd64/include
Building
/usr/obj/usr/src/amd64.amd64/sys/VM01-new/modules/usr/src/sys/modules/vmm/x86
x86 -> /usr/src/sys/x86/include
Building
Am 2024-02-24 21:18, schrieb Konstantin Belousov:
On Fri, Feb 23, 2024 at 08:34:21PM -0800, Gleb Smirnoff wrote:
Hi FreeBSD/main users,
the February 2024 stabilization week started with 03cc3489a02d that
was tagged
as main-stabweek-2024-Feb. At the moment of the tag creation we
already
On Fri, Feb 23, 2024 at 08:34:21PM -0800, Gleb Smirnoff wrote:
> Hi FreeBSD/main users,
>
> the February 2024 stabilization week started with 03cc3489a02d that was tagged
> as main-stabweek-2024-Feb. At the moment of the tag creation we already knew
> about several regression caused by
Moving these definitions breaks world outside the kernel :-(
building shared library libmapper_std.so.5
Building
/usr/obj/usr/src/amd64.amd64/lib/libiconv_modules/mapper_zone/libmapper_zone.so.5
building shared library libmapper_zone.so.5
Building
On Sat, Feb 24, 2024 at 03:59:01PM +, Gary Jennejohn wrote:
>
> The function run_rc_scripts is defined in /usr/src/libexec/rc/rc.subr and
> is called in /usr/src/libexec/rc/rc. /etc/rc includes /etc/rc.subr.
>
> So, maybe one of these files is not up to date under /etc?
>
My fault,
On Sat, 24 Feb 2024 06:53:37 -0800
bob prohaska wrote:
> A Pi4 running -current completed a build/install cycle for world and kernel
> without obvious errors but failed to reboot, reporting:
> ...
> Warning: no time-of-day clock registered, system time will not be set
> accurately
> Dual
On Sat, Feb 24, 2024 at 07:02:19AM -0800, David Wolfskill wrote:
>
> This is from an amd64 system at main-n268514-61b88a230bac, but
> run_rc_scripts is a shell function defined in /etc/rc.subr.
>
> So the whine about not finding run_rc_scripts would indicate that at
> least one of the following
A Pi4 running -current completed a build/install cycle for world and kernel
without obvious errors but failed to reboot, reporting:
...
Warning: no time-of-day clock registered, system time will not be set accurately
Dual Console: Serial Primary, Video Secondary
/etc/rc: run_rc_scripts: not found
Hi,
And whom do you want to „stab“ with this? ;)
Why not do the same thing that ports does and call this „monthly“ which is
pretty much what it is and easy to understand and you can have one build at the
end of that week?
Cheers,
Franco
> On 24. Feb 2024, at 12:51, Kirill Ponomarev wrote:
On 02/23, Mark Millard wrote:
> Gleb Smirnoff wrote on
> Date: Sat, 24 Feb 2024 04:32:52 UTC :
>
> > More seriously speaking, I
> > actually hope that in some future snapshots.FreeBSD.org will start using
> > these
> > points for snapshot generation.
>
> How about also the likes of:
>
>
Gleb Smirnoff wrote on
Date: Sat, 24 Feb 2024 04:32:52 UTC :
> More seriously speaking, I
> actually hope that in some future snapshots.FreeBSD.org will start using these
> points for snapshot generation.
How about also the likes of:
https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/
for
Hi FreeBSD/main users,
the February 2024 stabilization week started with 03cc3489a02d that was tagged
as main-stabweek-2024-Feb. At the moment of the tag creation we already knew
about several regression caused by libc/libsys split.
In the stabilization branch stabweek-2024-Feb we accumulated
Hi FreeBSD CURRENT users,
back in November I came up with a proposal of providing some stabilization
cadence to development of the main branch, also known as FreeBSD CURRENT. Here
is a video with the initial proposal and following discussion at VendorBSD
Conference (18 minutes):
On Fri, Feb 23, 2024 at 10:21:12AM -0800, Michael Dexter wrote:
> On 2/23/24 9:13 AM, Brooks Davis wrote:
> > Things are in a somewhat messy state. CASPER and CAPSICUM were moved to
> > a new __REQUIRED_OPTIONS list, but the various bits still exist and
> > there's even one use of MK_CASPER=no in
On 2/23/24 9:13 AM, Brooks Davis wrote:
Things are in a somewhat messy state. CASPER and CAPSICUM were moved to
a new __REQUIRED_OPTIONS list, but the various bits still exist and
there's even one use of MK_CASPER=no in Makefile.inc1. The commit
message (c24c117b9644) suggests that the intent
On 05-02-24 17:02, Brooks Davis wrote:
Could you do a quick test with an exe linked to libsys but not libc running
under Valgrind memcheck, please?
Could you suggest a more concrete example?
This little example seems to be OK
void _start(void)
{
_exit(0);
}
However I do see quite a
On Thu, Feb 22, 2024 at 07:49:08PM -0800, Michael Dexter wrote:
> All,
>
> The WITHOUT_CASPER build option was deprecated in main and 14-stable branches
> but is still showing up and will trip up the build option survey:
>
> sh src/tools/tools/build_option_survey/listallopts.sh | grep CASPER
>
All,
The WITHOUT_CASPER build option was deprecated in main and 14-stable
branches but is still showing up and will trip up the build option survey:
sh src/tools/tools/build_option_survey/listallopts.sh | grep CASPER
WITHOUT_CASPER
--- all_subdir_sbin/mdconfig ---
===> sbin/mdconfig (all)
Hi Lexi,
On Thursday, February 22, 2024 6:47:26 PM CET Lexi Winter wrote:
> hi Florian,
>
> Florian Walpen:
> > I have a Scarlett 18i20 myself, but maybe a different generation - it has
> > 18 recording channels as its name suggests. Is 20 recording channels
> > correct for your device?
>
>
On Thu, Feb 22, 2024 at 10:16:30AM -0800, Mark Millard wrote:
> Brooks Davis wrote on
> Date: Thu, 22 Feb 2024 02:03:09 UTC :
>
> > On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote:
> > > On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> > > > That's probably
Brooks Davis wrote on
Date: Thu, 22 Feb 2024 02:03:09 UTC :
> On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote:
> > On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> > > That's probably worth a shot. Static linking will work anyway because
> > > libc.a in effect
hi Florian,
Florian Walpen:
> I have a Scarlett 18i20 myself, but maybe a different generation - it has 18
> recording channels as its name suggests. Is 20 recording channels correct for
> your device?
this is a 3rd generation 18i20; as well the usual physical inputs it has
a stereo loopback
Hi Lexi,
On Thursday, February 22, 2024 2:45:07 AM CET Lexi Winter wrote:
> hello,
>
> since the commit:
>
> 42fdcd9fd917 snd_uaudio(4): Fix config detection with defaults set.
>
> my snd_uaudio(4) no longer works. the symptom is that applications
> attempting to play audio hang forever, and
Am 2024-02-21 10:52, schrieb hartmut.bra...@dlr.de:
Hi,
I updated yesterday and now event a minimal program with
cc -fsanitize=address
produces
ld: error: undefined symbol: __elf_aux_vector
referenced by sanitizer_linux_libcdep.cpp:950
On 21 Feb 2024, at 20:00, Brooks Davis wrote:
>
> The sanitizers reach somewhat questionably into libc internals that are
> exported to allow rtld to update them. I was unable to find an solution
> that didn't break this and I felt that fixing things like closefrom()
> using non-deprecated
On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote:
> On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> > That's probably worth a shot. Static linking will work anyway because
> > libc.a in effect embeds libsys to retain compatability.
> Please do not add libsys.so
hello,
since the commit:
42fdcd9fd917 snd_uaudio(4): Fix config detection with defaults set.
my snd_uaudio(4) no longer works. the symptom is that applications
attempting to play audio hang forever, and no audio is produced.
reverting this commit fixed the problem.
the issue only occurs if i
On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> That's probably worth a shot. Static linking will work anyway because
> libc.a in effect embeds libsys to retain compatability.
Please do not add libsys.so to the ABI. Right now it is an implementation
detail of libthr and libc, and
On 2024-02-20 10:09, Pete Wright wrote:
I just came across this blog post which seems to indicate that the drill(1)
utility from NLNet is ending development in favor of a rust based tool:
https://blog.nlnetlabs.nl/domain-dns-building-blocks-for-rust-application-developers/
That's probably worth a shot. Static linking will work anyway because
libc.a in effect embeds libsys to retain compatability.
-- Brooks
On Wed, Feb 21, 2024 at 09:12:41PM +0100, Dimitry Andric wrote:
> Can't we just add libsys.so to the /usr/lib/libc.so linker script? That would
> work for
Can't we just add libsys.so to the /usr/lib/libc.so linker script? That would
work for everything except static linking?
-Dimitry
> On 21 Feb 2024, at 21:00, Brooks Davis wrote:
>
> TL;DR: you can work around this by adding -lsys to the link line and I
> aim to improve the situation soon.
>
TL;DR: you can work around this by adding -lsys to the link line and I
aim to improve the situation soon.
The sanitizers reach somewhat questionably into libc internals that are
exported to allow rtld to update them. I was unable to find an solution
that didn't break this and I felt that fixing
[Brooks' activity related to commit 99ea67573164637d633e8051eb0a5d52f1f9488e
looks likely for what changed the status: "lib{c,sys}: move auxargs more
firmly into libsys".]
On Feb 21, 2024, at 09:02, Mark Millard wrote:
> On Feb 21, 2024, at 08:38, Mark Millard wrote:
>
>> Mark Johnston wrote
On Feb 21, 2024, at 08:38, Mark Millard wrote:
> Mark Johnston wrote on
> Date: Wed, 21 Feb 2024 13:33:43 UTC :
>
>> On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
>>> Hi,
>>>
>>> I updated yesterday and now event a minimal program with
>>>
>>> cc -fsanitize=address
Mark Johnston wrote on
Date: Wed, 21 Feb 2024 13:33:43 UTC :
> On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
> > Hi,
> >
> > I updated yesterday and now event a minimal program with
> >
> > cc -fsanitize=address
> >
> > produces
> >
> > ld: error: undefined symbol:
On Wed, 21 Feb 2024, Mark Johnston wrote:
MJ>On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
MJ>> Hi,
MJ>>
MJ>> I updated yesterday and now event a minimal program with
MJ>>
MJ>> cc -fsanitize=address
MJ>>
MJ>> produces
MJ>>
MJ>> ld: error: undefined symbol:
On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
> Hi,
>
> I updated yesterday and now event a minimal program with
>
> cc -fsanitize=address
>
> produces
>
> ld: error: undefined symbol: __elf_aux_vector
> >>> referenced by sanitizer_linux_libcdep.cpp:950
> >>>
Hi,
I updated yesterday and now event a minimal program with
cc -fsanitize=address
produces
ld: error: undefined symbol: __elf_aux_vector
>>> referenced by sanitizer_linux_libcdep.cpp:950
>>> (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950)
>>>
On Tue, Feb 20, 2024 at 11:21 AM Matthew L. Dailey
wrote:
>
> Hi all,
>
> I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after
> about 24 hours. This is the one without any debugging, so it only
> confirms the fact that the panics we've been experiencing still exist in
>
Hi all,
I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after
about 24 hours. This is the one without any debugging, so it only
confirms the fact that the panics we've been experiencing still exist in
CURRENT. There was some disk issue that prevented the dump, so all I
have
I just came across this blog post which seems to indicate that the
drill(1) utility from NLNet is ending development in favor of a rust
based tool:
https://blog.nlnetlabs.nl/domain-dns-building-blocks-for-rust-application-developers/
https://fosstodon.org/@nlnetlabs/111964417192522741
I was
On Mon, Feb 19, 2024 at 7:44 AM Matthew L. Dailey
wrote:
>
> Hi all,
>
> So I finally induced a panic on a "pure" ufs system - root and exported
> filesystem were both ufs. So, I think this definitively rules out zfs as
> a source of the issue.
>
> This panic was on 14.0p5 without debugging
Hi all,
So I finally induced a panic on a "pure" ufs system - root and exported
filesystem were both ufs. So, I think this definitively rules out zfs as
a source of the issue.
This panic was on 14.0p5 without debugging options, so the core may not
be helpful. The panic and backtrace are below
On 17 Feb 2024, at 12:15, Dimitry Andric wrote:
>
> On 17 Feb 2024, at 01:02, Bjoern A. Zeeb
> wrote:
>>
>>
>> probably related to the 20201215 UPDATING note:
>>
>> during an update from last year's main to now I hit the following error:
>>
>> install: /usr/libexec/kgdb exists but is not a
On 17 Feb 2024, at 01:02, Bjoern A. Zeeb wrote:
>
>
> probably related to the 20201215 UPDATING note:
>
> during an update from last year's main to now I hit the following error:
>
> install: /usr/libexec/kgdb exists but is not a directory
>
> Which is true as the old binary was still
Hi,
probably related to the 20201215 UPDATING note:
during an update from last year's main to now I hit the following error:
install: /usr/libexec/kgdb exists but is not a directory
Which is true as the old binary was still lingering around.
-r-xr-xr-x 1 root wheel 2833328 11 Aug. 2020
Hello,
Now that we have system tls-cert-store, if one needs to reference
a tls-cert-bundle like provided by ca_root_nss, do we need
to concatenate all of the certs listed in /usr/share/certs/trusted
into, for example cert.pem then symlink /etc/ssl/cert.pem to
that concatenated file?
thanks in
Hi all,
Before the week was out, I wanted to provide an update on this issue.
Last weekend, I installed two VMs with CURRENT
(20240208-82bebc793658-268105) - one on zfs and one on ufs - and built a
kernel with this config file:
include GENERIC
ident THAYER-FULLDEBUG
makeoptions DEBUG=-g
FreeBSD Status Report Fourth Quarter 2023
Here is the fourth 2023 status report, with 18 entries.
This is the last 2023 quarter. As you have probably noticed, this status report
comes later than usual and with fewer reports than the preceding quarter.
Indeed, please keep in mind that the last
On Wed, Feb 14, 2024 at 06:19:04PM -0800, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted
On Thu, Feb 15, 2024, 1:33 PM Mario Marietto wrote:
> Hello.
>
> What's the correct port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?
>
> A) https://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz
>
> B) https://cgit.freebsd.org/ports/snapshot/ports-release/12.4.0.tar.gz
>
A is your
Hello.
What's the correct port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?
A) https://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz
B) https://cgit.freebsd.org/ports/snapshot/ports-release/12.4.0.tar.gz
thanks.
On Thu, Feb 15, 2024 at 6:34 PM Jamie Landeg-Jones
wrote:
> Mario
On 2/14/24 11:03 PM, Mark Millard wrote:
On Feb 14, 2024, at 18:19, Mark Millard wrote:
Your changes have the RPi4B that previously got the
panic to boot all the way instead. Details:
I have updated my pkg base environment to have the
downloaded kernels (and kernel source) with your
changes
Mario Marietto wrote:
> After a lot of work I've been able to install FreeBSD 12.04 for armv7 on my
> ARM Chromebook. Now I would like to install some ports. This is what
> happens when I try to get a fresh ports tree :
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz
On Feb 14, 2024, at 18:19, Mark Millard wrote:
> Your changes have the RPi4B that previously got the
> panic to boot all the way instead. Details:
>
> I have updated my pkg base environment to have the
> downloaded kernels (and kernel source) with your
> changes and have booted with each of:
>
On Feb 14, 2024, at 18:23, Warner Losh wrote:
> You may need to grab the repo. You may have to back up to December's ports
> tree...
My understanding was that portsnap was staying installed
on 13.*-RELEASE until the last version is EOL and that
portsnap servers would be kept operational with
You may need to grab the repo. You may have to back up to December's ports
tree...
Warner
On Wed, Feb 14, 2024, 5:51 PM Mario Marietto wrote:
> Hello.
>
> After a lot of work I've been able to install FreeBSD 12.04 for armv7 on
> my ARM Chromebook. Now I would like to install some ports. This
Your changes have the RPi4B that previously got the
panic to boot all the way instead. Details:
I have updated my pkg base environment to have the
downloaded kernels (and kernel source) with your
changes and have booted with each of:
/boot/kernel/kernel
/boot/kernel.GENERIC-NODEBUG/kernel
For
Hello.
After a lot of work I've been able to install FreeBSD 12.04 for armv7 on my
ARM Chromebook. Now I would like to install some ports. This is what
happens when I try to get a fresh ports tree :
marietto@freebsd:/usr # sudo portsnap fetch extract
.
/usr/ports/databases/py-sqlalchemy10/
> Can we say that META is for speeding consecutives builds tracking
> current/stable and META + DIRDEPS for developing/testing specific
> parts of base code with speed + debug in mind?
The key focus of META_MODE is more reliable incremental builds, ensuring
targets are updated when anything that
[Added at bottom: EDK2 notes referencing the non-ECAM compliant
PCie in the BCM2711.]
On Feb 14, 2024, at 10:23, John Baldwin wrote:
> On 2/14/24 10:16 AM, Mark Millard wrote:
>> Top posting a related but separate item:
>> I looked up some old (2022-Dec-17) lspci -v output from
>> a Linux boot.
Hey John,
On Wed, Feb 14, 2024 at 10:30 AM John Baldwin wrote:
> On 2/14/24 8:42 AM, Warner Losh wrote:
> > On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
> >
> >> On 2/12/24 5:57 PM, Mark Millard wrote:
> >>> On Feb 12, 2024, at 16:36, Mark Millard wrote:
> >>>
> On Feb 12, 2024,
On 2/14/24 10:16 AM, Mark Millard wrote:
Top posting a related but separate item:
I looked up some old (2022-Dec-17) lspci -v output from
a Linux boot. Note the "Memory at" value 6 (in
the 35 bit BCM2711 address space) and the "(64-bit,
non-prefetchable)" (and "[size=4K]").
01:00.0 USB
On 2/14/24 9:57 AM, Mark Millard wrote:
On Feb 14, 2024, at 08:08, John Baldwin wrote:
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I was
Top posting a related but separate item:
I looked up some old (2022-Dec-17) lspci -v output from
a Linux boot. Note the "Memory at" value 6 (in
the 35 bit BCM2711 address space) and the "(64-bit,
non-prefetchable)" (and "[size=4K]").
01:00.0 USB controller: VIA Technologies, Inc.
On Feb 14, 2024, at 08:08, John Baldwin wrote:
> On 2/12/24 5:57 PM, Mark Millard wrote:
>> On Feb 12, 2024, at 16:36, Mark Millard wrote:
>>> On Feb 12, 2024, at 16:10, Mark Millard wrote:
>>>
On Feb 12, 2024, at 12:00, Mark Millard wrote:
> [Gack: I was looking at the wrong
On 2/14/24 8:42 AM, Warner Losh wrote:
On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I
On Wed, Feb 14, 2024 at 9:08 AM John Baldwin wrote:
> On 2/12/24 5:57 PM, Mark Millard wrote:
> > On Feb 12, 2024, at 16:36, Mark Millard wrote:
> >
> >> On Feb 12, 2024, at 16:10, Mark Millard wrote:
> >>
> >>> On Feb 12, 2024, at 12:00, Mark Millard wrote:
> >>>
> [Gack: I was looking
On 2/12/24 5:57 PM, Mark Millard wrote:
On Feb 12, 2024, at 16:36, Mark Millard wrote:
On Feb 12, 2024, at 16:10, Mark Millard wrote:
On Feb 12, 2024, at 12:00, Mark Millard wrote:
[Gack: I was looking at the wrong vintage of source code, predating
your changes: wrong system used.]
On
Can we say that META is for speeding consecutives builds tracking
current/stable and META + DIRDEPS for developing/testing specific
parts of base code with speed + debug in mind?
Simon J. Gerraty escreveu (domingo, 28/01/2024 à(s) 01:43):
>
> > I use meta-mode in /etc/src-env.conf so that if
Hi all,
> Am 13.02.2024 um 20:56 schrieb Pete Wright :
> 1. M.2 nvme really does need proper cooling, much more so than traditional
> SATA/SAS/SCSI drives.
I recently found a tool named "Scrutiny" that presents a nice dashboard
of all your disk devices and their SMART data including crucial
I had issues with a nvme drive in an intel nuc. When I asked
freebsd-hackers, overheating was the first guess:
https://lists.freebsd.org/pipermail/freebsd-hackers/2018-May/052783.html
I blew the dust out of the fan assembly and changed the bios fan
settings to be more aggressive and the
There's a tiny chance that this could be something more exotic,
but my money is on hardware gone bad after 2 years of service. I don't think
this is 'wear out' of the NAND (it's only 15TB written, but it could be if
this
drive is really really crappy nand: first generation QLC maybe, but it seems
Am 2024-02-13 01:58, schrieb Konstantin Belousov:
On Mon, Feb 12, 2024 at 11:54:02AM +0200, Konstantin Belousov wrote:
On Mon, Feb 12, 2024 at 10:35:56AM +0100, Alexander Leidinger wrote:
> Hi,
>
> dovecot (and no other program I use on this machine... at least not that I
> notice it) segfaults
On 12 Feb, Warner Losh wrote:
> On Mon, Feb 12, 2024 at 9:15 PM Don Lewis wrote:
>
>> On 12 Feb, Maxim Sobolev wrote:
>> > Might be an overheating. Today's nvme drives are notoriously flaky if you
>> > run them without proper heat sink attached to it.
>>
>> I don't think it is a thermal problem.
On Mon, Feb 12, 2024 at 9:15 PM Don Lewis wrote:
> On 12 Feb, Maxim Sobolev wrote:
> > Might be an overheating. Today's nvme drives are notoriously flaky if you
> > run them without proper heat sink attached to it.
>
> I don't think it is a thermal problem. According to the drive health
> page,
On 12 Feb, Maxim Sobolev wrote:
> Might be an overheating. Today's nvme drives are notoriously flaky if you
> run them without proper heat sink attached to it.
I don't think it is a thermal problem. According to the drive health
page, the device temperature has never reached Temperature 2,
On 12 Feb, Mark Johnston wrote:
> On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote:
>> I just upgraded my package build machine to:
>> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
>> from:
>> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
>> and I've had two nvme-triggered
On Mon, Feb 12, 2024 at 04:28:10PM -0800, Don Lewis wrote:
> I just upgraded my package build machine to:
> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> from:
> FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
> and I've had two nvme-triggered panics in the last day.
>
> nvme is
Might be an overheating. Today's nvme drives are notoriously flaky if you
run them without proper heat sink attached to it.
-Max
On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote:
> I just upgraded my package build machine to:
> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> from:
>
On Feb 12, 2024, at 16:36, Mark Millard wrote:
> On Feb 12, 2024, at 16:10, Mark Millard wrote:
>
>> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>>
>>> [Gack: I was looking at the wrong vintage of source code, predating
>>> your changes: wrong system used.]
>>>
>>>
>>> On Feb 12, 2024,
On Feb 12, 2024, at 16:10, Mark Millard wrote:
> On Feb 12, 2024, at 12:00, Mark Millard wrote:
>
>> [Gack: I was looking at the wrong vintage of source code, predating
>> your changes: wrong system used.]
>>
>>
>> On Feb 12, 2024, at 10:41, Mark Millard wrote:
>>
>>> On Feb 12, 2024, at
I just upgraded my package build machine to:
FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
from:
FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
and I've had two nvme-triggered panics in the last day.
nvme is being used for swap and L2ARC. I'm not able to get a crash
dump, probably
On Feb 12, 2024, at 12:00, Mark Millard wrote:
> [Gack: I was looking at the wrong vintage of source code, predating
> your changes: wrong system used.]
>
>
> On Feb 12, 2024, at 10:41, Mark Millard wrote:
>
>> On Feb 12, 2024, at 09:32, John Baldwin wrote:
>>
>>> On 2/9/24 8:13 PM, Mark
On Feb 12, 2024, at 10:02, John Kennedy wrote:
> On Mon, Feb 12, 2024 at 09:36:46AM -0800, John Baldwin wrote:
>> Without a stack trace it is pretty much impossible to debug a panic like
>> this.
>> Do you have KDB_TRACE enabled in your kernel config? I'm also not sure how
>> the
>> PCI
[Gack: I was looking at the wrong vintage of source code, predating
your changes: wrong system used.]
On Feb 12, 2024, at 10:41, Mark Millard wrote:
> On Feb 12, 2024, at 09:32, John Baldwin wrote:
>
>> On 2/9/24 8:13 PM, Mark Millard wrote:
>>> Summary:
>>> pcib0: mem
>>>
In message <20240212193044.e089d...@slippy.cwsent.com>, Cy Schubert writes:
> In message <625e0ea4-9413-45ad-b05c-500833a1d...@freebsd.org>,
> tuexen@freebsd.o
> rg writes:
> > > On Feb 12, 2024, at 10:36, Alexander Leidinger =
> > wrote:
> > >=20
> > > Hi,
> > >=20
> > > I got a coredump with
On 2/12/24 13:44, Michael Butler wrote:
On 2/12/24 12:36, John Baldwin wrote:
[ .. trimmed .. ]
Short of a stack trace, you can at least use lldb or gdb to lookup
the source line associated with the faulting instruction pointer (as
long as it isn't in a kernel module), e.g. for gdb you
In message <625e0ea4-9413-45ad-b05c-500833a1d...@freebsd.org>,
tuexen@freebsd.o
rg writes:
> > On Feb 12, 2024, at 10:36, Alexander Leidinger =
> wrote:
> >=20
> > Hi,
> >=20
> > I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
> Hi Alexander,
>
> we are aware of this problem,
401 - 500 of 138331 matches
Mail list logo
