[Asus  Eee Pad Transformer Prime] _motley:
For GENTLE_FAIR_SLEEPERS, the check boxes in this tool are confusing I think. I opened the app as well and see the same thing. However, if I look in sysfs (/sys/kernel/debug/sched_features), I can see an array of directives and can tell that it is turned off as expected (we should have NO_GENTLE_FAIR_SLEEPERS. I am always careful using these types of tools and always like to verify what they are really doing by first checking the default in sysfs and then manually going back and checking to see what the tool has done.

For read-ahead cache size, the stock values is 2048. I think this is a good setting since we have plenty of RAM. Some ROMs are setting this to 1024 using init.d on startup. This is a good setting to check when folks are complaining about read speed during benchmarks as it will affect disk i/o speed quite a bit. Up to a certain point, increasing this number will improve read speeds, particularly for large files. 2048 is the sweet spot I think.

Weird, glad we have this sorted out to what works on what versions. I can see the newer MMC driver is identifying these cards as different (HC vs XC), whereas before, it was not and both were treated the same (as far as I can tell so far). I may be able to revert that part of the code and see if things are better. Which ROM are you on? Just wondering since those Tuxera modules may come into play and I am not sure if all ROMs include them like for stock. I am fairly sure AOKP does, but not sure about the other non-stock custom ROMs.

Thanks, glad it is working better on a real disk bench tool. Those results are painful for me to interpret LOL. I hope I can find some time to get the last problems sorted out. This driver is so sensitive to changes since it is tied into power management and WiFi (SDIO, regulator on/off switches etc). I was able to fix the deep sleep and then that broke the MicroSD card again (doh!).

Thanks! Yes, this is an interesting memory address load-time relocation issue. I have dealt with the position independent code problem before with broadcom modules when building kernels using the Google NDK toolchain (newer versions seem to need this). It doesn't seem to be a problem with the Code Sourcery Lite toolchain I am currently using, but I will change the compiler flag in the module in the next version so that we can use other toolchains and see if it helps for the sporadic module loading issues. In some of the Linaro and other optimized toolchains, I see they add this tip get WiFi to work properly. How many tweaks did you have to make to use Linaro? Do you think it is worth it? I did a lot of testing with other toolchains last year on the Galaxy tab 8.9 and never was able to quantify any performance improvement. Now I see a lot of touting about performance again with these new toolchains, so I am willing to take a look. Please send a link to the Linaro version you are using and I will give it a try!

Also, if you have any ideas on the MMC issue (deep sleep etc.), give me a shout. I would really love to put this to bed, but haven't had a lot of time to look at it. In my one trial to fix thus far, I have failed (as I mentioned above in my response to saturn_de).

Thanks guys!