yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] lukacar1:
troubles with link... (and battery)

i haven't seen anyone complaining about links, so i will do it:

Links don't work.

it is easy to find stuff on your website. i just wanted to inform you that links are dead... for me..

I'm from Slovenia if its region problem?

batter quality? "http://shrani.si/f/2J/Gr/4D9UwsjV/screen-site-links.png

and one BIG question!!!!!!! when i charge my phone it gets stuck at 99%. what the ?!&$%#= should i do??

i had 3h of screen and almost 2h gaming and 2 days of battery until this happened... :( (i played real racing 3. it is heavy game) (auto brightness)
[Nexus 4 Original Android Development] Emilius:
I don't believe that is kernel issue. I have similar results on battery and using bricked kernel exclusively for some time now and no problems for me. If that happens to me I will do clean install of ROM and then apply latest bricked beta. If problem still exists I will change the ROM and then if needed the kernel just in case. If nothing is helping then you know what to do. Back to default and use that 1 year warranty :angel:
[Nexus 4 Original Android Development] show-p1984:
Correct, my first post was reset to an older version (I suspect some mysql memcaching issue on xda's side), hence the links didn't work.

#fixed

That is kernel unrelated. Sometimes that will happen because the battery needs to re-calibrate itself. It is not uncommon for any device with Li-ion batteries to show such behavior.

The problem is that batteries get worse over time and charging cycles. Hence you will need some algorithm that adjusts your battery "100%"-state to the current (which may be significantly lower than original design capacity) max charged state. Running this algorithm is usually done during a power off/on cycle.

Without this algorithm your phone would only show about 60% when fully charged after 1 year of intensive usage (=more than one charging cycle each day).

For example my laptop battery:

Bought about 5 Months ago, usually only runs on AC power. There were very few occasions the battery was being used.

Yet it already dropped 0.7Wh (1.3%).
[Nexus 4 Original Android Development] justthefacts:
Is there a possibility to have a copy of the latest with S2W enabled right off the box?

Thank you.
[Nexus 4 Original Android Development] guru_shastri:
i've encountered some unicorns.

yesterday my notification bar stopped responding. (someone else mentioned it and you said it was nothing..) i reset the device and the problem was gone.

just now the screen stopped responding altogether. had to turn on and off, seems ok.

i'm running the newest version of this kernel and stock rom. can't see anything else that could cause this. ( i suspect s2w, somehow)
[Nexus 4 Original Android Development] delacrow:
When I asked this previously the response was that this is a known, though random behavior with s2w. After the app (which is top priority right now) is released, the s2w version 2 will be implemented. I think we seem to expect something new with every release, but in terms of s2w nothing has been changed in a while. I even created tasker profiles to reboot the phone when screen locks up (in response to NFC tag). But for now I am just waiting for the release of v2 and using the old-fashioned power button. The other benefits of this kernel make it all worth it.

---------- Post added at 09:01 AM ---------- Previous post was at 08:47 AM ----------

I do have a question though.

I tried flashing the latest kernel 0507 and got into a boot loop. I cleared cache/dalvik and used the latest twrp. I am sure it's not this kernel, but there must be some common rule I need to be aware when flashing any kernel as I have seen this same behavior earlier and only complete reflash of kernel and rom made it work.

So - can anyone suggest a good rule of thumb when flashing a kernel? I am on the ROM that comes with faux-based kernel. I tried kernel reset zip - that stopped the boot loop but led to indefinite boot animation. I searched this thread for the word"loop" and lack of such term only confirms that this kernel has nothing to do with this behavior.
[Nexus 4 Original Android Development] guru_shastri:
i think some changes has been made with this s2w. it consumed far less battery than be4. but if its still under construction - i'll wait.. i agree about the other benefits of this. its great
[Nexus 4 Original Android Development] jassycliq:
He hasn't touched sweep2wake in the longest time. Proof is in deh sauce.
[Nexus 4 Original Android Development] Hai_Duong:
Sometimes I have to tap the screen first then swipe than it wakes the screen up.. Is that normal? Because when I lock the screen and swipe instantly it wakes the screen up but when I wait 1h then I need to tap it first.
[Nexus 4 Original Android Development] show-p1984:
If this was happening across different kernels and roms then that sounds like a bad emmc to me. Seems that some flashes are hitting bad blocks and hence fail to be written.

Watch this behavior closely and use your warranty :)

As to your question: There is no special way to flash a kernel. Take me for example, I am lazy. I just flash everything over. Still works. :p

The unresponsive touchscreen issue is related to sweep2wake, hence that feature is disabled as default.

The statusbar unresponsiveness is not kernel related. (The kernel doesn't even know that there is a statusbar on the screen, yet alone where it is)

There were no changes to s2w inside of this kernel in a long time. s2w2 is developed on a different branch and hasn't left my house, yet.

S2W is disabled as default exactly because of those issues. If you use it, brace yourself for the unicorns.

###

There is a new beta up with a fix to the new input boost feature.
[Nexus 4 Original Android Development] justthefacts:
Show-p,

I am using your 4-28 release which has S2W enabled by default.

Are there any other later releases that have s2w enabled? I've had no good experiences with apps that tweak the kernel and am adb illiterate. :(
[Nexus 4 Original Android Development] lukacar1:
...

thanks :) (clicked too :D)

i rebooted phone many times from the incorrect or something charging... and phone was charging on 99% for about 2h.

today i only had 2h of screen and 20min. of light game (beny bananas :P good game :) )

