yashsingh1/xdaforums huggingface dataset:
[Nextbit Robin] jabashque:
[MENTION=5795145]javelinanddart[/MENTION] For the hell of it, I flashed the boot image that you said was causing your device to hard reboot. I grabbed the contents of pstore every time my phone crashed and hard rebooted.

This is on build 2018-02-20, and I was using MagiskSU to get root access for pstore_00 to pstore_05, and the original unmodified boot image for pstore_06 to pstore_09 after realizing that I'm dumb and that I can grant ADB root access without patching the boot image with Magisk. I've included pstore_00 to pstore_05 regardless, just in case they'd still be helpful in any way.

For pstore_{00,01,02,05,06}, I unplugged my ether from my computer, then waited for a short duration (maybe over 20 seconds) before trying to push my power button, which would result in absolutely nothing happening for about 5-ish seconds before the device hard reboots.

For pstore_03, I unplugged my ether from my computer, waited for a bit, then sent an email to myself so that I could trigger a Gmail push notification, causing my device to try and wake up and crash when it finally receives the notification.

For pstore_04, I unplugged my ether from my computer, waited for a bit, then sent a message via Pushbullet so that I could actually tell that my device was crashing when attempting to wake up, since the Pushbullet notification is more instantaneous than the Gmail push notification I tried earlier. A couple seconds after sending my message, my ether notification light stops blinking, and a second later, my device hard reboots.

For pstore_07, I unplugged my ether from my computer, waited a bit, then plugged it back in, with my phone hard rebooting only a few seconds later.

BUT, for pstore_{08,09}, I just had my phone off my computer and the screen off for only maybe 10 seconds at most, only for my phone to just hard reboot.

At least for pstore_00 to pstore_07, I've been able to make my phone crash by just trying to wake it up from sleep mode. Sadly, I don't really know how to read the dmesg logs to figure out what's happening. At least in pstore_05 to pstore_09, the last three lines before the call trace end up being:

lp5523x 9-0032: device detection err: -5

lp5523x 9-0032: lp5523 resume device fail

lp5523x 9-0032: **** DPM device timeout ****

but I don't know what to make of that.

EDIT: now with the actual files attached.
[Nextbit Robin] iluvatrix:
Hi just a quick question. I read that Lineage require encryption but when I go to my security settings I see Encrypt Phone but that option is greyed out further into the settings.

So can this ROM be encrypted?
[Nextbit Robin] jabashque:
Figure I might as well dump the kernel log from my phone, from when I couldn't get the screen to turn on at all. In some cases, plugging into my computer would wake my phone up, which would be why you can see some events from SMBCHG since I attempted to do that. But regardless, the screen never came on. I eventually just hard restarted my phone and grabbed the contents of /sys/fs/pstore/*, which is attached to this post.

EDIT: never realized that the forums just silently fails uploads if it's not in a format it likes. Fixed this post, along with the previous post with all the pstore_{00..09} that I had mentioned, because whoops.
[Nextbit Robin] javelinanddart:
I haven't had a whole lot of time to look at those logs, but lp5523x is our LED driver. If that's connected with I2C, this patch could be messing with it.

In other news, I have O booting. Pretty much nothing works except WiFi at this point.
[Nextbit Robin] iluvatrix:
Hi is there a way to have this ROM remain encrypted from stock?

Thanks
[Nextbit Robin] jabashque:
Regarding the I2C issues, I really wish I could help more besides just providing logs. But regardless, if you do push new kernel images to test, I'll still try them out and report back.

As for Oreo, I'm curious, what changes have you made so far to get Oreo booting?

EDIT: Never mind, I've been only looking at the LineageOS Gerrit. It didn't occur to me to check the actual git repos.
[Nextbit Robin] javelinanddart:
Experimental ether O build: http://downloads.codefi.re/jdcteam/...age-15.1-20180305_230742-UNOFFICIAL-ether.zip

What works:

- Boots

- WiFi

- NFC

- ???

What doesn't work:

- Video Recording

- WiFi Mac Address

- VoLTE

- ??

If anything else doesn't work, let me know, give me steps to reproduce, and a log. I don't know if RIL works, I haven't had a chance to put my SIM in.
[Nextbit Robin] Sparubens:
You are the man! Will report back
[Nextbit Robin] javelinanddart:
Thanks.

Forgot to mention: GApps and SU are included - no need to flash separately.

GPS also seems to be working fine
[Nextbit Robin] jabashque:
This is not an exhaustive list, as this is my main phone and I needed to switch back to my Nougat backup, but I might as well post anyway:

Works:
- GPS:
No GLONASS, but that's expected
- Mobile Data:
AT&T LTE, tested only very briefly to open ipmonkey.com in Jelly

Maybe:
- Bluetooth:
tested A2DP only, didn't have a HSP device.
Status bar battery indicator seems wonky though, compared to
the QS tile:
[IMG]https://i.imgur.com/5rlcAo9.png[/IMG]

Meh:
- Flashlight tile:
Takes about 2 seconds to turn on after tapping the tile.
Logs attached.
- Wake-on-plug lag:
same as Nougat, as expected

Doesn't work:
- Accelerometer, Compass:
Wasn't able to really generate logs that showed anything about these
devices. Tried using SatStat (which has accelerometer/compass sensor
reporting) and looked through the logcat, but couldn't really find anything.
- Dialer:
Make any outbound call in the dialer, and you will get "not responding"
errors in the beginning of the call. The dialer will then force quit, but
you can see a notification in the status bar for the call still. Dialer will
continue to repeatedly restart and crash in the background until you
manage to force stop it. Logs attached.
- Fingerprint:
Any time you push the power button to sleep or wake the device,
logcat gets a bunch of errors related to FingerprintService. Security
settings also does not show an option to add fingerprints.
Logs attached (for screen wake/sleep).
- Internal Speakers:
No sounds play on the device itself, e.g. button taps, volume adjusting
noises (which I enabled). Logs attached, which shows an attempt to
play an Opus media file from the file browser in the settings app.
Bluetooth is another story (see above).
[Nextbit Robin] javelinanddart:
Thanks.

http://downloads.codefi.re/jdcteam/...age-15.1-20180306_030404-UNOFFICIAL-ether.zip

Sound and fingerprint fixed.
[Nextbit Robin] Rimmer1966:
Not sure you're getting the credit you deserve for this. As an early build it's great. The dialer seems to have issues but once that's sorted it'll be close. Keep it up.
[Nextbit Robin] javelinanddart:
Dialer is actually working fine here, I just called my voicemail and it's working fine :/

However, I think I know why some people are having issues, it's an issue with my build environment.

Big issues left to fix:

- Sensors

Small things left to fix:

- Codec support, maybe

- WiFi MAC

- Minor reorganizations, Selinux, etc (things required for shipping, but _should_ mean nothing for you)

What else?

Video recording was fixed. I'm not happy about it, but it works, which is better than the alternative.

Working on fixing tethering with T-Mobile US right now. I hope I can fix that, I'll get a build out with that hopefully fixed soon.
[Nextbit Robin] Sparubens:
Great work for a first build. Vid recording works okay in Open Camera, but maybe at 10 fps most. Sound is ok but as distorted as in the 14.1 builds. Changing the icons from Squircle to another shape doesn't also make it system wide, the squircle icons are still in the apps menu in settings or in the recent apps overview. However, that's just nitpicking and I'm sure those things aren't priority right now. Great work!
[Nextbit Robin] DiePirate:
Any final Nougat build with all the know bugs fixed?
[Nextbit Robin] jabashque:
Out of curiosity, what is it that you don't like about having to open the camera as a HAL3 device in Snap?
[Nextbit Robin] javelinanddart:
That's not changeable on a system level, unfortunately. Squircle is what I like, so I override that for my builds. And yeah, our media stack seems completely broken right now, we're dropping frames all over the place in videro recording, and screen recording is broken :/

It doesn't support HDR and ZSL. Not deal breakers, but minor annoyances. What is a deal breaker is that our media stack is pretty broken. HAL1 seems to be broken for the same reason that screen recording is. And no one I've talked to knows what's up with it.

Soo, after more observation:

Things broken that should be fixed (in terms of functionality, not counting the other things that don't affect you as directly) before shipping:

- Media stack (specifically, the AVC encoder seems to be really busted, and HAL3 video recording is dropping frames everywhere)

- Sensors

- Encryption (could be broken, not entirely sure, haven't tested -- anyone willing to be a guinea pig?)

Less important things that should be resolved:

- WiFi Mac

- T-Mobile Tethering

- Codec support is a bit lacking (not sure to what extent that *can* be fixed, but worth looking into)

Things that may never be resolved:

- VoLTE

Feel free to keep adding onto the list. I don't have a ton of time nowadays, but I have spring break coming up in a few weeks, so hopefully I'll be able to grind a bit on this then.
[Nextbit Robin] iluvatrix:
Hi there can some kind soul help me understand how to get the 14.1 ROM encrypted?

Much thanks
[Nextbit Robin] javelinanddart:
Quick update: I fixed HAL1 recording, the AVC encoder, framerate drops, and probably other various related bugs (screen recording is a notable one). There's a few parts, one is the kernel side I already submitted (I erroneously picked a kernel patch from another device), and the other is a patch or two to the media hal. I'm going to narrow it down today to hopefully just 1 patch, and I'm pretty sure I know what it is. I'll also resync because my sources are a bit stale atm.

Next build should have Dialer properly fixed as well. Sorry for not releasing a build (explicitly anyways - they're all uploaded to the same folder if you can find it), I was hoping to fix T-Mo tethering before doing so, but I guess that's for another time.
[Nextbit Robin] javelinanddart:
http://downloads.codefi.re/jdcteam/...age-15.1-20180307_132753-UNOFFICIAL-ether.zip

Should have fixed Dialer, AVC encoder, and framerate dropping in video recording.
[Nextbit Robin] pattyboi:):
Badass. Thanks for the work you do. :good:
[Nextbit Robin] Sparubens:
Thank you so much! Dialer was already working perfectly when using Google Dialer from Play Store.
[Nextbit Robin] javelinanddart:
NP.

I generally use most of our stock apps, so it's important for me. That's also why it bothered me that HAL1 video recording didn't work, because though Snap is one of the few apps that use it, I actually use Snap.
[Nextbit Robin] rahul200023:
Thank you so much for this. I have been patiently been waiting for Oreo ever since the Omni and Carbon rom developers said it was hapenning. I honestly thought development was dead. So happy i was wrong, this is amazing for a first build. Keep up the great work!!!!!!!
[Nextbit Robin] javelinanddart:
Because I'm a tease.....https://imgur.com/a/t8CpH
[Nextbit Robin] /root:
hey [MENTION=5795145]javelinanddart[/MENTION] I am just curious why aren't you pushing this to the official build?
[Nextbit Robin] jabashque:
Probably because the current device tree + kernel doesn't satisfy all the requirements for the LineageOS charter.

For example, encryption hasn't been tested yet, and tethering is broken, at least on T-Mobile. All of the sensors also need to be working as well, for which javelinanddart seems to have made some progress. There's also other things that aren't as obvious to the end user, such as having SELinux be in enforcing mode, or having Spectre patched because the Snapdragon 808 has two Cortex-A57 cores, which is affected by Spectre.

EDIT: Unless you meant "why doesnt javelinanddart release builds with these new fixes". In that case, well, just grab any of the ether build links he posted earlier and take off the zip file name to see the entire directory. I'm assuming codefi.re is the build server javelinanddart is using, so any new builds he makes to test himself also show up in that directory. But as a result, there may be some builds that he doesn't want people to try just yet, so keep that in mind.
[Nextbit Robin] javelinanddart:
Just because all the bugs you care about are fixed doesn't mean that it meets our standards for nightlies. There's plenty of work to do still with reorganizations to match O's new layout, and SELinux policy writing, to name a few blockers. Besides...what does official builds mean except OTAs? At least for now, I'm updating every few days. Surely that's better than the weekly cycle? Plus, I also get to build with fun compiler optimizations in unofficials that won't get anywhere near official builds because the compiler is proprietary and that bothers our infrastructure guy.

TL;DR: Just because it looks to be all working fine doesn't mean it's done. It'll get there eventually.
[Nextbit Robin] javelinanddart:
Sensors are working as they were on N and are up to the requirements. Tethering on T-Mo isn't just limited to ether, but needs to be looked into all the same. Yeah, selinux enforcing, and yeah, not looking forward to patching the kernel with the meltdown/spectre stuff. As for the directory, 99% of what I test is on there, it's just not always full builds (e.g. etherperm2.img is a boot.img that has sensors fixed). The only time stuff may not go in there is if I know it's going to be slow for me to download based on previous history from that day (Qwest has some routing issues from time to time).

Quick update while I'm at it: I'm working on WiFi MAC, once that's fixed I'll explicitly link that build here. Hopefully tomorrow.
[Nextbit Robin] jabashque:
[IMG="embrace the guh-oodness of free software"]http://i.imgur.com/V5K7N1I.jpg[/IMG]
[Nextbit Robin] DiePirate:
Thank you for the hard work, i love u!
[Nextbit Robin] /root:
Ah okay. Makes sense now.

I always assumed nightlies are supposed to be partially working builds.
[Nextbit Robin] tongjia19:
Haven't been able to flash any of the Oreo builds I've tried.. doesn't boot up. Can't flash on top of 14.1? Have to flash back to stock first?

Also, all the 15.1 builds are gone from Codefire it seems.
[Nextbit Robin] javelinanddart:
Well, WiFi MAC works as it did in 14.1.

New build: http://downloads.codefi.re/jdcteam/...age-15.1-20180308_144850-UNOFFICIAL-ether.zip

Fixed: Sensors, Some WiFi driver errors with WiFi MAC

Left to fix: Encryption (confirmed broken), T-Mobile tethering
[Nextbit Robin] rahul200023:
new build works great, i dont know if this is a result of the new changes, but i can record in 60fps 1080p now as well as turn on the torch. I couldn't do that in yesterday's build. Also out of curiosity can the beta gapps be installed on this, and one last question can future updates be dirty flashed or is clean flash required?
[Nextbit Robin] javelinanddart:
No, they're not, there's 4 there. I moved a bunch of ones into the old folder.

http://downloads.codefi.re/jdcteam/javelinanddart/ether

And no, you can't flash over 14.1. You need to wipe and flash 15.1.
[Nextbit Robin] pattyboi:):
I can also vouch that the new build works awesomely. Haven't had a issue yet,battery seems pretty solid too
[Nextbit Robin] javelinanddart:
It probably is. GApps are preinstalled. Future updates can be dirty flashed as far as my builds go.
[Nextbit Robin] KUJO1001:
Does quick charge work?
[Nextbit Robin] pattyboi:):
Yes
[Nextbit Robin] AnierinB:
Oreo working like a charm so far :)
[Nextbit Robin] pattyboi:):
Does anyone else have MUCHHHH better Bluetooth audio performance on Oreo? I used to get mad stutters when using my phone + listening to music,haven't had any yet on Oreo.
[Nextbit Robin] JaN0h4ck:
Same for me. Switched over from Omni.
[Nextbit Robin] jabashque:
Anyone noticing that the big cores aren't coming up at all? This is on lineage-15.1-20180308_144850-UNOFFICIAL-ether.
[Nextbit Robin] javelinanddart:
https://photos.app.goo.gl/FCoc0o7n177OPscT2 Seems fine here. They are throttled more aggressively than before, though.

