[KERNEL][OREO-PIE][TREBLE] Schwifty Kernel [vR5] | AOSP | 12/12/18 |

Search This thread

Dodgexander

Senior Member
Mar 31, 2013
627
168
Hmm thanks for the log, do you happen to have Adreno idle on? It appears that may be causing the crash.

Also check the telegram group. I posted a new beta the other day ?
No problem. It's you who deserves the thanks.

Yes adreno idler is on, is it by default on? I use AKT profiles app with xhana profile right now which may be turning on but I revert to stock and its on too?

I try to get kmesg too btw but it seems to be depreciated now? Limited info to learn about it online by a noob like me but I couldn't work out how to grab it.

I have to say, I'm enjoying my battery life with this kernel. It wasn't long ago I was only getting 2h but now almost 4h with the right AKT profile.

Of course I know you probably think stop testing my kernel with 3rd party mod, if that's the cause I apologise.

I will join group on telegram. Thank you kindly
 

P650SE

Senior Member
Aug 14, 2013
670
187
I will look into that PWM thing for sure, looks interesting.

Did you ever manage to figure this out? I have an Axon 7 that I bought around this time last year, but it has been kept in a drawer since February after I found out that PWM from the display had been causing me daily headaches and eyestrain for months. :( Ever since this happened I have switched back to my old ZUK Z2 which does not cause me the same symptoms.

As someone else mentioned, I believe this was also an issue with the Galaxy S7 which uses the same display as the Axon 7. It would be good if a fix could be implemented within the kernel like it was for that phone. Then I could revert back to using the Axon 7 on a permanent basis.
 

SaintZ93

Senior Member
Did you ever manage to figure this out? I have an Axon 7 that I bought around this time last year, but it has been kept in a drawer since February after I found out that PWM from the display had been causing me daily headaches and eyestrain for months. :( Ever since this happened I have switched back to my old ZUK Z2 which does not cause me the same symptoms.

As someone else mentioned, I believe this was also an issue with the Galaxy S7 which uses the same display as the Axon 7. It would be good if a fix could be implemented within the kernel like it was for that phone. Then I could revert back to using the Axon 7 on a permanent basis.

I have looked into PWM and I am not going to incorporate it because it requires a whole lot of converting onto ZTE files.
 

anon1135

Senior Member
Jan 23, 2017
840
176
Some screenshots for those interested. Music apps used with Bluetooth. Next time with more wifi and lighter usage, it can definitely reach over 6hr+ sot!

Edit - looks like one of the pics didn't get uploaded for some reason and I didn't want to double post. The one showing sot is 2hr 50m
 

Attachments

  • Screenshot_Settings_20180820-154816.png
    Screenshot_Settings_20180820-154816.png
    208.8 KB · Views: 1,054
  • Screenshot_Settings_20180820-154801.jpg
    Screenshot_Settings_20180820-154801.jpg
    137.5 KB · Views: 1,012
  • Screenshot_Settings_20180820-154753.png
    Screenshot_Settings_20180820-154753.png
    248 KB · Views: 1,016
  • Screenshot_Settings_20180820-154744.png
    Screenshot_Settings_20180820-154744.png
    198.3 KB · Views: 1,030
Last edited:

yarecco

Senior Member
Dec 26, 2013
259
78
Warsaw
Aw this also happened to me. Not that often and no biggie though. Everything else perfect. It was during when the phone was off in my pocket
It is quite annoying whe you use SIM card PIN security... some operators don't allow to deactivate this and your phone being in the pocked gots that reboot and you can't receive callls not knowing it happened.
 

anon1135

Senior Member
Jan 23, 2017
840
176
A general question that maybe doesn't belong here but what are the advantages using this (or any custom kernel) compared to the stock ones is there?

Lots of posts in different threads describe better performance and battery using custom kernels but generally I see no difference whatsoever when I try them.

I even use AKT or LXT with heavily orientated power save profiles and see no gains, only loss in performance.

Do other people never use their phones as phones? I'm usually in a Skype call, sometimes video. Sometimes YouTube and the only time I ever see over 3h sot is when I'm just browsing and not actually using my phone very much.

It just seems confusing to me, I cannot understand how people have such long screen on time. I've seen reports of 8h even :eek:

Mind you, it was the same with every phone I've had.

I think the ones who have reported 8h are not giving u other full details as in things like light usage only, mostly wifi and a new battery. I should also be able to reach close to it if I keep this same usage or similar from the first 50% and let it drain almost to 0% but I never charge it that low. And with 25% brightness not much else turned off besides location and sync.
I read a few pages back about saintz saying to disable adreno idler to avoid the random reboots but I also read about that adreno idler afterwards and it sounds like it helps with battery. Not sure if should leave it on or off needs testing!
 

Attachments

  • Screenshot_Settings_20180822-143345.png
    Screenshot_Settings_20180822-143345.png
    192.1 KB · Views: 336
  • Screenshot_Settings_20180822-143351.png
    Screenshot_Settings_20180822-143351.png
    253 KB · Views: 324
Last edited:
  • Like
Reactions: Dodgexander

Top Liked Posts

  • There are no posts matching your filters.
  • 39
    The Schwifty Kernel (Yeahhh, Get Schwifty)

    Hello guys welcome to the Schwifty Kernel! If you watch the show "Rick and Morty" you will understand why I named it this ;) if you don't understand well either youtube it or just don't worry and enjoy the sh*t out the kernel anyways hehe. Alright lets get Schwifty, here's all the info about the kernel in a way that will help you decide how you want to set up your phone! The second post will contain changelogs and third post, well not sure yet. But enjoy!!

    Basic Specifications/Information:
    • Based On Axon 7 LoS 16.1 Kernel Source
    • Updated to the latest linux kernel source (3.18.126)
    • Built with Custom CrossTool-NG Toolchain (GCC: 8.2.0)
    • Allow 5-10 to settle in after booting up for better usage
    • Take the time to read all the information to get an understanding on the kernel (Will help with less bug reports)
    • If you report a bug please search before posting and give all information about your issue (Such as rom, kernel version, kernel setup... ect)
    • I will edit the page with dates when there is something new added such as govenors, schedulers ect...

    I/O Scheduler Information - I/O:
    • NOOP - Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
    • DEADLINE - The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number. Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.
    • BFQ - Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
    • ZEN & ZEN v2 - Based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones.
    • MAPLE(8/30) - is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.

    Governor Information - CPU:
    • Interactive - Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency. Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above. Interactive is the default governor of choice for today's smartphone and tablet manufacturers.
    • Ondemand - Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.
    • Performance - Sets the frequency at the maximum available frequency. This governor always returns UINT_MAX as frequency so that the DEVFREQ framework returns the highest frequency available at any time.
    • Powersave - Sets the frequency at the minimum available frequency. This governor always returns 0 as frequency so that the DEVFREQ framework returns the lowest frequency available at any time.
    • Userspace - Sets the frequency at the user specified one. This governor returns the user configured frequency if there has been an input to /sys/devices/.../power/devfreq_set_freq. Otherwise, the governor does not change the frequnecy given at the initialization.

    GPU Governors:
    • Adreno Idler - It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.
    • Simple - An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.
      simple_ondemand[/b] - As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.
    • msm-adreno-tz - The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.
    • Performance - As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.
    • Powersave - Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.
    • Userspace - This governor basically allows the user is able to set a desired frequency for the GPU to run at.
    • cpubw_hwmon - A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.
    • MSM Cpufreq - The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.

    Other Information:
    • Moved Core Control To Kernel - Moved core control from out-of-tree module into the kernel proper. Core control monitors load on CPUs and controls how many CPUs are available for the system to use at any point in time. This can help save power. Core control can be configured through sysfs interface.
    • Moved Core Control Trace Events To Scheduler
    • Added A Knob To Disable The core_ctl (Core Control) - The CPU hotplug tests does not work with core_ctl compiled statically into kernel. Provide an interface to disable the hotplug by core_ctl.
    • Updated the performance is cpufreq
    • Lots of UPSTREAM changes to cpuidle and schedulers
    • Some under and overclocks with how the phone idles and returns
    • Added a State Notifyier
    • Added CAD Project
    • Imported Boeffla Wakelock Blocker v1.1.0
    • Updated Kcal Support
    • Fixed Various Issues
    • Low Persistence Fixed For DayDream
    • Selinux Switcher Between Permissive & Enforcing (Please install the Magisk SELinux Manager)
    • And a whole lot of other sh*t, view the github to see all the changes

    Credit:
    Tester:
    Disclaimer: I do not and will not take any responsibility towards anything that happens to your phone after flashing.

    If you would like to donate a beer or a blunt feel free, its not obligated though! Each donation is appreciate by being added to OP!

    XDA:DevDB Information
    [KERNEL][OREO][AOSP] Schwifty Kernel | Custom | 6/8/17 |, Kernel for the ZTE Axon 7

    Contributors
    SaintZ93
    Source Code: https://github.com/SaintZ13/schwifty_oreo_axon7

    Kernel Special Features:

    Version Information
    Status: Stable
    Current Stable Version: v1
    Stable Release Date: 2018-06-24

    Created 2018-06-25
    Last Updated 2018-06-24
    30
    Okay guys its finally official! After a few months of rebasing and lots of kernel bugs and other problems, Schwifty vR5 is here! Check the massive changelog in the download section, enjoy :)
    • This kernel now has an option to choose between Permissive and Enforcing Selinux. Please install the "Magisk SELinux Manager" Magisk app through recovery only.
    • Kernel is updated to 3.18.126
    • CAD (AK4490) Sound is back
    • Lots of new Ramdisk and kernel features thanks to @Skrem339
    • This kernel is now only 100% treble only as the new sources are based on treble
    • Low Persistence is fixed for DayDream! Thanks @_phk_

    EDIT: Pulled the download forgot something in the kernel, sorry guys.
    RE-EDIT: Re-uploaded, I forgot to add the Low Persistence fix for DayDream!
    28
    Please note: I will begin work on vR6 soon, you can check for beta updates in the telegram group. (There are none at the time of this post) As it stands vR6 will be the final build for Schwifty Axon 7 as I have moved onto a new device and I'm beginning development there. Just would like to say thank you to everyone whose supported the kernel and any of my other work. You are all appreciated ??
    23
    New build is finally coming soon after about 3 rebases and a whole lot of work. I am currently about to push the latest beta to the group. After that there will be a public release of v5! Thank you for the patience :)
    20
    Install Instructions:
    • Boot To Recovery
    • Flash Schwifty Kernel
    • Wipe Dalvik & Cache
    • Re-flash Magisk

    Downloads:
    Stable Release: vR5 Changelog (12/12/18)
    Download:
    MD5: ef8222968aaea32fed85245d53599c56
    Kernel Size: 13.6MB

    Stable Release: vR4 (Treble & Non-Treble)
    Changelog (8/30/18)
    Download:
    MD5: Treble - 55fb1a7e7dade9f560725f5bc135e4d7
    Non-Treble - 69d034f21ba8b39330633c1b96bf8c97
    Kernel Size: 13MB


    Stable Release: vR3 (Treble & Non-Treble)
    Changelog (7/30/18)
    Download:
    Treble said:
    Non-Treble said:
    MD5: Treble - f30ef3e8220146331f657195d46bc8b8
    Non-Treble - dc055bcc684df594820e741c3e912be2
    Kernel Size: 10.6MB


    Stable Release: vR2

    Schwifty Kernel: Initial Release (6/24/18):

    Download:
    MD5: c30d7ed7c4e7b2843f3ae83e9e75509b
    ROM Size: 10.9MB