i hope battery isn't broken... (allready went to ebay i can get new deliverd for 35€ in 5-6 days :P)

i reverted everything to stock. now and im waiting for results...

and i know a lot about Li-po and Li-ion batteries i was just reading and readnig from batteryuniversity.com or something like that... :)

i did backup for all apps no system. but when i restore it get stuck at googlequicksearchbox.apk i checked the forum a little and only reports have been with titanium backup to not ever restore... (haven't searched for googlequicksearchbox but for all who get stuck at restore...)
[Nexus 4 Original Android Development] show-p1984:
New beta build is running:

http://buildmachine.zapto.org:88/projects/1/builds/859577219f330a8cae50a413c7380c1a76b87ca0

Grab it while it's hot :p

Changelog for the lazy ppl: https://github.com/showp1984/bricked-mako/compare/7dc471c...8595772

(sets s2w to disabled by default in aroma and allows you to reactivate it in aroma if you choose it. Beware of the unicorns and don't report any bugs with s2w enabled :p)

That's wildly off topic here and I have no idea what would cause that.

###

Edit:

The new beta was just bumped to stable. Happy flashing.
[Nexus 4 Original Android Development] justthefacts:
Just flashed it. s2w through aroma. U D Man.........:cowboy:
[Nexus 4 Original Android Development] Emilius:
Woohhaaa new stable is smooth like crazy. Butter smooth. Let's test it for couple days and see what happend with the battery. :good:

---------- Post added at 02:38 AM ---------- Previous post was at 02:20 AM ----------

I have some strange things found with new stable kernel. I am using Kernel Tuner as always. Min. CPU on line 4 (my decision) and single core on screen off is disabled but after turning on the screen there is just 2 CPUs on line. Also min. frequency for CPU 0 and 1 is 918 MHz not 192 how I set it up. In previous beta versions I did not have that problem. :rolleyes:

uh oh, going bak to previous beta from 05/08 the problems now exists too. hmmm now what?
[Nexus 4 Original Android Development] show-p1984:
Something sets that min freq. Find out what and get rid if it :)

(Even kcontrol gets confused by the freq boost, I need to update it too)

As to the cores on/off: I suspect you didn't disable mpdecision but rather set min cores to 4. As default mpdecision does unplug all cores on screen off and only replugs cpu1 on screen on. (Scroff_single_core)

The other cores will come online the first time they are needed and will stay online then. (With min cores set to 4)
[Nexus 4 Original Android Development] Emilius:
Okay thanks, will try to find what is setting that min, freq. The problem is Kernel Tuner dues not have switch ON/OFF for mpdecision. I guess I need to do init.d script for that. Oh man I am lazy for editing every time I need something.
[Nexus 4 Original Android Development] jassycliq:
check the trickster beta. He recently added support for show-p1984s mpdecision. It has the on/off switch and more. Only thing is that it hasn't been updated for the new touch boost stuff.
[Nexus 4 Original Android Development] Emilius:
Where I can find beta version? Here on XDA I am unable to locate ti in original treat.
[Nexus 4 Original Android Development] jassycliq:
http://timos.me/tm/downloads/start?&#beta_versions
[Nexus 4 Original Android Development] Emilius:
There is a hotplug not mpdecision switch. Am I missing something here?
[Nexus 4 Original Android Development] jassycliq:
To disable you disable and turn off screen off single core
[Nexus 4 Original Android Development] Emilius:
it is already off for me but hot plug is different from mpdecision, These are 2 completely different ways how to handle CPU and the options for it are on completely different folders,

Anyhow, I have made init.d scrip but seems that is not working for me eider. Is it this how the line should look like?

echo 0 > /sys/kernel/msm_mpdecision/conf/enabled

Do I need to add anything else to it?
[Nexus 4 Original Android Development] elbermu:
Did you set the correct permissions?

chmod 755 /system/etc/init.d/yourfile
[Nexus 4 Original Android Development] Emilius:
Yes, that is first thing i check. I am on Slim ROM and init.d is enabled. I don't get it.
[Nexus 4 Original Android Development] show-p1984:
Leave your setup as is and try the new beta (39ba7de) http://bricked.de/index.php?action=kdownload&device=mako&release=beta&type=aosp

It fixes some mpdecision bugs and restores min/max_cpu settings on screen on/off if you use scroff_single_core.
[Nexus 4 Original Android Development] Emilius:
Yep, that fix to problem completely. Kernel Tuner still get confused with min. CPU freq. but System Monitor shows min. freq. 192 MHz for all cores which is correct. Turn off screen dues not kill CPUs anymore and all 4 of them are on line all the time. :good:
[Nexus 4 Original Android Development] leos0000:
Got bootloop sh!t with latest beta on hynon rom :(
[Nexus 4 Original Android Development] Emilius:
as usual try to clean the cache and then if that dues not help dirty flash again same rom.
[Nexus 4 Original Android Development] show-p1984:
Don't see a kmsg, sh!t!

I guess you have checked the md5 and sha1 before flashing? :/
[Nexus 4 Original Android Development] Emilius:
Is it latest stable from 05/10 any different from latest expo from 05/09?
[Nexus 4 Original Android Development] show-p1984:
https://github.com/showp1984/bricked-mako/compare/028db65...39ba7de
[Nexus 4 Original Android Development] Emilius:
KControl is needed more then ever now. Kernel Tuner starts to akt really strange. I am not really sure is it in Min, freq. still some bugs to fix but Kernel Tuner is still confused there.
[Nexus 4 Original Android Development] show-p1984:
Here is a good explanation as to why this is happening with some apps:

http://xdaforums.com/showpost.php?p=41268860&postcount=2458
[Nexus 4 Original Android Development] Emilius:
So, in short, boosting and unboosting make Kernel Tuner go crazy? is it? That is the reason why I see idle freq, is back to 192 in System Monitor app but Kernel Tuner is all mest up and showing me some ridicules freq.
[Nexus 4 Original Android Development] show-p1984:
Probably (I don't use Kernel Tuner). :)

It may also set some new min freq. while it is freaking out, watch out for that. (That was what happened to the ppl on the ville thread, who had a phone running @ 918min and ofc had a warmer phone than usual)
[Nexus 4 Original Android Development] apatal:
Just flashed the newest stable build. Really loving the butter. Great job on this, Dennis. ;)
[Nexus 4 Original Android Development] justthefacts:
Just flashed 05/10. So far so ggod...Nice & smoooooth.

One thing I have noticed ever since your earliest May version, the Minimum frequency is set at 918. when I choose a lower value, it still shows 918 but the actual value changes to whatever I set it to (384) and I can see the cpu goes down to 384 but after a while the cpu does not go down to 384 anymore and gets stock at minimum value of 918.

The 4/28 version did not have this behavior. the minimum value was changeable on the screen and always stayed at that value.

Thank you.
[Nexus 4 Original Android Development] Ranaquajaro:
Correct me if I'm wrong but I think it only goes higher after you touch the screen. Try waiting a while and see if it goes down
[Nexus 4 Original Android Development] Emilius:
Very same problem here. What ever you use to setup CPU or kernel is no good. That app is not fully compatibile with briked. I have no idea what we can use at this point. Try other kernel apps. Drop the line here if you found any other app without this problem. :confused:
[Nexus 4 Original Android Development] show-p1984:
System Tuner works perfectly so far but has the disadvantage that it does not care about offline cpus.

And it isn't incompatible with bricked, those apps are just malfunctioning. (Now I can say that because I already fixed KControl :P)
[Nexus 4 Original Android Development] Emilius:
It's loo like FauxClock dues not have that problem. There is no mpdecision settings but I can change that manually with Root Explorer for now. :)
[Nexus 4 Original Android Development] justthefacts:
I don't use any third part apps. Never had any good experience with any of them I set the cpu speeds within the rom
[Nexus 4 Original Android Development] jassycliq:
AFAIK CM has either

A) Not bothered to updated that code, so it only sets it to the first core.

Or

B) Relies on the kernel to set all the cores according to the first core.
[Nexus 4 Original Android Development] bigeyes0x0:
[MENTION=4195844]show-p1984[/MENTION]: I managed to code my app to work with your boost_freqs sysfs (msm_mpdecision) correctly but then I find changing that also changes scaling_min_freq to the previous boost frequency for online cores at the time. This problem happens sometimes but not all the time, and when I add sleep one second to my code before writing values to boost_freqs in hope of not triggering the boost mechanism the problem goes away.

