On Mon, Feb 24, 2014 at 2:54 PM, Didier Roche <didro...@ubuntu.com> wrote: > Hey, > > We took a big hit for multiple reasons since Friday. Our goal is to go back > to a green baseline as soon as possible. The current image status isn't > great[1], more details below. > > Consequently, we do *not* attribute any CI train silo nor landing which > isn't targeted to get to a greener image or fix android 4.4 issue. > Desktop-only impact landings can still land as usual. If you would like to > help us getting greener faster, please see the "CALL TO ACTION" section > below. > > In the meantime, we never had working image for flo and the emulator with > 4.4, so those 2 were promoted on latest image (#206). > > First, we didn't have full image testing results since Friday (apart from > latest one which was rerun, #206), due to issues Paul mentioned on the > mailing list. This doesn't allow us to know if any regressions are coming > from one of the 3 big landings: autopilot, unity8 and android 4.4. > Fortunately, the autopilot and unity8 landings are small enough to hope they > are not the root cause of any big issues. In addition to that, a lot of core > apps have been updating and affect the global result as well. > > Let's sum up image by image: > # 200: > * this one mostly contains the autopilot change + what was discussed on > Friday > > # 201: > * mostly about new unity8 to isolate downloads in separate threads, card > background support and a bigger sidestage threshold. > * some core apps updates > > #202: > * we got the click update UI back on the image > > -> we didn't get test results due to CI infrastructure issues. > > Then, we had the switch to the new android 4.4 kernel. > > #203: > * First tentative version with the new android version, including hybris > support > > # 204: > * Minor changes, mostly some dropped dependencies on zeigeist > > # 205: > * Some android configuration change for flo. > > # 206: > * First real 4.4 version being able to be flash recovery and boot on your > devices. > * New music and terminal application. Music introduced a bug on first > launch[2]. This wasn't in previous version of music-apps. Alan reverted it. > We'll need upstream as well to ensure they write an integration test for > that case. > > -> We didn't get until this morning any results on those image as the CI > test infrastructure needed to be changed to take into account due to the new > flashing image code being the only working for the 4.4 switch. 206 was rerun > this morning and we see a lot of system-settle issues. > > It took a big part of the day to clear that out: idle definition changed in > the kernel (it's based on all active CPU and not on all active + shutdown > CPUs) as in the past. That's why we started to see pulseaudio and > unity-system-compositor reporting higher CPU usage than they used to. We > need to the CI team to accord to those new ways of reporting idle values.
When trying to better understand why pulseaudio is constantly consuming at least 1% of the cpu, I noticed that alsa ends up waking pulseaudio quite frequently on mako, which might explain the cpu usage (bug https://bugs.launchpad.net/ubuntu/+source/android/+bug/1284415). David, do you know if this is somehow the expected behavior? I though pulseaudio would be mostly down all the time, but maybe this is not the case when the device doesn't support SNDRV_PCM_INFO_NO_PERIOD_WAKEUP. Also looking at our boot log, I noticed that maliit-server always has an open connection with pulse, which might not necessarily be what we want. Bill, do you know if we can change maliit-server to only open the connection with pulse if the user really wants sound on his keyboard? At least pulse was not consuming any cpu after I disabled maliit-server (saving battery). Thanks, -- Ricardo Salveti de Araujo -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