Another note:

Looks like I'm wrong about WiFi mac and crypto. WiFi MAC is wrong (and for some reason, my school network recognized this incorrect MAC without registering it), and Encryption works if you wipe your /data partition with fastboot -w when in fastboot mode.
[Nextbit Robin] akeemk:
Is MTP working for anyone?
[Nextbit Robin] javelinanddart:
Works in Linux.

http://downloads.codefi.re/jdcteam/...age-15.1-20180310_170949-UNOFFICIAL-ether.zip

WiFi mac fixed (for real this time. If you want to verify, compare the mac in settings to /proc/wifi_mac)

Encryption works

If it's still not encrypting, use the recovery linked below to format /data and try again.

http://downloads.codefi.re/jdcteam/javelinanddart/ether/ether-lineage-recovery-20180310_170949.img
[Nextbit Robin] rahul200023:
This may just be me being stupid but can you not move the system clock to center as you could in 14.1?
[Nextbit Robin] javelinanddart:
Not sure. I don't use that feature, and it's possible we missed forward porting it.
[Nextbit Robin] joshnolt777:
Awesome stuff man! Just installed the latest build and have been playing around with it getting it setup and everything for the last couple hours and everything seems to be working just fine havnt had any bugs yet. I will be out of town camping for the next couple days so will test it in real world conditions and report back after i get back to civilization. Thanks again for all your work! :o
[Nextbit Robin] jabashque:
Thanks for the new build.

I'm gonna go run Tinycore to monitor when my big cpus spin up, but I will say that I find it odd that both big cpus are kept off, while in 14.1, the default settings kept at least one big core on.

I also ran the LOS 14.1 su addon removal and installed Magisk instead, so I can't really submit any bug reports and logs at the moment. But I am going to keep note of all the bugs I run into, and once I have some time, I'll restore the original system image (for that build) to collect the logs. Maybe sometime next week.
[Nextbit Robin] javelinanddart:
NP, and thanks

I implemented more aggressive thermal tuning in O, so that could be it.

As for bugs, if you post a description and steps to reproduce, I'll attempt to reproduce them when I have a chance. Post logs whenever you have time, but it's not the most urgent thing.
[Nextbit Robin] jabashque:
Ah, I see. If that involves spinning down the big cores when the phone's over a certain temperature threshold, then that could probably explain why I don't see my big cores spinning up, since I usually check during heavy loads to see whether my phone is bringing up the big cores to get the job done faster.

