View Single Post
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#47
Originally Posted by brontide View Post
Hmmm...wirdness.

I was looking over everything and I noticed that /media/mmcX didn't have noatime. So I did a mount -o remount,noatime and the problem went away
wow, noatime makes sense with vfat, never thought of it (there is no access time field in fat filesystem). Did some google search and indeed
Alert readers may be thinking: “Wait, there's no atime on FAT filesystems!” True. There's only a single timestamp field for each file or directory, but Linux deals with this by updating that single time value on any occasion it ordinarily would update atime, mtime or ctime. So, disabling atime still reduces the frequency of erase/write operations, even on FAT.
If this really makes difference I guess it should be reported as maemo bug. metalayer-crawler scans everything and also file open dialog scans a lot files, both may cause big atime updates ==> unneeded writes, audio stutter and cpu burning in mmcqd.

Originally Posted by brontide View Post
, but now canola is flipping out. It works *significantly* faster displaying images until the images start to corrupt and then it just barfs. I have to kill it off with a kill -9 on the python-launcher.
See kernel log via dmesg, are there some mmc related errors? If not then silent mmc corruption is unlikely. 48MHz mode is indeed unsupported by TI but my guess is that if it doesn't work under some conditions you would see device hangs and ton of errors in kernel log, not silent corruption of data.
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.