[G Tablet Q&A, Help & Troubleshooting] rajeevvp:
First things first: I'm not an SD Card expert. If anyone is, its Pierre Ossman, the guy who wrote most of the MMC/SDHC/SDIO device driver code currently in the Linux kernel. Sometime back I described the Groundhog Day problem to him in an email and asked "Any idea why this would be happening and how it can be fixed?". A few days ago he replied:

If we go through that dmesg.txt file we can see the problem right away in your case:

<6>[ 8.507543] mmc2: new high speed SDHC card at address aaaa
<6>[ 8.524833] mmcblk3: mmc2:aaaa SE16G 14.8 GiB
<6>[ 8.529570] mmcblk3:
<4>[ 11.328784] mmcblk3: retrying using single block read
<4>[ 14.131049] mmcblk3: retrying using single block read
<3>[ 16.932398] mmcblk3: error -110 transferring data, sector 1, nr 7, card status 0x80900
<3>[ 16.940315] end_request: I/O error, dev mmcblk3, sector 1
<3>[ 19.741976] mmcblk3: error -110 transferring data, sector 2, nr 6, card status 0x80900
<3>[ 19.749901] end_request: I/O error, dev mmcblk3, sector 2
<3>[ 22.551560] mmcblk3: error -110 transferring data, sector 3, nr 5, card status 0x80900
<3>[ 22.559507] end_request: I/O error, dev mmcblk3, sector 3
<3>[ 25.361167] mmcblk3: error -110 transferring data, sector 4, nr 4, card status 0x80900
<3>[ 25.369111] end_request: I/O error, dev mmcblk3, sector 4
<3>[ 28.170764] mmcblk3: error -110 transferring data, sector 5, nr 3, card status 0x80900
<3>[ 28.178709] end_request: I/O error, dev mmcblk3, sector 5
<3>[ 30.980362] mmcblk3: error -110 transferring data, sector 6, nr 2, card status 0x80900
<3>[ 30.988306] end_request: I/O error, dev mmcblk3, sector 6
<3>[ 33.789957] mmcblk3: error -110 transferring data, sector 7, nr 1, card status 0x80900
<3>[ 33.797880] end_request: I/O error, dev mmcblk3, sector 7
<3>[ 33.803273] Buffer I/O error on device mmcblk3, logical block 0
<4>[ 36.606220] mmcblk3: retrying using single block read
<4>[ 39.408269] mmcblk3: retrying using single block read

You can see the kernel trying to read the MBR (master boot record) to figure out the partitions on the internal SD card. Right away it fails with a -110 error. The -110 is actually a -ETIMEDOUT error, meaning, "Card took too long to respond" to a command. Normally the kernel tries to read a few pages (4 KB) at a time from the disk instead of single sectors (512 bytes). This failed, so it retried "using single block read". This, too, failed quite badly because the kernel was not able to read even the first sector (containing the MBR) properly, and so didn't create the device files associated with the individual partitions (/dev/block/mmcblk3p1 and p2). So, its no surprise that these command all failed to work as expected:

/dev/block/mmcblk3 refers to the whole disk, and mount needs a device on which there is a filesystem--ie. it needs the partition devices /dev/block/mmcblk3p{1,2,...n}. So the device name you provided to mount was an "Invalid argument". BTW, this is how errors on the SD card should have shown up. Both Pierre and I were surprised that the other SD cards were not returning the proper error messages when they were obviously not writing any data to the SD card. Instead, it looks like they were returning successful operation messages.

Good point, and this is one of the reasons why I'm generally chary of recommending nvflash. But, in these cases, going by what some of the users have done, I would have to say that the problem is not nvflash-caused. Both sandyjb and titobetlogs noticed their problem first, then tried to fix it using nvflash. (Bikewobble and sktsswth can chime in here with their own statements.)