Maybe you replaced the module for the wrong kernel. Make sure you are copying to the proper modules directory under /lib/modules.

Maybe it is possible to modify the driver to never unmount on cove-off? Of course attaching magnet isn't bad idea, but puristic way of things would be do change this behavior on code side

Anyway, can someone explain me rationale of unmounting/cutting microSD card on removing cover? There is one at all, or designers just thought that users are idiots and will remove card hard-way when in use?

I don't know where the logic is to unmount the microSD, but I assume it is something with HAL. It should not be in the kernel.

Why would you open the back cover and not want the microSD to unmount? What is there besides the microSD that could be changed during runtime? You can't change the battery without powering down.

AFAIK the idea is that people might remove the battery without shutting off the phone first, so unmounting the sd card is an emergency measure.

Bizarrely that is EXACTLY what I did. As another user describes the same symptoms, moving to directory and replacing old this leads me to suspect that either the version you have uploaded is not the one you think it is OR you did not test with the correct setup (i.e. kernel). However I don't know but as it stands only you have this working and anyone else who has tried has ended in a boot loop.

No, I will not be installing multiboot. I wish to write to the NAND as little as possible and multiboot writes the kernel every change of boot. Uboot all the way (probably, if I ever get round to it!)


QBW for mount/unmount? What did we lose a war? I am not chimping well manually running an unmount script for something that should be automatable. I just want to be able to take the back off without the card spazzing out. If only joerg still hung out here, id bet he could 'fix' the sd card driver.

Anyway. I will be monitoring this thread with great interest, what with having a ropey LX Patriot 16GB card 'n all.

The same reason you unmount (or "safely remove" in Windows) your pendrives on computer. User may not have any app opened, but there might be some system deamon (like tracker indexing multimedia files) or some delayed write operations may be performed (I don't know how it works on N900, but often when you want to write some files to your pendrive on your computer, the system may show that operation finished, but the driver is still packing it on the device and writing and thus using it). And if one would take sd card out of reader, it could lead to memory corruption and loss of data (the same applies to removing pendrives from your computer without using "safely remove" option :P)

Well, how often DO you change boot? It flashes kernel only when you actually select different option than previously (if you choose the same kernel as previously, it looks inteligent enough not to flush it again). So, if you don't have multiboot and thus only boot one kernel, your nand would be safe. And if something would go wrong, you could just choose second (fail-safe) boot option, for example the default omap1 N900 kernel. I think that, after all, this means the same or less write operations to nand than using flasher on your pc, am I right?

Couple of things: There is no good argument for completely-unchangeable forced-unmount. Just... isn't. Unmounting card at back open is like unmounting a USB stick when your hand nears the front of your desktop computer (or pick whatever orientation relative to your computer your hand will be to get to your desktop's USB ports. Sure, you may only be trying to pull out the USB device(s) and/or press the power switch. Or maybe you wanted to brush of some dust or your hand was there for computer-unrelated reasons.

Oh, and yes, you can change battery without shutting down - it's a major hack and requires tricking your N900 into thinking it's charging even when it isn't, but I think (memory's hazy) I've pulled that off with a combination of a tiny inch-sized micro-to-mini and micro-to-normal USB adapter (one or the other, not both at once) and USB host mode. Or just having access to an outlet and charger at which point you don't need to 'trick' it, it just does. But you do get about 30 seconds to hotswap the battery, which is more than enough time. Especially if you can open the battery cover BEFORE you switch batteries. (And no it doesn't matter if 5 users out there do this, or 50, or thousands. Some do, and giving people options shouldn't be limited to the very popular ones.)

More to the point though - ever drop the N900? Ever drop it without a case? If your back cover has NEVER managed to come off in the process, you have been very lucky, or very skilled at breaking the N900's fall by controlling its fall with your legs or other body parts.

I have dropped my N900 a rather large amount of times, and I have had the back cover fly off. Especially for users who use SD cards for swap (which is a lot more than hot-swap batteries, if you're going to ignore that demographic), a drop or other event (any event, like letting your kids fiddle with your device or something) that results in the back cover opening can be much less pleasant for usability than data corruption. Which, whether it's opening the back cover or just yanking your card out unmounted, is about equally likely if you're in the middle of writing data to your card, and similarly unlikely if nothing is writing to your microSD card.

If you aren't using your card for swap, force unmount is equally possibly annoying, but not a major deal. If you are using your card for swap, force unmount can be disastrous (more often just really annoying, disastrous is possible but less likely), while the vi_ proposed option allows for much more pleasant outcomes.

There is of course the possibility that the dto change itself doesn't get along with your device for some reason. Based on everything I've read I doubt that is the case, but you never know. So far 3 people here had success with it, including me. 2 had the boot loop.

In the past (not with this particular change) I've gotten the boot loop when I flashed a kernel but forgot to install the modules first. So encoiuntering that after messing with a module does seem to point to something gone awry.

I'm using the power47 from extras-devel, I'm also using multiboot and the modified backupmenu in multiboot, I don't know if those things change how the boot process works as far as kernel module loading goes... I don't think it should make a difference, but obviously something is not working the same for you guys.

I downloaded the module I attached here and it is indeed the one I am using:

I've also compiled & successfully used the modified module with the PR1.3 stock kernel, power46 and power46-wl1, and possibly-successfully for the nitdroid kernel from e-yes' git repository (nitdroid spazzed because of my previous installation, but did not self-destruct like it does with the unmodified kernel). In all cases I'm leaving the installed kernel and modules unchanged, with the exception of my new omap_hsmmc which I just copy over the old one.

Hope someone else can perhaps detect what might be going on.

I did not replace the kernel itself, just the kernel module. I am using the stock PR1.3 kernel so it would not make any sense to use the power kernel module if that is what you are suggesting.

It would be far easier to test this using rmmod and modprobe but unfortunately Maemo doesn't let you do this as the watchdog resets the device when you run "rmmod omap_hsmmc.ko". Anyone know a way around this?

Disable the lifeguard timer.