Hello,
We have got now some model instances up in our local lava instance.
What I would like to find out is 'how best to manipulate the model parameters'.
>From my logs I can see
<LAVA_DISPATCHER>2013-11-06 06:27:33 PM INFO: launching fastmodel with command u'sudo -u www-data ARMLMD_LICENSE_FILE="<license-server-loc>" /fastmodels/current/FVP_Base_Cortex-A57x4-A53x4 -C bp.virtioblockdevice.image_path=/srv/lava/instances/production/var/www/lava-server/images/tmppF_EKI/sd.img -C bp.secure_memory=0 -C bp.smsc_91c111.mac_address="02:90:00:03:00:06" -C pctl.startup=0.0.0.0 -C bp.pl011_uart0.untimed_fifos=1 -C bp.flashloader0.fname=/srv/lava/instances/production/var/www/lava-server/images/tmppF_EKI/uefi_fvp-base.bin -C bp.secureflashloader.fname=/srv/lava/instances/production/var/www/lava-server/images/tmppF_EKI/bl1.bin -C bp.smsc_91c111.enabled=true -C bp.hostbridge.interfaceName="armv8_06" -C cache_state_modelled=0'
Also from http://git.linaro.org/gitweb?p=lava/lava-dispatcher.git;a=blob;f=lava_dispa…
I can see some of these parameters defined at the above link.
Q1. Is there an easy way to have any of these parameters, for example cache_state_modelled , modified via the json file itself, which define the job?
I can see from one of Linaro's json files has the following entry.
"command": "boot_linaro_image",
"parameters": {
"options": [
"boot_cmds=boot_cmds_oe"
]
}
Is this it correct for me to assume that this corresponds to the kernel command line arguments passed via UEFI?
- Arguments: console=ttyAMA0 earlyprintk=pl011,0x1c090000 debug user_debug=31 loglevel=9 root=/dev/vda2
Can anyone please confirm?
On a related theme, I can see the following being defined in the dispatched device_type def
simulator_dtb = fvp-base-gicv2-psci.dtb
and then this getting subsequently used in the UEFI fdt argument
- FDT: VenHw(C5B9C74A-6D72-4719-99AB-C59F199091EB)/fvp-base-gicv2-psci.dtb
Q2. Since the hardware pack do have additionally fvp-base-gicv2legacy-psci.dtb and fvp-base-gicv3-psci.dtb, how can I specify the UEFI to pick the alternate dtbs during the run? What is the easiest option?
Thanks
Basil Eljuse...
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Hi,
I've been looking at moving my ghetto multinode stuff over to proper
LAVA multinode on and off for a while now, and have something that I'm
still not sure how best to handle: result aggregation.
The motivating case here is having load generation distributed across
various machines: to compute the req/s the server is actually able to
manage I want to add up the number of requests each load generator made.
I can sort of see how to do this myself, basically something like this:
1. store the data on each node
2. arbitrarily pick one node to be the one that does the aggregation
3. do tar | nc style things to get the data onto that node
4. analyze it there and store the results using lava-test-case
but I was wondering if the LAVA team have any advice here. In
particular, steps 2. and 3. seem like something it would be reasonable
for LAVA to provide helpers to do.
Cheers,
mwh
Thanks for pointing out the correct mailing list to use for this... I
wasn't sure which one was appropriate and wanted to be as low-key as
possible about this issue since I wasn't paying much attention about what
was updated.
The virtual environment in question is my Ubuntu 12.04 workstation... not a
local LAVA server environment. So there is no lava deployment tool in this
environment AFAIK. The lava tools were installed from binary packages
found in a combination of the official Ubuntu repositories plus "deb-amd64
http://ppa.launchpad.net/linaro-maintainers/toolchain/ubuntu precise main"
and "deb-amd64 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntuprecise
main".
I normally assume that any updates which come from the 12.04
distribution-compatible repositories should be a safe and reliable upgrade,
and I try to stick with binaries from the official repositories rather than
locally compiled packages in order to minimize packaging compatibility and
upgrade issues. Why is a package for Ubuntu 12.04 requiring pyxdg ==0.25
when the latest pyxdg version available in the 12.04 repositories is
0.19-3ubuntu2 (which was already installed)? And why didn't this
requirement get listed as a dependency in the package, flagged as an unmet
dependency and prevent the package upgrade from occurring?
And most importantly now that this binary update has occurred despite the
unmet dependency, how do I cleanly get a working set of lava tools for
accessing the production servers from command line scripts again? Is there
a way to back out the update and revert to the earlier version? The new
lava-scheduler-tool package version is 0.6-0ubuntu1~linaro1, but I don't
know what the previous working version was nor if it is still accessible
for installation.
Any help will be appreciated. Fortunately I'll be on vacation next week so
I have some time to fix this before it becomes a serious handicap to my
work.
Gary Robertson
On Sun, Nov 24, 2013 at 5:28 AM, Neil Williams <neil.williams(a)linaro.org>wrote:
> Please use linaro-validation for queries like this.
> linaro-validation(a)lists.linaro.org (Please do not reply directly to me
> or to this private team list)
>
> The error message describes what is wrong - pyxdg has been added as a
> requirement but is not in the virtual environment.
>
> lava-deployment-tool upgrade or re-running the buildout command is
> normally sufficient for this.
>
> On 24 November 2013 00:13, Gary Robertson <gary.robertson(a)linaro.org>
> wrote:
> > Hello,
> >
> > Today there was an update to the lava tools on my Ubuntu 12.04 x86_64
> > workstation. I have the PPA repository enabled to try and stay up to
> date
> > on all my Linaro tools.
> >
> > Some time after the update, I tried to submit a job from my local
> machine
> > thusly:
> >
> > lava scheduler submit-job
> http://gary-robertson@validation.linaro.org/RPC2/
> > workspace-le/my_test.json
> >
> > The json file was:
> >
> >
> > {
> > "actions": [
> > {
> > "command": "deploy_linaro_image",
> > "metadata": {
> > "distribution": "openembedded",
> > "hwpack.build": "13",
> > "hwpack.type": "arndale"
> > },
> > "parameters": {
> > "hwpack":
> > "
> https://people.linaro.org/~gary.robertson/hwpack_linaro-arndale_20131123-23…
> ",
> > "rootfs":
> > "
> http://snapshots.linaro.org/openembedded/images/lng-armv7a-gcc-4.8/160/lina…
> "
> > }
> > },
> > {
> > "command": "lava_test_shell",
> > "parameters": {
> > "testdef_repos": [
> > {
> > "git-repo":
> > "git://git.linaro.org/qa/test-definitions.git",
> > "testdef": "openembedded/hackbench.yaml"
> > }
> > ],
> > "timeout": 18000
> > }
> > },
> > {
> > "command": "lava_test_shell",
> > "parameters": {
> > "testdef_repos": [
> > {
> > "git-repo":
> > "git://git.linaro.org/qa/test-definitions.git",
> > "testdef": "openembedded/ltp.yaml"
> > }
> > ],
> > "timeout": 7200
> > }
> > },
> > {
> > "command": "lava_test_shell",
> > "parameters": {
> > "testdef_repos": [
> > {
> > "git-repo":
> > "git://git.linaro.org/qa/test-definitions.git",
> > "testdef": "openembedded/ltp-realtime.yaml"
> > }
> > ],
> > "timeout": 18000
> > }
> > },
> > {
> > "command": "lava_test_shell",
> > "parameters": {
> > "testdef_repos": [
> > {
> > "git-repo":
> > "git://git.linaro.org/qa/test-definitions.git",
> > "testdef": "openembedded/kvm.yaml"
> > }
> > ],
> > "timeout": 18000
> > }
> > },
> > {
> > "command": "lava_test_shell",
> > "parameters": {
> > "testdef_repos": [
> > {
> > "git-repo":
> > "git://git.linaro.org/qa/test-definitions.git",
> > "testdef": "openembedded/lmbench.yaml"
> > }
> > ],
> > "timeout": 18000
> > }
> > },
> > {
> > "command": "submit_results",
> > "parameters": {
> > "server": "http://validation.linaro.org/RPC2/",
> > "stream": "/anonymous/gary-robertson/"
> > }
> > }
> > ],
> > "device_type": "arndale",
> > "job_name": "gary.robertson_linux-lng-preempt-rt_le_13",
> > "timeout": 172800
> > }
> >
> > As of yesterday I was able to submit identical jobs for different hwpacks
> > successfully, but this evening after the update had occurred it failed
> with
> > the following error:
> >
> > Traceback (most recent call last):
> > File "/usr/bin/lava", line 5, in <module>
> > from pkg_resources import load_entry_point
> > File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2711, in
> > <module>
> > parse_requirements(__requires__), Environment()
> > File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in
> > resolve
> > raise DistributionNotFound(req)
> > pkg_resources.DistributionNotFound: pyxdg==0.25
> >
> >
> > I was able to submit the above json file via the web interface and so was
> > able to schedule the test successfully that way... however I would very
> much
> > like to restore the ability to do this from a local command line, as my
> > kernel tree maintenance duties require frequent LAVA tests for pending
> > patches to the LNG kernel.
> >
> > I'm not sure if this is a bug or some kind of configuration error on my
> part
> > due to mixed repository specifications or such - so I'm reporting it
> here to
> > let the gurus get a look at it.
> >
> > Any help or insight would be appreciated.
> >
> > Gary Robertson
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
>
Hi,
lava-gerritbot is back, but now it is less chatty than before.
It now reports in #linaro-lava, events such as patchset-created and
patchset-merged, other events are ignored! Hope everyone will like this
change :)
Thank You.
--
Senthil Kumaran
http://www.stylesen.org/http://www.sasenthilkumaran.com/
Hello all,
lava-tool version 0.8.1 was just released. This release introduces the
following new convenience features. From an excerpt of lava-tool README:
Dealing with jobs
$ lava job new file.json # creates file.json from a template
$ lava job submit file.json # submits file.json to a remote LAVA server
$ lava job run file.json # runs file.json on a local LAVA device
Dealing with LAVA Test Shell Test Definitions
$ lava testdef new file.yml # creates file.yml from a template
$ lava testdef submit file.yml # submits file.yml to a remote LAVA server
$ lava testdef run file.yml # runs file.yml on a local LAVA device
Dealing with LAVA Test Shell Scripts
$ lava script submit SCRIPT # submits SCRIPT to a remote LAVA server
$ lava script run SCRIPT # runs SCRIPT on a local LAVA device
lava-tool can be installed form PyPi with the pip command line tool [0] and
from the Linaro Tools PPA [1].
[0] $ pip install lava-tool
[1] https://launchpad.net/~linaro-maintainers/+archive/tools/
--
Antonio Terceiro
Software Engineer - Linaro
http://www.linaro.org
Hi LAVA folks,
I don't know if you guys know, but Android is moving to LLVM for the next
release or so. As such, we'll need to do a lot of testing between now and
next release to make sure each component can be compiled (and runs
correctly) with LLVM on an incremental basis.
We're trying to come up with a way for remotely testing the Linux kernel
booting on ARM devices, more specifically an Android stack, and I'm finding
it hard to do that with my home equipment. Doing that in LAVA would be
ideal, and I know the Android team does it already, but our constraints
could be a little different.
Basically, there are two fronts:
1. Building Android components with LLVM, using a GCC-compiled kernel
booting on an ARM board, in LAVA. This is something we should work
internally on how to do it, and it'll be between Android, LAVA and
Toolchain groups.
2. Building the Linux kernel with LLVM, and using a GCC-compiled image
(like stock CyanogenMod) to test the kernel. We don't have such a kernel
(many patches), but the LLVMLinux guys do, and that's where they come in.
On the second case, the topic of this email, we'd have to liaise with them
to fire jobs at LAVA from their own infrastructure (originally, manually
only), and that might need some thinking. But ultimatelly, we want to have
those jobs running on LAVA, so that later on we'd be able to have a third
layer: Linux+Android built with LLVM with the same system level tests.
Since the LLVMLinux guys don't have access to much ARM hardware, and since
it's easier for us to scale (or to re-define) hardware requirements, having
them running on LAVA makes even more sense.
Is this something we can do? Is this being done already? Is this just a
question of legal/corporate decision, or is there any technical issues we
have to look into?
Android folks,
It might make more sense if you guys just grab their kernel and build the
Android system based on that internally, so that we don't need external
access to job submissions in LAVA, but that would mean work from you guys
to patch it up, and that might not be in the roadmap for the next months.
Is that a feasible route?
cheers,
--renato
Hi All,
It seems we have broken LDT with the documentation updates.
Our install tests confirm this issue. Sometime on November 11th the LDT
installation stopped working.
http://validation.linaro.org/dashboard/filters/~tyler-baker/lava-master-ins…
Any thoughts here?
---------- Forwarded message ----------
From: DeBerg, Jeremy L <jeremy.deberg(a)intermec.com>
Date: 12 November 2013 13:37
Subject: lava-deployment-tool failing
To: "tyler.baker(a)linaro.org" <tyler.baker(a)linaro.org>
Hey Tyler,
The lava-deployment-tool is broken, I receive this error:
> lava_scheduler_app:0019_set_testjob_owner
> lava_scheduler_app:0020_auto__add_field_testjob__results_bundle
> lava_scheduler_app:0021_rename_results_link
>
lava_scheduler_app:0022_auto__chg_field_testjob__results_bundle__add_unique_testjob__results_b
> lava_scheduler_app:0023_auto__add_field_devicetype_use_celery
> lava_scheduler_app:0024_auto__add_field_devicetype_display
>
lava_scheduler_app:0025_auto__chg_field_testjob__results_bundle__chg_field_testjob_submit_toke
> lava_scheduler_app:0026_auto__add_field_device_device_version
> lava_scheduler_app:0027_auto__add_field_testjob_priority
> lava_scheduler_app:0028_auto__del_field_devicetype_use_celery
>
lava_scheduler_app:0029_auto__add_jobfailuretag__add_field_testjob_failure_comment
>
lava_scheduler_app:0030_auto__add_field_testjob_sub_id__add_field_testjob_target_group
> lava_scheduler_app:0031_auto__add_field_testjob_multinode_definition
> lava_scheduler_app:0032_auto__add_field_testjob_original_definition
- Loading initial data for lava_scheduler_app.
Installed 0 object(s) from 0 fixture(s)
+ set +x
Starting instance again...
+ sudo start lava-instance LAVA_INSTANCE=production
lava-instance (production) start/running
+ set +x
INFO: building documentation for lava-android-test from
/srv/lava/.cache/git-cache/exports/lava-android-test/2013-10-01-08f25ef/doc
INFO: building documentation for lava-dispatcher from
/srv/lava/.cache/git-cache/exports/lava-dispatcher/2013-11-08-8a9833c/doc
INFO: building documentation for lava-server from
/srv/lava/.cache/git-cache/exports/lava-server/2013-10-17-97c7da5/doc
INFO: building documentation for linaro-dashboard-bundle from
/srv/lava/.cache/git-cache/exports/linaro-dashboard-bundle/2013-08-07-a8f2158/doc
Running Sphinx v1.1.3
Exception occurred:
File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 188, in
main
warningiserror, tags)
File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 102,
in __init__
confoverrides or {}, self.tags)
File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 216, in
__init__
exec code in config
File
"/srv/lava/instances/production/var/www/lava-server/static/docs/_src/conf.py",
line 53, in <module>
import lava_server
ImportError: No module named lava_server
The full traceback has been saved in /tmp/sphinx-err-1U0et6.log, if you
want to report the issue to the developers.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Either send bugs to the mailing list at <
http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <
http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
Running installation step docs
INFO: building documentation for lava-android-test from
/srv/lava/.cache/git-cache/exports/lava-android-test/2013-10-01-08f25ef/doc
INFO: building documentation for lava-dispatcher from
/srv/lava/.cache/git-cache/exports/lava-dispatcher/2013-11-08-8a9833c/doc
INFO: building documentation for lava-server from
/srv/lava/.cache/git-cache/exports/lava-server/2013-10-17-97c7da5/doc
INFO: building documentation for linaro-dashboard-bundle from
/srv/lava/.cache/git-cache/exports/linaro-dashboard-bundle/2013-08-07-a8f2158/doc
Running Sphinx v1.1.3
Exception occurred:
File "/usr/lib/python2.7/dist-packages/sphinx/cmdline.py", line 188, in
main
warningiserror, tags)
File "/usr/lib/python2.7/dist-packages/sphinx/application.py", line 102,
in __init__
confoverrides or {}, self.tags)
File "/usr/lib/python2.7/dist-packages/sphinx/config.py", line 216, in
__init__
exec code in config
File
"/srv/lava/instances/production/var/www/lava-server/static/docs/_src/conf.py",
line 53, in <module>
import lava_server
ImportError: No module named lava_server
The full traceback has been saved in /tmp/sphinx-err-BWaJik.log, if you
want to report the issue to the developers.
Please also report this if it was a user error, so that a better error
message can be provided next time.
Either send bugs to the mailing list at <
http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <
http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
All installation is done
Is this you guys or Sphinx?
Thanks,
-Jeremy
This message is intended only for the named recipient. If you are not
the intended recipient, you are notified that disclosing, copying,
distributing or taking any action based on the contents of this
information is strictly prohibited.
--
Tyler Baker
Technical Architect, LAVA
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 Arthur,
I couldn't understand the commit message below. I could see that
migrations are broken due to this commit. Can you elaborate what should
be done here?
I usually run schemamigrations once I change something on the model, but
it is not working anymore due to the following commit.
<snip>
commit 9cd85a647703f080cecd0e5070ca81f8684ee7b4
Author: Arthur She <arthur.she(a)linaro.org>
Date: Wed Oct 16 19:24:37 2013 -0700
Add new permission 'cancel_resubmit_testjob' to allow manipulating
test jobs
- Bug #1172724
- Due to command "lava-server manage syncdb --all" will cause db
migration
fail and it need to modify lava-deployment-tool. Change to data
migration method to add the new permission cancel_resubmit_testjob.
- Anyone who has this permission can cancel / resubmit test jobs.
Change-Id: Ib5ee8cd4df2850f16747dc2e2cb182732cbec1cc
Reviewed-on: https://staging.review.linaro.org/321
Reviewed-by: lava-bot <lava-bot(a)linaro.org>
Reviewed-by: Antonio Terceiro <antonio.terceiro(a)linaro.org>
</snip>
I would like to know what do you mean by the following:
<snip>
Due to command "lava-server manage syncdb --all" will cause db migration
fail and it need to modify lava-deployment-tool. Change to data
migration method to add the new permission cancel_resubmit_testjob.
</snip>
Thank You.
PS: Blocked on this for a long time now, since I couldn't modify the
model for heartbeat check :(
--
Senthil Kumaran
http://www.stylesen.org/http://www.sasenthilkumaran.com/
