Cfrtjryk

I am trying sleep and wake up my Kobo Mini ebook reader manually by using the command rtcwake. The reader is using busybox.
cat /proc/version gives me this output:
Linux version 2.6.35.3-850-gbc67621+ (gallen@gallen-P5KPL-AM-BM) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #617 PREEMPT Mon Apr 22 11:07:47 CST 2013

rtcwake sets the reader to sleep but fails with this message:
wakeup from "mem" at Wed Nov 13 18:02:44 2013

rtcwake: short write

...and does not wake up again. After some googling I tracked the error down to the removable micro sd card which the reader uses as its primary (and only) storage. Which means that the whole system is running on that sd card which is being removed on standby.

I also found another user with the same problem on a completely different device but also with a removable sd card as the primary storage. He solved the problem by enabling the kernel option/parameter
MMC_UNSAFE_RESUME.

Now my question: How do I set/enable/activate this parameter?
Do I have to recompile the kernel?

I think you do have to recompile the kernel. Grepping the 3.11 source, it is not mentioned in [src]/Documentation/kernel-parameters, which is where command-line params for the kernel are documented. It's not mentioned in other docs either.

Of course, there could be a param that does not literally mention MMC_UNSAFE_RESUME. There are some documented options for tweaking the resume from hibernation/sleep, but in order to assume one of those is useful this way, they would probably need to be connected somehow to MMC_UNSAFE_RESUME in the source.

So, it's declared in [src]/drivers/mmc/core/core.c, and used to set the value of an exported symbol, mmc_assume_removable. The only place this is used is in in [src]//include/linux/mmc/host.h to influence the return value of an inline function.

That's far from a conclusive analysis -- and of course there may be another way to get what you want, a /proc setting, etc. -- but looking at some of the dev discussion about this, I doubt very much it will have anything to do with MMC_UNSAFE_RESUME; in most contexts it would be something most people would want to avoid at all costs, particularly since individual drivers can accomplish the same thing on a per device basis (whereas that switch is global).

Yes, normally the kernel unmounts the file system on removable media when it goes to sleep because of the concern that you will unplug the card while the system is sleeping. It then does the remount when it resumes.

If you "promise" that you will not remove the MMC card(s) you can set the MMC_UNSAFE_RESUME kernel option. This will essentially tell the kernel that you consider the MMC drive as permanent storage. So it won't unmount and remount the device.

But you do need to rebuild the kernel for this.

If you are still having trouble resuming from a sleep, another thing to do is add "debug" to the kernel boot params. This will add verbose output to the console, and many drivers will report their status as they wake up. So if a driver hangs on resume, you may be able to identify which one.