yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] richardcto:
Yes the power buttons do get weak over time. If DTW is working there is already a way to wake the phone with that and the fingerprint scanner. But the only way to sleep the phone is with the power button. So I think if you could manage to keep Sweep to Sleep, that would be nice. But then get rid of Sweep to wake, as we already have two other ways to unlock the phone. But I don't know how integrating these options work and if that is a option, or if that could possibly make it easier implementing battery/performance enhancements.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
well, I'm not going to worry about it for now... I have a theory as to what is happening, but I'm working on something else right now, that's more important - so I'll revisit wake gestures, after that...

I merged like a 160 commits into my dev branch lastnight and I'm testing the build. long standing stuff that I've worked on before, but with some new info and a fresh start/perspective: I think I have actually sorted out all of the mainline locking, sched and hot plugging code in my kernel (catching up with Linux 4.4).... seems very stable. fast. no FCs or other oddness.

so after I get this finished, I'll have another look at the wake gesture stuff... but I've Bern itching to get this code all merged, huge pain to do though / get right.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION]

Most likely I will have a build up later - but in the thread. as decribed above - I've been working on finally merging in some code that I've been working on for a month. It's a very large set of changes 170+ commits now, but there are some very noticeable improvements and I think I've finally gotten this code sorted out....which would be excellent.

anyhoo, more info on that later.

PS: It's a test build, won't replace the main download (yet). So basically, anyone who's interested in testing can do so and report back.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
TEST BUILD: https://github.com/nine7nine/Apps/raw/master/TEST-v2.1_4df0038.zip

Ok. So.... I 've posted a test build. Some things to keep in mind; it's a *test* build. The changes in this build are rather substantial and affect critical / core parts of the kernel (not just some hacks on drivers or that kind of thing)... It is possible that you may get a random reboot / live-locks or something like that (although, I have not)....

Background / Changes:

- I've pulled in a number of upstream sched / locking / cpu hotplug commits, leading upto to linux-4.4 (massive changes)

- I've undone some reverts/bad commits for code that should be in the kernel, that is needed to move forward (I'm still reviewing other changes, but I think I've gotten the meat of it)

- improvements to the cpu-boost driver (it should have slightly lower latency / response, among other changes)

- changes to cfg io scheduler

- other misc improvements

* This kernel should use noticably less CPU on idle, once settled. In some cases, performance is measurably better (but it's possible there may be regressions too, although I haven't noticed any yet)... give it a whirl, if you like ~ please, report back any issues ***but please do try to avoid being overly subjective .... observations are good, but if they don't contain some level of objectivity or have something I can use / test for myself ~ it won't be too helpful to me...

* I haven't disabled wake gestures or Kcal ~ nor have I addressed any issues that may exist.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
so not too much feedback here yet. but I bit in the XL forum. positive, so far and the test build is working quite well for me, as well...

hopefully tomorrow, once things have been running for 24hrs or so, I'll hear a bit more outta here. happy testing.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
From initial test,I find that the random read speed is improved significant,about 20% faster than last build under same condition.nice work!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
next build DT2W in Wake Gestures will work as expected.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
where/what did you use to test that? just curious
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So I may have some nice performance optimizations coming, in the next build. A few consecutive benchmarks in Geekbench pro showed a nice 2-300 point gain in multi-threaded performance. So that's promising.

The gist is that I've added in a handful of commits from mainline (linux-4.4) that changes locking/unlocking behaviour. The core code now supports acquire/release/relaxed versions of the atomic_inc family, and then the final commit implements the *_relaxed versions of the atomic_inc family for Arm64, which in turn pulls in all of the others. (relaxed use of barriers for locking/unlocking)

So I'll give this a good test. But I'm also working on other commits, trying to track down a few others => before I post another build ~ If the next (test) build turns out to be stable, I will update the OP download, after possibly getting a few other people to try it as a test build, first....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Well I have now given your test build a good try, it is working great battery use from browsing and no use is fantastic. My 3d games are using a little more power but I don't care everything is smooth.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
That could be (on the 3d games), but I do have some changes coming that may improve that too. The test build does reduce battery life a bit (but not overly so) and I think I'll overcome that, in subsequent releases...

Thanks, Siheals!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
androbench,I test it several times,last build always show about 80mb/s,and test build show about 100mb/s.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
ya, that's due to cfq changes in the test build.

I generally use geekbench pro, as it's an easy goto. i can compare to other devices + other pixel results online... the pro version lets you increase the worker thread count... I don't put a ton of faith into synthetic benchmarks, as they don't always mean a better user experience and it really depends on what's being bench'd...

