yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] Entropy512:
I won't be able to look at the detector source for a while, but it might be interesting to potentially look into a way to force hotplugging in/out. Also I need to look into whether there's an easy way to figure out which core you're running on.

It would be VERY interesting to see:

"Corruption detected, current core is NOT the same as the core that we started on"
[General Omni Discussion] drdays:
Left screen to turn off automatically. Didn't do any Intensive read-write tasks.
[General Omni Discussion] Lanchon:
the detector is the same one i posted months ago except i added a sleep call in the loop. you only need look in jni directory, the rest is bloat. there's a bash script (in ../) to build the native executable. you can run it from the shell instead of building the whole app. it seems one process is enough.

i dont see a reason why linux wouldnt normally migrate cores, and nothing bad happens then. that code probably works fine, hence the requirement of cpu off.
[General Omni Discussion] ajislav:
Fpbug1 just left sleeping for a fewminutes.
[General Omni Discussion] ajislav:
Better screenshots
[General Omni Discussion] Lanchon:
it would help to know if there is advantage in running 2 process instead of 1. does it trigger the problem sooner? or is it the same?
[General Omni Discussion] zeitferne:
So for me this looks like an error to restore the registers when the CPU is brought up. Looking at the (probably) relevant function in the source code, the possibility of a mismerge comes up again:

Relevant kernel code. ("called" from here)
[General Omni Discussion] Lanchon:
i looked at the same code earlier, can't be. the folks at the linux arm list told me there is no reg saving during hotplug cause it only happens when the cpu is idle. and it looks like they are right:

https://github.com/CyanogenMod/andr...k4412/blob/cm-11.0/arch/arm/kernel/smp.c#L349
[General Omni Discussion] zeitferne:
I tried the 2-Processes Version. Installed via adb, started, screen off, wait a few seconds, screen on, already all two processes have ended. (Note: I'm still running the kernel with my patched GIC/MCT if that matters). Result is similar to the others, no hex-digit is less than 3.

Tried a second time, kept the screen on, made sure the second core goes on and off a few times ‒ nothing. Switch the screen off and on again: Instant "success".

EDIT: It would be really helpful if the processes could print the "kernel time" (the one you see in the kmsg) when starting and ending. That would make it easier to correlate with the kernel log.
[General Omni Discussion] grzwolf:
Couple of runs each with just screen off, no further activities. No reboot in between, only app kill.

1 process - corruption after: 74ms, 156ms, 52ms, 17ms, 121ms, 99ms

2 processes - corruption after: 54ms/24ms, 50ms/19ms, 60ms/12ms, 39ms/64ms, 215ms/80ms, 115ms/45ms

Seems to happen pretty random.

btw: I never before experienced any issue regarding "music bug".
[General Omni Discussion] Lanchon:
so success is instant, ok. what happens with 1 process? is it as fast to trigger?

(see my answer to entropy, very easy to mod yourself, especially if one process is reliable.)

---------- Post added at 07:33 PM ---------- Previous post was at 07:30 PM ----------

thanks! the displayed time does not say how long it took to detect, only the duration of the sleep that was affected (the last one).
[General Omni Discussion] zeitferne:
Without using a stopwatch, I would say yes, the one and two process version show corruption after about the same time.

In both cases, it does not happen if I switch the screen on and off instantly (e.g. double-tap the lock HW-button), but only if I keep it off for a few seconds.

EDIT: Does anyone have a Stock ROM or 4.3 based ROM available? Testing on that would be really helpful!
[General Omni Discussion] Lanchon:
i ran out of thanks today :(

the bug should be triggered on anything newer than gingerbread, including stock ICS and JB. that's why i wanted an app that didnt require root.
[General Omni Discussion] Hank87:
I'm using an n7000, tw based rom android 4.1.2

Using fpBug1, after about 10-15 seconds, always screen on, appear this:
[General Omni Discussion] Lanchon:
testers needed please...

these are recovery-flasheable i9100 kernels. they are matched to CM11 M12. if you are running M12 (or somewhat near, it should work anyway) please test:

START) you may want to take a nandroid or backup your kernel

1) flash this STD kernel (just a standard rebuilt CM11 M12 kernel). verify that you can reliably detect corruption using fpbug1 or fpbug2 (your choice).

2) flash V0, verify that you can still detect corruption.

3) flash V1, verify that you can still detect corruption.

4) if you were unable to detect corruption in 2) or 3), please flash STD again and verify that you can detect corruption once again.

END) restore your full nandroid, or just your kernel (boot partition), or reflash your favorite kernel.

thank you!!!
[General Omni Discussion] zeitferne:
Tested on all three kernels, happens everywhere (1 process version).

What did you change in these kernels?
[General Omni Discussion] ajislav:
I am getting corruption with fpbug2 even with screen on, STD kernel, isn't this weird?
[General Omni Discussion] cdrivex4:
I second that, the third kernel seemed especially quick to generate an error, the screen was still on and hadn't even pressed power button.all however generate the issue.
[General Omni Discussion] zeitferne:
For me, the corruption takes longer to occur when the phone has already been running for some time.
[General Omni Discussion] Acid0057:
I'd help test to but I'm on a nightly right now. Hopefully m13 is out soon. If you setup a test on m13 I'll gladly help.

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] Lanchon:
thank you guys!

this more or less rules out scenario #3 in my post above: context switches failing do to FPUs powering up in an unexpected state.

here is the relevant diff for V0:

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 6f4ecfc..6092599 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -42,6 +42,10 @@

#include <mach/sec_debug.h>

+#include <asm/vfp.h>
+#include "../vfp/vfpinstr.h"
+//#include "../vfp/vfp.h"
+
/*
* as from 2.5, kernels no longer have an init_tasks structure
* so we need some other way of telling a new secondary core
@@ -281,6 +285,18 @@ static inline int skip_secondary_calibrate(void)
#endif
}

+static void vfp_init_4210(void)
+{
+	/* Enable full access to VFP (cp10 and cp11) */
+	set_copro_access(get_copro_access() | CPACC_FULL(10) | CPACC_FULL(11));
+
+	/* Enable VFP */
+	/*fmxr(FPEXC, fmrx(FPEXC) | FPEXC_EN);*/
+
+	/* Disable VFP */
+	fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
+}
+
/*
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
@@ -312,6 +328,7 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
printk("CPU%u: Booted secondary processor\n", cpu);

cpu_init();
+	vfp_init_4210();
preempt_disable();
trace_hardirqs_off();

basically, in the code that boots up stopped CPUs to bring them back online i wasn't finding FPU initialization. the CPUs boot to idle, so the FPUs could be initialized by the next context switch and the power-up state could be completely irrelevant, or initialization could happen elsewhere in code i didn't see, but it was worth a try.

STD is just your standard CM kernel for control purposes.

V0 initializes the VFP and then disables it when booting secondary CPUs

V1 initializes the VFP and then enables it when booting secondary CPUs

---------- Post added at 10:54 AM ---------- Previous post was at 10:46 AM ----------

yes it is, very. STD is just a standard CM kenrel. any chance you might be confusing it with V1?

you also had trouble with STD? or only with V1?

V1 boots to an enabled FPU and that could potentially trigger failure of context switching after all secondary CPU boots. so screen-on corruption in V1 (and only V1) wouldn't be surprising. it would be interesting to see the register values produced after a screen-on corruption though.

---------- Post added at 10:57 AM ---------- Previous post was at 10:54 AM ----------

i suppose you can safely flash an M12 kernel over any later nightly. very few changes are being made after M12, they are working on CM12.
[General Omni Discussion] cdrivex4:
on a nightly 3.0.64-CM-g22cbfc build02@cyanogenmod #1 it generated the error, ran test as per steps methodology and on all 3 kernels supplied it generated the error. Returned to nandroid backup afterward.
[General Omni Discussion] Lanchon:
unfortunately i have no idea which kernel is 3.0.64-CM-g22cbfc build02@cyanogenmod... :(
[General Omni Discussion] Lanchon:
this kenel is essentially V0 but it also loads the constant 0xDEADBEEFu into d0.

please test and capture the output of the p#/d0 lines. this will tell us if secondary boot state ends up creeping into userland visibility.

thank you!

static void vfp_init_4210(void)
{
/* Enable full access to VFP (cp10 and cp11) */
set_copro_access(get_copro_access() | CPACC_FULL(10) | CPACC_FULL(11));

