This is perhaps a novelty problem report. And it's also a throw away card data wise, and is a $12 Samsung EVO+ SDXC card used in an Intel NUC. Kernel is 4.15.14-300.fc27.x86_64 It contains FAT, ext4, and Btrfs file systems. They can all be fsck'd, but none can be mounted. Even if it use blockdev --setro on the entire mmc device and then mount -o ro it still fails. Kinda weird huh? [68498.521260] mmc0: new ultra high speed SDR104 SDHC card at address 59b4 [68498.521990] mmcblk0: mmc0:59b4 EB2MW 29.8 GiB [68498.530899] mmcblk0: p1 p2 p3 p4 [68507.152842] BTRFS info (device mmcblk0p4): using free space tree [68507.152919] BTRFS info (device mmcblk0p4): has skinny extents [68507.165855] BTRFS info (device mmcblk0p4): bdev /dev/mmcblk0p4 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0 [68507.192935] BTRFS info (device mmcblk0p4): enabling ssd optimizations [69107.488123] mmc0: Card stuck in programming state! mmcblk0 card_busy_detect [69107.539128] mmc0: Tuning timeout, falling back to fixed sampling clock The corrupt 10 was fixed with a scrub months ago, and I never reset the counter so that's not a current corruption. The most recent scrub was maybe a week ago. And even offline scrub works. So literally every single block related to this Btrfs file system is readable, and yet it's not mountable? Very weird. Anyway, that's it. No further errors. No timeouts. User space is hung on the mount command. mccqd/0 is using 7% CPU, the stack for that process is: [root@f27s ~]# cat /proc/2865/stack [<0>] mmc_wait_for_req_done+0x7b/0x130 [mmc_core] [<0>] mmc_wait_for_cmd+0x66/0x90 [mmc_core] [<0>] __mmc_send_status+0x70/0xa0 [mmc_core] [<0>] card_busy_detect+0x59/0x160 [mmc_block] [<0>] mmc_blk_err_check+0x170/0x640 [mmc_block] [<0>] mmc_start_areq+0xc6/0x3c0 [mmc_core] [<0>] mmc_blk_issue_rw_rq+0xcf/0x3b0 [mmc_block] [<0>] mmc_blk_issue_rq+0x298/0x7c0 [mmc_block] [<0>] mmc_queue_thread+0xce/0x160 [mmc_block] [<0>] kthread+0x113/0x130 [<0>] ret_from_fork+0x35/0x40 [<0>] 0xffffffffffffffff [root@f27s ~]# Basically the card is in some sort of state that the kernel code is not going to ever second guess. So there's no further error or reset attempt. # cat /sys/block/mmcblk0/queue/scheduler noop [deadline] cfq This part of the stack trace is interesting: mmc_blk_issue_rw_rq Something wants to write something, even though I'm using mount -o ro, and also blockdev --setro should prevent any writes from being attempted? Almost sounds like user error... -- Chris Murphy
