Re: Changes in cam/nvme causes issues?

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 
> <Alexander@leidinger.net> 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

Bye,
Alexander.

> F

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF