Date: Mon, 22 Sep 2025 07:29:17 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 289748] ahci driver not attached on New supermicro board H13SSW starting from atlast 14.3 to CURRENT Message-ID: <bug-289748-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289748 Bug ID: 289748 Summary: ahci driver not attached on New supermicro board H13SSW starting from atlast 14.3 to CURRENT Product: Base System Version: Unspecified Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: satan@Ukr.net We received several Supermicro servers — AS-1115CS-TNR (https://www.supermicro.com/en/products/system/clouddc/1u/as%20-1115cs-tnr) They are based on the H13SSW motherboard with the latest BIOS, Turin 9355 CPU, and so on. Since local storage is only needed for system startup, and we have a stock of SATA SSDs, the chosen storage type is SATA. However, when trying to boot FreeBSD CURRENT 15-ALPHA2/ALPHA3 and 14.4-STABLE from an install source, we receive a kernel error when attempting to attach ahci0. ahci0: <AMD KERNCZ AHCI SATA controller> mem 0xc5201000-0xc52017ff irq 37 at device 0.0 numa-domain 0 on pci2 device_attach: ahci0 attach returned 6 ahci0: <AMD KERNCZ AHCI SATA controller> mem 0xc5200000-0xc52007ff irq 38 at device 0.1 numa-domain 0 on pci2 device_attach: ahci0 attach returned 6 output of pciconf -lv none3@pci0:226:0:0: class=0x010601 rev=0x93 hdr=0x00 vendor=0x1022 device=0x7901 subvendor=0x15d9 subdevice=0x1c85 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'FCH SATA Controller [AHCI mode]' class = mass storage subclass = SATA none4@pci0:226:0:1: class=0x010601 rev=0x93 hdr=0x00 vendor=0x1022 device=0x7901 subvendor=0x15d9 subdevice=0x1c85 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'FCH SATA Controller [AHCI mode]' class = mass storage subclass = SATA And of course, we don't see any devices — except the virtual CD-ROM via IPMI. We tried booting with verbose mode, but found no additional messages related to the issue. The situation is further complicated by the fact that we don’t have direct physical access to the machines, so preparing an installation medium on another system and deploying it to the target server is a time-consuming process. Could you please advise on what additional diagnostics we can perform, and generally help us resolve this issue? Thank you in advance. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-289748-227>