2
A friend gave me a broken SD-card, hoping I might recover something from it. I have no trouble mounting any other cards, whatsoever. I am not getting any block devices in /dev, but the mmc subsystem recognizes the inserted card as mmc0 and lists it. edit3: the card specs from the mmc subsystem look good to me (appended in code section.)
edit2: this is not about data recovery per se. My question is if and how I can get any data from the recognized mmc0.
Is there any way to coax the recognized mmc device to give me at least some data or is everything lost?
I could not figure out what "mandatory SD Status" could be, but I guess that is a standard status for SD storage cards.
At least a binary dump of the contents could be helpful for recovering anything. I know this is kindof a lost cause, but I'd like to try anyway. From there on out, I should be good to go. I hope the blocks are not too randomly spread over the memory. I'd even go as far as cracking it open, but I guess I won't be able to do anything.
Sorry if this is a duplicate, I had to be really specific in my search since most of my hits were unrelated to the specific problem. Thank you :3
$ dmesg | tail -n3:
[10674.146692] mmc0: cannot verify signal voltage switch
[10674.244739] mmc0: card lacks mandatory SD Status function
[10674.244774] mmc0: new SD card at address 59b4
$ find /sys -name '*mmc*' (abbrev.)
/sys/bus/mmc/devices/mmc0:59b4
/sys/bus/mmc/drivers/mmcblk
/sys/bus/platform/devices/rtsx_pci_sdmmc.0
/sys/bus/platform/drivers/rtsx_pci_sdmmc/rtsx_pci_sdmmc.0
/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/rtsx_pci_sdmmc.0/mmc_host/mmc0/mmc0:59b4
/sys/class/mmc_host/mmc0
/sys/module/mmc_core/holders/mmc_block
/sys/module/mmc_core/holders/rtsx_pci_sdmmc
/sys/module/mmc_block
/sys/module/rtsx_pci/holders/rtsx_pci_sdmmc
/sys/module/rtsx_pci_sdmmc/drivers/platform:rtsx_pci_sdmmc
$ lspci -vvvs 04:00.0
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader (rev 01)
Subsystem: Lenovo Device 21dd
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 24
Region 0: Memory at f0600000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: rtsx_pci
Kernel modules: rtsx_pci
$ uname -a
Linux 4.4.1-2-ARCH #1 SMP PREEMPT Wed Feb 3 13:12:33 UTC 2016 x86_64 GNU/Linux
$ for i in /sys/bus/mmc/devices/mmc0:59b4/*; do echo -n "$i: "; cat $i; done
/sys/bus/mmc/devices/mmc0:59b4/cid: 041641534d495344000000000000b901
/sys/bus/mmc/devices/mmc0:59b4/csd: 00000000000000000000000000000001
/sys/bus/mmc/devices/mmc0:59b4/date: 09/2011
/sys/bus/mmc/devices/mmc0:59b4/erase_size: 0
/sys/bus/mmc/devices/mmc0:59b4/fwrev: 0x0
/sys/bus/mmc/devices/mmc0:59b4/hwrev: 0x0
/sys/bus/mmc/devices/mmc0:59b4/manfid: 0x000004
/sys/bus/mmc/devices/mmc0:59b4/name: SMISD
/sys/bus/mmc/devices/mmc0:59b4/oemid: 0x1641
/sys/bus/mmc/devices/mmc0:59b4/preferred_erase_size: 0
/sys/bus/mmc/devices/mmc0:59b4/scr: 0000000000000000
/sys/bus/mmc/devices/mmc0:59b4/serial: 0x00000000
/sys/bus/mmc/devices/mmc0:59b4/type: SD
/sys/bus/mmc/devices/mmc0:59b4/uevent: MMC_TYPE=SD
MMC_NAME=SMISD
MODALIAS=mmc:block
notice: I found a kernel subsystem bug relating to my card reader; it does not apply to my kernel verion, tho.
edit: for reference, this is how a new working card looks like in dmesg:
[18936.957097] mmc0: cannot verify signal voltage switch
[18937.064604] mmc0: new ultra high speed SDR104 SDHC card at address e624
[18937.064787] mmcblk0: mmc0:e624 SE16G 14.8 GiB
[18937.074743] mmcblk0: p1
I am trying to figure out what actually is wrong with the card, I am now compiling a kernel with mmc-debug. While reading SD Specs
edit4: after compiling the modified kernel I got new output. After comparing the simplified host controller specs (with the output I got) I realized that the simplified specs don't cover the process enough for me to understand the problem. Maybe if somebody with some insight can share their thoughts?
I documented the dmesg debug output to help with the situation:
it starts with this, maybe resets some things o_0, it gets better, soon.
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_get_cd: RTSX_BIPR = 0x00010000
mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 timing 0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_switch_voltage: signal_voltage = 0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: Initial signal voltage of 3.3v
mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
mmc0: starting CMD52 arg 00000c00 flags 00000195
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 52, arg = 0x00000c00
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: 0xFDA0(8): 80 01 00 00 00 1f 00 00
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: 0xFDA8(8): 00 ff ff ff ff ff 91 08
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: 0xFDB0(4): 00 00 00 08 00 00 00 00
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: 0xFD52(8): 04 55 00 14 0d 03 03 15
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: 0xFD5A(8): 55 01 02 01 01 00 aa aa
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: 0xFD62(8): e9 55 55 15 04 00 64 04
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: rtsx_pci_send_cmd error (err = -110)
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: CMD 52 0x00000c00 error(-110)
mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000
repeated once with:
mmc0: starting CMD52 arg 80000c08 flags 00000195
[...]
mmc0: req done (CMD52): -110: 00000000 00000000 00000000 00000000
reset card (1) CMD0
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
mmc0: starting CMD0 arg 00000000 flags 000000c0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 0, arg = 0x00000000
mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000
mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
voltage check (2) CMD8
mmc0: starting CMD8 arg 000001aa flags 000002f5
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 8, arg = 0x000001aa
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x000001aa
mmc0: req done (CMD8): 0: 000001aa 00000000 00000000 00000000
get SDIO OCR (5) CMD5 (shortened)
mmc0: starting CMD5 arg 00000000 flags 000002e1
mmc0: req failed (CMD5): -110, retrying...
mmc0: req failed (CMD5): -110, retrying...
mmc0: req failed (CMD5): -110, retrying...
mmc0: req done (CMD5): -110: 00000000 00000000 00000000 00000000
this is according to spec, since the card is type=capacity not type=sdio, so flag SDIO=0
I don't know what happens here, I guess it checks for (MP memory present): so step (11)?
mmc0: starting CMD55 arg 00000000 flags 000000f5
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 55, arg = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00400120
mmc0: req done (CMD55): 0: 00400120 00000000 00000000 00000000
since step (2) did not "succeed" this should be (12), spec says to reset the card with CMD0 in this case
mmc0: starting CMD41 arg 00000000 flags 000000e1
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 41, arg = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00ff8000
mmc0: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc0: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 timing 0
mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 timing 0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_switch_voltage: signal_voltage = 0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: Initial signal voltage of 3.3v
mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 0 timing 0
so, powermode 2 it is, then? CMD0 and CMD8 to start back on square one.
mmc0: starting CMD0 arg 00000000 flags 000000c0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 0, arg = 0x00000000
mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000
mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
mmc0: starting CMD8 arg 000001aa flags 000002f5
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 8, arg = 0x000001aa
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x000001aa
mmc0: req done (CMD8): 0: 000001aa 00000000 00000000 00000000
mmc0: starting CMD55 arg 00000000 flags 000000f5
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 55, arg = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00000120
mmc0: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc0: starting CMD41 arg 51300000 flags 000000e1
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 41, arg = 0x51300000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00ff8000
mmc0: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
repeats 34x times until:
mmc0: cannot verify signal voltage switch
since the working card produces the same output, I guess this is okay.
I don't know what CMD11 is. simple spec does not cover that.
mmc0: starting CMD11 arg 00000000 flags 00000015
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 11, arg = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00000320
mmc0: req done (CMD11): 0: 00000320 00000000 00000000 00000000
mmc0: clock 0Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_switch_voltage: signal_voltage = 1
mmc0: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
WOW. Were magically back in the spec at step (30) CMD2 is issued to get CID
mmc0: starting CMD2 arg 00000000 flags 00000067
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 2, arg = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x04164153
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[1] = 0x4d495344
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[2] = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[3] = 0x0000b901
mmc0: req done (CMD2): 0: 04164153 4d495344 00000000 0000b901
step (31) get RCA
mmc0: starting CMD3 arg 00000000 flags 00000075
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 3, arg = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x59b40500
mmc0: req done (CMD3): 0: 59b40500 00000000 00000000 00000000
RCA != 0 so CMD3 is not issued again. spec ends here.
so uuuuh... no clue. CMD9 is not covered in spec
mmc0: starting CMD9 arg 59b40000 flags 00000007
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 9, arg = 0x59b40000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[1] = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[2] = 0x00000000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[3] = 0x00000001
mmc0: req done (CMD9): 0: 00000000 00000000 00000000 00000001
nor is CMD7
mmc0: starting CMD7 arg 59b40000 flags 00000015
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 7, arg = 0x59b40000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00000700
mmc0: req done (CMD7): 0: 00000700 00000000 00000000 00000000
mmc0: starting CMD55 arg 59b40000 flags 00000095
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd_get_rsp: SD/MMC CMD 55, arg = 0x59b40000
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: cmd->resp[0] = 0x00000920
mmc0: req done (CMD55): 0: 00000920 00000000 00000000 00000000
mmc0: starting CMD51 arg 00000000 flags 000000b5
mmc0: blksz 8 blocks 1 flags 00000200 tsac 100 ms nsac 0
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_read_data: SD/MMC CMD 51, arg = 0x00000000
mmc0: req done (CMD51): 0: 00000000 00000000 00000000 00000000
mmc0: 8 bytes transferred: 0
comclusion:
mmc0: card lacks mandatory SD Status function
rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_get_ro: RTSX_BIPR = 0x00010000
mmc0: new SD card at address 59b4
welp.
einsweniger
Posted 2016-02-09T15:40:36.430
Reputation: 121
@Moab it is not a duplicate of that one. – einsweniger – 2016-02-09T17:29:11.613
1"Recovery of damaged SD card", looks like a dupe to me. We cannot answer every individual situation on data recovery. – Moab – 2016-02-09T17:32:39.703
@Moab I updated the question, is that more like it? – einsweniger – 2016-02-09T17:37:25.893
Does the card work in another PC, such as Windows. There is a logged kernel bug for the Realtek RTS5209 card reader in which it cannot recognize some cards properly, particularly with cards in excess of 8GB. https://bugzilla.kernel.org/show_bug.cgi?id=53581 and there is more information here: https://bbs.archlinux.org/viewtopic.php?id=164210
– acejavelin – 2016-02-09T19:32:33.440@acejavelin yeah, I've seen those. I cannot reproduce the bug in the same manner mentioned in the bug, the output is way different than mine. My 16 and 64 GB cards work fine :D both produce the "cannot verify voltage switch" message.
I will try on another PC anyways, as soon as I find one.
Problem is, I don't trust the Windows PC to leave the data on the card alone, trying to "repair" something automatically o_0 – einsweniger – 2016-02-09T20:27:11.620
"Recovering" data and "coaxing" data are pretty similar. Either you can directly access the data or you can't. Can you clarify what you're trying to do that's different? Are you trying to "repair" the card so you can access the data normally? – fixer1234 – 2016-02-10T01:04:10.397