[ROM][JB] Team EOS 3 *JELLYBEAN* Nightlies - Stingray / MZ602 / US 4G ONLY

Team EOS XOOM​

JB 4.1.1 Stingray MZ602​

NIGHTLIES​

Continuing on from the success of the EOS ICS roms, we present to you EOS3, based on JELLYBEAN!

It is the goal of Team EOS to develop and maintain the highest performing and most stable AOSP based rom for an array of platforms. The launching point for this development effort is the Motorola XOOM.

For the latest news on Team EOS Xoom releases make sure you follow @teameos on twitter and on IRC on Freenode in #xoom.

--
NOTE: Team EOS, it’s members, friends, dogs, cats, and associates are in no way responsible for any loss of data or device functionality. Use this at your own risk!
--

A quick note on Nightlies: NIGHTLIES ARE DEVELOPMENT BUILDS. They are automatically generated every now and then, and represent the compilation of the latest commits to the code repository. While every effort is made ensure that the commits that are accepted are stable and do not have a negative impact to the overall performance and function of the builds it is not possible to test every aspect of a commits impact to the overall repo prior to it’s inclusion in a given build. As a result it is entirely possible that instabilities may be introduced as a result of a given days commits. That is the nature of the nightly system, and the risk that is taken using the latest code changes to the project.

EOS Xoom is an AOSP based rom. It is developed and maintained by Team EOS and is the culmination of our own in house development efforts.

Team EOS Xoom Nightly builds: http://goo-inside.me/devs/teameos/roms/eos3/nightlies/stingray/

G-Apps Package
Because this is an AOSP based rom Google Apps are not included in the base rom. To install Google Apps please flash the following package after installing the base rom:

Temporary Gapps package gapps
--
Features:
Because these are nightly builds the included features are constantly evolving, we do not provide a change log manually. Instead please see the changes on jenkins for your build.
For the most up to date and comprehensive listing of the changes included in this rom please visit http://review.teameos.org

Kernel:
Tiamat ICS Xoom kernel
Support for OC;Under/Overvolt
Governors: lagfree, interactive, conservative, ondemand, userspace, performance

Kernel Note: In compliance with GPL kernel source can be found at: https://github.com/solarnz/Tiamat-Xoom

--

Installation Notes:
These builds are designed to be installed from your favorite recovery (Solarnz R4c, Rogue, Clockwork)
Perform a full wipe (read Factory Reset) prior to installing this over ANY ICS based rom.

BUGS!
If you find strange or otherwise unexplained errors please report them here: https://bugs.teameos.org/ Please include logcats and as thorough a description of the issue and what lead up to the issue as possible. With out this we will be unable to track down these errors.

Changing the Stock Motorola Dual Core Boot Logo Splash Screen:
While not a necessary feature of the Team EOS ICS builds make sure you check out the Team EOS Motorola Xoom Boot splash utility in the Android Market:

EOS Motorola Xoom Boot Splash


Want to contribute to the Eos rom? Well you can!
Just follow http://teameos.org/?page_id=6 to checkout our source code, and information on how to submit changes for review.

Welcome to the XOOM evolved. Welcome to Team EOS.

electroman987 said:

... which I think I already know the answer, can I just wipe caches ...?

Click to expand...

Click to collapse

Nah, just leave your caches be.

Really. If the Framework thinks they need to be redone, they'll wipe and rebuild them on their own ("Android is updating apps"). It should only be necessary as a last resort (i.e., the machine instantly reboots upon first boot, or immediately returns to the Boot Animation, or apps immediately FC or don't come up at all).

