[Sprint Samsung Galaxy S6] tdhite:
Ok, so the log definitely has panics, and in fact here are the keys of the panic:

<4>[ 6129.686383] [3: kworker/u17:1:18022] [<ffffffc000206208>] do_mem_abort+0x3c/0x98
<4>[ 6129.686396] [3: kworker/u17:1:18022] Exception stack(0xffffffc0393ab760 to 0xffffffc0393ab880)
<4>[ 6129.686412] [3: kworker/u17:1:18022] b760: be119de8 ffffffc0 393a8000 ffffffc0 393ab920 ffffffc0 00a94bc8 ffffffc0
<4>[ 6129.686427] [3: kworker/u17:1:18022] b780: 60000045 00000000 2d124000 ffffffc0 00000000 00000000 00000097 00000000
<4>[ 6129.686442] [3: kworker/u17:1:18022] b7a0: 393ab7d0 ffffffc0 002063a0 ffffffc0 019efac0 ffffffc0 00002010 ffffff80
<4>[ 6129.686457] [3: kworker/u17:1:18022] b7c0: 393ab800 ffffffc0 0000200c ffffff80 393ab920 ffffffc0 0020c5e8 ffffffc0
<4>[ 6129.686472] [3: kworker/u17:1:18022] b7e0: be119de8 ffffffc0 393a8000 ffffffc0 393ab920 ffffffc0 0024b888 ffffffc0
<4>[ 6129.686487] [3: kworker/u17:1:18022] b800: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 6129.686503] [3: kworker/u17:1:18022] b820: 00000000 00000000 01d1b678 ffffffc0 014d1e30 ffffffc0 0000000b 00000000
<4>[ 6129.686518] [3: kworker/u17:1:18022] b840: 00000007 00000000 00000000 00000000 01010101 01010101 00000007 00000000
<4>[ 6129.686533] [3: kworker/u17:1:18022] b860: 00000038 00000000 00000000 00000000 fffffffc 0fffffff 00000000 00000000
<4>[ 6129.686547] [3: kworker/u17:1:18022] [<ffffffc00020c46c>] el1_da+0x18/0x6c
<4>[ 6129.686560] [3: kworker/u17:1:18022] [<ffffffc000a94ccc>] mutex_lock+0x2c/0x48
<4>[ 6129.686573] [3: kworker/u17:1:18022] [<ffffffc0007b11c0>] cpufreq_governor_dbs+0xc28/0xc8c

The call to mutex_lock is panic-ing, which means the data about the entire CPU structure has been trashed. That memory is available only to the governor or some external force (Xposed?) with root capability that is overwriting internal memory via bug of some sort. Very difficult to debug in any event. The code that allocates that memory is this:

https://github.com/TeamSPR/kernel/blob/skyhigh/drivers/cpufreq/cpufreq_ktoonservative.c#L138-L141

and the initialization of it is here:

https://github.com/TeamSPR/kernel/blob/skyhigh/drivers/cpufreq/cpufreq_ktoonservative.c#L2848

The only other references to that memory in the governor are here:

https://github.com/TeamSPR/kernel/blob/skyhigh/drivers/cpufreq/cpufreq_ktoonservative.c#L2719

https://github.com/TeamSPR/kernel/blob/skyhigh/drivers/cpufreq/cpufreq_ktoonservative.c#L2767

https://github.com/TeamSPR/kernel/blob/skyhigh/drivers/cpufreq/cpufreq_ktoonservative.c#L2789

https://github.com/TeamSPR/kernel/blob/skyhigh/drivers/cpufreq/cpufreq_ktoonservative.c#L2805

That is kernel code that has been stable for, ohhhhh, 20 years or so, lol.

All that said, I cannot, for the life of me, do anything to my phone to get that memory corrupted as you have it, so having trouble debugging. Worse, it appears that it is not just ktoonservative, rather according to [MENTION=5906430]crazynapkinman[/MENTION] also suggested as well the bahavior you see exists with the standard conservative governor, which presents us with evidence it's not the governor at all, rather something outside the governor code (could be Samsung code base has a bug, orrrrrrr ???, like I said, debugging up the stack on corrupt memory is difficult).

So I need a little help here -- need to understand the setup against which we are working. Beyond a stock Android system, for example custom ROM and other things like Xposed, what are you running? I am not going to, myself, load Xposed due to the severe security breach it represents, but whatever is there we can find out how to work around it if you can help debug the setup you have.

For now:

Can you send me a copy of your /proc/kmsg file after loading ktoonservative and letting it run a while with your current setup. Just issue a command like: "cat /proc/kmsg >/sdcard/kmsg.log" and send me the /sdcard/kmsg.log file.

I have no panics at all and am running Biggdaddy (ROM by [MENTION=1254481]amieldl143[/MENTION] with no Xposed or any other odd modifications, just for the record. Stock tests out perfectly as well.

:confused: