Bug 109231 - 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
Summary: 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: MMC/SD (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_mmc-sd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-11 18:23 UTC by Alex Ballas
Modified: 2018-06-11 09:49 UTC (History)
15 users (show)

See Also:
Kernel Version: v4.4-rc4
Tree: Mainline
Regression: Yes


Attachments
Environment Info (47.01 KB, application/octet-stream)
2015-12-11 18:23 UTC, Alex Ballas
Details

Description Alex Ballas 2015-12-11 18:23:21 UTC
Created attachment 197181 [details]
Environment Info

Hello,

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 [1]
$ 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 <adam.lee@canonical.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
>     command.
>     
>     Signed-off-by: Peter Guo <peter.guo@bayhubtech.com>
>     Signed-off-by: Adam Lee <adam.lee@canonical.com>
>     Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I originally logged this issue to the Ubuntu bug tracker[2], 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
A08
10/28/2015

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4-rc4-wily/ 
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523178

Thanks,
Alex
Comment 1 Pieter Hollants 2016-01-23 19:22:18 UTC
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/).
Comment 2 Pieter Hollants 2016-01-23 19:22:59 UTC
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
Comment 3 Philip Langdale 2016-05-26 00:09:08 UTC
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).
Comment 4 Alex Ballas 2016-05-28 23:32:16 UTC
debug_quirks2="0x10000" did the trick for me. Thanks! The SD speeds i was getting with 0x4 were too low.
Comment 5 Ron 2016-11-10 23:58:03 UTC
I am having this issue in Ubuntu 16.10 on my Dell E7450 as well with kernel:
4.8.0-27-generic

The workaround of debug_quirks2="0x10000" did the trick as well.
Comment 6 k150976 2016-12-17 02:16:10 UTC
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
sdhci: ===========================================

It's Intel NUC 6i5SY with SD Host controller: Intel Corporation Sunrise Point-LP Secure Digital IO Controller (rev 21).

However, 0x4 does work.
Comment 7 Dan Colquhoun 2017-01-15 19:16:24 UTC
I am having this issue in Ubuntu 16.10 on my Dell E7450 as well with kernel
4.9.3-xanmod6. 

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)
Comment 8 Ben Kero 2017-01-20 03:29:57 UTC
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.
Comment 9 Daniele Viganò 2017-01-30 09:09:09 UTC
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.
Comment 10 Will Thompson 2017-04-06 06:58:05 UTC
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 [0805]: 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: [48] MSI: Enable- Count=1/1 Maskable+ 64bit+
	Capabilities: [80] Express Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Capabilities: [200] Advanced Error Reporting
	Capabilities: [230] Latency Tolerance Reporting
	Capabilities: [240] L1 PM Substates
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci_pci
Comment 11 Jon Leech 2017-08-10 23:52:07 UTC
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.
Comment 12 Philip Langdale 2018-06-11 09:49:14 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.