C2CZ: mmc0: error -110 whilst initialising SD card: Fix

By Noah Lindqvist · C2CZ · 1 September 2026 · Last verified: 2026-09-01

mmc0: error -110 whilst initialising SD card means the kernel's MMC controller tried to bring the card through the SD init sequence and the card stopped answering — -110 is ETIMEDOUT in the Linux errno table. Your Raspberry Pi (or laptop card reader, or SBC) either never boots or drops the card minutes after boot, and the same line repeats in dmesg every time the controller retries. I've chased this on Pi 4s that died in a rack after months of clean uptime, and the fix is usually one of four things — a dead card, a bad contact, a weak power supply, or a controller that can't complete the handshake. This post is the diagnostic order I use, with the exact commands and the durable fix.

TL;DR

-110 is a timeout, not a corruption error. The controller sent the init command (ACMD41/SD_APP_OP_COND, then the status polls) and got no valid response within the kernel's deadline. The card is electrically present but not completing the handshake.
The card is the suspect first, the slot second, the power third. In the majority of Raspberry Pi reports the card itself is dead or counterfeit — the init handshake fails before a single block is read.
Reseat and reflash with Raspberry Pi Imager before you buy anything. A card that was yanked mid-write can wedge in a state where it answers some commands but never finishes init; a fresh image with verify often clears it.
Test the card in a PC card reader. If it initialises there, the problem is the Pi's slot, adapter, or power rail. If it fails there too, the card is done — replace it.
The durable fix for production Pis is USB SSD boot — it removes the weakest component (the SD card) from the boot path entirely. Details in the last section.

What the error actually means

The string is printed by mmc_sd_init_card() in drivers/mmc/core/sd.c — the SD-specific part of the kernel's MMC core. During init the host sends the card the operating-condition handshake (CMD55 + ACMD41, with the 3.3V/1.8V signalling switch for UHS cards) and then polls the card state with CMD13. The controller has a hard timeout per command; when the card fails to respond in time, the core aborts init and logs error -110 whilst initialising SD card before retrying with a lower bus speed.

That retry behaviour is why you see the line repeated with decreasing bus frequencies, like this real capture from a failing card:

[    3.142170] mmc0: new high speed SDHC card at address e624
[    3.199567] mmcblk0: mmc0:e624 SS16G 14.8 GiB
[    4.218871] mmc0: card e624 removed
[    4.338268] mmc0: error -110 whilst initialising SD card
[    5.117728] mmc0: error -110 whilst initialising SD card
[    6.830340] mmc0: error -110 whilst initialising SD card

Read it as: the card was fine (it identified as a 14.8 GiB SanDisk at address e624), then vanished mid-operation, and every re-init attempt timed out. That pattern — card present, then gone, then unresponsive — is the classic signature of a failing card, not a software problem.

