A couple of b0rked SD cards lost me most of last week.

First, I didn't really think anything was wrong. I booted the grapeboards from them, sshd into them, and started doing my thing. But when I restarted the boards, the data was gone!

After a while of trying to explore that, I got weird read errors. Writing went fine. But the kernel log started showing errors.

What's happening here is that kernel buffers get in the way. Your write isn't actually going straight to the SD card but to an ...

... in-memory buffer that gets flushed to the block device some (short) time later, and that failed.

The trick to triggering this a bit more reliably is to write (relatively) much, not just a file edit or two. Apt upgrade was enough in my case.

Anyway, I took out SD card #1 and tried it in my laptop reader, and that had the same behaviour (phew!). I tried fscking it, and the program complained that it couldn't write the superblock. That's not good, it tends to contain a partition table. ...

... You don't have to write it often, but it should be reliably written. Shortly after that, the card just wasn't recognised any longer.

Before that happened, though, I cloned the SD card. I put the clone onto SD card #2, and booted it in a grapeboard... but the system that came up was the previous one! Weird!

So I tried writing the image again, but this time verified by removing and reinserting the card in my laptop reader. The card accepted all changes I wrote to it, but silently...

Follow

... discarded them! No hints in the kernel logs, either! And while card #1 had been used once or twice, #2 was fresh from the pack.

At this point I realized that the cards were SDXC cards, and the grapeboard has an SDHC drive. Specifically, they were 64GiB SDXC cards.

So this was even more confusing. They should not have been accepted in the drive at all! How could I have booted off them? It didn't make sense!

I "quickly" checked my laptop drive...

... In this case, it meant trying to match any kernel log messages involving the device file to output from lspci and lsusb, because I didn't know how the drive was wired up. A few false starts later, and I found it was some realtek device.

Realtek? Doesn't know anything about it on its website.

Any search results only mention which Linux kernel driver feels responsible for it, which I already knew from the kernel logs, thank you very much.

It was then that I recalled a deep, dark secret...

... lost in the mists of time is the forbidden knowledge that search engines provide more than one results page! I delved deep into this occult mystery...

I think it was page four that had a data sheet on some Chinese site, which unceremoniously and without further detail listed the device as supporting SDHC1.

Which, well, doesn't exist by that name.

But SDHC I does, and that's close enough. So on to the specs! They confirmed what I had sort of known before, that an SDXC card in an SDHC ...

... reader should not really work. But they did! Kind of.

I was despairing, and dug out a... Probably ten year old SD card? Something like that. Flashed an OS image and... It worked like a charm. Phew! The drive(s) seemed to be okay.

One of my colleagues tried to confirm, and went through much the same exercise, with much the same result.

The next day, another colleague went through much the same confusion, but dug out a debugger for the cards. That should be more interesting! ...

... well, card singular. The one that became unrecognised also revealed nothing to the debugger. Dead as a doornail.

The other one? Turns out, the SPI commands for committing a block to the card were acknowledged as successful. The card was straight up lying!

The end of the story is that also the manufacturer found this fascinating, and we're sending them back (and will get a replacement).

Other than a faulty batch, one guess might be that they're counterfeit? I guess we'll never know.

Sign in to participate in the conversation
Finkhäuser Social

A private instance for the Finkhäuser family.