Fix for Class 10 microSD cards
 

Hello everyone,

Stlpaul and I have got certain class 10 microSD cards that were formerly not working properly with Maemo to work properly.
In particular, this thread's issues are addressed: http://talk.maemo.org/showthread.php?t=70974

I have been using this patch for over a week now, without any stability issues (I have swap on microSD).

Installation Instructions:

You can replace your current kernel module (backup up the old one first), and try the fix at your OWN RISK. The kernel module goes in your appropriate /lib/modules/ folder.

Here is the patched kernel for the power-kernel (v46)

http://forge.localcoast.net/clients/.../omap_hsmmc.ko

Or, if you want to change the kernel and recompile it yourself..

Look in drivers/mmc/host/omap_hsmmc.c and find the set_data_timeout function() function, and add
before the line that reads:
Notice: I hereby disclaim and damage(s), or issue(s) caused by the use of these/this modfied file(s). Only make these changes if you already have an issue, and are looking to fix it. Be sure to backup all user data before making changes.

Notice: This fix does not apply to NITDroid and any other kernel(s) or operating system(s) you may be using outside of Maemo. Additional software platforms may require a similar change(s) to be made to achieve the desired result.

Please let me know how it works for you!

Good luck.

Re: Fix for Class 10 microSD cards
 

You can, once this is tested long enough to be sure it doesn't screw up other stuff, submit this to pali, as he has become the power-kernel maintainer and can make this patch a normal part of the power-kernel.

Re: Fix for Class 10 microSD cards
 

Would be interesting to know if it affects other MicroSD cards at all - speedwise that is.

Re: Fix for Class 10 microSD cards
 

Thanks for posting, I've been meaning to create a thread about it but have been extremely busy lately.

14 (0xA) is the standard DTO setting for SD cards. The omap_hsmmc driver tries to use some logic to dynamically change DTO based on the card timings but apparently this logic is buggy, or perhaps certain cards return bad timing information when the driver requests it. It affects all devices which use this driver, not just the N900, and other devices with other drivers too. The suggestion to use DTO=14 came from Texas Instruments, so it should be safe for all. Forcing DTO to 14 is the fix/workaround for all kinds of SD drivers. Apparently it is quite a common problem.

The set_data_timeout function can actually be reduced quite a bit, inserting the dto=14 line ultimately has the same effect, but really all of the stuff related to the DTO calculation in that function can be removed. I don't have access to my computer right now but I can post the one I've been using when I get home.

This fixes the cards that suffer corruption and constant -110 errors in dmesg (this is a timeout error, because the DTO was set incorrectly by the driver). The same cards that work perfectly fine in other devices, USB card readers, etc.

I've been using this fix with both affected and unaffected cards for a couple weeks and have seen no problems either way. Since it worked for AndrewX192 also I think it should be safe for human consumption. :)

I tried to apply the same fix to the latest Nitdroid kernel but haven't been able to get it working so far. I very likely could just be doing it wrong. It could also be getting confused by my existing nitdroid installation which runs on my other SD card. I haven't had time to really try much more with it yet.

Re: Fix for Class 10 microSD cards
 

As this is compatible with power46, does that mean it is safe to use with power47?

I assume that because the wifi injection driver works (compiled for 46, works with 47) this will also work with 47.

I would just try however I don't want to risk ANOTHER £30 class 10 SD card by doing something obviously dumb.

Re: Fix for Class 10 microSD cards
 

It should, I doubt this module changed at all between power46 and power47. The risk of damaging your SD card would with the unmodified kernel, not the modified one! :)

If you want to be careful, when I get home I'll pull Pali's kernel and build it with this patch and upload the compiled module for you after I've made sure it works on my N900.

Re: Fix for Class 10 microSD cards
 

It's odd, because my N900 with HW 2101 was absolutely fine with my class 10 SD card. However, once Nokia Care had replaced it with HW 2204, I started getting these errors. It's been sent back again now due to other problems, but I'll definitely be applying this patch to kernel-bfs ready for when it's returned to me :)

PS I've tidied up the code and made a diff which can be applied in the build process - had to make it a .txt to attach it though.

Re: Fix for Class 10 microSD cards
 

I'm still of the opinion that the ideal thing to do would be to shove this into the default power kernel, when it's ready. Well, the most ideal is making the DTO logic try to get the right number, then use a heuristic to default to 14 if it starts to experience symptoms of errors. Perhaps, if possible, see if there's some way to check the device for errors without damaging any data. But that's a long term hope.

Re: Fix for Class 10 microSD cards
 

Thanks, that's basically what mine looks like, but I even removed the dto variable entirely and just used the DTO macro instead (it is already defined as 0xa early in the file)

BTW my N900 is rev 2101...

Re: Fix for Class 10 microSD cards
 

Here is the module compiled as part of power47, it works for me.

Re: Fix for Class 10 microSD cards
 

This is great, thanks.

This isnt a request just an idea...If the sd driver could be modified to unmount the mmc gracefully when the back cover was removed as opposed to just outright cutting the power. That be...sweet. Just think, if I remove the back cover while my swap was mounted on the SD card it would nicely unmount swap as opposed to rudely cutting it of, the machine spazzing out then dieing.

Or EVEN better, the driver would emit a dbus signal so I could run a script when the back cover was removed and nicely swap the swap elsewhere, beep/vibrate when it is done. Bleep nastily if I opened the back with the sd card mounted.

You get what I mean?

Re: Fix for Class 10 microSD cards
 

Not sure what has happened here but I replaced my power 47 module with this thing and wham! reboot loop. I cannot even mount the emmc through backup menu to restore. Im gonna have to reflash.

How exactly did you test this thing?

Re: Fix for Class 10 microSD cards
 

>_<

