Kmod-sdhci-mt7620 problem: Couldn't find valid filesystem superblock

Hi,

I apologize for the long post but I am trying to give as much information as possible.

Environment:

OpenWRT version: 18.06.1
system type : MediaTek MT7621 ver:1 eco:3
machine : ZBT-WG3526 (16M)
cpu model : MIPS 1004Kc V2.15
kmod-sdhci-mt7620 : 4.14.63-1

I am trying to use sdcard with the latest version (18.06.1, using previously 17.04.01). I installed the following packages in to enable sdcard support:

opkg install kmod-sdhci-mt7620 block-mount kmod-fs-vfat kmod-fs-ext4 kmod-fs-msdos kmod-fs-ntfs dosfstools e2fsprogs blkid dumpe2fs tune2fs

If I format the card using mk2fs.ext4 (see command below), the command completes successfully but I cannot mount the card.

mkfs.ext4 -b 4096 -O "^has_journal" -L sdcard -t ext4 /dev/mmcblk0

mke2fs 1.44.1 (24-Mar-2018)
Creating filesystem with 15630336 4k blocks and 3907584 inodes
Filesystem UUID: cdaa7018-ed73-4ed9-971b-80c5bb586bba
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

dumpe2fs /dev/mmcblk0

dumpe2fs 1.44.1 (24-Mar-2018)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mmcblk0
Couldn't find valid filesystem superblock.

If I format the card on a linux machine (Fedora 27), then I can mount it, but after I run dumpe2fs, and umount it then the error happens again:

dumpe2fs /dev/mmcblk0p1

dumpe2fs 1.44.1 (24-Mar-2018)
Filesystem volume name:
Last mounted on: /mnt/sdcard
Filesystem UUID: e435bacc-3db3-4d5d-a6fe-19b2691aa506
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 3907584
Block count: 15630080
Reserved block count: 781504
Free blocks: 15371467
Free inodes: 3907573
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Sep 29 20:09:35 2018
Last mount time: Sat Sep 29 20:13:49 2018
Last write time: Sat Sep 29 20:13:49 2018
Mount count: 2
Maximum mount count: -1
Last checked: Sat Sep 29 20:09:35 2018
Check interval: 0 ()
Lifetime writes: 260 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Default directory hash: half_md4
Directory Hash Seed: 3f8f68fc-08e6-45fc-87b3-a895fc1f60db
Journal backup: inode blocks

dumpe2fs /dev/mmcblk0p1

dumpe2fs 1.44.1 (24-Mar-2018)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mmcblk0p1
Couldn't find valid filesystem superblock.

Filesystem properties after formated on Fedora 27:

dumpe2fs /dev/sdf1

dumpe2fs 1.43.5 (04-Aug-2017)
Filesystem volume name:
Last mounted on:
Filesystem UUID: e435bacc-3db3-4d5d-a6fe-19b2691aa506
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 3907584
Block count: 15630080
Reserved block count: 781504
Free blocks: 15371467
Free inodes: 3907573
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Sep 29 20:09:35 2018
Last mount time: Sat Sep 29 20:09:42 2018
Last write time: Sat Sep 29 20:10:25 2018
Mount count: 1
Maximum mount count: -1
Last checked: Sat Sep 29 20:09:35 2018
Check interval: 0 ()
Lifetime writes: 260 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Default directory hash: half_md4
Directory Hash Seed: 3f8f68fc-08e6-45fc-87b3-a895fc1f60db
Journal backup: inode blocks

If I run fsck on openWRT, it shows basically the same things as running it on Fedora but it does not fix the problems. Below is the output on Fedora. The result of the operation will destroy any file on the filesystem.

fsck.ext4 /dev/sdf1

e2fsck 1.43.5 (04-Aug-2017)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
/dev/sdf1 was not cleanly unmounted, check forced.
Resize inode not valid. Recreate? yes
fsck.ext4: Cannot iterate data blocks of an inode containing inline data while reading bad blocks inode
This doesn't bode well, but we'll try to go on...
Pass 1: Checking inodes, blocks, and sizes
Inode 1 has inline data and extent flags set but i_block contains junk.
Clear inode? yes
Root inode is not a directory. Clear? yes
Inodes that were part of a corrupted orphan linked list found. Fix? yes
Inode 127058 was part of the orphaned inode list. FIXED.
Inode 127059 was part of the orphaned inode list. FIXED.
Inode 127060 was part of the orphaned inode list. FIXED.
Inode 127061 was part of the orphaned inode list. FIXED.
Inode 127062 was part of the orphaned inode list. FIXED.
Inode 127063 was part of the orphaned inode list. FIXED.
Inode 127064 was part of the orphaned inode list. FIXED.
Inode 127065 was part of the orphaned inode list. FIXED.
Inode 127066 was part of the orphaned inode list. FIXED.
Inode 127067 was part of the orphaned inode list. FIXED.
Inode 127068 was part of the orphaned inode list. FIXED.
Inode 127069 was part of the orphaned inode list. FIXED.
Inode 127070 was part of the orphaned inode list. FIXED.
Inode 127071 was part of the orphaned inode list. FIXED.
Inode 127072 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Root inode not allocated. Allocate? yes
/lost+found not found. Create? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(9260--9262) +(32768--33375) -(33801--34408) -(34912--34913) +(98304--99263) -(99337--100296) +(163840--164735) -(164873--165768) +(229376--230207) -(230409--231240) +(294912--295679) -(295945--296712) +(819200--820095) -(820233--821128) +(884736--885567) -(885769--886600) +(1605632--1606335) -(1606665--1607368) +(2654208--2654783) -(2655241--2655816) +(4096000--4096383) -(4097033--4097416)
Fix? yes
Free blocks count wrong for group #0 (23503, counted=23508).
Fix? yes
Free blocks count wrong (15371465, counted=15371470).
Fix? yes
Inode bitmap differences: +(3--10) -(545--556)
Fix? yes
Free inodes count wrong for group #0 (8180, counted=8182).
Fix? yes
Directories count wrong for group #0 (3, counted=2).
Fix? yes
Free inodes count wrong (3907572, counted=3907574).
Fix? yes

/dev/sdf1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdf1: 10/3907584 files (0.0% non-contiguous), 258610/15630080 blocks

I did one more test: I mounted the sdcard on openwrt and umounted it without running any command. Again, the filesystem gets corrupted. So, I believe the problem is with the mount command that is corrupting the filesystem.

This is the result of running fsck on openwrt (it does not fix the problem):

fsck.ext4 -y /dev/mmcblk0p1

e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
/dev/mmcblk0p1 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23505, counted=23508).
Fix? yes

Free blocks count wrong (15371467, counted=15371470).
Fix? yes

/dev/mmcblk0p1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mmcblk0p1: 11/3907584 files (0.0% non-contiguous), 258610/15630080 blocks

dumpe2fs /dev/mmcblk0p1

dumpe2fs 1.44.1 (24-Mar-2018)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mmcblk0p1
Couldn't find valid filesystem superblock.

The last test I did was to attach an sdcard reader on the usb port using the same sdcard. When I do that, then no corruption happens.

Is this a bug or am I missing something? If you have suggestions on how to troubleshoot this problem or need more information, please let me know.