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 requestThe 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=0xa801Samsung 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 [email protected]: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org [email protected] : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
