yashsingh1/xdaforums huggingface dataset:
[Nexus 7 Original Development] Ziyan:
Alright people, let's test :) in the attached archive, there are two files which implement a workaround for the FC problem. We failed to reproduce any FC with these.

Installation:

adb root
adb remount
adb push libnvossh.so /system/lib
adb push libnvos.so /vendor/lib
adb reboot
[Nexus 7 Original Development] AndDiSa:
For those who do not want to mess with adb, I've created a flashable zip (see attachment) which can be flashed by recovery.

As [MENTION=2633638]Ziyan[/MENTION] already wrote, we were not able to reproduce the crashes, so if anybody is detecting a crash, please get a logcat from your device.
[Nexus 7 Original Development] thierry+:
Hi all,....just a thought, it seems to me that there is a need for a tablet with a google stock ROM that you can test apps along side the ROM's used in this thread. I don't believe all the time that when an app FC's it is the fault of the ROM. If you think back to apps in the past on playstore a great many of them were updated by their developers to fix issues like this when google updated the ROM. I can tell you that I have tried a variety of USB and bluetooth utilities apps on AndDiSa's ROMs and not all work well and have fc issues. We ought to be able to say what app hads issues, check the reviews in play store and confirm whether it works in a stock ROM.
[Nexus 7 Original Development] chosin137:
It's about 50 / 50. I feel a lot of it is from dirty flashing a new build over the old ones. You will see issues where certain Google apps will crash and just need to be unninstalled and reinstalled and or need to have permissions reenabled again. With ParrotMod running I got a lot less FC's which is nice, but still seeing it randomly in apps occasionally. I haven't really seen anything worth dirty flashing over an older build from Feb 21st because then I have to go through and troubleshoot specific apps again. So theoretically it could be fixed since then but I doubt it. My assumption is apps are just running out of usable memory and crashing, but I'm not to technical so there is that. Overall I'm amazed so far with what the guys have done and kind of look at this as just a hobby. Still wondering if we can update the TWRP to the latest or if that will cause issues with the 3.4 kernel though.

---------- Post added at 09:35 PM ---------- Previous post was at 09:29 PM ----------

I think I'm just waiting for this to be merged before I flash a newer build "common: [WIP] Switch to hardware/nvidia/tegra3". I assume this is a big change but who knows :P .
[Nexus 7 Original Development] abhifx:
this is fantastic! time to revive my grouper.
[Nexus 7 Original Development] Ziyan:
If all variants are booting correctly with kernel 3.4 (I didn't get any non-booting reports since the last fix), we can do that :)

Since we support multiple Tegra 3 devices now, it seemed like a good idea to move out the power hal, etc from the grouper device tree to a common hardware tree :)
[Nexus 7 Original Development] gorneman:
Workaround seems to work. Spotify, Firefox and other apps haven't FC since I have flashed the libraries. Thanks [MENTION=2188693]AndDiSa[/MENTION] and [MENTION=2633638]Ziyan[/MENTION].
[Nexus 7 Original Development] Nanashi_anon:
This patch really reduced #of FCs on my device. Thanks!

However, after the patch, system hang-up a bit more than before and reduced the rendering speed? (it maybe just my case)

clean install

ROM: 20170325 build

opengapps: pico-20170304

filesystem: ext4
[Nexus 7 Original Development] AndDiSa:
[MENTION=3897304]Nanashi_anon[/MENTION] rendering speed may be affected, I had the same impression.
[Nexus 7 Original Development] AlessandroXCV:
Hi guys, I've flashed this ROM/Kernel for come back to life my Nexus 7. If I install only the ROM, all works well but if I install the Gapps, I've a lot of FCs specially of Google Play Service and Package installer. I've looked for a solution in this thread but nothing that I found works.

I think that it is a Gapps and memory problem. Maybe Gapps package is big for the system partition? I've a 16GB device and I'm using 03-27 build and Gapps.
[Nexus 7 Original Development] Ziyan:
Did you install the patch from the previous page? Got a logcat and dmesg after the crashes?
[Nexus 7 Original Development] AndDiSa:
[MENTION=4312695]AlessandroXCV[/MENTION] there might be also permission issues with gapps which cause FCs, especially if you install them later, e.g. after you booted already into the system. You yout try to go to the app management section of the settings and grant all permissions manually the google apps are requesting.
[Nexus 7 Original Development] namerke:
same experienced by me, also, none of the gapps packages seems to work for me either.

