ubuntu-phone team mailing list archive

[Ricardo Salveti de Araujo <ricardo.salveti@xxxxxxxxxxxxx>]

On Mon, Feb 24, 2014 at 2:54 PM, Didier Roche <didrocks@xxxxxxxxxx> 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