[Captivate Android Development] mr_psycho:
Thank you for consolidating and summarizing all this information into one thread. This really helps save a lot of time.

I believe TRIM support was added to Linux kernels back in 2.6.28 (NAND) and 2.6.33 (ATA). So, some of the older 2.6 kernels may have had support while some did not. Prior to the 3.0 kernels, 2.6.35 was a generally used/accepted version, which may have had TRIM support, though not enabled. For those that may not know, TRIM is only supported on certain file systems (eg. Ext4, FAT, XFS, Btrfs, etc.). And while the Data partition is Ext4, I believe you must mount the device with the "discard" option in order for TRIM operations to occur. Unfortunately, I'm not sure at what point TRIM was added to Android kernels, since Android forked the Linux kernel, and has only recently (since Linux v3.3) started to re-converge with the mainline Linux kernel.

Here is the output of my mount command for /data and /sdcard.

/dev/block/mmcblk0p2 /data ext4 rw,nosuid,nodev,noatime,nodiratime,barrier=1,data=ordered,noauto_da_alloc 0 0
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

As you can see, it does not look like I have TRIM enabled. MMC_CAP_ERASE, on the other hand, I cannot speak to.

For using the SGS2 i9100 kernel, I briefly looked at the kernel source, and I did not see any support for the Aries class of phones. I am not as accomplished a kernel dev as some of the others, so it's probably beyond my abilities to integrate Aries support into the i9100 update4 kernel (v3.0.15).

We may, however, be able to port the MMC code from the i9100 update4 kernel to our existing kernels (v3.0.8 and v3.1.10) in hopes of disabling MMC_CAP_ERASE. I may explore this as time permits. I am also considering going back to the v2.6.35. Again, as time permits.

I modified my kernel to add the missing fwrev and hwrev for MMC v4 (and higher) to check what my MMC's firmware is. Previously these values would show as "0x0". Here is what mine shows now:

root@android:/sys/class/block/mmcblk0/device # cat name hwrev fwrev manfid oemid date type serial cid
MAG8DD
0xf <<< hwrev
0x6 <<< fwrev
0x000015
0x0100
03/2010
MMC
0xf60ed222
1501004d414738444417f60ed2223d00

As you can see, the firmware version of my MMC is not 0x19 or 0x25. Those are probably the version of the firmwares in the SGS2 and/or Nexus devices. So, this doesn't seem to help us.

I would love to see this patch.

So, maybe we are seeing the same issue, or maybe just something similar. Either way, we are facing an uphill battle to resolve this issue, as vendors will only want us to abandon these old devices for current models.

In the meantime, I recommend only wiping data if absolutely necessary. Aside from moving /data to an external SD card, our options are rather limited.

I'd love to hear from other devs on what they think is feasible. I really hope we can find some way to permanently fix this bug.

MP