Created attachment 199149 [details]
dmesg (inc. I/O Errors), pciconf -lv, dmesg (boot_verbose=1)
I'm seeing various sdhci-related errors on an Intel Skylake compute stick (STK2M364CC). In particular, there are controller timeouts on boot (sdhci_pc1-slot0), as well as various intermittent timeout and I/O errors during operation (sdhci_pci0-slot0, which I believe corresponds to the emmc).
1) Standard dmesg containing examples of both types; they each have the header REGISTER DUMP (all caps).
2) pciconf -lv
3) Verbose dmesg (i.e. boot_verbose=1); note that this only contains the controller timeout messages observed on boot, since the timeout and I/O errors are intermittent.
FreeBSD XYXY 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 email@example.com:/usr/obj/usr/src/sys/GENERIC amd64
Given the apparent similarity to bug 228340, I've tried running the dmesg with boot_verbose=1, hw.mmc.debug=2, hw.sdhci.debug=2 (as was suggested for that bug). However, this causes the dmesg buffer to fill up very quickly with messages like the following:
mmc0: REQUEST: CMD25 arg 0x1885b80 flags 0x35 data 32768
sdhci_pci0-slot0: CMD25 arg 0x1885b80 flags 0x35 dlen 32768 dflags 0x9
sdhci_pci0-slot0: result: 0
Related to the eventual resolution of bug 228340, a lot of the Intel platforms (Apollo Lake, Braswell, etc.) have had quirks added to sdhci_pci.c for emmc and SDXC behaviour (e.g. at r311794, r327315), but IDs 0x9d2b and 0x9d2d aren't currently included there (if I understand correctly, these are the relevant chip IDs indicated by pciconf). As a comparison, NetBSD identifies these as PCI_PRODUCT_INTEL_100SERIES_LP_EMMC and PCI_PRODUCT_INTEL_100SERIES_LP_SDXC (pcidevs.h), and seems to have also added quirks relating to the former to their sdhci_pci.c (see: https://freshbsd.org/commit/netbsd/04f42dba691dc8bdd3795cd51e04d9c95ce18db1?diff=sys%2Fdev%2Fpci%2Fsdhc_pci.c ).