It reminds me Toshiba ac100 and nvidia terga driver +)
----

Anyway, i'm going to test this module later, these errors is annoying when downloading torrents on my n900.

Re: Fix for Class 10 microSD cards
 

after reflash i think you should install multiboot to get rid of such reboot loops in future (correct me if I'm wrong)

Re: Fix for Class 10 microSD cards
 

Yes, I am keen to see if this driver (once debugged/tested) increases MMC performance.

I have a 16GB class 4, and when copying from the EMMC to the MicroSD, I would get very low average transfer speeds once the kernel's buffers were full. On the order of 200-400 kBps. Using the card for swap made my phone into a dog.

Re: Fix for Class 10 microSD cards
 

I'm very sorry to hear that, but I'm not sure how that would happen.

I renamed old module (as a backup), copied in the new one, rebooted, used a class 10 SD card that previously had problems, experienced no errors.

Re: Fix for Class 10 microSD cards
 

I believe it already does that, for the standard first FAT partition on the SD card, but it only succeeds if it's not in use at the time. If it can't be unmounted cleanly, then it's just cut off.

Obviously if you're using it for swap, it is always in use, and that's always going to result in catastrophic failure.

I think one solution is to create your own "unmount SD card" script, make a Queen Beecon widget on your desktop or something to call it when you want to remove your cover. It would need to alert you if any partitions cannot be unmounted for any reason, that way you know it is not safe to remove the back cover.

Even better yet, glue a magnet onto the sensor so your N900 thinks the cover is always on. :)

Re: Fix for Class 10 microSD cards
 

I personally use multiboot, I have my boot choices as standard kernel, power kernel, nitdroid, backupmenu. If I break one kernel for some reason I always have the other as a safety net. The down-side is that modules for all possible kernels must be installed at once, which eats a large amount of rootfs space.

Re: Fix for Class 10 microSD cards
 

I tried the patched kernel module for the stock kernel and this resulted in a reboot loop too :(. The irony is that I haven't installed multiboot yet because I wanted to get my MircoSD card working before installing multiple OSs. Time to reflash I guess. It looks like I followed the same procedure you did to test it. I also made sure that the patched kernel module file permissions and ownership matched the original one.

Re: Fix for Class 10 microSD cards
 

I think when you replace the default kernel you will get the reboot loop problem. So, just replace for power kernel.

I´ve tested here, all good so far. Thank you!!!:D

Re: Fix for Class 10 microSD cards
 

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

Re: Fix for Class 10 microSD cards
 

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?

Re: Fix for Class 10 microSD cards
 

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.

Re: Fix for Class 10 microSD cards
 

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.

Re: Fix for Class 10 microSD cards
 

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.

Re: Fix for Class 10 microSD cards
 

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?

Re: Fix for Class 10 microSD cards
 

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.

Re: Fix for Class 10 microSD cards
 

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.

Re: Fix for Class 10 microSD cards
 

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?

Re: Fix for Class 10 microSD cards
 

Disable the lifeguard timer.

Re: Fix for Class 10 microSD cards
 

I finally got my N900 back on Wednesday - and the compiled module didn't work for me either on stock PR 1.3, to such an extent that BackupMenu couldn't even read mmcblk0 or 1. I was almost stuffed as I'd overwritten the module in /lib/modules on my rootfs backup, but thankfully I still had an old bfs-kernel uImage with the modules matching so was able to boot BackupMenu successfully. I then patched kernel-power46 myself with the diff posted earlier in the thread and booted from that - all was fine, although installing the kernel-modules flagged up the copied module in 2.6.28-omap1 as missing symtab and strtab. The one I've compiled for kernel-power is fine, though, so there's definitely something amiss with the hosted files?

Re: Fix for Class 10 microSD cards
 

I queried this in another thread (I think the one on moving swap to the SD), because forcing an unmount can't be good for the filesystem on the card since it may take several seconds or more to flush cached data to the card and if the filesystem driver is not given time to do this the filesystem won't be left in a clean state. Anyway I got a response from joerg_rw who was of the opinion that it could physically damage the micro SD card if you removed it while the slot was still powered.

Re: Fix for Class 10 microSD cards
 

@retsaw

Yea, i remember that discussion. But, we consider that users of modified driver want it on purpose, and are not idiots pulling out microSD card without unmounting it, especially when we have swap there ;)

I hope someone skilled enough (unfortunately, I'm definitely not) to "fix" driver will come to that conclusion also...

Re: Fix for Class 10 microSD cards
 

IMHO, anybody inclined enough to be running swap on the external microsd, has the ability to swapoff before yanking the back cover.

Can anybody confirm this is actually controlled by the driver? It makes no sense that it would be.

Re: Fix for Class 10 microSD cards
 

I don't think it has anything to do with the driver in question at all. It is N900-specific behavior.

Re: Fix for Class 10 microSD cards
 

From my N900...

Re: Fix for Class 10 microSD cards
 

That doesn't match the sha1sum of the file linked in the first post. Also, that file contains the magic "2.6.28.10power-omap1" which is not right.

I've attached my module that I am running on my N900 for stock kernel PR1.3.

Re: Fix for Class 10 microSD cards
 

Well here's what I am using for kernel-power

Re: Fix for Class 10 microSD cards
 

That one does match the one in the first post.

Re: Fix for Class 10 microSD cards
 

True, but still, there is no reason to Force unmount. It just add additional, unnecessary work to do.

Anyway, sorry then for mentioning the driver - my fault, i followed statement in few post earlier, that "maybe joerg would be able to "fix" the driver". Anyway, if it is specific behavior, it is controlled (sensor) purely by hardware, without any software, propertiary or not, support? I don't think so, but I may be wrong. If that's the case, hardware mod with magnet would be best thing to do.