logs are being gathered, hopefully we can help to resolve this :) :good:
[Nexus 7 Original Development] chosin137:
I dirty flashed the latest build with Supersu 2.79, parrotmod, and the patch in that order. Loaded into Android after one go and was getting FC on the Google play services. Downloaded OpenGapps Pico Arm variant and flashed on the reboot through TWRP. Loads into the initial google play services just fine and reauthorizes everything. Seems like this is needed every time you flash a new build otherwise it will just FC google play services and from there a ton of other Google Apps including Keep, Play Books, Play Music, Play Store and such. Yes there is a slight lag to the rendering speed but nothing to be really concerned with considering the state of the Nexus 7 before Project 3.4 :).
[Nexus 7 Original Development] biondi53:
Wich recovery are using the non-booting variant users to test latest builds? I have a ER3 variant, and after flashed the OP recovery my recovery partition broke. I flashed stock recovery without issues, but after flash the latest TWRP recovery (twrp-3.1.0-0-grouper), my recovery not boot again. Any help is welcome.

Regards
[Nexus 7 Original Development] Ziyan:
Those are actually pretty outdated recoveries (I thought I removed them already). Either ways, next time, simply 'fastboot boot' them :) but yeah, simply flash twrp 3.0.2/3 instead of 3.1.0, which is buggy: https://github.com/TeamWin/Team-Win-Recovery-Project/issues/890
[Nexus 7 Original Development] biondi53:
Thx for quick response, same issue with 3.0.2 but succes with 3.0.0. Now... could I try the latest build with this recovery version? Remember that I have an ER3 variant, in the past I had to disarm my n7 and disconnect the battery after testing the kernel 3.4 .... I'm scared LOL
[Nexus 7 Original Development] Ziyan:
Assuming your /cache is on ext4, try fastboot booting (not flashing!) the recovery.img, and report back the results :)
[Nexus 7 Original Development] biondi53:
EDIT: sorry im trying again

EDIT 2: Black screen, google logo, boot TWRP 3.0.0
[Nexus 7 Original Development] Ziyan:
Alright, please contact me on Hangouts or something, so we can find out why it rebooted :)
[Nexus 7 Original Development] chosin137:
I can confirm random reboots, but only happens about once or twice a day. I keep it in a dock next to the computer screen so I notice when it randomly just reboots. This is basically with no use. I imagine all it does is update the apps every once in awhile.
[Nexus 7 Original Development] Nanashi_anon:
latest build works like a charm (w/o Gapps)!

GAPPS seems yet to be compatible with those 7.1.2 roms. It crashes during the setup.

http://xdaforums.com/android/software/Open-GApps-t3098071

This is just e reminder for those wondering why it keeps on crashing during setup wiz... (like me)
[Nexus 7 Original Development] jpearn:
Does this still need the fix mentioned in earlier posts libnvos-patch ?
[Nexus 7 Original Development] kevinkoh:
Hi Ziyan,

I have a non-booting variant too. However, i am currently unable to boot into bootloader, recovery or the OS. It simply shows the google logo followed by a black screen (with backlight). After which it would reboot and show the google logo again. I have tried to connect the n7 to the computer and spam "adb reboot bootloader" command, but to no avail. "fastboot reboot-bootloader" does no good either. May i trouble you to provide some assistance? I can post a video of it to better help illustrate, if required. Thank you in advance!
[Nexus 7 Original Development] AndDiSa:
[MENTION=2753705]kevinkoh[/MENTION] did you try to hold down the vol- button only while the device is within the bootloop? Normally this should work while adb / fastboot commands will not because the adbd is not yet started and the device is not in fastboot mode to accept fastboot commands.
[Nexus 7 Original Development] kevinkoh:
[MENTION=2188693]AndDiSa[/MENTION], yes i have tried that, but the bootloop persists, its does not show the bootloader screen.

I have also tried the following button combinations, which yields the same results

Vol-

Vol+

Power

Power & Vol-

However, when I the Power & Vol+, it shows a black screen without back light, somewhat seems like it is turned off. However i believe this is the APX mode, to which i can't interact with as i did not make a flatline backup.
[Nexus 7 Original Development] AndDiSa:
power / vol+ should boot into recovery not APX. APX is entered when you hold down both vol+ and vol- in parallel. Do you probably have the vol- button stuck?
[Nexus 7 Original Development] kevinkoh:
I removed the back cover to check if the buttons were stuck before putting it back in place. But to no avail. Now the device continues to boot loop and no longer seems to boot into apx.
[Nexus 7 Original Development] chosin137:
I saw this got merged "common: Switch to hardware/nvidia/tegra3", I was wondering what this actually meant in regards to Grouper.
[Nexus 7 Original Development] abhifx:
seems like a different branch altogether, doesn't look like it is mainlined yet.

