Re: nvme controller reset failures on recent -CURRENT

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,

Re: nvme controller reset failures on recent -CURRENT

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, whatev

Re: nvme controller reset failures on recent -CURRENT

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

Re: nvme controller reset failures on recent -CURRENT

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 be

Re: nvme controller reset failures on recent -CURRENT

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: > Fr

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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, a

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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 09

nvme controller reset failures on recent -CURRENT

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

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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 Mi

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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 change

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[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 >>> 0x7d50-0x7d50

Re: kernel crash in tcp_subr.c:2386

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 so

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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 would

Re: kernel crash in tcp_subr.c:2386

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, but

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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 would use 'gdb /boot/kernel/kernel' and then 'l

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

On Feb 12, 2024, at 09:32, John Baldwin wrote: > 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_re

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

On 2/12/24 12:36, John Baldwin wrote: 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).

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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 reli

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

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

Kernel Panic sys/netinet/tcp_subr.c 2386

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? -Wolfram

Re: kernel crash in tcp_subr.c:2386

> 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--- > __

kernel crash in tcp_subr.c:2386

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 /space/system/usr_src/sys/amd64/inc

segfault in ld-elf.so.1

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).