x220 sd carder-reader strange Windows behavior

[felixkrull]

Hi,

strange problem with newly aquired (refurbished) x220 4291-QT1.

After installing Windows 7-64 the sd-cardreader is propely shown in device manager but after inserting a card there is no drive visible (i.e. card is not mounted).

Some research on the web showed that it may be a drivers issue involving incorrect PCI-IDs, see:
http://forums.lenovo.com/t5/X-Series-Th ... d-p/599291

however, this did not help. (Although indeed the PCI-IDs differed in the same way as described there)

Now the interesting part: when booting into a Linux-Live-CD (CentOS) the SD card (64GB SDXC) is mounted properly and if I then warm-reboot into Windows: the card is there as well!!!

I can only assume that Linux is doing something with this card which makes it visible in Windows (PCI registers?).

Does anybody know what this could be about?


thx,
fk

[felixkrull]

some additional things that I noticed.

-- once the SD card works under Windows it can be removed and re-inserted w/o problems
-- once the SD card works under Windows one can perform a warm reboot. A cold-boot re-introduces problem

-- now something stunning (for me). there is a differene in PCI-IDs between working and non-working scenario:

1. if the card does not work under Windows (but the card reader is properly recognized) the card reader has the following PCI-ID (retrieved through pciutils)

0d:00.0 System peripheral [0880]: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823] (rev 04) (prog-if 01)
Subsystem: Lenovo Device [17aa:21da] [...]

2. if the card works after warm-boot into Windows after the Linux boot the PCI-ID of the card reader is as follows:

0d:00.0 System peripheral [0880]: Ricoh Co Ltd MMC/SD Host Controller [1180:e822] (rev 07) (prog-if 01)
Subsystem: Lenovo Device [17aa:21da] [...]

It appears the PCI-IDs of a device are not fixed but subject to some parameter of the device initilization???


fk

[automobus]

In the past, we could look at PSREF to learn what is multifunction chipset. Today's PSREF from junk company LeNOvo is not as comprehensive as it was when IBM still compiled it.
http://www.lenovo.com/psref/pdf/ltwbook_2013.pdf

We should find, what is ACTUAL chip used. I cannot find good photos of X220 planar. Nor a good block diagram. The closest I found is unreadable.

I have a guess: Ricoh chose to use ID e823 for PCIe SD 3, rather than reuse ID e822. I get this idea, after reading dr_st's review of SD adapters.

A possible test to invalidate my guess: if you can demonstrate throughput in excess of 25 Mo per second, using ID e822, then my guess is incorrect.

What ID does your LiveCD use? If you Linux realises throughput in excess of 25 Mo/s using ID e823, that would support my guess.

[felixkrull]

[...]
I have a guess: Ricoh chose to use ID e823 for PCIe SD 3, rather than reuse ID e822. I get this idea, after reading dr_st's review of SD adapters.

A possible test to invalidate my guess: if you can demonstrate throughput in excess of 25 Mo per second, using ID e822, then my guess is incorrect.

What ID does your LiveCD use? If you Linux realises throughput in excess of 25 Mo/s using ID e823, that would support my guess.

That is a good idea, at least it would be a variable in how the reader is initialized. The Linux PCI-ID is the same as the one under Windows when the card can be successfully mounted --> lspci shows:

0d:00.0 System peripheral [0880]: Ricoh Co Ltd MMC/SD Host Controller [1180:e822] (rev 07) (prog-if 01)

Output of "sudo hdparm -t /dev/mmcblk0" gives 18,24 MB/s ...

Could this mean Windows (cold-boot) is trying the wrong SD-mode?


thanks,
fk

[automobus]

Maybe, Windows is not trying the 'wrong' mode, but software clearly is broken. If driver would work, then you would see no problem and would need no help.

I assume:
Ricoh conventional PCI devices, ALL PCI ID begin with 0.
Ricoh PCI Express (PCIe) devices, ALL PCI ID begin with e.

I observe, e822 was since three years ago not discussed. E822 and e823 both together was not discussed. So I assume:
Ricoh PCIe SD Host Controller device e822, ALL revision are pre-SD3.
Ricoh PCIe SD Host Controller device e823, ALL revision are SD3.

Maybe, revision 04 of e823 is not functional. Then driver for Windows, if it would work, configures Ricoh chip to e822.
Or, maybe, Linux does not yet support e823 rev 04, so it forces fall-back to e822. Then driver for Windows, if it would work, uses e823.

Did you see '[Lenovo ThinkPad T420] Borked Ricoh SD card reader e823; device misidentifies as e822 after system reboot'? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/939548 I expect, in a few years from now, the code will be more mature.



