strange problem with Intenso 4GB SDHC card

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

| glamo-mci glamo-mci.0: Error after cmd: 0x120
| glamo-mci glamo-mci.0: Error after cmd: 0x8120
| glamo-mci glamo-mci.0: Error after cmd: 0x120
| glamo-mci glamo-mci.0: Error after cmd: 0x8120
| glamo-mci glamo-mci.0: Error after cmd: 0x120

This bit is normal, it's the Linux MMC / SD stack seeing if it is an
SDIO card.

| glamo-mci glamo-mci.0: powered (vdd = 20) clk: 16666kHz div=2 (req:
| 16666kHz). Bus width=2

This bit is a good sign, it was able to complete getting recognized by
the stack and put into 4-bit mode at 16MHz SD_CLK.

| mmc0: new high speed SDHC card at address b368
| mmcblk0: mmc0:b368 SD    3931136KiB
|  mmcblk0:<6>glamo-mci glamo-mci.0: Error after cmd: 0x8310
| mmcblk0: error -110 sending read/write command

This first real error is ETIMEDOUT.  It can be a genuine timeout because
your card is a bit slow, but it could also mean communication problems.

| 2) I can trick it to work doing the following steps:
|    - check sd_drive parameter (not required)
|      >root at om-gta02:~# cat /sys/module/glamo_mci/parameters/sd_drive
|      >0
|    - re-set it to this (or possibly any other) value
|      >root at om-gta02:~# echo 0 > /sys/module/glamo_mci/parameters/sd_drive
|    - now the device works fine:

I don't see how that can impact it, none of our code runs when you
change that, it simply gets written to the int that holds sd_drive
behind our back.  And when you catted it, that is the real value of that
int, it doesn't keep a copy somewhere.  Maybe something else in the
threshing around helped.

|      >root at om-gta02:~# fdisk -l /dev/mmcblk0
|
| Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
| 126 heads, 61 sectors/track, 1022 cylinders
| Units = cylinders of 7686 * 512 = 3935232 bytes
|
|         Device Boot      Start         End      Blocks  Id System
| /dev/mmcblk0p1               1        1022     3927515+ 83 Linux
| ==========================
|
| A suspend/resume cycle seems to do the trick as well.
| I think that some parameter connected to sd_drive might be uninitialised
| before sd_drive is explicitly rewritten.

I don't see it can be uninitialzed data, it is more likely working or
not working according to its own plan.

Once you formatted it, can you write reliably to it and read stuff back
with same md5sum after umount to flush the cache?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiHkqcACgkQOjLpvpq7dMpeOwCfWfNTye1954C23FKy6aA7lvg+
fSgAnjun7jOgrNFnzuWu2yT//YFwuVEl
=wt0V
-----END PGP SIGNATURE-----