/* Enable VFP */
fmxr(FPEXC, fmrx(FPEXC) | FPEXC_EN);

vfp_put_double(0xDEADBEEFu, 0);

/* Disable VFP */
fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
}
[General Omni Discussion] cdrivex4:
When u say capture we are still talking screenshots..
[General Omni Discussion] Lanchon:
yes. were these taken with V0X then?
[General Omni Discussion] cdrivex4:
Yup, had to rename 001-004 not enough character space in Cwm considering ur name convention. gt a little confusing.
[General Omni Discussion] Entropy512:
There is actually a way that userspace processes can inject stuff into the dmesg. (But this might require root or at least system permissions...)

I'll try and remember to look up the exact code tonight. Look for "klog" stuff in system/core for hints

That's VERY useful info, it confirms the stuff the Mozilla guys found, and also confirms it's not a mismerge issue due to us moving to the smdk4412 kernel

Most of the Exynos4 kernels have barely been touched in ages, so unless changes were made in system/core that led to init incompatibilities, you can probably use the kernel for anything done in the past few months.
[General Omni Discussion] zeitferne:
EDIT: SORRY, false alarm. Don't know why the corruption didn't happen first. After a restart, it happened again. :(

-----

Looks like our kernel is missing this commit: ARM: vfp: fix a hole in VFP thread migration (and the next one). The commit message of the former contains a very exhaustive description of what happens.

This is basically the best thing that could possibly happen! :victory: A mainline patch that was forgotten to be merged that addresses exactly our problem! I compiled the kernel with these two commit cherry-picked, and so far, I have not been able to reproduce the corruption using the FPBug app.

I just don't know why the problem does not affect 4412 based devices. Maybe just the different timings?

I have attached the boot.img (MD5: fdf38e921df15d94aa801d222aed8db5) (flashable with heimdall). Lanchon, it would be great, if you could make a flashable zip out of it!
[General Omni Discussion] Lanchon:
very interesting. those commits should probably be included anyway. i assumed arm vfp's handling was done all neat by hooking context switch and vfp trap and sort of proved to be correct. but it seems to be a can of worms with corruption cases on races appearing over and over. this sucks!

---------- Post added at 02:16 PM ---------- Previous post was at 02:14 PM ----------

i'm still waiting for these answers....

[/COLOR]

yes it is, very. STD is just a standard CM kenrel. any chance you might be confusing it with V1?

you also had trouble with STD? or only with V1?
​
[General Omni Discussion] notabenem:
Are we looking into the right direction?

I have installed FPBug2.apk. Gustavo's latest kernel with root.

Had it running for a couple of minutes with screen on: no corruption.

Turned off the screen, waited 10 seconds, turned on, and I say corruption in both threads/processes.

I fired it up again. Screen on. While it was running, i executed a couple of:

1|root@i9100:/ # echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu0/online

commands.

This guaranteed turns off the CPU, even if only for a short while. There was no corruption.

Turned off the screen again, and after 14secs I got the corruption again. Which kind of raises the question: can't it be the MALI blobs and graphics drivers (which to my knowledge are binaries) messing up the FPU regs? I mean, what else can it be at this point?
[General Omni Discussion] zeitferne:
I'm pretty sure there is some additional Android specific magic going on when you turn off/on the screen, e.g. wakelocks, early/late suspend/resume.
[General Omni Discussion] cdrivex4:
---------- Post added at 02:16 PM ---------- Previous post was at 02:14 PM ----------

[/COLOR]i'm still waiting for these answers....

[/COLOR]

yes it is, very. STD is just a standard CM kenrel. any chance you might be confusing it with V1?

you also had trouble with STD? or only with V1?
​

[/QUOTE]

Yes I did, at least I think I did see below.

Renamed the kernels 001-004 each required three screenshots in total...

installed kernel..let it boot, let the cpu calm down a bit, ran apk..turned off screen though on some of them the error came up even before turning off the screen...3 screenshots..reboot nxt kernel till end.

Only used Fpbug2.apk

So 001a,b,c - 004a,b,c for the last released kernel..

Hope it helps a bit, took great care to ensure pictures are in order.

sent from my gt-i9100
[General Omni Discussion] Lanchon:
thanks a lot! unfortunately you are still not telling me the only thing i wanted to know lol!! :) which is this

which kernel(s) failed with the screen on?

(someone said STD but that *must* be wrong)
[General Omni Discussion] notabenem:
AFAIK, one of the big differences between 2.3.x and 4.0.x was that Android 4 used OpenGL to compose the windows/layers. Gingerbread used plain 2d canvas. So one of the theories could also be, that this bug was there even in Gingerbread, but did not have chance to manifest itself, because the graphics were not used for regular work, only for games (and no Power Management kicked in while playing games).

But this is pure theory at this point.
[General Omni Discussion] cdrivex4:
Nope not wrong..have done the following..

With screen on ( as in thumbing around to prevent sleep)

001 aka STD

002 aka V0

003 aka V1

004 aka V0X

All exhibit the previous error...u don't actually have to wait as long as 3 mins.... u really want more screenshots..

sent from my gt-i9100
[General Omni Discussion] zeitferne:
Have you changed any settings like the default CPU scheduler? Or do you use any "power saving" apps, wakelock killer, or something like that?

At least with the default kernel I was not able to reproduce the issue while the screen was on.
[General Omni Discussion] cdrivex4:
Cpu scheduler ondemand, cfq, as per $aybe previous post bout graphic I have 16 bit transparency enabled.

Checking start up apps the only thing I have on is Cool Tools, greenify is installed but I turned that off as I seemed to have high battery usage.

Edit;

Didn't really think about it but there is clean master installed, but i don't have it autokill anything..prefer to choose what I kill..

Crap...plot thickens...I had greenify on it was set up to hibernate winamp and real racing 3 apps on screen off, so disabled greenify completely, rebooted an installed the STD kernel...low on juice at this point 20%...so I go back to bedroom plug in charger still waiting this time waiting longer....un plug the charger even though the screen is on...it displays the error the instant I un plug the cable.....repeating this by clearing app cache,force stop an run again within 6 seconds or so of removing the cable it errors...

Can someone else try this..its 0100hrs for me I think I'll turn in.

sent from my gt-i9100
[General Omni Discussion] toroid:
hi,

I have n7000 with cyanogen mod 11-20141205-NIGHTLY-n7000, original kernel from the nightly

I get the bug everytime before 30s after screen off, pc plugged in, even in airplane mode.
[General Omni Discussion] Entropy512:
Yeah. I know historically, hotplug has often interfered with the sysfs online/offline logic in a way that causes them to often not work as expected. System load is fundamentally higher when the screen is on - vsync interrupts, etc. Lots of processes go to sleep when the screen turns off.

Most specifically, if you actually offlined CPU0 when the screen was on, you would've seen the system crash/go bat**** insane. I'm 95%+ positive it's impossible for the 4210 to offline core 0 without going into a complete system suspend state. (more specifically, the only times I've ever seen core 0 turned off when core 1 was on due to bad hotplugging logic was guaranteed to cause an unusable system...)
[General Omni Discussion] notabenem:
Strange. When I go to Settings/Performance, I can see the clock freq of both CPUs. If I don't do anything on that screen, CPU1 often goes to "offline". While on that screen, if I execute the echo 0 > ... I see immediately CPU1 offline, but many times in a second it's back online, until it decides that it really does not have any work to do and goes offline.

Based on this observation I assumed that the echo command would turn off the CPU at least for a fragment of a second while Lanchon's test APK is running.

Evidence that my theory is correct. While running the bug detector (2 threads) I started an adb shell with the following script:

while :; do sleep 2; echo -n "FREQ1: "; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq; echo -n "FREQ2: "; cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq;done

The output was the following (note: during these lines the screen was still on):

FREQ1: 1200000
FREQ2: 1200000
FREQ1: 200000
FREQ2: tmp-mksh: cat: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: No such file or directory
FREQ1: 200000
FREQ2: tmp-mksh: cat: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: No such file or directory
FREQ1: 200000
FREQ2: tmp-mksh: cat: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: No such file or directory

