Re: Changes in cam/nvme causes issues?

On Tue, Dec 23, 2025 at 7:19 AM Alexander Leidinger <[email protected]>
wrote:

> Am 2025-12-23 10:31, schrieb Alexander Leidinger:
>
> Am 2025-12-22 17:58, schrieb Warner Losh:
>
>
>
> On Sun, Dec 21, 2025 at 8:37 AM Alexander Leidinger <
> [email protected]> wrote:
>
> Am 2025-12-14 14:05, schrieb Warner Losh:
>
> Let's do one issue at a time. There's too much missing info. Top posting
> since there's  not a lot of context to this request
>
>
> The disk died now completely, so the CRC errors are out of reach now.
>
>
> First, let's start with pciconf -l of the nvme drive. I have a strong
> idea, but need some data.
>
>
> While already provided privately with some other data, here for the public
> so that people are aware that currently there is an issue with such drives:
> nvme0@pci0:5:0:0: class=0x010802 rev=0x00 hdr=0x00 vendor=0x144d
> device=0xa809 subvendor=0x144d subdevice=0xa801
> Samsung SSD 980 1TB 2B4QFXO7 S649NL0T819360V
>
>
> Yea, so far this is the only report I've received, and there's not enough
> data in it to reproduce it with any of the dozen NVMe drives that I have,
> or to spot a difference with what I know I check in the code. So if it's
> compiled into the kernel with cam also compiled into the kernel, I know it
> works.
>
>
> CAM is in the kerne, nvme is loaded as a module (from 15-current):
> ---snip---
> # kldstat | egrep '(nvm|cam)'
>  2    1 0xffffffff811e3000    20db8 nvme.ko
> ---snip---
>
> I will do a clean rebuild with the most recent 16-current and provide a
> full dmesg if this still doesn't work.
>
>
> As a module it fails:
> [1] link_elf_obj: symbol nvme_handle_aen_desc undefined
> [1] KLD file nvme.ko - could not finalize loading
>

The kld problem has been fixed.

Warner


> Bye,
> Alexander.
>
> F
>
>
> --
> http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF
>