yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] Entropy512:
We call that find7op - The maintainers for that device are a bit inexperienced (although we have one more experienced one involved with 5.0) but since it's only minimal changes from find7, it doesn't need that much maintainer experience. That said, most of our focus is on the find7 and not find7op, it just happens to be "easy" thanks to our find7 work.

Yeah, I may actually dust off my n7000 and evaluate the patches and put them on Gerrit this weekend for further review/testing/work.

Yes

Interesting, could be useful to look at. I don't think we have a final fix YET - but we're REALLY damn close thanks to you and Lanchon.
[General Omni Discussion] zeitferne:
I just had the opportunity to run the FPBug app on stock 4.1.2 and Lanchon was right: the corruption does happens there. Interestingly, it even happens when the screen is on.

---------- Post added at 06:19 PM ---------- Previous post was at 05:51 PM ----------

Using this diff

diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 2d30c7f..6910383 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -43,6 +43,19 @@
#endif
.endm

+ .macro DBGSTR2, str, arg1, arg2
+ stmfd sp!, {r0-r3, ip, lr}
+ mov r2, \arg2
+ mov r1, \arg1
+ add r0, pc, #4
+ bl printk
+ b 1f
+ .asciz "<4>VFP: \str\n"
+ .balign 4
+1: ldmfd sp!, {r0-r3, ip, lr}
+
+ .endm
+
.macro DBGSTR3, str, arg1, arg2, arg3
#ifdef DEBUG
stmfd sp!, {r0-r3, ip, lr}
@@ -125,7 +138,12 @@ vfp_reload_hw:
@ last loaded onto.
ldr ip, [r10, #VFP_CPU]
teq ip, r11
- beq vfp_hw_state_valid
+ beq vfp_skip_reload_hw
+ b vfp_reload_hw
+
+vfp_skip_reload_hw:
+ DBGSTR2 "state already valid, state=%p, CPU=%u", r4, r11
+ b vfp_hw_state_valid

vfp_reload_hw:
@ We're loading this threads state into the VFP hardware. Update

I printed to kmsg whenever the optimization you commented out was made and it got flooded, so it seems that the optimized path is taken more often than (at least I) expected.
[General Omni Discussion] Lanchon:
at the point where the state load would normally be bypassed you can verify that the state in hardware actually matches the state in ram and detect would be corruption as it happens and without FPBugX.apk. to do this it's easiest to save current state to a new area and compare both saved states.

this doesn't help me cause i don't have a device but it might help your debugging

---------- Post added at 03:29 PM ---------- Previous post was at 02:47 PM ----------

i can't look at this now, but i got 2 complete n00b questions: what is stopping us from merging most of mainline? and is there a tool to do this, some GUI that eases the process? i just used git and manually solved the .rej files in the past

---------- Post added at 03:31 PM ---------- Previous post was at 03:29 PM ----------

btw, i broke the news to users with a bit of history, hopefully they'll bite :)

http://xdaforums.com/galaxy-s2/deve...ernel-fpbug-stable-4-x-kernel-galaxy-t2978088
[General Omni Discussion] zeitferne:
I normally use git cherry-pick or git merge, so git inserts conflict markers directly into the files. There is also git mergetool, for which you can use e.g. meld or kdiff3 (or vimdiff :P) but personally, I find these tools confusing as I don't know which change comes from where in the three windows that are then shown. Also, AFAIK, Dorimanx' Kernel has more mainline commits integrated than CM/Omni.

EDIT: The trick to use git merge and cherry-pick is to add the official linux kernel as a remote to the 4412 kernel.

But I'm not a git expert either.
[General Omni Discussion] notabenem:
Dorimanx has 3.12 (and maybe even beyond) kernel, but it wasn't updated for more than a year. Guess it won't work out-of-the-box for Omni. I am very interested in reviving this kernel (and maybe even more), because it's a suitable candidate to have the bluetooth implementation replaced to that of BlueZ (needs kernel >3.9). That in turn would bring the now very much missing L2CAP support -> the phone could act as a bluetooth HID for your PC and let you use wii remotes, etc.
[General Omni Discussion] pilgrim011:
I don't have the time right now for all of that, but I ran the test once with your cm11 FPBug kernel, and it seems like it's the best i9100 antutu score ever, or something like that ;) :
[General Omni Discussion] Lanchon:
lol

almost beats my opo! :-p

look you should be glad it even finished the test, ok? ;)
[General Omni Discussion] presola:
DorimanX has had only "unofficial" builds during the period you mentioned. They work pretty well with Omni, I've been using the combination for as long as official Omni builds were available for the i9100.

Can't post screenshot nor thread link - ten posts limitation...
[General Omni Discussion] Twiq:
most recent build of dorimanx is by [MENTION=4663860]Computoncio[/MENTION] github (with 2 commits behind dorimanx's)

i think he started merging 3.15 couple months ago, a while after dorimanx started focusing on LG G2 kernel development

the unofficial thread is this way
[General Omni Discussion] zeitferne:
Afte a lot of try & error I finally managed to read the s0 (lower? half of d0) register in assembler, and printed a message when they do not match (and forced reloading of the registers (even when the message is not printed)). I also added printks to the hotplug and cpu_pm notifiers (also merged the two commits I mentioned). Then I ran the FPBug detector and my message got printed far more often than I expected (it also got printed before a few times).

Here are all relevant files: the patches, the kmsg and also a translation from assembler to ("pseudo")-C of the vfp_support_entry procedure, that I manually made (read: may contain errors).

As soon as the screen is turned off, it seems that the FPU register values of CPU0 (!) always get clobbered between the invocation of the vfp_support_entries. Noob question: Do the cores have separate FPU registers?
[General Omni Discussion] Lanchon:
to access the VFP reg set look into vfphw.S, there are vfp_get/put_float/double functions. you can get the asm from there.

the code certainly looks like each core has an fpu! and i always suspected smp implied that
[General Omni Discussion] zeitferne:
Yes I initially got the code from there, but got stuck in a bootloop. The solution was then to use p11 instead of p10 (this specifies the coprocessor to use and is also used in VFPFSTMIA macro, that is used for reloading the state).

Meanwhile I have two more insights:

1. I compared the i9300_defconfig with the i9100 one and noticed that CONFIG_EXYNOS_PM_HOTPLUG is disabled there. The i9100 also does not exhibit the bug in this configuration.

2. I found a vfp_enable implementation and calls in mach-exynos/cpuidle-exynos4.c. Commenting them out did not change anything though.

Having become suspicious of the file, I added prinks at the beginning of the exynos4_enter_core0_aftr and the exynos4_enter_core0_lpa functions that called vfp_enable. Indeed, when I get my flood of "HW state (=%x) for %p on CPU0 not in sync" messages, I also get a flood of messages from "exynos4_enter_core0_aftr". Since this function is only called from exynos4_enter_lowpower, I disabled the CONFIG_EXYNOS4_LOWPWR_IDLE configuration option. Result: The FPU corruption seems to be gone (and my phone is still able to wake up this time :) )
[General Omni Discussion] Lanchon:
zei, this weekend ill try to get ahold of an S3 for a few minutes and verify that it's really not affected. then ill post patches that can be merged in soc-shared trees. i got 200+ kernel downloads yesterday and no probs reported so i think its ready. i wanted to merge the two commits u found though, they sure look relevant, but i dont want to push anything untested. did u find any problems?

anyway we should look for the cause but i cant do much without a device :( in the meantime i think its better to merge asap and then reenable the restore state optimization when the cause is found.
[General Omni Discussion] zeitferne:
Maybe. Android sometimes nearly hangs, it gets so slugish that it causes a soft reboot but even the boot animation is slugish and I have to restart. It seems to affect just userland though and I can get a kmsg (looks normal) or logcat (constant stream of messages, could be normal though) via adb. I'm not sure though if this is cause by these commits, or if I did something wrong with my debugging messages, but for now it would be better not to merge these two commits.
[General Omni Discussion] Lanchon:
thank you. ill follow your advice. plus, i didnt have time to look into those commits yet but at first glance it looks like more are needed anyway. its better if leave kernel updating to people that can test anyway.

speaking of which, i got an invite a month back and bought a oneplus one as a present for a friend who lives in barcelona. and soon he'll be sending me his old S2 with a friend that is coming to visit (i live in argentina), so ill be able to test :)
[General Omni Discussion] AndDiSa:
[MENTION=5948587]zeitferne[/MENTION] [MENTION=4141005]Lanchon[/MENTION] i've merged those two commits into my kernel. I am running it since yesterday but I did not realize those performance issues yet.
[General Omni Discussion] zeitferne:
The performance cost seems to be really marginal. If you want to measure it, an ideal benchmark would look something like that:

1. In one thread, do FPU operations. The speed of this thread is the benchmark's result.

2. Setup other threads that do not use the FPU (make sure to compile with -msoft-float) but which do use the CPU, so that as many context switches as possible occur for the first thread.

Without this patch, Linux would notice that the other threads did not use the FPU and therefore will skip writing the data it saved when it switched away from that thread to the FPU registers again, since it is (or should be; that's the bug) already there. With the patch, it writes the data to the registers anyway (but on the other hand, the patch saves the checking if it has to write the data).

Now I have reverted to stock CM kernel and applied only this single configuration change for which there is one single #ifdef in mach-exynos/cpuidle-exynos4.c (and no references in any makefile) and the bug is still gone. If my thinking is right, this means, our bug can be summarized succinctly as:

FPU registers on CPU0 get corrupted in Low Power Idle State. EDIT3: More specifically in AFTR (sic!) mode. Googling for "Exynos 4210 AFTR" reveals interesting results. [/EDIT3]

There are quite a few branches on soc_is_exynos4210() in the related functions, which would be a good explanation why this happens only on these devices.

EDIT2: Since this Low Power Idle Mode can only be entered if only one CPU is online (see this line) also explains why disabling hotplug gets rid of the bug.

EDIT: A file that is properly unifdefed for i9100 is here (ca. 200 lines ~ 10% less; all remaining #if-branches are active).
[General Omni Discussion] Lanchon:
top performance loss is one fpu context load per timeslice (only the load itself, not the whole trap). its probably under 1%.

you can try antutu before and after, but be sure to run it many times: variation will probably occlude the real impact.
[General Omni Discussion] zeitferne:
Alternative fix, one level deeper

After my investigations in my post above, I just had to put the pieces together:

Actually enable the power management handlers (CPU_PM).

Mimick the mainline cpuidle driver and call cpu_pm_enter/exit when the FPU-corrupting low power states are entered (I have tested, and just AFTR is not enough).

I based my kernel on [MENTION=4141005]Lanchon[/MENTION]'s (this one), removed the last commit that always reloads the FPU and also merged three other commits related to CPU_PM. Here is the gist with the patches:

https://gist.github.com/9fb17c20e635bbffcb7f

I hope the corruption does not come back after a second restart ;) but so far the FPBug app displayed nothing.

I don't know if these low power states are supposed to corrupt the FPU registers, but if they are, this fix should actually adress the root cause.

EDIT: I have added a flashable ZIP with this kernel (MD5: 55b591535854b66ef0de3245183eb33e).

EDIT2: Updated the ZIP to include driver modules, so that WiFi now works. New MD5: 4d9cd2b9021a4652f7d14ea5a101291d.

EDIT3: Fixed a potential bug. Since the kernel was running fine for (almost?) everyone, users don't need to update, but kernel developers should take a look at the change: https://gist.github.com/Oberon00/9f...xynos-call-pm-notifiers-w-irqs-disabled-patch. New MD5: 4852de8e7c3b77878290a72519b8004d

EDIT4: Added a flashable ZIP for Note1/N7000. MD5: df4fb01a03f10ac88309616cddc787ce. WARNING: As I do not own this phone, I cannot test the kernel or the flash-procedure there. Better make a backup before you flash it!

For a full patchset (includes Lanchon's required changes), see here: http://xdaforums.com/showpost.php?p=57654708&postcount=833.
[General Omni Discussion] grzwolf:
Pro: "FP-PM-fixed-kernel-CM11-i9100.zip" runs FPBug.app with no corruption.

Con: WiFi is not working anymore on my s2.

It was and is working on Lanchon's latest.

Fixed with EDIT2 above from Zeitferne. Great Work, many thanks.
[General Omni Discussion] zeitferne:
OK, sorry, now I know what this magic.patch was for ^^. The kernel refuses to load the WiFi driver which lies in a separately compiled module, because it has a different kernel version. Let's see if I can quickly fix this…

EDIT: I updated the ZIP, WiFi should work now.
[General Omni Discussion] snow:
Wi-Fi is working. Don't know if it's placebo, but in my case it seems phone is more responsive (or maybe a little bit). :D

Can you share the commits necesarry to apply to default kernel? Because you made a lot of posts and I don't fully understand what to do (I'm a newbie and maybe a clean post with all commits and/or patch would be easier to "digest" for me). :)

Thanks in advance! ;)
[General Omni Discussion] zeitferne:
Here you go! https://gist.github.com/88964a724d19f2b1e808 (apply with "git am *.patch")

It is based on the current CM11 Kernel.

Up to and including the 8th, these are the patches that Lanchon applied minus his last one that always reloads the FPU registers.

Next come commits related to CPU_PM (including actually enabling them in the kernel configuration) and finally the last one is the essential one: Calling cpu_pm_enter/exit when entering/leaving the low power states.

EDIT: Made a small update, see here: http://xdaforums.com/showpost.php?p=57643086&postcount=829
[General Omni Discussion] pilgrim011:
[MENTION=5948587]zeitferne[/MENTION], do you think that this is the final fix, the "real deal", or another workaround?
[General Omni Discussion] zeitferne:
I'm optimistic:
[General Omni Discussion] pilgrim011:
How should we positively determine this? Do you have an idea?
[General Omni Discussion] zeitferne:
A very good hint that this is supposed to be that way is that the current Linux kernel also calls cpu_pm_enter() when entering the AFTR state (didn't see the LPA (Low Power Audio?) though, maybe it is Android-specific); see here. For a real confirmation, one would probably have to look into the Exynos documentation, if there is any (publicly accessible).
[General Omni Discussion] pilgrim011:
Ran out of thanks, so - thank you very much. :)
[General Omni Discussion] Lanchon:
hey zei, THIS IS GREAT!!!!!

i wanted to work out why the restore optimization broke when i had the time but it looks like you've done it all!! didn't have the opportunity to look into the code you posted but i don't even feel the need to do it now lol! well unless a problem shows up, let's hope not :) this is why i love free software, only question is... when i finally get my i9100 what should i do with it now?? anybody needing a phone here :( ?? lol

i'll edit my project and point to your discoveries. if you can, make sure people test and when ready give a green light to kernel maintainers to merge. i won't be pushing my fix to CM after these news, my published kernels already work as stopgap so no rush. but when you green light your changes, if you don't wanna do it yourself i can push them to CM, just holler.

regarding your patchset, please consider doing this: merge my workaround commit then revert it in a commit of yours. i worry that if you don't do this, both fixes might work their way into some kernels and we don't want that: it'll work but it's not optimal, all your hard work fixing the state restore optimization will go to waste if my fix disables it.

and while you are at it, consider using git format-patch --stdout .. >xxx.patch to put out a single file and reduce chances of mistakes (remember to exclude magic.patch!)

once this is shown stable, maybe it's time for somebody to figure out why CONFIG_EXYNOS_PM_HOTPLUG is disabled in the 4412 kernels. maybe it's part of samsung's workaround for this kernel bug that they couldn't find and it might make sense to revert it.

---------- Post added at 03:08 PM ---------- Previous post was at 02:58 PM ----------

a couple more things for you to look at if you want. last week when i was looking at the code i remember seeing this:

1) vfp_enable (i think) was duplicated in two files (very yuck!) and one of the versions had a commit over it that fixed some bug, while the other didn't

2) does soc_is_exynos4210() even work? superficially at least it looked like there was a problem, can't remember which, looked like not implemented i think
[General Omni Discussion] snow:
You could be a great maintainer for i9100 because you have proved you can fix things without having a i9100 device. :D Imagine if you will receive the device what other great things you can do :D

"Fun" for i9100 (and Exynos4 platform) is not near to end, buddy. ;) [MENTION=5145944]GeeckoDev[/MENTION] which owns N7000 tries to implement hwc, gralloc and Mali driver (r3p2-01rel0 with dmabuf, not UMP) from Insignal source. HWC for our platform it seems to do nothing, so his work will make Project Butter to be a reality and our devices should be smoother than even before! :D

Look here:

http://xdaforums.com/showpost.php?p=57565566&postcount=810
[General Omni Discussion] Lanchon:
[MENTION=5948587]zeitferne[/MENTION] i updated my thread with your findings

http://xdaforums.com/galaxy-s2/deve...ernel-fpbug-stable-4-x-kernel-galaxy-t2978088

well done!

btw, over the weekend i run FPBug2 and 4 (we have more cores) on a friend's i9300 (S3 internat) and couldn't trigger the bug, as expected
[General Omni Discussion] GeeckoDev:
[MENTION=4141005]Lanchon[/MENTION] [MENTION=5948587]zeitferne[/MENTION] [MENTION=591147]Entropy512[/MENTION] I love you guys.

Just a question though, I applied the initial patchset that disables lazy restore, but didn't enable CONFIG_CPU_PM. Tested on Touchwiz 4.1, fix seems to be working. Should I enable it anyway? :)
[General Omni Discussion] Lanchon:
wow that really is amazing work geecko is doing!!! but unfortunately i dont know even half of the acronyms you mention lol :) i dont know the first thing about the linux kernel, arm arch or android for that matter, so dont look at me for maintaining any ports, sorry about that! :)

---------- Post added at 05:01 PM ---------- Previous post was at 04:56 PM ----------