Two things this error is not: it is not a filesystem error (you won't fix it with fsck), and it is not a cmdline.txt/config problem. The failure happens before the kernel can even read the partition table, so no amount of boot-config editing helps. If you see it on a Pi that was working yesterday, start with hardware, not config.

Diagnose: three commands before you touch anything

On the Pi (if it boots at all) or from a serial console, confirm what you are dealing with and how often the controller retries:

# current boot's kernel log — the authoritative source for this error
journalctl -k -b | grep -i mmc

# older boots, to see when the card started failing
journalctl -k -b -1 | grep -i mmc

# is the card visible as a block device at all?
lsblk -f

What to look for:

Error repeats every few seconds → the controller is stuck in an init retry loop. Card is dead or the slot/adapter contact is bad.
Card appears as mmcblk0 after several attempts → marginal card or marginal power. It may boot if you're lucky, then die under load.
lsblk shows nothing → the init never succeeded. Go straight to the card test in the next section.

If the Pi itself won't stay up long enough to run this, skip ahead — the next test runs on a PC and doesn't need the Pi at all.

Fix 1: reseat and reflash with Raspberry Pi Imager

Shut the Pi down properly (sudo poweroff — never just pull the cable), eject the card, and push it back in until you feel the click. On a Pi 4/5 the spring-loaded holder can leave a card half-seated, and a half-seated card fails exactly like this: power and clock reach it, but the data lines don't make contact, so every command times out.

If reseating doesn't help, reflash the card with the official Raspberry Pi Imager (download for Windows/macOS/Linux from raspberrypi.com/software). Use the same OS you were running, and leave the verify step enabled — Imager reads the card back after writing and reports any mismatch. A verify failure on a card that otherwise formats fine is a reliable early-warning sign that the card's flash is degrading.

# on Raspberry Pi OS / Debian, install the imager from the official repo
sudo apt update && sudo apt install -y rpi-imager
# then: choose OS → choose your SD card → WRITE (keep verify ON)

One note from personal experience: don't use a bare dd image write when Imager is available. The Imager's verify pass catches marginal cards that dd silently writes over, and its OS-customisation step (hostname, SSH key, WiFi) saves a headless redeploy.

Fix 2: the card test that settles it

Pull the card and put it in a PC card reader — a USB reader, not the built-in slot, to rule out the laptop's own controller. Then run a full overwrite with the official SD Memory Card Formatter from the SD Association (the OS-format tools are not optimised for SD cards and leave the card in a state some controllers choke on).

After a full overwrite, re-run the init test:

# Linux: watch the kernel log while you insert the card in the PC reader
journalctl -k -f | grep -i mmc
# you want to see "new high speed SDXC/SDHC card" and an mmcblk0 line
lsblk -f

Card initialises on the PC but not on the Pi → the card is fine; the problem is the Pi's slot, adapter, or supply. Go to Fix 3.
Card fails on the PC too, even after a full overwrite → the card is dead or counterfeit. Replace it, and this time buy from a vendor on the Raspberry Pi SD card compatibility list — counterfeit cards are a top cause of this exact error and they fail within weeks.

If the card works on the PC but the Pi still won't boot with it, run the USB-reader test on the Pi itself: put the card in a USB adapter and plug it into a Pi USB port. A card that initialises over USB but not in the SD slot points at the slot's contacts or the board's SDIO routing — at which point the reliable move is the USB boot path in Fix 4.

Fix 3: power supply — the underrated cause

An undervolted Pi drops cards exactly like this. The SD controller needs a clean 3.3V rail; under brownout the card starts the init handshake and then the signalling collapses mid-command, which the controller reports as a timeout. Pi 4/5 official supplies are rated 5.1V/3A (27W for Pi 5); cheap phone chargers sag under load and produce intermittent -110 storms that look like a dead card.

Check whether the Pi ever throttled itself for power:

# bit 0 set = under-voltage currently detected; bit 2 = currently throttled;
# bits 16/18 = under-voltage / throttling has occurred since last boot;
# bit 19 = soft temperature limit has occurred since last boot
vcgencmd get_throttled
# example: 0x10000 = under-voltage occurred once since boot, not active now
# example: 0x50005 = under-voltage + throttling, both current and latched

If get_throttled shows bit 0 or bit 2 set, swap the supply for an official one and re-run the boot test before condemning the card. While you're at it, check the USB-C cable — a thin cable on a Pi 4 drops more voltage than most people expect. This is also worth checking on the laptop side: the same -110 error appears in laptop card-reader bugs when the reader's own rail sags (see the Ubuntu bug 1810416 thread for a long history of that).

Fix 4: the durable fix — boot from USB SSD instead

If this is a production Pi — a Klipper host, a home-automation controller, a self-hosted service — stop treating SD cards as a boot medium you can trust. SD cards wear out; the Pi's controller retries are a symptom of a component with a finite write life. Move the root filesystem to a USB SSD, and keep the SD card only for /boot/firmware if at all.

On a Pi 4/5 the cleanest path is Raspberry Pi Imager's bootloader utility:

# Imager → Misc utility images → Bootloader → USB Boot → write to a blank SD card
# insert that card, power on the Pi with the SSD attached, wait for the green LED
# once the Pi boots from USB, remove the SD card entirely

For an existing install, the manual route is to copy the running rootfs to the SSD and update the EEPROM boot order:

# check the current bootloader and update the EEPROM if needed
sudo rpi-eeprom-update -a
# then confirm the boot order prefers USB.
# BOOT_ORDER is read right-to-left: 0xf41 = SD (1) → USB mass storage (4) → RESTART (f)
# the stable Pi 4 default already is 0xf41; network boot would be digit 2 (e.g. 0xf241)

With the rootfs on SSD, the mmc0 error becomes a boot-time cosmetic line at worst (the controller probing an empty SD slot) and disappears entirely if you remove the card. I've run Klipper and Docker hosts off USB SSDs for over a year with zero card-related reboots — the error that used to take down the box now never appears.

Verification checklist

Step	Pass condition
`journalctl -k -b \| grep -i mmc`	No `-110` lines; card enumerated once as `mmcblk0`
`lsblk -f`	`mmcblk0p1`/`mmcblk0p2` (or SSD) mounted, root filesystem readable
`vcgencmd get_throttled`	Bits 0–2 clear (no undervoltage, no throttling)
Repeated power cycles (3×)	Boots clean every time; card survives a forced reboot
SSH in after boot	If you've ever had ssh_exchange_identification failures, confirm the box is reachable and stable over the network too

If the card passed the PC test, the power is clean, and the Pi still logs -110 from the SD slot, treat the slot as the fault and move to USB boot. Don't keep reflashing — I've seen teams burn a week on that loop. The same hardware-first logic applies to other flaky-sensor faults on these boards: an ADC out of range shutdown on a Klipper host is usually the wiring or the supply, not the config (see our Klipper "MCU 'mcu' shutdown: ADC out of range" fix for the same decision pattern).

Bottom line: mmc0: error -110 whilst initialising SD card is a hardware handshake timeout. Reseat, reflash with verify, test the card in a PC reader, check the supply, and if the workload matters, stop booting from SD entirely.