I also test fps in YEBIS and a few other apps...then onto, beatonal and my runs of audio tests + the usual rounds of applications...

I'd like to get a more standard Linux set of utilities together to do tests with, but they tend to be annoying to cross compile for android. so I haven't done it yet.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
Ok, so i am on the lateat stable. And the story is that I was in a conference, and didn't touch my phone for 2 hours or so. Suddenly it auto rebooted, and strange thing is that it went into a bootloop. It rebooted like 8/9 times. I could see the lockscreen, and immediately it rebooted again.

So I pressed vol down and power and it went to fastboot. Waited for some time (to make it calm down a bit, lol), and then booted into system. It's been working since then

Should I get you a logcar or something? Please note that it's been 2 hours since that event happened. If you still think any log will have that events somewhere, please let me know.

I'm gonna try the latest beta tonight.

Thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
interesting. Never have I ever had anything like that happen. have u changed anything recently, that u can think of?. ...and are u using any non default settings? .... as it's not like u just started using my kernel and this would be a first time, anything like this has happened right?

....no it's a bit late to be able to catch what might have gone wrong with logcat...

EDIT: I'm off to bed. but I'm going to PM you tomorrow and get you to send me a full log file via email, if that's cool.... maybe I will see something strange or that pops out...

does that work for you? lemme know

ya, try the test build. as it does have some fixes in there stuff that should be in the stable build... I haven't had any random reboots or crashes or anything like that with it... and that's after 3 days of use...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
Nope...i alwaya use default. Kinda noob in kernel tweaking, ?. Haven't changed anything recently either. And I'm not new to your kernel. This thing happened for the first time.

Which log should I get you if this happens again before I reach home from office?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
cool. didn't think u were. best to avoid getting crazy tweaking stuff anyway.

well, first. try the test build. if it happens again;

I'm going to get you to send me a zip using the 'bug report' option in developer settings... then u can fire it off to me via email...

I'll probably get u to send some other stuff too, possibly... but bedtime. ttyl... try the test build out. yada yada. ?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] bladels:
Wow, latest test kernel really improve performance, haven't tested battery life yet. Thank you nine7nine for your great work.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
cool.... thanks for the positive feedback.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
NEW TEST BUILD: https://github.com/nine7nine/Apps/raw/master/TEST-v2.1_460df33.zip

Changes;

- dt2w should work ok now.

- atomic_inc family supported in core code && arm64

- a few bug fixes to optimistic spin queue code

- restoration of a patch that should've never been reverted during EAS integration.

- increase of RT priority for mdss and kgsl

- minor change to futex code

a couple of these patches *should've* been in the stable build, but are not (as I didn't uncover them until now). I'm still digging through previously reverted commits, so each new (or three) build may contain fixups like this... Some of these reverts could be leading to subtle issues and corner cases where something goes sour, unpredictably so (*cough* [MENTION=4429310]Nil253259[/MENTION]).... (in previous builds for 8.1)

So, if you want to test this, please do .... if you have encountered any issue on the Stable or previous test build - please use this and see if the problem persists....

make sure to report back. thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
NEW TEST BUILD: https://github.com/nine7nine/Apps/raw/master/TEST-v2.1_62f9440.zip

Ya, I know - crazy short window before posting a new test build, Am i right? ;)

A few reasons;

#1 A handful+ commits that I worked on yesterday fix a long-standing live-lock / crash that I could easily trigger/produce when applying a particular patch (that I've been waiting to include for a while, EAS code) - but this required getting all of the scheduler / locking code upgraded && fixing some related code paths, first.

I've resolved this now (as well as a couple of potential other splats / bugs), It seems to be quite stable.

#2 I've pulled in last remaining EAS commits present in aosp/kernel_common/android-4.9-eas-dev ... that weren't present in my kernel. AOSP only committed them on Dec 1st, but the 3 troublesome patches (for me) had been floating around for a while. I had tried to integrate them previously, but failed... But now having recently reworked my kernel significantly; addressing the related issues ~ it seems to be fine now, working very well on my phone.

#3 Lastly, I also restored a couple of commits, that shouldn't have been reverted (much like others that I've been reviewing and fixing). One of these not being there could have definitely caused a splat / random reboot, being as it fixes a race condition in the cpufreq driver....

anyway, pretty valid reason to push a new one. critical bug fixes and EAS integration.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
so a couple of things;

