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 Dave,
I'm now writing test cases for WiFi on Linaro Android platform and would
like to know that whether we have the access point in our LAVA lab.
If we do have, then would you send me the detailed information about that?
Like the access point name, encryption method & password (if enabled).
Thank you.
Best Regards
Botao Sun
Hi all,
We have some thermal issues with the Calxeda servers, and so we need to take them out of circulation for a short time tomorrow. I'm planning this for 09:00 UTC.
Thanks
Dave
Hi all,
I see from https://validation.linaro.org/scheduler/,LNG devices are all
online,but when I try to submit jobs,it said:
Submit JobError:
Permission denied. You not have the required permissions to submit new
jobs.
Please contact the administrators.
I think I need to ask someone for the permission.Anyone knows what can I
do?
Thanks.
+ Linaro Validation Mailing List
On Wed, Dec 4, 2013 at 11:34 AM, Botao Sun <botao.sun(a)linaro.org> wrote:
> Hi Vishal & Tyler,
>
> I'm now working on the WiFi automation testing on TI Panda board, which is
> using "svc" tool to enable and disable WiFi.
>
> And again, I met the issue which is related to the difference between the
> image in our LAVA lab and my local board. "svc" command can be run
> successfully on my local board but got terminated in LAVA:
>
> http://validation.linaro.org/dashboard/attachment/585306/view
>
> <LAVA_SIGNAL_STARTRUN 0_wifi-android 43d17aac-3314-4b5f-a24a-a9a9c6463915>
> /system/bin/svc
> /system/bin/busybox
> Killed
> enable_wifi: FAIL - Run svc WiFi enable command failed
> /system/bin/svc
> /system/bin/busybox
> Killed
> disable_wifi: FAIL - Run svc WiFi disable command failed
> <LAVA_SIGNAL_ENDRUN 0_wifi-android 43d17aac-3314-4b5f-a24a-a9a9c6463915>
>
> However, according to the output, "svc" command is actually available
> there.
>
> Any suggestions?
>
> Thanks.
>
>
> Best Regards
> Botao Sun
>
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/
>