I tested with 028db65 (latest stable ATM), is it a bug in my app or a weird side effect in your code? The work-around works, but is rather ugly so I want to find a better solution. Any pointer is appreciated.
[Nexus 4 Original Android Development] show-p1984:
I would just scream it's your app now :)

No seriously now. I tested it over sysfs extensively and the kernel behaves as it should. Touch the screen, echo a min freq and the kernel keeps that minfreq and also remembers it for any consecutive boosts.

Try it yourself, if it happens over sysfs on your device you can give me a call :)

I would look into your async thread used for updating the ui elements, as it runs out of sync there might be an update before the frequency can be set, which would result in the current frequency being set. (Haven't looked at your code, if that is even possible, but a thread would be the best way to do it so I just assume you are using one)
[Nexus 4 Original Android Development] bigeyes0x0:
Here's the code:

local ARGS
local INDEX
if [ -f /sys/kernel/msm_mpdecision/conf/boost_freqs ]; then
local -a ARR
ARR=( `cat /sys/kernel/msm_mpdecision/conf/boost_freqs|xargs` )
[B]sleep 1[/B]
fi
while test $# -gt 0; do
case $1 in
HP_CONTROL_BOOST_FREQ_CPU?)
INDEX=${1: -1}
if [ $2 -ne ${ARR[$INDEX]} ]; then
echo "$INDEX $2" > /sys/kernel/msm_mpdecision/conf/boost_freqs
echo "$1=$2"
fi
;;
*)
ARGS="${ARGS}$1 $2 "
;;
esac
shift
shift
done
setTunablesInPath "/sys/kernel/msm_mpdecision/conf" HP_CONTROL_ $ARGS