#1. I've restored the smpboot code to Marlin -mr1 vanilla kernel sources (some upstream/mainline commits had made some modifications). I'm hoping that this solves any of the sporadic boot hangs or resets (on boot) that people may have mentioned or experienced randomly. ~ I did this because I bumped into a couple of them today, on my newer builds and became motivated to try and address it... I haven't had a boot hang or reset since and i've cold booted, flashed multiple builds, reboots, etc... So hopefully that is the end of that... who knows though; I've never been able to reproduce it reliably. time will tell, with the new commit...

#2 - I've merged in more locking code; a few bits were missed, while others I needed to enable a compile time locking feature. (I think this is what caused me to see the boot hangs / reboots today.)

#3 - If you've experienced any hangs or anything else "not-so-good" on either of the last test builds ~ as mentioned above I did revert some problematic code (3 EAS commits) and I also have a v2.3 test build on my github. You can flash that one, if you like ~ It's the build that I've been using all day/evening (minus a handful of commits that I'm testing).

https://github.com/nine7nine/Apps/raw/master/TEST-v2.3_97d7ede.zip

#4 - I've been looking into the whole "contact your manufacturer warning" - as It's getting old, really quick. lol .... It used to be that you could modify the vendor build.prop (commenting out just 3 lines) and it would stop issuing that warning... however, that doesn't seem to work anymore... sigh....

Next I did a bit of googling to see what I could turn up. I was already vaguely aware that the init binary also does verity checks, but I didn't know much about the specifics. I came across this; https://gist.githubusercontent.com/...ab04ecd21c3e0176ee12f46579554c0653cf/foo.diff ... You can see invisiblek is bypassing safetynet checks in the init... So, it's very possible that the check giving us the warning is done in there, but idk ~ and we have a binary init anyway.

I also looked to see if there was possibly a new kernel cmdline that was the cause (that could be removed, just like how the safetynet is handled in the kernel). Sultanxda has a newer patch that allows removing multiple flags, but I have committed that patch (today) - it doesn't make a difference + I don't see anything that "pops out" like it too should be handled...

so no dice on fixing that yet. :( fun stuff.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] グリッチ:
I had TEST v2.1 downloaded (but not installed) cuz it was late and I went to sleep, but by the time I woke up a new version had already come out, and I got busy, and now another two versions released haha, man you're on fire!

Good thing I didn't flash them all (I like testing but I still don't like doing daily flashing, maybe at least once a week), so anyways, it has been a while since my last flash and decided to flash today's latest test (v2.3).

I read somewhere I think in the Marlin thread, someone had some issue with substratum, can't tell if it was that or magisk related, but I had boot loops and "no command" error at some point... very weird because I never installed anything new and did everything the same as I always did. Of course, not saying it was your kernel that caused it, just wanted to throw it out there in case someone else may experience it.

I fixed it by flashing (without -w) the system image, and flashing the regular way (kernel > magisk > reboot), so now I am about one hour in using the latest kernel. So far no crashes, everything else seems normal. Performance wonderful as always.

I'm still very excited to see how things will turn out when you shift your focus more onto battery saving than performance and security (I understand there are a lot of things in the way before you can get to this so there is no rush, I have a few tweaks and use the noop scheduler and input boost disabled to help for now)

Thanks as always! I will post again after a day or two.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
lol. not on fire; I go through a lot of builds, just most don't hit the thread... right now due to the large changset(240 commits) and ironing out stability/regressions; I'm pushing builds quicker... the latest build would be the one to use, and I won't push another build for a day or two anyway..

well, ironing out any stability on 8.1 is my concern right now. I don't really need to focus on hardening or security. I already keep up with LTS and have many hardening features...

battery is always tricky. 8.1 caused me to have to switch things up, but my first build was like 4hrs of SOT vs. now getting more like 6hrs... but just an FYI; while it may be possible to get more SOT (and I do have to improve it a bit, as the test builds drain a bit more) - getting another 2hrs ain't going to happen... not without making significant sacrifices to performance and usability, interactivity, etc... - which I won't do... nor will I switch to noop or be disabling input boosting by default.

there are for sure limitations imposed by hardware, battery size, the OS and the device itself... I think if we can get upto 7hrs of SOT (without making any performance sacrifices) - that might be the limit and nothing to scoff at.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
NOTE: The latest TWRP supports decryption on 8.1 now.

Installing my kernel and magisk works fine with it too. ~ tested.

I've updated the twrp link in the OP, as well.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Well all is running great, games and memory access improved, no problems at all.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
cool. I was kind of curious how things were going for you. If you remember; last time I tried to do the big merge (that I just did again), you had some issues with loading times on some of the games ~ I paid attention to that this time around and didn't notice any delays vs. the kernel before the merge or stock....

