I/O errors from SD card slot? (Manjaro, kernel 5.7)

[zackw]

I'm getting I/O errors from some, but not all, attempts to use the SD card slot in my PBP.  `badblocks -w /dev/mmcblk1` completes without error, and `fdisk` is also happy, but when I attempt to run `mkfs.ext4` or `cryptsetup luksFormat` on the (single, whole-disk) partition, the operation fails and I see errors like this in dmesg:

Code:

blk_update_request: I/O error, dev mmcblk1, sector 2120 op 0x1:(WRITE) flags 0x8800 phys_seg 255 prio class 0
blk_update_request: I/O error, dev mmcblk1, sector 2128 op 0x1:(WRITE) flags 0x8800 phys_seg 254 prio class 0
blk_update_request: I/O error, dev mmcblk1, sector 2117 op 0x1:(WRITE) flags 0x8800 phys_seg 255 prio class 0
blk_update_request: I/O error, dev mmcblk1, sector 2127 op 0x1:(WRITE) flags 0x8800 phys_seg 255 prio class 0

(Only one error occurred per attempt to format the partition.)

I put the card into a different computer and was able to create a filesystem successfully, so I don't think the card itself is at fault. However, when I put the formatted card back into the PBP and tried to mount the filesystem or to run e2fsck on it, I got more of the same errors, just with different sector numbers and flags:

Code:

blk_update_request: I/O error, dev mmcblk1, sector 8301 op 0x1:(WRITE) flags 0x8800 phys_seg 251 prio class 0
blk_update_request: I/O error, dev mmcblk1, sector 40960 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
blk_update_request: I/O error, dev mmcblk1, sector 59023360 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

This is a 2019-batch PBP, so it shipped with MrFixit's modified Debian, and the card slot was working fine with that kernel; I only started seeing problems after I reflashed the internal storage with Manjaro. So right now I'm inclined to suspect a kernel bug. Anyone else seeing similar problems? Workarounds? Debugging advice?

[tophneal]

have you tried running 'badblocks -n -v /dev/mmcblkX'?

I had a similar issue with a uSD that was less than a month old. No matter what I did, when I put an OS to it, I'd get one boot before it wouldn't boot again. Ran the above command on it, and it turned out to be the uSD. Was able to easily get it RMA'ed with the output from badblocks.

[zackw]

have you tried running 'badblocks -n -v /dev/mmcblkX'?

I did not run that exact command but I did run `badblocks -w`, which AIUI does an even more aggressive test.  No problems were found.

[Surehand53]

have you tried running 'badblocks -n -v /dev/mmcblkX'?

I had a similar issue with a uSD that was less than a month old. No matter what I did, when I put an OS to it, I'd get one boot before it wouldn't boot again. Ran the above command on it, and it turned out to be the uSD. Was able to easily get it RMA'ed with the output from badblocks.

Hi tophneal.

What exactly does it mean to 'rma' the sd card with the badblocks output?

I have a similar problem, I can write (mostly) images to the sd cards but after one boot with updates the trouble starts, usually a read only file system.
I am using 5-6 different sd-cards though, some of them only a few weeks old.
Is there another way to test if the sd-card reader is maybe broken? Is that even a thing ?
Currently I am not able to boot anything reliable from sd card.

[tophneal]

Hi tophneal.

What exactly does it mean to 'rma' the sd card with the badblocks output?

I have a similar problem, I can write (mostly) images to the sd cards but after one boot with updates the trouble starts, usually a read only file system.
I am using 5-6 different sd-cards though, some of them only a few weeks old.
Is there another way to test if the sd-card reader is maybe broken? Is that even a thing ?
Currently I am not able to boot anything reliable from sd card.

"Return Merchandise Authorization"

I tested my suspect/bad SD card, and contacted SanDisk with the test output I got and my receipt for when I purchased the SD card. They agreed that the SD was bad, issued an RMA and sent me a replacement. (Typically, companies will request you send the faulty item back as part of the RMA, but given it's a bad SD card, this is unlikely.)

[25519]

I'm having the exact same problem. Whenever I try to write to the SD card, the operation fails and dmesg gets filled with messages like:

Code:

[  343.365760] blk_update_request: I/O error, dev mmcblk1, sector 15138815 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[  343.365785] Buffer I/O error on dev mmcblk1, logical block 1892351, lost async page write
[  343.367655] blk_update_request: I/O error, dev mmcblk1, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 5 prio class 0
[  343.367668] Buffer I/O error on dev mmcblk1, logical block 0, lost async page write
[  343.367725] Buffer I/O error on dev mmcblk1, logical block 1, lost async page write
[  343.367742] Buffer I/O error on dev mmcblk1, logical block 2, lost async page write
[  343.367757] Buffer I/O error on dev mmcblk1, logical block 3, lost async page write

Likewise, the SD card works perfectly in other computers, and this issue only appeared right after I installed the latest linux-pinebookpro and uboot-pinebookpro packages from Manjaro (versions 5.7.19 and 2020.10, respectively). Previously the system had mrfixit2001's Debian image and I did not experience this issue.

I also found another thread where someone seems to be experiencing the same issue after installing Manjaro. It seems likely that it's either a kernel issue or an issue in U-Boot.