To put it short, this code does not touch scaling_min_freq (setTunablesInPath function only affects syfs under its $1 argument), it does use an async thread and that thread is run right after user applies settings, so I'm pretty sure it's side effect in your code. It can be described like this:

User touches apply in my app -> touch boost apply (scaling_min_freq get boosted) and async apply thread in my app runs with above code -> scaling_min_freq isn't reset back to previous min frequency in your code so it keeps the previous touch boost freq value

If I have the bold "sleep 1" there, it does not happen as the flow above is different. The async thread will wait 1 second in the script there before writing to any sysfs. It works but I want something less hacky :D.

EDIT: If you simply test over sysfs, there's no touch boost involved during this process so it works. If you echo to boost_freqs during touch boost applies (by touching screen around), it happens.
[Nexus 4 Original Android Development] show-p1984:
I assumed that you were talking about the scaling_min_freq, which you are not.

The boost_freqs sysfs link doesn't have any actual function linked to it in my kernel, it just updates the variable in my per_cpu struct.

( https://github.com/showp1984/bricke...fcf34/arch/arm/mach-msm/msm_mpdecision.c#L939 )

Changes to the boost_freqs sysfs stuff can't possibly affect that your cpu min gets stuck. The next boost will just use the new boost freqs.

I can take a deeper look tomorrow and test this with some bash scripts, but it's currently 8 am here and I need to sleep after I picked some stuff into my grouper repo :)

Edit:

To your edit: :D

I am ofc touching the screen while echoing stuff over sysfs -.-

Edit2:

I have to correct myself, after lying in bed for 2 minutes I thought about my min update function:

if ((cpu_policy->min != per_cpu(msm_mpdec_cpudata, cpu).boost_freq) &&
(cpu_policy->min != per_cpu(msm_mpdec_cpudata, cpu).norm_min_freq)) {
pr_info(MPDEC_TAG"cpu%u min was changed while boosted (%lu->%u), using new min",
cpu, per_cpu(msm_mpdec_cpudata, cpu).norm_min_freq, cpu_policy->min);
per_cpu(msm_mpdec_cpudata, cpu).norm_min_freq = cpu_policy->min;
}

This might be triggered if you change the boost_freqs while boosted since the current boosted freq is different than the one saved in my per_cpu array.

As I said I will test that tomorrow but chances are that the store function just needs to update the current boost value on all cpus to fix this. (if it is this at all, you can check that btw if you look at the kmsg, the kernel should spit out that the min freq of cpux was changed).
[Nexus 4 Original Android Development] bigeyes0x0:
Yep, I'm pretty sure that sysfs store code does not touch scaling_min_freq, but it's somewhere else in your msm_mpdecision implementation. This is why I said it's a side effect. Side effects are nasty, hard to track, but when you actually found the place causing the problem, typically it'll be very simple to fix.

This is how to reproduce it without using my code, my app, just with only adb shell, my hand, and my phone with your kernel:

- Supposedly boost_freqs is at default (918 918 702 594)

- adb shell to the phone then

$ su
$ cd /sys/kernel/msm_mpdecision/conf
$ for i in 0 1; do
> echo $i 810000 > boost_freqs
# IOW, change core 0 and 1 boost freq to 812, "fondle" your screen just before the enter after "done" below :D
> done
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
918000
$

This is how I reproduce it, and it works every time for me.

EDIT: If you like conversation like this to be on other channel, please do tell me, as it might be inconvenience for other users.
[Nexus 4 Original Android Development] show-p1984:
Look at my previous message, I edited it a few minutes ago :)

Sent from my bed. Good night /me setting phone to vibrate
[Nexus 4 Original Android Development] bigeyes0x0:
Yep this is it, as this is exactly the log in kmsg when I ran my previous dummy code

<6>[14656.310543] [MPDEC]: cpu0 min was changed while boosted (384000->918000),
using new min
<6>[14656.310573] [MPDEC]: cpu1 min was changed while boosted (384000->918000),
using new min

Tell me how you want to handle this when you wake up, as I definitely don't like how I have to sleep my code to workaround this.

Good night for now. as I'm also going for a nap :D.
[Nexus 4 Original Android Development] show-p1984:
I will fix that in a sec, currently dealing with this though:

Mirrors until bricked.de comes back again: (only stables)

( https://plus.google.com/u/1/108262968419038009038/posts/fywCkXpfVZD )

Mako:

Kernel: bricked_mako_20130510_005118_master-028db65.zip

MD5: bricked_mako_20130510_005118_master-028db65.zip.md5

SHA1: bricked_mako_20130510_005118_master-028db65.zip.sha1

Grouper:

Kernel: bricked_grouper_20130510_211856_master-ef19bf2.zip

MD5: bricked_grouper_20130510_211856_master-ef19bf2.zip.md5

SHA1: bricked_grouper_20130510_211856_master-ef19bf2.zip.sha1

Ville:

Kernel: bricked_ville_20130510_033625_master-e34c2f0.zip

MD5: bricked_ville_20130510_033625_master-e34c2f0.zip.md5

SHA1: bricked_ville_20130510_033625_master-e34c2f0.zip.sha1
[Nexus 4 Original Android Development] franciscofranco:
Why are you changing min instead of boosting policy->cur?
[Nexus 4 Original Android Development] show-p1984:
Because policy->cur just holds the current rate. Changing that would only bump the freq for as long as it takes for the governor to change it again. Using ondemand that would be very very very short.

I wanted to boost the frequency for about a second, because most ui animations take a second to complete. The only thing that could do that for me was changing policy->min for the required time.
[Nexus 4 Original Android Development] franciscofranco:
Yeah I suspected you would say that. How about scaling sampling_rate dynamically instead of pushing min to 918MHz (in case of your example)?
[Nexus 4 Original Android Development] show-p1984:
That would have too much hooks in other files and therefore be dependent on them. Some governors also modify the sampling rate. I also wouldn't be happy with that since it's more like a dirty hack instead of the solution. (it would also pause the governor from scaling ABOVE that frequency, which is not what I want)

I only had two options that would be clean and uniform:

a PM QOS request that bumps the min freq.

This one I ruled out because the pm qos was the one thing that made so much problems on my 1X. Because I wanted a piece of code that allows being used on tegra 2.6.x and msm 3.4+ kernels without major headaches, I didn't choose this.

bumping min freq to a specified value for a specified time.

I ended up choosing this. Why? It is fairly easy to do: verify that you are within limits, bump the freq, push the cpu policy. User changes the min freq? Update it and restore boosts to that.

It's also clean and effective.
[Nexus 4 Original Android Development] myfluxi:
Dennis, 2 Zeilen code fixen s2w.

Cheers from Kölle
[Nexus 4 Original Android Development] superleeds27:
Fluxi :0 You have an N4?
[Nexus 4 Original Android Development] geroxx:
Thought the same!
[Nexus 4 Original Android Development] myfluxi:
Just like the S2, just better.
[Nexus 4 Original Android Development] superleeds27:
Just stumbled across hells-Core b14

Seems really good!

mako_hotplug 2 ;)