Ditto wiping, unless you're coming from HC. I'm just trying to spare you guys from unnecessary wiping and (Now, that being said, for those who don't mind wiping I've got a filesystem change for /userdata that requires wiping, but will speed up access to the flash and reduce lag, sometimes greatly. Stay tuned, as I'll be announcing that in a day or so after I button it all up and make it ready for Prime Time).

---------- Post added at 07:02 PM ---------- Previous post was at 06:33 PM ----------

So, about the reboots: For the longest time (around October '11), the TeamEOS kernels for the Xoom have been overclocking the GPU from 300MHz to 400MHz; it worked great and we never really got anyone complaining about it. Right around the time we got JellyBean, however, we ended up in a "perfect storm" of video issues: (1) apparently JB uses the GPU far more than ICS, putting more strain on it at 400MHz, and (2) I'd added into the kernel an optimization that came from NVidia to remove a CPU<->GPU synchronization aid that was deemed unnecessary (and probably innocuous under ICS) with a standard-speed GPU.

So, some of you guys got spontaneous reboots (especially when watching YouTube, with certain animated wallpapers, and/or watching videos), and eventually, so did I. After tracking it back, first I'd turned down the GPU speed back to 300MHz, but that didn't fix it for everyone, so I reverted back the NVidia patch, and at the same time turned back the GPU speed to 400MHz- unfortunately, that fixed one possible reboot source but brought back another.

So, it's now obvious that we've got to be stock-clocked in the GPU for JB now, so we're going to revert back to that. I've known this for a couple of days, but haven't pushed the change until I'd not only tested it on my own Xoom (as I did continue to see reboots myself before my fix) and to verify that there were no other isuses (as I've upgraded the compiler for- and the way we build- the kernel).

Look for a permanent fix in the next day or so. In the meantime, for those I've asked to PM me if you're seeing reboots, I'll have a link up soon for a boot.img that you can "fastboot flash boot" on (unfortunately, no update.zip-able image).

BTW, if you're a Benchmark Whore (like me ) you'll notice ~20% or so decreased scores in graphics-based testing. I'm gonna miss my 29.8 NenaMark score, but I'd miss stability while watching YouTube even more!

I thank you guys for sticking with TeamEOS throughout all this, and be assured that quality and stability is always Goal #1 with us, as if it doesn't work, y'all won't use it.


(TL;DR: I know what the problem is, have fixed it, and you'll all have it soon.)

Guys, there's a kernel on the way that not only fixes the random reboots with video (I'll post up the gory details tomorrow) but also brings back the Video optimization I was talking about earlier and the 400MHz GPU speed as before.

I've been quiet these last few days nailing down both the random-reboot (which is actually a "lockup") issue, plus the issue where sometimes you can hit the power button but the device doesn't respond.

I'm 99.9% sure I have the reboot issue down (it was something that wasn't even where I was looking for it), and the changes I've made to eliminate the power-button-on issue are also going to generally make the device more responsive as well. I had a 2-1/2 hr YouTube HD video running from start to finish without a single issue.

Again, sorry for the inconvenience, but rest assured that I've been on it since it'd started to happen (my Xoom is my daily driver too)!

bigrushdog said:

You guys should be maxing out that thanks button for kcrudup.

Click to expand...

Click to collapse

Ya know what's funny? I couldn't care less about those, and even have Thanks counts turned off in settings.

bigdave240 said:

Since flashing 128 i have had my xoom go into a stuck state twice where it looks like it has gone into standby but wont wake up and gets hot like it is running something while in that state. Only way to wake it has been a reboot. Anything you need me to look at?

Click to expand...

Click to collapse

<grumble>

Yeah ... next time this happens, if you have "adb" can you do: for about a minute or two and send me that output? I know exactly what happened, I'll bet- you were caught up in an "I/O Storm", and the machine never got to service your PowerOn request before the screen-off timer kicked in (so the screen never came on). Your machine was probably running just fine, otherwise.

The other thing I'm working on lately is fixing lag caused by a combination of our using a relatively-older kernel (2.6.39.4), our slow EMMC flash disk, and believe it or not, not enough RAM (732MB isn't really enough anymore as the size of the OS and Apps increase to fill the vacuum).

Have you noticed that when the Xoom first boots, everything is so fast, then after a while, things start to slow down? Well, what's happening is that when RAM begins to fill with Apps, libraries and disk data, the system does what it can to page out memory that's not needed (disk-cache data that hasn't been used in a while, parts of programs that haven't been executed in a while (which can be reloaded from disk if necessary) and if all else fails, there's a "low-memory-(app)-killer" that runs in the kernel and forcibly shuts down apps (this is the reason why sometimes you'll switch back to a large-memory-footprint app like the Browser, and the tabs will all have to reload).

A lot of that involves what's called "paging" back and forth from the EMMC flash disk. When the stale data gets written out, we're doing writes to the flash filesystem- and those operations can take a LONG time (relative to the speed of reads, and of the CPU) and because of the way the flash disk works, while that slow write is happening, no reads (which are a lot faster) can run- so when the memory starts to get full of running programs (and/or is doing a lot of I/O (especially write I/O)) the system ends up slowing down:

- dirty data is being written out, while
- new programs (or parts of programs that were paged out and now need to run) are being read in, while
- the system is spending CPU cycles trying to scan memory and free blocks

so we end up in a condition called "thrashing". I've been spending a LOT of time trying to reduce this as much as I can: I've been working on doing ANYTHING I can to get the write thruput up, and have been tweaking both the V(irtual) M(emory) parameters and the I/O Scheduler parameters in an effort to keep the number of random writes down, to prioritize reads over writes, and to avoid "I/O Storms", where we spend a lot of time hitting the flash disk.

it's a lot of work, mostly due to the limitations of the device and kernel I have to work with, but it's coming along. Unfortunately, it still hits me, too (I can't run "Google Earth" with Hi-Res images and sync "Google Currents" at the same time without running into the same issue you do) but I'm making progress- I've got unreleased patches that are working much better than stock, and as soon as I'm satisfied with them, they'll go into a nightly.