Created attachment 197181 [details]
I have a Dell Latitude E7450 with a O2 Micro, SD/MMC Card Reader [1217:8520] card reader. When I insert my Sandisk ultra 64GB microSD (with a SD card adapter) I get the following errors.
Dmesg output after I insert the SD card:
[ 306.054203] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 306.055982] mmc0: tuning execution failed
[ 306.055987] mmc0: error -5 whilst initialising SD card
[ 306.466185] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 306.467964] mmc0: tuning execution failed
[ 306.467970] mmc0: error -5 whilst initialising SD card
[ 306.890205] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 306.891993] mmc0: tuning execution failed
[ 306.892005] mmc0: error -5 whilst initialising SD card
[ 307.330197] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 307.331980] mmc0: tuning execution failed
[ 307.331990] mmc0: error -5 whilst initialising SD card
I used the latest mainline kernel available to me 
$ uname -a
Linux cosmo 4.4.0-040400rc4-generic #201512061930 SMP Mon Dec 7 00:32:31 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
It was working fine for kernel versions older than 4.1.8.
I did a bisection and here is the first bad commit
> e6c69099f63c84e1825c0f742a76ff4a8afeaa9b is the first bad commit
> commit e6c69099f63c84e1825c0f742a76ff4a8afeaa9b
> Author: Adam Lee <email@example.com>
> Date: Mon Aug 3 14:33:28 2015 +0800
> mmc: sdhci-pci: set the clear transfer mode register quirk for O2Micro
> commit 143b648ddf1583905fa15d32be27a31442fc7933 upstream.
> This patch fixes MMC not working issue on O2Micro/BayHub Host, which
> requires transfer mode register to be cleared when sending no DMA
> Signed-off-by: Peter Guo <firstname.lastname@example.org>
> Signed-off-by: Adam Lee <email@example.com>
> Signed-off-by: Ulf Hansson <firstname.lastname@example.org>
> Signed-off-by: Greg Kroah-Hartman <email@example.com>
I originally logged this issue to the Ubuntu bug tracker, but it appears to be an upstream issue and so I was instructed to report here.
Please note that I use the latest Bios version for the model.
$ sudo dmidecode -s bios-version;sudo dmidecode -s bios-release-date
I'm suffering from the same problem but found a workaround for as long as there is no proper fix: loading the "sdhci" kernel module with the option "debug_quirks2="0x4" works for me (see also http://www.0xf8.org/2016/01/workaround-for-broken-o2-micro-sd-card-reader-support-since-linux-kernel-version-4-1-8/).
Also for visitors coming from Google, there is a related discussion on the linux-mmc mailing list at http://comments.gmane.org/gmane.linux.kernel.mmc/34979
A better work around is setting debug_quirks2="0x10000" or some other value that is non zero and doesn't include any existing quirks. The 0x4 quirk disables 1.8V support which means the new high speed modes (SDR104, DDR50, etc) are not available (apparently these are only valid in 1.8V mode).
debug_quirks2="0x10000" did the trick for me. Thanks! The SD speeds i was getting with 0x4 were too low.
I am having this issue in Ubuntu 16.10 on my Dell E7450 as well with kernel:
The workaround of debug_quirks2="0x10000" did the trick as well.
On 4.8.13 debug_quirks2="0x10000" doesn't work:
mmc0: Timeout waiting for hardware interrupt.
sdhci: =========== REGISTER DUMP (mmc0)===========
sdhci: Sys addr: 0x00000008 | Version: 0x00001002
sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000008
sdhci: Argument: 0x00000000 | Trn mode: 0x0000003b
sdhci: Present: 0x01ff0001 | Host ctl: 0x0000001f
sdhci: Power: 0x0000000f | Blk gap: 0x00000080
sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
sdhci: Timeout: 0x00000004 | Int stat: 0x00000000
sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
sdhci: Caps: 0x7568c881 | Caps_1: 0x00000807
sdhci: Cmd: 0x0000123a | Max curr: 0x00000000
sdhci: Host ctl2: 0x0000800b
sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000004120ce200
It's Intel NUC 6i5SY with SD Host controller: Intel Corporation Sunrise Point-LP Secure Digital IO Controller (rev 21).
However, 0x4 does work.
I am having this issue in Ubuntu 16.10 on my Dell E7450 as well with kernel
The workaround of passing the option debug_quirks2=65536 in my /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT parameter works for me. It allows SDR104 access to my UHS-II card (which appears to be the max speed the mmc driver is capable of today as it has not yet implemented the .4V bus voltage and whatever else might be required to support FD156 or HD312)
I can confirm having this issue with Fedora 25 on a Panasonic Let's Note CF-RZ5.
I can also confirm that unloading the sdhci/sdhci_pci modules, adding a debug_quirks2=0x10000 option, and loading the modules again causes my Sandisk Extreme 200GB MicroSD card to be recognized and read normally.
Same here. Fedora 25, kernel 4.9.5 on a Dell Latitude E5450.
Adding debug_quirks2=0x10000 to the kernel parameters solved the issue on my machine.
Me too™ on a Lenovo Yoga 900, with slightly different model of reader. debug_quirks2=0x10000 does the job with 4.9.14-200.fc25.x86_64.
02:00.0 SD Host controller : O2 Micro, Inc. Device [1217:8620] (rev 01) (prog-if 01)
Subsystem: Lenovo Device [17aa:3800]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at a1001000 (32-bit, non-prefetchable) [size=4K]
Memory at a1000000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [6c] Power Management version 3
Capabilities:  MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities:  Express Endpoint, MSI 00
Capabilities:  Virtual Channel
Capabilities:  Advanced Error Reporting
Capabilities:  Latency Tolerance Reporting
Capabilities:  L1 PM Substates
Kernel driver in use: sdhci-pci
Kernel modules: sdhci_pci
Confirmed on a Thinkpad Yoga 14 on Debian9.1 (kernel 4.9.0-3-amd64) using
03:00.0 SD Host controller: O2 Micro, Inc. Device 8620 (rev 01) (prog-if 01)
Subsystem: Lenovo Device 5041
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at f1c01000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at f1c00000 (32-bit, non-prefetchable) [size=2K]
Capabilities: <access denied>
Kernel driver in use: sdhci-pci
Kernel modules: sdhci_pci
However, I also see the kernel message "error -110 whilst initialising SD card":
[ 163.277284] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 163.279450] mmc0: tuning execution failed: -5
[ 163.279500] mmc0: error -5 whilst initialising SD card
[ 163.513203] mmc0: error -110 whilst initialising SD card
[ 164.161328] sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
[ 164.163495] mmc0: tuning execution failed: -5
[ 164.163545] mmc0: error -5 whilst initialising SD card
[ 164.422865] mmc0: error -110 whilst initialising SD card
I attempted using the debug_quirks2=0x10000, but it simply deferred the problem - the SD card was initialized and mounted successfully, but using it via the unison file synchronizer caused unison to lock up HARD (and unkillably), and I was unable to unmount the SD card. Fortunately after rebooting, the SD card was recoverable due to using an ext4 filesystem, but this has made me very reluctant to experiment with other debug_quirks2 values.
Also reported to Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871646, with some more information about the system.
So, in the last two years (yeah, it's been that long), the number of quirk2s in the driver has been increasing and increasing and in 4.15, it finally got to 0x10000 so the work-around will started turning on a quirk that breaks things. So, set the value to debug_quirks2=0x80000000 which is the last bit. But presumably, in another year or two, we'll fill up quirks2 and move on to quirks3 and then the work-around will no longer be possible without patching the kernel itself. Maybe we'll see it fixed by then? Who knows - I've never observed any negative behaviour with the work-around, but I never tried to understand why the original quirk was deemed more correct than not having it.