Bug 233147 - sdhci/emmc Errors on Intel Skylake Compute Stick
Summary: sdhci/emmc Errors on Intel Skylake Compute Stick
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2018-11-11 22:23 UTC by dal36
Modified: 2018-11-11 22:23 UTC (History)
0 users

See Also:

dmesg (inc. I/O Errors), pciconf -lv, dmesg (boot_verbose=1) (140.47 KB, text/plain)
2018-11-11 22:23 UTC, dal36
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description dal36 2018-11-11 22:23:35 UTC
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).

I've attached:
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.

uname -a
FreeBSD XYXY 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018     root@amd64-builder.daemonology.net:/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 ).