I'm working on the dispatcher again, and as usual I'm getting a bit
grumpy. Partly this is because the abstractions I added a couple of
weeks ago aren't really working, but that's my problem. What I want to
complain about is the error handling.
I've always found the error handling in the dispatcher to be a little
strange, so in this mail I'm going to try to set out the issue and maybe
propose a solution.
A lot of the confusion comes from the fact that there are many things
that could be called an error in the dispatcher, and some overloading in
the way we try to handle and report errors.
Kinds of error that I can think of immediately:
1) Flat out bugs in the dispatcher
2) Errors in the job file (e.g. typoing an action name)
3) Failing tests
4) Tests that fail to even run
5) The board hanging at some point
6) Infrastructure failures, like l-m-c or deployment failing
7) Recoverable errors, e.g. where we want to be in the master image but
might be in the linaro image
Category 1 bugs we can't really do *too* much about -- if we have
incorrect code, who's to say that the error handling code will be
correct? -- but in general dispatcher bugs should IMO cause the
dispatcher to exit with an exit code != 0 (we talked at the connect
about having the scheduler display jobs that exited like this
differently). Currently because we have lots of "except:"s all over the
place, I think we risk swallowing genuine bugs (indeed, we had one of
these for a while, where we said "self.in_master_shell()" instead of
"self.client.in_master_shell()" but the AttributeError was caught).
If we hit this sort of thing, I don't think we should try to continue to
execute other actions and in particular I'm not too bothered if this
kind of error does not result in a bundle being submitted to the
dashboard.
Category 2 -- errors in the job file -- we should try to detect as early
as possible. Maybe we should even create the action objects and do a
simple argument check before doing anything else? I think this sort of
error should also result in an exit code != 0. To the extent that its
reasonable, invalid job files should be rejected by the submit_job api
call.
As for bugs, I don't think we should try to continue to execute other
actions and I'm not too bothered if this kind of error does not result
in a bundle being submitted to the dashboard.
Category 3 -- failing tests -- is not something the dispatcher itself
should care about, at all.
Category 4 -- tests that fail to run, I guess this includes things like
lava-test hanging or crashing -- I think this should result in a failure
in the magic 'lava' test run of the submitted bundle (and I think this
is the case today). If this happens, I don't know if we should try to
continue to execute other actions (apart from submit_results I guess).
Category 5 -- things like the board hanging at some point -- I guess
this depends a bit when this happens. If it's during deployment say,
that's pretty bad -- certainly we shouldn't try to execute other
non-reporting actions if this happens.
Category 6 -- infrastructure failures -- seem to fall into the same kind
of area as the previous 2: we should report a failure and stop executing
any other actions.
Category 7 -- recoverable failures -- are a bit different. We should
log that they have happened and continue.
After all this thinking and typing I think I've come to some
conclusions:
1) There is a category of error where we should just stop. As far as I
know, this isn't really handled today.
2) There is another category of error where we should report failure,
but not execute any other actions. This makes me thing that having
'report results' as an action is a bit strange -- perhaps the
dashboard and bundle stream should really be directly in the job,
rather than an action?
3) I need to write another, probably equally long, email about
dependencies between actions :-)
Cheers,
mwh
Key Points for wider discussion
===============================
* Toolchain build modified to generate both arm-eabi and
arm-linux-androideabi toolchains
Team Highlights
===============================
* ALmost all Team members attended Connect
* Progress on Androidizing Snowball GLK3.1 kernel
* Workaround created for gdbserver crash on startup
* All board kernels generates config.gz by default
* A bot metrics script to determine the bot's contributions to gerrit done
* Solution to LAVA test iMX53, Origen and Snowball on review
* Progress on video recording bug
* libpng 1.5.5 integration issues solved
* Android builds on tool chain tip build
* Progress on linphone on panda.
Miscellaneous
===============================
* New members Amit Pundir and Prashanth Srinivasan
Issues
===============================
* Slow progress on "Build the Non-Proprietary Igloo Android A Release with
Linaro Tools"
Blueprints
===============================
https://launchpad.net/linaro-android/+milestone/11.11
Hello, All
Does anyone who know where to get the test files defined in
file src/com/android/mediaframeworktest/MediaNames.java.
or how to generate those files.
like
public static final String MP3CBR =
"/sdcard/media_api/music/MP3_256kbps_2ch.mp3";
public static final String MP3VBR =
"/sdcard/media_api/music/MP3_256kbps_2ch_VBR.mp3";
public static final String SHORTMP3 =
"/sdcard/media_api/music/SHORTMP3.mp3";
public static final String MIDI = "/sdcard/media_api/music/ants.mid";
public static final String WMA9 = "/sdcard/media_api/music/WMA9.wma";
public static final String WMA10 = "/sdcard/media_api/music/WMA10.wma";
public static final String WAV =
"/sdcard/media_api/music/rings_2ch.wav";
public static final String AMR =
"/sdcard/media_api/music/test_amr_ietf.amr";
public static final String OGG =
"/sdcard/media_api/music/Revelation.ogg";
public static final String SINE_200_1000 =
"/sdcard/media_api/music/sine_200+1000Hz_44K_mo.wav";
public static String[] MP3FILES = {
"/sdcard/media_api/music_perf/MP3/NIN_56kbps_32khz_stereo_VBR_MCA.MP3",
"/sdcard/media_api/music_perf/MP3/NIN_80kbps_32khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_80kbps_44.1khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_80kbps_48khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_112kbps_32khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_112kbps_44.1khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_112kbps_48khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_192kbps_32khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_192kbps_44.1khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_192kbps_48khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_256kbps_44.1khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/NIN_256kbps_48khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_112kbps_32khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_112kbps_44.1khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_112kbps_48khz_stereo_VBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_192kbps_32khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_256kbps_44.1khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/MP3/PD_256kbps_48khz_mono_CBR_MCA.mp3",
"/sdcard/media_api/music_perf/MP3/WC_256kbps_44.1khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/MP3/WC_256kbps_48khz_mono_CBR_DPA.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Apologize.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Because_Of_You.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Complicated.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Glamorous.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Im_With_You.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Smile.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/Suddenly_I_See.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/When You Say
Nothing At All.mp3",
"/sdcard/media_api/music_perf/regular_album_photo/my_happy_ending.mp3"};
Thanks,
Yongqin Liu
From: Linus Walleij <linus.walleij(a)linaro.org>
Machines that have embedded pin controllers need to select them
explicitly, so why broadcast their config options to menuconfig.
We provide a helpful submenu for those machines that do select
it, making it possible to enable debugging for example.
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
ChangeLog v1->v2:
- Removed some more pointless help text
---
drivers/pinctrl/Kconfig | 22 +++++++---------------
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ef56644..e17e2f8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -2,23 +2,17 @@
# PINCTRL infrastructure and drivers
#
-menuconfig PINCTRL
- bool "PINCTRL Support"
+config PINCTRL
+ bool
depends on EXPERIMENTAL
- help
- This enables the PINCTRL subsystem for controlling pins
- on chip packages, for example multiplexing pins on primarily
- PGA and BGA packages for systems on chip.
-
- If unsure, say N.
if PINCTRL
+menu "Pin controllers"
+ depends on PINCTRL
+
config PINMUX
bool "Support pinmux controllers"
- help
- Say Y here if you want the pincontrol subsystem to handle pin
- multiplexing drivers.
config DEBUG_PINCTRL
bool "Debug PINCTRL calls"
@@ -30,14 +24,12 @@ config PINMUX_SIRF
bool "CSR SiRFprimaII pinmux driver"
depends on ARCH_PRIMA2
select PINMUX
- help
- Say Y here to enable the SiRFprimaII pinmux driver
config PINMUX_U300
bool "U300 pinmux driver"
depends on ARCH_U300
select PINMUX
- help
- Say Y here to enable the U300 pinmux driver
+
+endmenu
endif
--
1.7.3.2
Hi,
I'm trying to make a SIP stack run on a low-end processor (720 MIPS capable). Problem is the stack's EC is not neon-optimized & with a 256 ms EC tail, I'm exhausting the CPU.
On one of the forums, I came across neon optimization trials for speex AEC by Linaro. Has there been a completed project? Or any other that can help me?
Thank you for answering.
Regards,
Sangram
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
From: Linus Walleij <linus.walleij(a)linaro.org>
Machines that have embedded pin controllers need to select them
explicitly, so why broadcast their config options to menuconfig.
We provide a helpful submenu for those machines that do select
it, making it possible to enable debugging for example.
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
drivers/pinctrl/Kconfig | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ef56644..e816f60 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -2,18 +2,15 @@
# PINCTRL infrastructure and drivers
#
-menuconfig PINCTRL
- bool "PINCTRL Support"
+config PINCTRL
+ bool
depends on EXPERIMENTAL
- help
- This enables the PINCTRL subsystem for controlling pins
- on chip packages, for example multiplexing pins on primarily
- PGA and BGA packages for systems on chip.
-
- If unsure, say N.
if PINCTRL
+menu "Pin controllers"
+ depends on PINCTRL
+
config PINMUX
bool "Support pinmux controllers"
help
@@ -40,4 +37,6 @@ config PINMUX_U300
help
Say Y here to enable the U300 pinmux driver
+endmenu
+
endif
--
1.7.3.2
Hi Michael,
I went to take a look at the kernel ci-loop page to see the build
status of upstream builds and have a few new comments on
the UIL
1) When there is a build failure, is it possible to have
the build link go directly to the build results?
It currently takes 3 clicks to get to the results
from the main page and it may not be obvious to
someone that the "consoleText" attachment
is the correct link to use.
2) From the main ci-loop page, how do I get to
a link for the RSS feed? Are the RSS feeds
per-tree or per (tree + defconfig) combination?
The later is preferred from the perspective of
having upstream sub-arch maintainers who
want to watch specific platforms.
Thanks,
~Deepak
Hi,
For a better performance in USB charging operation, the DA9052/53 charging
current can be configured in accordance with the USB host current
delivering capacity (known through USB drivers negotiation).
To implement this useful feature, a new writable property "USB charge current"
needs to be added in the Linux battery core.
Let me know your views on it.
Regards,
Ashish
Hello,
Based on the discussions and decisions made at the Linaro Connect Q4.11,
Infrastructure team is pleased to announce changes in the process of
Linaro Android Infrastructure planning and maintenance. The main
audience of the new process is Linaro Android Team, which is the primary
stakeholder of the Android infrastructure, but it also applies to other
groups and individuals in Linaro, as well as external contributors and
community.
The basic idea is to make Android infrastructure planning and
management more sustainable, as well as improve the Infrastructure Team
internal processes which will allow entire team to handle Android
infrastructure tasks and improve cross-team work and knowledge sharing.
The new process is as follows:
1. There's a new Linaro Android Infrastructure project at Launchpad,
https://launchpad.net/linaro-android-infrastructure/ , which is
intended to be a central facade for Android infrastructure development
and maintenance.
2. The bugtracker in that project,
https://bugs.launchpad.net/linaro-android-infrastructure is intended as
a single contact point to report Android infrastructure issues, so
please bookmark it and keep it handy. This ticket queue replaces all
older communication means, like direct email, IRC pings, etc. (that
doesn't mean they can't be used, it means that any issue should be
reported as a ticket nonetheless). The bugtracker is indeed conceived
to be a single point of contact, and if a ticket requires recursing to
Linaro IS team, that will be handled by Infrastructure team itself.
Using the "bug also affects project" Launchpad feature, tickets can be
easily cross-posted to other projects which are affected.
3. The blueprints area in that project,
https://blueprints.launchpad.net/linaro-android-infrastructure is used
to host all blueprints related to Android infrastructure. That may
change in the future (i.e. they will be filed against individual
projects), but so far it's good step forward from such bluprints being
filed against linaro-android project, which caused scheduling and
accounting issues for both Android and Infrastructure teams.
4. The usual rules of thumb are applied to blueprints and tickets:
Blueprints represent work to develop new (sub)systems or add
non-trivial functionality to existing systems. They can be filed at any
time, but prioritized and scheduled for execution at the beginning of
monthly milestones. Tickets represent issues reports and requests to
make changes which only Infra team can do, other maintenance requests,
and feature requests. Tickets which turn out to require substantial
effort, may be converted to blueprints.
5. For the time being, the Infrastructure team commits to working on
1-2 Android infrastructure blueprints each milestone, with more time
spent on maintenance (including documentation and testsuites) of
existing systems. Following the process above will allow us to optimize
and improve our workflow, and provide more resources to Android
infrastructure work, if that proves to be required.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
