Hello,
On Fri, 5 Apr 2013 17:45:07 +0300
Paul Sokolovsky <Paul.Sokolovsky(a)linaro.org> wrote:
[]
> I know that Matt tried to do bunch of builds and they were failing by
> one reason or another, the best thing I can do besides re-enabling
> daily builds is to launch build of a previous known-good revision on
> couple of boards in parallel (to insure against possible hw issues of
> a particular board). Hope that will re-establish baseline, so let's
> check the builds on Monday.
Ok, so here're these 2 builds:
gcc-4.8~svn196132
panda-es02
https://validation.linaro.org/lava-server/scheduler/job/50993
panda-es05
https://validation.linaro.org/lava-server/scheduler/job/50994
#50993 went well.
#50994 midway in compilation started to get invalid data (grep for
"is not valid in preprocessor expressions"), then got kernel fault,
then got caught in reboot loop, apparently due to:
[ 6.631256] thermal_init_thermal_state: Getting initial temp for cpu domain
[ 6.638702] thermal_request_temp
[ 6.642150] omap_fatal_zone:FATAL ZONE (hot spot temp: 128490)
- all these behaviors were seen by me before (actually, previously, I
didn't see such explicit messages from kernel that it's a thermal
faults).
So, CBuild/LAVA can do (successful) builds, but some builds fail due to
thermal issues. Actually, let me load up all boards with the same build
now, towards assessing thermal failure rate more scientifically.
I'm not sure what's wrong with Matt's Fri builds, none of which
succeeded, will look into that on Mon.
--
Best Regards,
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
Hi Team,
Below patch is to print result.csv file on to complete log of lava job.
Please review below patch and request you to merge this on to production
ASAP, because this patch is a part of parsing workload automation results
automatically.
Patch:
https://code.launchpad.net/~naresh-kamboju/lava-android-test/print-workbenc…
Best regards
Naresh Kamboju
=== modified file 'lava_android_test/test_definitions/hostshells/workload.sh'
--- lava_android_test/test_definitions/hostshells/workload.sh 2013-01-14
10:54:17 +0000
+++ lava_android_test/test_definitions/hostshells/workload.sh 2013-04-03
17:46:31 +0000
@@ -138,6 +138,7 @@
echo "Failed to run workload.py config.csv outputdir/"
exit 1
fi
+ cat ${result}
parse_output_result ${result}
}
Hi,
I noticed that since last March 27, 2013, the following devices status are
'idle' or 'offline' and are not responding to job submitted on
LAVA-Scheduler jobs.
*rtsm_foundation-armv8*
*snowball_sd*
http://validation.linaro.org/lava-server/scheduler/
once the job is submitted, it is still on Submitted status.
http://validation.linaro.org/lava-server/scheduler/job/50605
Would you like to raise a bug on this issue ?
With Best Regards
Soumya Basak
[beware of the x-post!]
Hi all,
As discussed briefly with some of you, I've been hacking on some scripts
to allow us to run some tests / benchmarks that make use of more than
one calxeda node before we get proper support in LAVA. The script is
here:
http://bazaar.launchpad.net/~mwhudson/+junk/highbank-bench-scripts/view/hea…
but it's pretty terrible code, you probably don't want to look at it.
More interesting might be the test code branch:
http://bazaar.launchpad.net/~mwhudson/+junk/highbank-bench-1/files
If it's not clear, the idea here is that:
1) devices.yaml file defines roles for nodes and says how many of each
role you want,
2) the test code branch is copied to each node,
3) the run-$rolename.sh script is run on each node,
4) finally the contents of the /lava/results directory on each node is
copied back to the system the tests were run from.
Coordination between nodes is done via lava-wait-for and lava-send shell
scripts as proposed in the connect session.
fakedispatcher is invoked with the URL of the test code branch, e.g.:
python fakedispatcher.py lp:~mwhudson/+junk/highbank-bench-1
Some notes:
1) I hope that using an "API" like that proposed in the connect session
will let us figure out if it's actually a useful api.
2) fakedispatcher is still pretty terrible in many ways (e.g. it has a
hardcoded list of (currently just 2) calxeda nodes to use), and
either gives obscure errors or just hangs when things go wrong.
3) Despite 2), it does actually work. So I'm pretty happy about that,
and would like to talk to all of you about how to write your test
cases in a form that works with fakedispatcher :)
Cheers,
mwh
Hi Tom,
(cc'ing the validation list)
Basically, as I always say, LAVA is an enabler - we provide the framework for people to run jobs which can install and run anything they like. We are not pro- or prescriptive. So the short answer is, someone may well have run the WebKit test suite as part of a LAVA job, but personally I don't know who.
Anyone on the list have any further info for Tom?
Thanks
Dave
On 3 Apr 2013, at 18:02, Tom Gall <tom.gall(a)linaro.org> wrote:
> Hi Dave,
>
> I've been asked if webkit was put into LAVA in any form. By this I
> presume the person asking is wonder if WebKit's test suite has been
> added.
>
> Do you know how we can find out if this is the case and who might have done it?
>
> Sorry if this might be misdirected and something better asked of someone else.
>
> Thanks!
>
> --
> Regards,
> Tom
>
> "Where's the kaboom!? There was supposed to be an earth-shattering
> kaboom!" Marvin Martian
> Tech Lead, Graphics Working Group | Linaro.org │ Open source software
> for ARM SoCs
> w) tom.gall att linaro.org
> h) tom_gall att mac.com
hi, linaro:
i want the whole LAN can access to the lava-server on my compute. but when i run it ,it only can be accessed with 127.0.0.1:8000. how can i change it to another?
http://pastebin.com/U4VGxYck
Look forward to your reply。
liulinlang
Huawei
Hey guys,
Looking at the LAVA queue right now, we have:
- 20 jobs for rtsm*
- 15 jobs for snowball_sd
- 15 jobs for vexpress-a5
Dave:
regarding rtsm*, what's the status of the cloud problems? Do you need
any help with that?
regarding snowball_sd, how close we are from a solution?
regarding Vexpress A5, the notes from the last leads weekly meeting say
"microSD needs updating for UEFI, we can’t enable it yet". Is there
anything other than manpower with physical access to the lab blocking us
from going ahead with this?
Everyone:
Is there a way to pause the submission to those devices while
we have these issues to avoid the queue growing out of control? Does it
make sense?
--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org
Hi Naresh,
As per our IRC discussion yesterday am writing this email to let you
know how to proceed with your requirement in python.
In order to parse the following stdout.log file, you must use the 're'
module in python:
http://validation.linaro.org/lava-server/dashboard/attachment/266112/view
Once the data is parsed you can make use of 'csv' module in python in
order to create a file as given in the following link:
https://pastebin.linaro.org/2080/
Hope this will help you to start writing the script in python. If you
require more inputs feel free to follow up with your queries in this
thread.
Thank You.
--
Senthil Kumaran
http://www.stylesen.org/http://www.sasenthilkumaran.com/