So if everything is running great ~ well, that's great! ;)

thanks. In a few days, I'm going to have a stab at improving battery life, a bit... No time over the weekend. busy busy... A few days of the same running kernel will give my device / accubattery to get some better averages anyway...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
UPDATE: Stable build => https://github.com/nine7nine/Apps/raw/master/exNoShadez-eas_1ac9db8.zip

Also available on the OP download

- 3.18.88 lts

- a bunch of misc changes

- some fixups/changes to scheduling code.

it's largely based on the last test build, but I also touched a lot of scheduling code to workaround some issues && improve a few things. I didn't bother with making them into nicely formatted commits. for a couple of reasons;

1. I'm in the middle of getting a clean repo / rebase together.

2. I'm trying to best figure out how to manage / deal with my non-public/unavailable features, that doesn't create a lot of extra effort for me. ~ which is taking a lot of extra time and planning.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
UPDATE: Stable build: https://github.com/nine7nine/Apps/raw/master/exNoShadez-eas_62eb178.zip

you most likely won't necessarily need to update to this one, if already running the new stable build, although there are some differences... Most of the changes come down to re-organizing scheduler code and related headers... functionally, the changes shouldn't be noticeable, although they do exist...

Side note / fun fact; I'm toying around with the idea of porting marlin to android/linux-4.4 ~ I currently have a 4.4 kernel for marlin that boots - it has other problems, instabilities (as expected), but hey; that's not surprising.... it required some ugly hacks and a bit of forward-porting to get it booting, but interesting that it was doable at all.... I haven't decided whether or not this is something that I actually want to pursue, release or support; it would be a lot of work and added stress in my life.... Something that probably isn't worth doing, unless it was a legit paid gig... ~ It's kind of a similar situation to a couple of valuable && unique features (not from mainline or available in any android kernel) that I use, but won't be adding to my public builds, either; I'm not spending months implementing stuff; only to have kangers and vendors pick them up for free. that would be silly/dumb...

but I digress - anyway, I'm house-sitting over the holidays and xmas is busy - So, I may not push another build for a bit, unless I need to.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
All I can say is thanks very much for your hard work and I hope you have a great Christmas and New year.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
thanks, siheals! I hope u have an excellent Christmas too...

my holidays should be good. I imagine that all of my nieces, nephews and friend's kids are going to make me broke though. lmfao...

should be a good time though.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
my last cycle on the latest stable build...I would say not too bad.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] discolemonade:
Installed your kernel for the first time yesterday, on 8.1 Sailfish, too early to tell about battery but it looks promising so far.

I did notice one minor glitch, the "smart lock" page (Settings -> Security and Location -> Smart Lock) appears to be blank, which prevents setting up trusted voice / trusted face (trusted voice can still be setup through the Google App, but I think this is preventing trusted voice from using "Hey Google" in addition to "Okay Google"). Not a huge issue at all and I'm still going to stick with your kernel for now, just wanted to make sure you're aware.

Thanks so much for making this kernel and happy holidays!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nick80835:
This isn't a bug related to the kernel, it's an issue with Android and should be reported to Google but I think they should know by now as many users face this issue.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
+1
[Google Pixel ROMs, Kernels, Recoveries, & Other De] discolemonade:
Ah, my mistake. At any rate, I reflashed the stock kernel and then flashed exNoShadez again, and now the issue appears to be resolved.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nick80835:
I think rebooting resolves it for most people. :silly:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
seems to be a known issue,on 8.1

https://xdaforums.com/pixel-xl/help/smart-lock-broken-8-1-t3715631

I don't use those features, so have never investigated. seems like people get it tovwork though. odd
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
just have a random reboot,here is last_kmsg,hope it help.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
just curious. when did this happen? maybe, more context;

on boot?

where u using the phone?

was the phone sleeping?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
I was just using stock browsering app and then out of sudden it reboot,look like soft reboot.and not long after it boot back to system,it reboot again.so I power it off and power back on,and now it's normal again.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
so by stock browsing app, you mean Google chrome.

k. I'm not at home, so can't really do anything immediately, or push a kernel for u to test or anything...

I'll have a look, ASAP and try to resolve this.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
no hurry,take your time,maybe it was nothing.just a single random reboot.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] buddyb0i:
got a pixel and would like to use kernel and running 8.1.0 on Project Fi was wondering if I could get assistance on what steps to take to successfully root this device if someone has the time, thank you and appreciate it!!!!!!!