i can only say that my initial fix is not sensitive to any configuration options but the rest of the kernel might be. so if you disabled that option to try to fix this bug, you can reenable it with my fix in place. otherwise your answer lies elsewhere.
[General Omni Discussion] zeitferne:
I think w/o at either calling the notifiers during suspend or when entering low power states enabling CPU_PM would have no effect.

BTW, it's not lazy restore but skipping restore entirely if the thread state is (believed to be) already on the FPU.
[General Omni Discussion] Lanchon:
thats right, my fix just disables a lazy restore optimization
[General Omni Discussion] snow:
I just hope you will not leave S2 area. :D Like FPBug, Geecko's work will help Exynos4 devices to work properly, as other newer devices (smooth). :) Hardware composer (HWC) saves battery while using hardware instead of GPU for screen composition. Look here for more: https://wiki.mozilla.org/Platform/GFX/hwcomposer :D
[General Omni Discussion] GeeckoDev:
[MENTION=5948587]zeitferne[/MENTION] [MENTION=4141005]Lanchon[/MENTION]

I've compiled my Touchwiz kernel with the newer patchset from [MENTION=5948587]zeitferne[/MENTION] but I'm always getting a freeze after turning the screen off and on. :(
[General Omni Discussion] Lanchon:
sorry to hear that. did you also try my patchset or just zei's?
[General Omni Discussion] FrodgE:
Unfortunately I've been pretty busy the past 6 months so I couldn't help with testing, but for what it's worth I added [MENTION=5948587]zeitferne[/MENTION] patch set from post 833 to my local omni clone and have been running it all day without any issues :) I am however still using exFat on my sdcards. As expected the FPbug detector apps [MENTION=4141005]Lanchon[/MENTION] posted in 714 didn't pick up any problems although I must admit I didn't try to reproduce the problem on stock omni. From reading the posts though it sounds like it was easy to reproduce so I'll assume my testing steps were adequate and it passed.

All of the kernel downloads that I've seen listed are targeting CM11 (kinda ironic given this is an omni thread) other than [MENTION=4217277]Gustavo_s[/MENTION] kernel which I don't think contains [MENTION=5948587]zeitferne[/MENTION] last update yet.

For the benefit of other omni users I'd post the kernel I built so it could be tested by more people. Unfortunately my EXTREME n00b status prevents me from doing so (I make the average n00b look like Stephen Hawking). I actually have no idea how to compile and release the kernel independently of the entire ROM build. My googling brings me to guides for downloading the source and configuring the toolchains from scratch, I'd assume that if I have a complete git clone and working build environment many of these steps can be skipped. If anyone can tell me otherwise or point me to a guide I'll upload my build, unless of course someone credible beats me to it.

[MENTION=4141005]Lanchon[/MENTION] [MENTION=5948587]zeitferne[/MENTION] you guys are awesome ! Thanks heaps for your hard work.
[General Omni Discussion] zeitferne:
I assume you mean this Note 1 (N7000) kernel: http://xdaforums.com/showthread.php?t=2397000.

First question(s): Does it only affect the touchwiz version of your kernel? And do I understand correctly that it is based directly on Samsung N7000 Sources and not on any AOSP (CyanogenMod, OmiROM, …) Kernel? Did the patches even apply cleanly there?

That would have been my second question, but looking at https://github.com/libcg/raw_kernel_tw/commits/master, it seems you did. I assume it did work?

Third: Try some debugging yourself! If you can answer all the question above with "yes", you might first want to try independently reverting this (a) and this (b) (and maybe this (c)) . If reverting (a) fixed the problem, simply leave it out, this was a "just to be sure" cherry-pick. For (c), check with the FPBug-App if the bug is still fixed; if so you can leave that one out too. If reverting (b) fixes the problem, add some printks around my cpu_pm_enter/exit calls: Where exactly does the freeze occur?
[General Omni Discussion] grzwolf:
Since you already have a complete ROM:

boot.img --> flashable zip

Concept:

http://android.stackexchange.com/questions/36265/flash-boot-img-without-using-fastboot-usb

Look at answer 1: graph and script only, skip the rest.

You might start with a proven functional zipable kernel for your device.

Anything capable to zip some files will do the job.

Forget about signing the package on a rooted ROM.
[General Omni Discussion] FrodgE:
Thankyou ! I'll take a look. Can you check the url ? It's broken.

---------- Post added at 08:58 PM ---------- Previous post was at 08:42 PM ----------

Never mind, think I found it.

EDIT: Link all sorted, quote updated to avoid confusion.