Meanwhile, I guess I'll just mention that for Snap's video recording mode, the "High speed 60fps" option for High-framerate recording results in me getting a "Could not start media recorder. Can't start video recording." toast pop up every time I try hitting the record button. I recall this option was working in 14.1.

EDIT: this is on the 2018/03/10 17:09:49 build
[Nextbit Robin] javelinanddart:
Interesting. All the High speed options are broken, but their Slow motion counterparts are working. Successive attempts to video record are also occasionally buggy. Thanks for the tip.
[Nextbit Robin] rahul200023:
I too have noticed the two big cored remaining silent. I downloaded kernel auditor, and the big cores average up time at each frequency for a just a few seconds. Is there anyway to keep them always on?
[Nextbit Robin] j2bv16:
Looks like this build will meet the new LOS standard soon. Looking forward to install the official one
[Nextbit Robin] jabashque:
No problem, thanks for listening.

Also, now that I've actually left my phone on for a while, I found out what's happening regarding the big cores.. When my phone is idling or doing very little work, one of the big cores actually turns on (running at 633 MHz, as expected). But, as soon as I increase the CPU load (e.g. opening up Recents and scrolling around), my phone actually shuts off the big core.

If I open Kernel Aduitor and push up the minimum online big CPUs to 2, then I have both big cores online, but as soon as I increase the CPU load, both cores get shut off.

In both cases, once I let my phone idle for a few seconds, the big core(s) turn back on again.

I... don't think that was the behavior you intended, was it?
[Nextbit Robin] akeemk:
Lovely! It's working with the latest build now. Thank you!
[Nextbit Robin] javelinanddart:
Errr...I intended to unplug them after a certain temp (42 C for the 1st big core, 40 C for the other one). What temps are yours reading? It's probably just way too aggressive. I'm used to dealing with bad performance, so it didn't really bother me a whole lot. I do like keeping my phone cool though. I'm not opposed to playing with the thresholds a bit to get something more balanced.

I did manage to fix the high speed recording bug, and I picked a commit that should help fix some other weird recording bugs. I'm going to update the commits I'm picking into my builds, and rebuild tonight. I have a nasty habit of letting my sources get stale, so I'm trying to avoid that.
[Nextbit Robin] shunjou:
Do you plan on bringing any of these updates to TWRP? The latest build is still using a kernel with the garbage screen on wake bug.

Thanks.
[Nextbit Robin] jabashque:
Since I don't know which temp sensor corresponds with what in CPU-Z, I just recorded a video of me looking at my temps on CPU-Z: https://streamable.com/3nr9r. The bar on the top right indicates the frequencies of the two big cores. You can see me kinda moving the CPU-Z temp list around to try and turn off the one big core that's running.

Glad to hear that you fixed the high speed recording bug. Thanks!
[Nextbit Robin] javelinanddart:
The TWRP linked on the Lineage wiki shouldn't have any of these bugs, but I haven't tested it on Oreo.

Looking at that screen recording...our thermals are ridiculously aggressive for the temps we're seeing. I'll bump all of the thresholds at least 10C in a future build, and we'll see how it is then.

On a somewhat related note: A few weeks ago on Nougat (which has been propogated to Oreo) I removed input boosting for ether.

Did any of you notice a decrease in smoothness or fluidity as a result, and would you like it back? Did anyone notice an increase in battery life?
[Nextbit Robin] jabashque:
Ah, I see. Thanks; I'll let you know what I find when you push out a new build.

I can't really say anything because that time, I was completely ignoring your interactive governor tunings + input boosting values and using the Glassfish tunables instead, which was more conservative about ramping up the clock speed and decreases smoothness/fluidity even more compared to the stock settings before and after you disabled input boosting by default. I also turned down the minimum online big cores to 0 that time.

I stopped doing that recently. Once you release a new build with the bumped up thermal thresholds, I'll go play with manually turning on input boost and comparing the performance myself.
[Nextbit Robin] javelinanddart:
It's not as simple as a switch, there's hooks in the power hal as well that need to be re-turned on. I'll post two builds soon then, one with and one without input boosting. Both will have the upped thermal thresholds.
[Nextbit Robin] jabashque:
Ah, okay, thanks.

Hm... will probably try each of them for a week and report back what I find once you release them.

(On a side node, would that probably explain why I had to run `stop perfd` to disable the non-kernel input boosting back then? I'm pretty sure that ended up causing other problems that I might've not noticed. For that matter, what does perfd even do?)

EDIT: never mind, perfd is proprietary Qualcomm software and wouldn't be affected by any changes you make to the power hal.

EDIT2: or actually, would it? There's a lot I'll need to learn...