[Bug 233147] sdhci/emmc Errors on Intel Skylake Compute Stick

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Nov 11 22:23:37 UTC 2018


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233147

            Bug ID: 233147
           Summary: sdhci/emmc Errors on Intel Skylake Compute Stick
           Product: Base System
           Version: 11.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: dal36 at gmx.co.uk

Created attachment 199149
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=199149&action=edit
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 at 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
).

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list