OESF Portables Forum
General Forums => General Discussion => Topic started by: gojira on February 01, 2005, 03:39:04 am
-
All processes using a filesystem on the CF card are killed and the filesystem is remounted on suspend/resume. This makes CFs unusable for general use.
I've looked but can't find much on this issue. There are a couple of old list posts, but no answers (1 (http://www.google.com.au/search?q=cache:2KTU0L1dbVsJ:www.geocrawler.com/archives/3/18496/2002/7/50/9171295/), 2 (http://www.google.com.au/search?q=cache:GtPh1XnUqbMJ:www.geocrawler.com/archives/3/18496/2002/9/550/9563626/)).
/etc/pcmcia/ide is responsible for the kill and remount. See the Linux PCMCIA HOWTO (http://www.tldp.org/HOWTO/PCMCIA-HOWTO-4.html). /etc/pcmcia/ide stop kills and umounts, and /etc/pcmcia/ide start mounts, but /etc/pcmcia/ide suspend/resume do nothing, so for some reason stop/start is being used, rather than suspend/resume.
NO_FUSER=y can be used to skip the fuser -k so that processes aren't killed and filesystems aren't umounted if busy, but then the filesystem gets messed up, so presumably the driver can't handle a suspend/resume.
cardctl suspend makes the card unavailable, but doesn't umount or kill. cardctl resume kills procs and reenables access. I haven't tested how /etc/pcmcia/ide is being called in these cases.
zimager and musicplayer cope ok, so presumably they don't leave files open and don't chdir.
I've tried 2 CF cards, both have the problem (and one MMC, which is fine).
Does anyone have any info on this? In particular:
Is this standard linux behaviour i.e. does it happen on other archetectures? If it's zaurus specific, does it affect all models/kernels? Is cardctl called on suspend/resume and how? If not, who calls /etc/pcmcia/ide? Does it affect all CF cards? It would make microdrives less useful if so...
(I did buy a SanDisk SD 1GB card originally, but had to return it because of the usual SD problem. Anyone using a SanDisk Ultra II SD 1GB? They might be ok if they use a different controller...)
Thanks.
-
My understanding is that this the kernel behaviour for the Sharp version of 2.4.18, but it can be altered (to not eject the cards) fairly easily. Mickeyl posted a reply to a similar query a while back, possibly in the OpenZaurus part of the forum.
Regards,
Si
-
As far as I remember this is a general problem of 2.4.x ARM kernel and it's not fixed...
-
I found an older thread (https://www.oesf.org/forums/index.php?showtopic=1228) on this, so I'll use that for all further replies.
Thanks.