linaro-validation November 2013

linaro-validation@lists.linaro.org

20 participants
17 discussions

What is the best way to configure fast model parameters...

by Basil Eljuse

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

10 years, 11 months

multinode question: aggregating results

by Michael Hudson-Doyle

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

11 years, 1 month

Re: [Linaro-validation] Local lava fails to submit job after update

by Gary Robertson

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/ >

11 years, 1 month

Please help to review changes on LAVA

by YongQin Liu

Hi, Antonio, LAVA team Could you please help to review and deploy the following two changes? https://staging.review.linaro.org/#/c/507/ https://staging.review.linaro.org/#/c/508/ especially the first change on rtsm_fvp_base-aemv8a.conf, we want to run jobs for release during the weekend. -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/pipermail/linaro-validation

11 years, 1 month

deploy_linaro_kernel boots, but stuck at command line.

by Riku Voipio

Hi, succesfully booted kernel on arndale. But while the boot is successful, lava doesn't seem to recognize being in the test image: http://validation.linaro.org/scheduler/job/87154/log_file#L_22_0 The question is, is the test definition correct: http://validation.linaro.org/scheduler/job/87154/definition Or does there need to be something in the rootfs for lava to recognize the boot command succeeded? Riku

11 years, 1 month

lava-gerritbot is now less chatty

by Senthil Kumaran

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/

11 years, 1 month

lava-tool 0.8.1 released

by Antonio Terceiro

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

11 years, 1 month

Testing Android on LAVA

by Renato Golin

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

11 years, 1 month

Fwd: lava-deployment-tool failing

by Tyler Baker

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/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

11 years, 2 months

Doubt in a commit

by Senthil Kumaran

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/

11 years, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation November 2013