also this simply means that all tegra 3 based devices can now share common codebase thus making easy to develop for multiple devices. nothing groundbreaking but contribution from more developers seems one plus point.
[Nexus 7 Original Development] Ziyan:
Today's build (0424) fixes yet another, although fairly rare boot problem :) if there's ANYONE who still can't get it to boot, please contact me on Hangouts, so we can look into it ASAP!
[Nexus 7 Original Development] igor1st:
With UA 6.0/7.1 builds my tilapia unit has ~2 times slower online charging speed. Offline charging works with full speed. Is it a known limitation/bug for 3.4 kernel in UA? Is it happens with all units?
[Nexus 7 Original Development] Ziyan:
I guess you use a wall charger, in which case, it probably got (wrongly) recognized as a USB charger, limiting the current to 500 mA. I only tested one wall charger, so yeah... Can you post a dmesg after attaching the charger?
[Nexus 7 Original Development] igor1st:
Yes, I use 2A wall chargers. But dmesg shows that it was correctly recognized:

10:47:43 - wall charger was connected

10:48:07 - usb port was connected
[Nexus 7 Original Development] adstraylight:
I've seen this question asked, but never categorically answered: Is it necessary to use the k3.4 recovery in order to install this ROM?

I tried to DL the recovery from the OP link to find that it has been removed, so can I just install the latest version of the ROM via the standard latest TWRP?
[Nexus 7 Original Development] Ziyan:
Alright, we will test with more chargers.

No, any TWRP (not too old) is fine :)
[Nexus 7 Original Development] abhifx:
looks like unlegacy team is gearing up for lineage os builds too, plus nvos libs shims are merged. good times :)
[Nexus 7 Original Development] csk1jw:
[MENTION=2633638]Ziyan[/MENTION] [MENTION=2188693]AndDiSa[/MENTION] Hi I am sharing my root cause for the FC problem. Please check http://xdaforums.com/showpost.php?p=72140393&postcount=737

There is no need to patch vendor blobs and make use of library shim layer. The setjmp/longjmp to recover from SIGSEGV is an expensive performance hit.
[Nexus 7 Original Development] Ziyan:
Interesting - we'll investigate this. Like we always said, patching the blobs were always a quick a dirty, but working temporary solution until the root cause is found :)
[Nexus 7 Original Development] igor1st:
OK.

I see another problem with tilapia - after some hours of uptime, radio dies in sleep. Toggle airplane mode doesn't help, you have to restart the tablet to get mobile data back. Dmesg and logcat show identical denies to rild.
[Nexus 7 Original Development] sheffzor:
[MENTION=5799877]csk1jw[/MENTION], I've talked with [MENTION=2633638]Ziyan[/MENTION] and we managed a way that is less invasive on the platform, instead of reverting/ifdefing that offending commit change, we can just remove GL_EXT_unpack_subimage from the supported extensions list in gles2 blobs.

After some googling we found a document @ Nvidia website that refers that extension and describes it in the following way:

GL_EXT_unpack_subimage - "Limited stride support for texture updates"

What we concluded is that this extension wasn't finished, but since it wasn't being used in anyway by android, Nvidia didn't complain about it and released the graphic driver binaries with it unfinished/limited.

We have searched for GL_EXT_unpack_subimage in other devices blobs just to confirm that it wasn't a standard and actually they don't feature it, so we got this solution:

https://gerrit.unlegacy-android.org/#/c/2084/

The main goal apart of just getting things work is to avoid touching in the platform side, so this seems to be a correct way of fixing the issue. :good::good::good:

About that, I've noticed that, I'll look into it when I've some time.
[Nexus 7 Original Development] csk1jw:
I don't think bluntly removing the GL extension is a good idea. The GL extension may be used somewhere (esp. special Tegra3 games) in the correct context. The pristine grouper GL blobs has been working for LP and MM with the availability of the GL extension, so in my opinion, it is best to fix the frameworks at the source level. Source level fixes are always easier to manage and track compared to binary patch. Here's what I did for the LG-P880 Nougat ROM:

- inline bool hasUnpackRowLength() const { return mVersionMajor >= 3 || mHasUnpackSubImage; }
+ inline bool hasUnpackRowLength() const { return mVersionMajor >= 3 /*|| mHasUnpackSubImage*/; }

Anyway, I shared and presented the root cause and my solution. Every devs has his/her own perspective and reasons for doing things differently.
[Nexus 7 Original Development] Ziyan:
Right, but if this extension was correctly implemented, it wouldn't cause a segmentation fault on driver level; apps that might try to use it would crash the driver as well. Because of this reason, it's better to remove this extension altogether, as we definitely don't want any potential crashes because of this incomplete/broken implementation - even if some Tegra 3 specific games can use it correctly (which I doubt).

Also, this extension isn't Tegra specific (otherwise, it would be GL_NV_something) - it's simply an optional OpenGL extension that might or might not be available. Anything that wants to use it should check if it's available (and use something else if it isn't), as it's not part of the GLES 2.0/3.0 specifications.

Sure, but this extension wasn't used at all by LP or MM; that's most probably the reason. :confused:
[Nexus 7 Original Development] csk1jw:
I am not an OpenGL expert, so I google'ed a bit on the GL_EXT_unpack_subimage extension and its typical use case. Basically, it gives OpenGL ES 2.0 SW access to GL_UNPACK_ROW_LENGTH, a property that simplifies sub-region texture update. This property is standard in OpenGL ES 3.0+. For OpenGL ES 2.0 missing this extension, there is a performance hit on sub-region texture update.

This article explains the performance hit well. Check out "A Wrinkle" section.

https://fgiesen.wordpress.com/2013/09/25/texture-uploads-on-android/

And also in Issue #1 of the extension spec.

https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_unpack_subimage.txt

The whitepaper on OpenGL ES implementaion for Tegra GPU found on NVIDIA website also documented limitation of this extension, ie. it does not support arbitrary width/stride. This can also imply that OpenGL ES SW/Games vendors who work closely with NVIDIA devtech would have known about this and would be able to use this extension in the correct context.

Sub-region texture update is a typical use case for OpenGL accelerated 2D GUI and video acceleration through OpenGL texture. The article I mentioned earlier comes from RAD Game Tools, and the Bink 2 video engine is typically used for cinematic playback in 3D accelerated games.

For all the pre-OpenGL ES 3.0 mobile GPUs, PowerVR 530/540, Mali400, Tegra2/3 and Adreno2xx, Tegra3 would have the most advanced Open GL ES 2.0 implementation. This could be the reason that this extension is only available on Tegra2/3 OpenGL ES implementation.
[Nexus 7 Original Development] Ziyan:
Let's just take a look at the pros and cons. It's your will to decide which route to go with; both is fine.

Pros of having it:

- OpenGL ES SW/Games vendors who work closely with NVIDIA devtech would have known about this and would be able to use this extension in the correct context

Cons of having it:

- Incomplete implementation with Tegra 3 specific limitations

- Android framework already tries to use it without considering the above -> driver crash (this is fixed with the framework change)

- Apps potentially trying to use it also without considering the above will crash as well

Generally saying, the use case of this extension (especially when properly used) is probably so rare (today's apps/games probably only use the standard GLES 2.0 extensions - no point for them in optimizing for 2.0/T30) that in the end, it probably doesn't matter which route you or we choose. Stopping the extension advertisement will avoid changing the framework, and it doesn't create any CTS failures, so we simply think that it is the cleaner solution in this case.

It also worth noting that removing the extension advertisement won't necessarily break the ability to actually use it: if, for example, you only check if the current device is Tegra 3 (skipping the advertisement check), and use the extension in that case (considering the limitations), it *might* work just fine. But then again, I'm not an OpenGL expert either.
[Nexus 7 Original Development] igor1st:
I measured the current with tester and got ~0.85A (with connected 2A charger). Maybe this information will help somehow.
[Nexus 7 Original Development] adstraylight:
Hi, just wanted to share a recent experience in the offchance that it might help somebody else.

I had a problem app with this ROM, (Duolingo), that would often freeze and crash when it was playing one of its internal animations (if you know the app, it's the one that says "you are correct"). The logs simply said that the window had crashed waiting for the animation to complete, I paraphrase, but this is what I took it to mean.

Having played with various use scenarios, I found that it wouldn't, or was less likely to crash when there was another app working in the background. This led me to the cpu settings, and eventually to the interactive governor parameters.

Again after much experimentation and googling, I got it to stop crashing by raising the value of min_sample_time to 50000.

As a consequence the whole ROM has become more responsive as well!?

Apologies for the long post..
[Nexus 7 Original Development] adstraylight:
I was wondering whether it would be possible for the devs to enable Zram in the kernel? Just as an option for those of us who can't help fiddling with stuff...?
[Nexus 7 Original Development] norman0:
Does the kernel also work with LineageOS 14.1? In the thread I have unfortunately found nothing about it. Chears.
[Nexus 7 Original Development] adstraylight:
The kernel and ROM are developed as a single entity, so the answer is no.
[Nexus 7 Original Development] adstraylight:
The exp build is running perfectly, many thanks. Even my problem app is entirely stable.
[Nexus 7 Original Development] adstraylight:
I'm currently running the exp build, and will stay that way until the experimental patches are merged.

I'm finding that with the min sample time increased to 50000, having CPU Quiet set to "runnable" makes for the smoothest most stable UX, if not the snappiest feel.

Something that does noticeably speed up load times for apps is an app on the playstore called SSD Boost which reduces the io overhead. I think the tradeoff being that the RAM is used up quicker, so hence my request for the option of using Zram to offset. I used this combination pretty successfully with AndiSa's ROM btw.

Anyway, just wanted to give some feedback, thanks for all your efforts to make legacy a thing of the past ?
[Nexus 7 Original Development] abhifx:
well the good news is that the patches have merged. :)
[Nexus 7 Original Development] adstraylight:
Yeah, I saw that - good news indeed!!:good:
[Nexus 7 Original Development] abhifx:
OTA is on the way too. I wonder if we will be able to keep up the pace for android O too.
[Nexus 7 Original Development] shockdesign:
Finally installed it all on my Nexus 7.. great to have it finally updated to something modern and seems faster than the last "official" Android release for it. Thanks Ziyan and everyone else working on this.
[Nexus 7 Original Development] kbal:
ROM is very smooth, but my tab seems to freeze a lot after waking it from sleep?
[Nexus 7 Original Development] sudokamikaze:
Someone can provide link to Recovery?

in op post download not available
[Nexus 7 Original Development] kk131:
I'm using the latest recovery from TWRP.ME
[Nexus 7 Original Development] sudokamikaze:
I've tryed already official recovery, and that works
[Nexus 7 Original Development] Geko45:
I've been trying to get the latest tilapia 6.0 build to install (20170606041853), but it just seems to hang forever and never actually start (don't even get to the "starting apps" phase, just the android animation endlessly). I did a factory reset and then wiped system on top of that just to make sure I had a completely clean slate (pardon the pun). I'm using TWRP 3.0.2 (official release) and I am only flashing the ROM and Open Gapps nano. System and cache are ext4 and data is f2fs.

Any thoughts? (edit to add: ua_tilapia-6.0.1-20170529073457 seems to install fine, so the problem was introduced in the June 6th build)

logcat seems to be looping through some sort of camera/mediaserver error:
[Nexus 7 Original Development] sheffzor:
Thanks, we will look into it, might be related to the recently merged patches for a Lenovo device that uses Nvidia t30 soc too.

Enviado do meu A0001 através de Tapatalk
[Nexus 7 Original Development] Geko45:
I can confirm this behavior on tilapia with the 6.0 rom as well.
[Nexus 7 Original Development] Geko45:
For those that use ParrotMod, I'm sure you are aware of the high IO latency of the grouper and talapia devices. The single biggest optimization that ParrotGeek provided was the use of RAM as an IO buffer in the form of establishing a zRAM disk in memory and then using that as swap space. The problem here is that this new 3.4 kernel does not offer zRAM support (but does have many other advantages).

However, while it doesn't offer zRAM support, it does offer traditional RAM disk support. So, as the next best thing to zRAM, I altered my ParrotMod su.d script to include the following in place of the zRAM block towards the end of the script. This code provides 128mb of RAM disk space dedicated to acting as swap and performs the same function (almost as well) as ParrotGeek's original script.

This is the original code that I replaced with the above. You'll notice that I make 16 8mb RAM disks as it seems that this is the maximum size that can be made. This provides a total of 128mb of swap (as opposed to ParrotGeek's 256mb below).
[Nexus 7 Original Development] AdriK:
Hmmmmmmm.........

This seems to be a bad things to do.

Why reserve 128 MB of memory for swap?

You're better of using the same 128 MB of memory for apps.

The only reason ZRAM might have a benefit is due to the compressed pages stored in ZRAM.

Normal swap will never compress the pages stored.