I'd say hotplugging is happening even with the screen on. I am getting more and more confident, that the IRQ problems on offline CPU and such do not have much to do with our problem here (but it's good we have the commits to fix them).

Edit: I realized you're speaking about core0. The question is, on which CORE does the apk start.
[General Omni Discussion] ajislav:
I am one of the guys who reported corruption with screenon., fpbug2

Yes it was the STD kernel but it might have been due other reasons (see * below)

I tried to reproduce the issue, but unsuccessfully.

I can confirm the issue exists with screenoff on all 3 initially posted kernels: STD, V0, V1 with fpbug2

* what I think was the sequence which lead to my seeing the error with screenon:

install STD kernel

check for bug with fpbug1

uninistall fpbug1 and install fpbug2

test for bug with fpbug2

.... something something

test for bug again with fpbug2 -> bingo

in other words, I did not reboot...
[General Omni Discussion] Lanchon:
could someone please try to reproduce the bug on this CM11 kernel?

thank you!!
[General Omni Discussion] ajislav:
I could not reproduce at first, but then it happened. Confirmed. Will test with the latest kernel and report back.
[General Omni Discussion] ajislav:
MG8 kernel fpbug2 shortly after unplugging from charger
[General Omni Discussion] Lanchon:
thanks! no need to post those horrible numbers anymore, just knowing it fails is enough.

EDIT: actually, its useful to see that its the same kind of corruption. but it's enough with the first snapshot :)
[General Omni Discussion] Lanchon:
MG8 has these mainline commits merged:

https://github.com/torvalds/linux/commit/f8f2a8522a88aacd62a310ce49e8dac530d1b403

https://github.com/torvalds/linux/commit/19dad35fe0f10df8f0524f98037469e3a0dd1ec2

https://github.com/torvalds/linux/commit/ab10023e0088d5075354afc7cb9e72304757dddd

https://github.com/torvalds/linux/commit/746a9d1963f1c7a3cd22662065d7dcd3d93ee62e

https://github.com/torvalds/linux/commit/2498814fcb3068f19b82b1519b4038721f61af43

https://github.com/torvalds/linux/commit/ff9a184cfb6542bef98aff1789481284e122a4b3

https://github.com/torvalds/linux/commit/56cb248428ead13a6b423ed3f3cf9e4aa01244b1

https://github.com/torvalds/linux/commit/384b38b66947b06999b3e39a596d4f2fb94f77e4

issues that can cause VFP corruption and should probably be merged in the kernel anyway. unfortunately they are not the cause of the corruption at hand.
[General Omni Discussion] notabenem:
Lanchon, can you please change the apks so that at least one of the processes is forced to start on CPU1? I am trying to eliminate a simple context move between CPUs to be the cause of the corruption. The theory would be that for ajislav the processes start on CPU1 and get moved to CPU0 when he unplugs the charger.

I have tried to play with "busybox taskset -p 2 PID" but without much succcess. If CPU1 is offline, I can't set this mask. When it comes back online, all the processes have a CPU Mask of 3. At this pont it's possible to set mask "2", but I don't think it's effective. I've never seen CPU1 as the last processor this process ran on, based on the output of cat /proc/PID/stat.

In my case the corruption appears always "after a sleep of >10.000 us". Assuming this means the phone was in deep sleep during that time and got woken up by random alarm..
[General Omni Discussion] Lanchon:
you can shell to your phone and start the native executable manually, check the sources.
[General Omni Discussion] Lanchon:
could someone please try to reproduce the bug on this CM11 kernel?

FR has changes in MG8 plus workaround for possible context tracking issues

thank you!!
[General Omni Discussion] zeitferne:
So far, I could not reproduce the issue with this kernel, even after a restart. But I won't become euphoric before others confirm :)
[General Omni Discussion] notabenem:
I must be doing something wrong. Flashed the kernel, but I am stuck at the boot animations screen (rest of the system is still Omni, no data-wipe)
[General Omni Discussion] glhfggnore:
Damn that's a pity. When 4.4 came up I decided that I would sell all stability for ART. Nearly two months of pain with file operations and MP3 players. Off topic but somehow related to this bug in heart I destroyed my hd partition on my notebook. And nether Samsung nether Google won't compensate it to me!!!