Bug 109231
| Summary: | 1217:8520 [Dell Latitude E7450] O2 Micro, SD/MMC Card Reader doesn't work | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Alex Ballas (alex) |
| Component: | MMC/SD | Assignee: | drivers_mmc-sd |
| Status: | NEW --- | ||
| Severity: | normal | CC: | alex, ben.kero, chris, cosmo789lcn, dan, dennyvatwork, devrel, grant, happydemic, jeanluc.malet, k150976, kernelbugs.philipl, leho, pieter, rvanscherpe, Sergiy.Borodych, tony.darko, will, wolfram |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | v4.4-rc4 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Environment Info | ||
|
Description
Alex Ballas
2015-12-11 18:23:21 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/). 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: 4.8.0-27-generic 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 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. 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) 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 [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 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. Mee too on my Lenovo Ideapad 520-15IKB with Kingston SDHC 32GB card. lspci -nnk cut: 05:00.0 SD Host controller [0805]: O2 Micro, Inc. SD/MMC Card Reader Controller [1217:8621] (rev 01) Subsystem: Lenovo SD/MMC Card Reader Controller [17aa:3805] Kernel driver in use: sdhci-pci Kernel modules: sdhci_pci dmesg cut: [ 136.858651] mmc0: Tuning timeout, falling back to fixed sampling clock [ 136.858688] mmc0: new ultra high speed SDR104 SDHC card at address 0007 [ 137.199757] mmcblk0: mmc0:0007 SD32G 29.1 GiB [ 137.251857] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.501975] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.555314] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.555375] print_req_error: I/O error, dev mmcblk0, sector 0 [ 137.608643] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.608701] print_req_error: I/O error, dev mmcblk0, sector 4 [ 137.661967] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.662030] print_req_error: I/O error, dev mmcblk0, sector 6 [ 137.715135] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.715204] print_req_error: I/O error, dev mmcblk0, sector 7 [ 137.715209] Buffer I/O error on dev mmcblk0, logical block 0, async page read [ 137.768478] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.821837] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.875143] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.875213] print_req_error: I/O error, dev mmcblk0, sector 0 [ 137.928460] mmc0: Tuning timeout, falling back to fixed sampling clock [ 137.928524] print_req_error: I/O error, dev mmcblk0, sector 2 [ 137.930769] Buffer I/O error on dev mmcblk0, logical block 0, async page read [ 137.930807] ldm_validate_partition_table(): Disk read failed. [ 137.981800] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.035136] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.088495] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.088577] print_req_error: I/O error, dev mmcblk0, sector 0 [ 138.141797] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.141857] print_req_error: I/O error, dev mmcblk0, sector 1 [ 138.195188] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.195252] print_req_error: I/O error, dev mmcblk0, sector 2 [ 138.251798] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.251866] print_req_error: I/O error, dev mmcblk0, sector 6 [ 138.252500] Buffer I/O error on dev mmcblk0, logical block 0, async page read [ 138.305151] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.358481] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.411795] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.465134] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.518464] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.520772] Buffer I/O error on dev mmcblk0, logical block 0, async page read [ 138.571855] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.625145] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.681803] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.735326] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.788668] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.790035] Buffer I/O error on dev mmcblk0, logical block 0, async page read [ 138.790121] mmcblk0: unable to read partition table [ 138.845131] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.898475] mmc0: Tuning timeout, falling back to fixed sampling clock [ 138.951989] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.005317] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.058487] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.111820] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.165172] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.218504] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.271882] mmc0: Tuning timeout, falling back to fixed sampling clock [ 139.273955] Buffer I/O error on dev mmcblk0, logical block 7628784, async page read [ 149.868783] mmc0: card 0007 removed Workaround: load module "sdhci" with parameter debug_quirks2="0x4". Still present with Dell E7250 on 4.18.0-22 (Ubuntu 18.04.2) lspci --nnk 01:00.0 SD Host controller [0805]: O2 Micro, Inc. SD/MMC Card Reader Controller [1217:8520] (rev 01) Subsystem: Dell SD/MMC Card Reader Controller [1028:062d] Kernel driver in use: sdhci-pci Kernel modules: sdhci_pci dmesg: [ 1.369287] sdhci-pci 0000:01:00.0: SDHCI controller found [1217:8520] (rev 1) [ 1.371230] mmc0: Unknown controller version (3). You may experience problems. [ 1.373523] mmc0: SDHCI controller on PCI [0000:01:00.0] using ADMA [ 419.378067] mmc0: Tuning timeout, falling back to fixed sampling clock [ 429.519557] mmc0: Timeout waiting for hardware interrupt. [ 429.519561] mmc0: sdhci: ============ SDHCI REGISTER DUMP =========== [ 429.519566] mmc0: sdhci: Sys addr: 0x00000008 | Version: 0x00000603 [ 429.519571] mmc0: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000008 [ 429.519575] mmc0: sdhci: Argument: 0x00000008 | Trn mode: 0x0000003b [ 429.519580] mmc0: sdhci: Present: 0x01ff0000 | Host ctl: 0x00000017 [ 429.519584] mmc0: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 [ 429.519589] mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 [ 429.519593] mmc0: sdhci: Timeout: 0x0000000a | Int stat: 0x00000000 [ 429.519598] mmc0: sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b [ 429.519602] mmc0: sdhci: AC12 err: 0x00000004 | Slot int: 0x00000000 [ 429.519607] mmc0: sdhci: Caps: 0x25bec8bf | Caps_1: 0x1000207f [ 429.519612] mmc0: sdhci: Cmd: 0x0000123a | Max curr: 0x005800c8 [ 429.519616] mmc0: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x0742ff7f [ 429.519621] mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x80000900 [ 429.519624] mmc0: sdhci: Host ctl2: 0x0000800b [ 429.519628] mmc0: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x3541f208 [ 429.519629] mmc0: sdhci: ============================================ [ 450.058602] mmc0: Tuning timeout, falling back to fixed sampling clock The workaround still works for me: modprobe sdhci debug_quirks2="0x80000000" Commented at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523178 try this patch :
diff --git a/drivers/mmc/host/sdhci-pci-o2micro.c b/drivers/mmc/host/sdhci-pci-o2micro.c
index 19944b004..1d8938a68 100644
--- a/drivers/mmc/host/sdhci-pci-o2micro.c
+++ b/drivers/mmc/host/sdhci-pci-o2micro.c
@@ -681,7 +681,6 @@ static const struct sdhci_ops sdhci_pci_o2_ops = {
const struct sdhci_pci_fixes sdhci_o2 = {
.probe = sdhci_pci_o2_probe,
.quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
- .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD,
.probe_slot = sdhci_pci_o2_probe_slot,
#ifdef CONFIG_PM_SLEEP
.resume = sdhci_pci_o2_resume,
this fixed my issue on yoga 900 that have the same controler
|