I hate SD, I like to call it ScheißDigital. I say that as a joke; I do not want to offend you. I hardly know what I am talking about: it took me LONG time to find Linux sdhci quirk table! (I wanted to know what is sdhci debug_quirks=0x4671.) Apparently, drivers/mmc/host/sdhci.h is different than include/linux/mmc/sdhci.h. I proceeded to spend seven minutes, trying to learn what is the difference between /include and rest of Linux source tree. I fond this text in book "The Linux Kernel", but I still do not understand.

[dr_st]

This is really a strange case. And it's even stranger that it is also reported on the Lenovo forums (i.e., more than a one-time glitch).

Changing PCI IDs on the fly by something other than the BIOS is possible, but certainly not common.

I have an X220 with the same Ricoh card reader, with Windows 7 installed on it, and it works just fine. The PCI ID shows E823 rev 4, and speeds are in line with the faster UHS-I (SD spec version 3).

The driver used (according to Device Manager) is for Ricoh PCIe SDXC/MMC Host Controller, by Ricoh Company, version 6.10.10.32, dated 25/05/2011.

I will try a Linux LiveCD (cannot do it today, but maybe tomorrow; please remind me if I somehow forget) and see how it behaves there.

My theory - maybe there is something wrong with the hardware or the hardware configuration, which makes it dysfunctional in the faster SD3 mode. Linux successfully negotiates some fallback to the legacy mode (which persists until cold reboot), but Windows does not do it, and instead attempts to operate in the nominal mode, which fails.

In the meanwhile - let's see if we can find any discrepancies in the PCI config space registers of the devices, as well as the PCIe root port above it. Sometimes the culprits are at the parent port, not the device itself.

Here's what I have for the root port:

Code: Select all

C:\>lspci -s 0:1c.4 -vv
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) (prog-if 00 [Normal
 decode])
        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
        Bus: primary=00, secondary=0d, subordinate=0d, sec-latency=0
        I/O behind bridge: 00003000-00003fff
        Memory behind bridge: f1500000-f1cfffff
        Prefetchable memory behind bridge: 00000000f0c00000-00000000f13fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #5, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
                        ClockPM- Surprise- LLActRep+ BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
                SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
                        Slot #4, PowerLimit 10.000W; Interlock- NoCompl+
                SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
                        Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
                SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
                        Changed: MRL- PresDet- LinkState-
                RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
                RootCap: CRSVisible-
                RootSta: PME ReqID 0000, PMEStatus- PMEPending-
                DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: 00000000  Data: 0000
        Capabilities: [90] Subsystem: Lenovo Device 21da
        Capabilities: [a0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

And for the card reader itself:

Code: Select all

C:\>lspci -s d:0.0 -vv
0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 04) (prog-if 01)
        Subsystem: Lenovo Device 21da
        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 16
        Region 0: Memory at f1500000 (32-bit, non-prefetchable)
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [78] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
        Capabilities: [80] Express (v1) Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
                        ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 unlimited
                        ClockPM+ Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-

[GomJabbar]

I've also seen behavior like this on my X220. See if the following is any help (for Windows).

http://forum.thinkpads.com/viewtopic.ph ... 86#p722786

[dr_st]

OK, I can confirm this strange behavior.

• Booting a Linux LiveCD (Lubuntu 14.0.1) causes the card reader device ID to change from E823 to E822.
• Testing the speed of the device using HDParm shows ~20MB/s, which means the card reader is not working in UHS-I mode under Linux.
• Rebooting into Windows keeps the E822 device ID (and Windows does not recognize it, because the driver for the device has not been installed).
• Turning the PC off (shutdown or hibernate) restores the device ID to E823 (unless Linux is booted again) and the read speed in Windows is ~85MB/s, which indicates UHS-I mode.

It is obvious that the device is really E823. Furthermore, when Linux is booted, it first detects it as E823 (according to SDHCI-PCI printouts in the kernel logger), but then something causes the actual PCI config space to change to E822 (confirmed with LSPCI). I have no idea what causes this strange behavior, but I'll see if I can find something.

Note that OP's problem seems to be opposite - E822 works in Windows, E823 doesn't. I would double check again that the correct driver for E823 is installed.

Windows 7 version of the driver I have:
Ricoh PCIe SDXC/MMC Host Controller, by Ricoh Company, version 6.10.10.32, dated 25/05/2011.

Windows 8.1 version of the driver I have:
Ricoh PCIe SDXC/MMC Host Controller, by Ricoh Company, version 6.20.11.42, dated 04/07/2012.