Resetting MMC controller without physically removing the card

ddrescuesd card

I'm trying to rescue data from an SDHC card using ddrescue:

while true ; do ddrescue -d /dev/mmcblk0p1 mmc.img mmc.log ; done

The controller, I'm not sure if it's the one on the card or the one in my laptop, seems to return errors for all sectors (which shows up in syslog) after a certain number of bad sectors have been read (which don't show up in syslog), I found that popping the card out and into the slot again resets this and reports good sectors as good again until too many bad sectors have been read, and so on.

Currently I'm using this loop, keeping an eye on ddrescue's status output, resetting the card manually. Is there a way to reset the controller without removing the card, so the rescue process can run unattended?

Maybe this is related, but in this Dell laptop, for the reader to even notice a card has been inserted it must be done during boot or using echo 1 > /sys/bus/pci/rescan, but only once, after that the reader PCI device appears, and everything works as expected:

07:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30)
        Subsystem: Dell Device 046e
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f0600000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [a4] Power Management version 3
        Capabilities: [80] Express Endpoint, MSI 00
        Capabilities: [94] MSI: Enable- Count=1/1 Maskable- 64bit-
        Kernel driver in use: sdhci-pci

Relevant syslog:

# pop in card
mmc0: new SDHC card at address b368
mmcblk0: mmc0:b368 NCard 15.0 GiB (ro)
mmcblk0: p1
# ddrescue begins to read, error count increases, until at some point:
mmcblk0: error -110 transferring data, sector 12854624, nr 1, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 12854624
mmcblk0: error -110 transferring data, sector 12854625, nr 1, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 12854625
mmcblk0: error -110 transferring data, sector 12854626, nr 1, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 12854626
mmcblk0: error -110 transferring data, sector 12854627, nr 1, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 12854627
mmcblk0: error -110 transferring data, sector 12854628, nr 1, cmd response 0x900, card status 0x0
end_request: I/O error, dev mmcblk0, sector 12854628
# time since last successful read increases, pop out card
mmc0: Card removed during transfer!
mmc0: Resetting controller.
mmcblk0: error -123 sending status command, retrying
mmcblk0: error -123 sending status command, retrying
mmcblk0: error -123 sending status command, aborting
mmc0: card b368 removed
# GOTO 10

I also tried using a USB card reader, instead of generating these errors in syslog, it just disappears and needs to be re-plugged to continue.

It seems reloading the sdhci_pci module does the trick, but I wonder if there's a less brute-force option to do this:

while sleep 1 ; do
    ddrescue -d -T 1 /dev/mmcblk0p1 mmc.img mmc.log 
    modprobe -r sdhci_pci
    modprobe sdhci_pci
done

Best Answer

I had the same issue (I/O errors as shown above) after changing SD-cards on the fly in an embedded device (Kobo eBook Reader). It would not detect the new card, its capacity, and so on and instead expect the old card to be still present.

Reloading a module was not possible since the driver was built-in. device/delete or host/scan was not available. Setting a "removable" module parameter did not make it work.

The solution in my case was to unbind, and subsequently bind, the driver for the MMC block device.

# blockdev --getsize64 /dev/mmcblk0
3965190144
# readlink /sys/block/mmcblk0
../devices/platform/mxsdhci.2/mmc_host/mmc0/mmc0:af9e/block/mmcblk0
# echo mxsdhci.2 > /sys/bus/platform/drivers/mxsdhci/unbind
~~~ change card ~~~
# echo mxsdhci.2 > /sys/bus/platform/drivers/mxsdhci/bind
# blockdev --getsize64 /dev/mmcblk0
8168931328

The nice thing is this only affects the device you're interested in. If there's another card in the external slot (same driver, /dev/mmcblk1) it is unaffected.

Related Solutions

Mount SD Card – How to Mount an SD Card Without a Partition

The link /dev/$disk points to the whole of a block device, but, on a partitioned disk without unallocated space, the only part which isn't also represented in /dev/$disk[num] is the first 2kb-4mb or so - $disk's partition table. It's just some information written to the raw device in a format that the firmware and/or OS can read. Different systems interpret it in different ways and for different reasons. I will cover three.

On BIOS systems this table is written in the MBR master boot record format so the firmware can figure out where to find the bootable executable. It reads the partition table because in order to boot BIOS reads in the first 512 bytes of the partition the table marks with the bootable flag and executes it. Those 512 bytes usually contain a bootloader (like grub or lilo on a lot of linux systems) that then chainloads another executable (such as the linux kernel) located on a partition formatted with a filesystem the loader understands.
On EFI systems and/or BIOS systems with newer kernels this partition table can be a GPT GUID partition table format. EFI firmware understands the FAT filesystem and so it looks for the partition the table describes with the EFI system partition flag, mounts it as FAT, and attempts to execute the path stored in its Boot0000-{GUID} NVRAM variable. This is essentially the same task that BIOS bootloaders are designed to do, and, so long as the executable you wish to load can be interpreted by the firmware (such as most Linux kernels since v. 3.3), obviates their use. EFI firmware is a little more sophisticated.

After boot, if a partition table is present and the kernel understands it, /dev/${disk}1 is mapped to the 4mb+ offset and ends where the partition table says it does. Partitions really are just arbitrary logical dividers like:

start of disk | partition table | partition 1 | ... and so on | end of disk

Though I suppose it could also be:

s.o.d. | p.t. | --- unallocated raw space --- | partition 1 | ... | e.o.d.

It all depends on the layout you define in the partition table - which you can do with tools like fdisk for MBR formats or gdisk for GPT formats.

The firmware needs a partition table for the boot device, but the kernel needs one for any subdivided block device on which you wish it to recognize a filesystem. If a disk is partitioned, without the table the kernel would not locate superblocks in a disk scan. It reads the partition table and maps those offsets to links in /dev/$disk[num]. At the start of each partition it looks for the superblock. It's just a few kb of data (if that) that tells the kernel what type of filesystem it is. A robust filesystem will distribute backups of its superblock throughout its partition. If the partition does not contain a readable superblock which the kernel understands the kernel will not recognize a filesystem there at all.

In any case, the point is you don't really need these tables on any disk that need not ever be interpreted by firmware - like on disks from which you don't boot (which is also the only workable GPT+BIOS case) - and on which you want only a single filesystem. /dev/$disk can be formatted in whole with any filesystem you like. You can mkfs.fat /dev/$disk all day if you want - and probably Windows will anyway as it generally does for device types it marks with the removable flag.

In other words, it is entirely possible to put a filesystem superblock at the head of a disk rather than a partition table, in which case, provided the kernel understands the filesystem, you can:

mount /dev/$disk /path/to/mount/point

But if you want partitions and they are not already there then you need to create them - meaning write a table mapping their locations to the head of the disk - with tools like fdisk or gdisk as mentioned.

All of this together leaves me to suggest that your problem is one in these three:

your disk has no partition table and no filesystem
- It was recently wiped, never used, or is otherwise corrupt.
your disk's partition table is not recognized by your os kernel
- BIOS and EFI are not the only firmware types. This is especially true in the mobile/embedded realm where an SDHC card could be especially useful, though many such devices use layers of less-sophisticated filesystems that blur the lines between a filesystem and a partition table.
your disk has no partition table and is formatted with a filesystem not recognized by your os kernel

After rereading your comment above I'm fairly certain it is the latter case. I recommend you get a manual on that tv, try to find out if you can get whatever filesystem it is using loaded as a kernel module in a desktop linux and mount the disk there.

How to estimate loops/time for completion of GNU ddrescue (1.18.1) using current status

Even though the question was asked 10 months ago, the answer might be relevant because the recovery cycle might still be running depending on a few factors! No pun intended.

The reason is that, time estimate is almost impossible, however sometimes you could get a rough idea as follows. One of the most obvious reasons is that you can't predict how long it will take the drive to read a bad sector and if you want ddrescue to read and retry every single one, then it could take a very long time. For example, I'm currently running a recovery on a small 500GB drive that's been going on for over 2 weeks and I possibly have a few days left. But mine is a more complicated situation because the drive is encrypted and to read anything successfully, I have make sure to get all sectors that have partition tables, boot sectors and other important parts of the disk. I'm using techniques in addition to ddrescue to improve my chances for all the bad sectors. IOW, your unique situation is important in determining time to completion.

By estimate of "loops", if you mean number of retries then that's something you determine by the parameters you use. If you mean "total number of passes", that's easily determined by reading about the algorithm here.. >man ddrescue< / Algorithm: How ddrescue recovers the data

I'll specifically speak to the numbers in the screen captures you provided. Other situations may have other factors that apply, so take this information as a general guideline.

In the sample you've provided take a look at ddrescue's running status screen. We get the total "estimate" of the problem (rescue domain) by "errsize". This is the amount of data that is "yet to be read". In the sample it is 345GB. Next line below to the right is "average rate". In the sample it is 583kb/s

If the "average rate" was to remain close to steady, this means you have 7 more days to go. 345 GB / (583 kb * 60*60*24) = 7.18 However the problem is that you can't rely on the 583kb/s. In fact deeper you go into recovery, the drive gets slower since it's reading more and more tougher areas and is doing more retries. So the time to finish exponentially increases. All of this depends on how badly the drive is damaged.

The sample you've provided shows a "successful read" was over 10 hours ago. That's saying that it's not really getting anything from the drive for 10+ hours. This shows that your drive may have 345GB worth (or a portion) of data shot. This is very bad news for you.

In contrast, my second 500GB drive that had just started giving me "S.M.A.R.T" errors, was copied disk to disk (with log file on another drive) and the whole operation took about 8-9 hours. The last part of it slowed down. But that's still bearable. While the very bad drive, as noted above is well past 2 weeks working on 500GB and still has about 4-5 % remaining to recover.

HTH and YMMV

Best Answer

Related Solutions

Mount SD Card – How to Mount an SD Card Without a Partition

How to estimate loops/time for completion of GNU ddrescue (1.18.1) using current status

Related Question