[Galaxy Note 10.1 Android Development] esgie:
Almost true, but not in every situation. During my experiments I reproduced the issue by symlinking su applet included in the kernel's busybox (which is rare but it is - or at least was - included in andis kernel some time ago...) in a custom way (to /system/bin), so it has been existing in parallel along with regural /system/xbin/su. Two su's = recurrent su requests betwwen those two until something unknown and random breaks the deadlock (stack overflow resulting from too many queued su requests? Dunno... it happens in a random time between 10 mins to 1h after summoning the su = absolutely unusable device) and then the su access is gained successfully by on of the binaries. Also, the deadlock is regarding even some stock system apps which does not require su at all (!). And the best mess happens when supersu settings receives its ownership from different su binary than the app. Then, some apps works " fine" (despite of extremely laggy su access) and others ask for su every time even if u save its settings. I do believe that it can be solved by removing all system busybox instances + symlinks and same with supersu, and then reflashing supersu again and use a regular bb installation method (via boeffla app) or - if u are a scientist-like type - mess with bb in a way that will not result in creating two different su instances in the system. But it may be not enough - as the apps and their data had already obtained two different su permissions during the problems, the ones that were influenced by bb su may still not work. And here comes the fix permission script which shall change ownership of the files to the proper su binary... forgot to add that you may also want to confirm that usb debugging hasnt disabled itself in settings...

Well, that's why it is indeed an issue related to system, BUT it may be initially triggered by busybox included in the kernel. I would vote for removing su applet from busybox binary, then, to exclude such a scenarios and i dont find it useful in any way if you have the other su binary, provided in a standard supersu installation process..

Sorry, but starting from removing everything is the worst advice that can be given. I always try to deal with the issues without clearing all my settings, because i am not a fan of configuring everything from scratch every time something weird happens, and in such a case titanium bkp may NOT be working at all as the su access is messed up! 300 apps to configure = two days of monkey job, without gaining any experience of how to deal with the issue if it happens again. Full clean shall be considered as a last resort, and not as a universal first-aid-like solution to every strange issue.

Whats the point of this advice? Yes, the device is creating some caches to increase fluency when the device is used, but it may collect the same caches with custom kernel, too. No point of delaying the mods, they will NOT cause system to stop building its caches or sth. Plus, after flashing the mods, some caches related to modded parts will have to be built again from scratch, so waiting for system to collect some data has (a very little...) sense only after flashing all mods you need, doing it earlier is a wate of time in my opinion.

When the issue happened, it is no matter if it is su from supersu or koush superuser, as they stuck in a deadlock in absolutely same way. When working well, i haven't noticed any significant differences between the performance of thouse two. Never had any issues with koush superuser (however, i use supersu as it has more config options). Heard about some superuser inconsistences for android 4.4 (or 4.3... something related to file contexts and selinux, afaik), but as for 4.1.2 no difference at all. There is another superuser app by chaindd but didn't use it, as it seems to be obsolete and outdated - i wrote it to be sure that we are talking about same superuser by koush (aren't we?).

Wrong again. As discussed some pages ago, my device has been described as extremely opportunist to overclocking even by the kernel's author. BUT i am still able to oc for 1600mhz, however, i have to use much higher voltages than most users. Didnt ever heard of n80xx that couldn't be oc'ed to at least 1600mhz, but in some cases - if the necessary voltage is much more higher than the one chosen by the kernel's author - it may require some skills to force enabling your extremely high but stable (for u) voltages before the cpu is scaled to 1600mhz on default (too low) values, which will cause annoying reboots in 30 seconds after boot completion due to too low voltage. That is why andi helped me a lot by reconfiguring his app to set my voltages BEFORE enabling 1600mhz freq, and recently he increased default 1600 voltages a little, so more users can use oc out-of-the box (but my "difficult" device still require additional 50mv, so the second solution wouldn't be helpful for me without the first one, eg triggering voltage table modification BEFORE allowing cpu for 1600mhz, so it will be using modded voltages for the oc freqs from the same beginning, without a risk of freezee.

However, if my device is a rare example of very nasty one when it comes to oc'ing, with some combinations (and after recent dev's changes - even without any magic tricks...) it still CAN be oced to 1600mhz and keep stable. I do not believe that there are n80xxs that can't be oc'ed at all, no idea from where did you got that info.

BEEP. Not true, but really a myth when discussed in the context of modern devices. The silicon electronics does NOT degrade of the electricity flowing thru it - it's not a car's engine, for god's sake! In theory, the damage may occur by forwarding a bad ccurrency to a wrong, unprotected electric path, but it is a 0/1 situation, which happens in a second and that's all, cpu is dead, or doesn't happen at all. "Degradation" shall be understood as a process of regular decreasing the inner cpu electrical connections quality in a function of time - and it just does not happen, as the electrons does not harm the physical structure of wiring itself!!! Summary: if you kill the devicy by oc'ing it, it is a result of one, microsecond-long electrical event, and it is not dependant of for how long you've been using oc succesfully before it happened. It's a magnetic field flow, not a mechanical movement, for god's sake.

In practice, even the "immediate death" does not seem to be somthing that may happen at all. Yes, too high voltage causes the electric loads to "jump" between electric paths, which is unwanted and which may cause a serious cpu overheat of course - but the temperature will raise after some significant time! And it is impossible to happen, as the device crashes in a millisecond after first flow error (obvious! The "jump" causes the cpu to behave in a random way immediately, which breaks the machine code logic, so all the instructions are performed in absolutely random way, which system isn't prepared to support, so it crashes in a sec) and it does not even give a chance to flood the cpu with further unwanted electric loads to increase the temperature furthermore (exception: it may keep working in an unwanted way if you mess with kernel panic settings and force kernel to keep running even if errors happen, but the default settings are ok and prevent the cpu from continue working after detecting the very first symptomps that it is happening).

When running on stable oc setting the device may heat up a little bit which might cause harm, at leas in theory - BUT, again, sammy's devices do have an inbuilt rescue mechanism, forgot its name, which is triggered after reaching the last safe value of the cpu temperature, which causes the cpu to lower its frequency (ignoring the governor's request...) until it cools down to some point. No risk here, too!

The only danger that shall be considered as real may be a data loss caused by an immediate freezee (ie during some unfinished io operations), but - AGAIN - it will not cause a harm to system or data devices when using default ext4 with journaling on (journaling has been created to prevent data loss in EVERY situation of fs operations failure other than physical flash chip damage (however, there are popular tweaks out there which are disabling the journaling to gain io performance, but it is your choice if you use them).

In fact, you may lose some data from ext sd if using fat32 or exfat, as they dont use journaling. And that's the worst what may happen at all.

Dont repeat the gossip-like opinions which hasn't EVER been explained in details. They are much more harmful than oc'ing...