@kcrudup: does your kernel has exfat support?
I tried the frandom version and I couldn't see my ext sdcard anymore.
I have posted a solution in post #198. BUT - I have a better one, hehe
It uses original script from the modification which is not only the mount script, but it also cares for scanning the card, etc etc. and it let you mount ntfs sdcards, too! My single-command workaround posted in #198 was simple and working, but absolutely not stable. And Here's updated tutorial...
Working exFat SD card on kcurdup's kernel
1. Using a computer or stock kernel with exfat support, create a file called
at the root of exfat extSdCard (i.e.
/storage/extSdCard/.mounthere - plz be aware that there is a dot (".") at the beginning of the filename...
2. Edit the file and input
only such a text:
Save the file and leave it there for a while...
3. Reflash the kcurdup's frandom kernel of your choice. At this time, your exfat card - containing a file created in our previous steps - will disappear from the filesystem. Anyway...
4. You will need a init.d support with the kcurdup's kernel to run some code at boot - well, even if I had init.d support added to the stock kernel, after flashing kcurdup's one it stopped working... I had to add it once again. So you may want to look here:
http://xdaforums.com/showthread.php?t=1933849
for an kernel-independent init.d support. I can say that zip-init method is working well for me... so after flashing with CWM/TWRP or installing with Terminal Emulator, and testing if the init.d work (details in the topic above..) we may proceed to the essential point...
5. Download the newest version of FUSE mount mod from here:
http://xdaforums.com/showthread.php?t=2155363 d
and flash it with CWM/TWRP.
Ur exfat card is working isn't it?
The script in the zip is fully automatic.. It mounts all exfat/ntfs devices for a "test mount", then it reads the .mounthere file from the device (if exist) to find out what is the proper path of mountpoint, it dismounts the test mount and performs a mount again, but to the mountpoint achieved from the created file...
after that, /storage/extSdCard shall be fully accessible, as usual...
Hope I helped.
@kcurdup
Well, please take my apologizes for such a late answer.
1. My device is absolutely ok, I just flashed the same, OC'ed kernel twice by mistake
Non-OC version is working absolutely ok.
2. Well, I have found a way to use your OC'ed kernel on my device, but it's tricky and needs a bunch of reflex...
A VERY RISKY AND DANGEROUS solution how to run kcurdup's OCed kernel along with custom voltages
So: before flashing your kernel, I have installed again a Tegrak Overclock Ultimate app (from Google Play, paid version needed as we will need a "start on boot" function... which does not work in free version) - it is an app which let me OC/UV even on stock kernel by using some custom kernel module (however, the changes are not reported "outside" the app, so you may be wondering if it isn't a placebo - but it is not...), and it will let me to change the voltages in your OC'ed kernel too (and this time the changes WILL be visible, lol...). It is no use to configure the app at the moment, as after changing the kernel to OC'ed - which offers different range of frequencies and different number of freq steps than stock - it will not preserve any settings and it even won't let you load a saved profile; I just run it once to give it root privileges, then I ve made a shortcut on the main homescreen - you'll see why it's a brilliant idea in the next step... Then, I do a NAND backup
(!!! - important!!!) and after flashing your OC kernel - here comes a tricky part
Kcurdup's kernel will cause a system crash of my device (running average, deodexed, near-stock XXCMI2 with some script mods written by myself for my own purposes) in about 30-40 secs after first appearance of the homescreen. There is not much time - I must run the Tegrak (from the shortcut on the homescreen - ha!) and
as quickly as possible try to click options in an order below:
a) load overclock module (it should confirm success with vibration);
b) optimization menu;
c)change upper voltages, for i.e.1600 - 1300 mhz, to ones accepted by my device, or at least similar ones - there is no time to be very precise moving the voltage slider, as even a little too low or too high voltages shouldn't cause a crash immediately without a large CPU stress....
If I manage to do it very fast - and it
is possible
- I am achieving enough stability to browse through optimization menu freely, without time pressure, however it is good idea not to wait because low frequencies (25 and 50) are causing crashes too on device of mine, although they are much more rare. So, first I am making a precise voltage setting (to the values I had obtained experimentally in the past) for 1600 - 1300 MHz voltages, so I am now almost-sure that no reboot for high frequency will happen. Then, I do change scaling setting to 100 - 1600, as 25 and 50 MHz also a reboots on my device (they are much less frequent but they WILL happen for sure in not more than in hour from the boot...). Then, I set the rest of 100 - 1200 MHz voltages to my own settings, then I save the profile + tick "start on boot" setting. This is however not the end...
...as the tegrak won't stick to the scaling settings at boot (as the author says: "it may result in a bootloop" ehh...), which may result in not loading the voltages profile at all on the boot or a reboot when using 25-50 MHz (I don't remember which effect it caused as I did above four-five days ago...). And this is where i make use of the second app - this time it's free - called No Frills CPU, but you may want to use any other app that is applicable for setting the standard CPU settings.. The only thing I use it for is to lock the scaling on 100 - 1600 and use the setting on boot - that is why I have chocen No Frills, 'coz it's the smallest one in the market I think.
After that, the device boots up every time (! -
for sure. I have booted it about 200 times for the last week, every time with success...
And since then, it's working
absolutely stable and
with overclocking (and tegrak's app tweaked voltages...) -- and
with frandom...
Phew...
WARNING: I am not responsible for any damage of device and/or data caused by the method described above, and especially for the possible data corruptions caused by reboots which
will happen if you're too slow.
WARNING 2: DO A NAND BACKUP - after one trial my device never booted again and stuck on "android is updating" screen for ever... no cache/dalvik wiping nor even rom re-flash helped as it was /data partition which was corrupted. There was no solution for similar freezees on the internet (at least I have not found them...), but as it was not the first time for me with such an effect, so I have spent some time (i.e. whole night...) comparing broken and non-broken backups, etc. and finally found the solution - using adb via recovery, or "File Manager" in TWRP recovery, one should
delete /data/system/sync directory - the files inside gets corrupt if the crash/reboot happens when the system is accessing them; deleting the folder may result in some problems with data sync or accounts, but it's a way more easy to fix than installing and configuring all your programs again from the beginning... I had backups of previous system-states with /data corrupted and "android is updating [forever...]" problems caused, for example, by using "reboot" command from the terminal (= immediate reboot without closing the memory access = a risk of corruption...) and not closing the system with the menu... including one from the past that came with no backup around, and as I hadn't found solution that time, I was forced to configure whole tablet from the beginning; deleting /data/system/sync directory
fixed the issue for every previous case of "android is upgrading" hang which couldn't be fixed by reflashing the /system nor by wiping any caches etc..., so it might be a very important observation for all users that like to play with their filesystems (that's why I am mentioning it here, even if it's an offtop)! Anyway, the best solution is to do a NAND backup before playing with stuff like that and this is the only option which I do recommend.
WARNING 3 If someone will try to repeat above steps, he should first check if maybe the kcurdup's OC kernel works WITHOUT all this crazy stuff, as above solution for OC + frandom refers to my device, which is a very hard partner to cooperate I must say... on the contrary, kcurdup's device does not need any gymnastics for OC to work so please try if it is working out-of-the-box, first...
3. Frandom surely
is something. You are right -
N8000 is working as it has never before. It seems that there is nothing to discuss, it's just a good piece of code and I can realize no other kernel than yours in my device - others are just
LAGGY, no matter what entropy they are using
Well, good to hear that I have not wasted your time
And - it is a pleasure to be an inspiration for you (for the second time - our very first conversation resulted in custom kernel + AllShare Cast solution ;P), as the final results are... enormous
Well, I love to swallow and then store millions of information in my head - and good that I have found someone who is worth sharing the theoretical conclusions
Hope you'll continue developing your kernel as it is really blazing fast with frandom... and too bad it's the only frandom based solution for N8000 around... (well, to be exact, it's - almost - the only solution for N8000 at all...)
My next idea is to port a
fiops (v2? or maybe there's further one?) scheduler module for IO operations... it gives me the very very best benchmark results on custom kernels on my N7100. However, it will not result with such a boost in performance as
frandom, for sure, so I can't say that it is essential component ;]
