# Progress #
* LAVA-1199
* Deployed 3 D01s into LAVA. One into LNG rack, two into production - in progress
* LAVA-1188
* Started work on ARM/LAVA presentation - in progress
* LAVA-1139
* Now have new office LAB spec completed - Complete
* LAVA-1128
* Started work on planning an ARM only master/dispatcher configuration - in progress
* LAVA-1187
* Trying to deploy k3v2-02 - blocked
* Updated health check to use local private image instead of snapshot that disappeared - complete
* General maintenance
* Investigating highbank issues
* Power cycling and restoring highbank nodes
* Time
* LAVA-1199 (4/10)
* LAVA-1188 (1/10)
* LAVA-1139 (1/10)
* LAVA-1128 (1/10)
* LAVA-1187 (2/10)
* Other/Misc (1/10)
# Plan #
* LAVA-1199
* Deploy when dispatcher03 available
* Work on board with corrupted firmware
* LAVA-1188
* Get outline slide deck complete
* LAVA-1123
* Start deployment of ARM only master/dispatcher
* LAVA-1187
* Try to resurrect k3v2 with help of Huawei
# Issues #
* LAVA-1199 D01 deployment
* 1 D01 has firmware corruption - in contact with Huawei to try to fix
* 1 D01 awaiting new dispatcher
* LAVA-1187
* Board is not behaving - am in touch with Huawei to try to resolve
Dave Pigott
LAVA Lab Lead
Linaro Ltd
t: (+44) (0) 1223 400063
# Progress #
* LAVA-851 - Initial wip patch submitted for nested-vms
* #1292522 - Fixed role for actions in lava-dispatcher
* #1292522 - Fixed/Tested role for actions in lava-server
* correct fix production hot-fix (workaround) for state transitions
* various code reviews
* Time
* LAVA-851 - 50%
* #1292522 - 10%
* state transition fix - 20%
* various code reviews - 20%
# Plan #
* LAVA-851 - continue with nested vms work
--
Senthil Kumaran
http://www.stylesen.org/http://www.sasenthilkumaran.com/
# Progress #
* LAVA-944 - completed django-tables2 fixes for LAVA
* LAVA-933 - LAVA django1.6 patches up for review.
* CARD-1255 - Hidden device types, initial local changes and new unit
tests, not finalised for review yet.
* CARD-1073 - community support, updating packaging helpers, LAVA on
ARM testing using arndale
* #1294613 - can't cancel a users job when their email invalid, in review.
* #1294344 - public filter table fix
* Time
* LAVA-944 - 20%
* LAVA-933 - 20%
* CARD- 1255 - 20%
* CARD-1073 - 20%
* Bugs: 20%
* Other/Misc - Linaro GSoc14
# Plan #
* LAVA-1123 - finalise
* LAVA-849 - Support running virtual machines on devices under test -
supporting Antonio & Senthil where requested.
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
# Progress #
* [LAVA-943]
* Remove bug link icon from the front end UI of test run table to let it
be consist with image report 1.0 & 2.0
* Working on test case table
# Plan #
* [LAVA-943]
* To let test case table be able to link bug
# Issues #
* No issues
Hi,
I'm trying to communicate between 2 multinode jobs and send some short
messages. The docs say that the key-value pairs are stored in the
/tmp/lava_multi_node_cache.txt file. So I was expecting something
like:
my_key=my_value
or:
my_key: my_value
What I'm getting is:
sending-device-name:my_key=my_value
Is this the expected output and the documentation is just not detailed
enough? Or I'm getting buggy output in the cache file?
milosz
Re: Message-ID: <20140223143441.293e5997(a)sylvester.codehelp>
https://bugs.launchpad.net/lava-server/+bug/1271527
> The bug is due to be fixed soon - at which point tags which are *not*
> supported by the instance to which the job is submitted will cause the
> job submission to *fail*. This is so that device tags can be used to
> dictate which devices actually run the TestJob.
The bug fix has now been merged and will soon be available on
staging.validation.linaro.org
There are a few more updates to make elsewhere in tip but this change
will now be part of the next production rollout to
validation.linaro.org.
If you have not checked all of your JSON templates for device_tags, now
is the time to do it.
Any device_tags in JSON files after this rollout must be supported in
the database for the instance - suitable devices must exist with the
specified tags or your submission will fail.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Hello All,
Background::
The armv8 models supports multiple uarts. The primary one being uart0. I believe this is the one which LAVA listens to, to provide the log message when tests are run.
Till now uart0 was the serial connection in use. However with our recent changes to the arm trusted firmware we introduced the test secure payload which is a test component in the secure world that is using uart1 for dumping its log info.
Issue::
I have to test in 2 configuration where
a) This test secure payload is included
b) This test secure payload is excluded (which is the default case when using the standard make file flags)
For the second config, this are all perfect, no issues.
However for the first config when this test secure payload is there that uses uart0, I can see that the kernel does to complete the boot sequence.
When run with the same firmware and the filesystem, it works perfectly OK.
The key observation is that lava log output abruptly stops after the file system is mounted and just before we expect messages about udev bindings (in a successful run I see some udev messages and almost immediately the 'Last login' message which cue for lava to confirm the boot was successful).
There were 2 additional flags which the developer was using in his manual run and I gave that too in the device config, but in vain!
bp.pl011_uart0.out_file=- (when I included this lava started throwing duplicate set of messages in the log! So I removed it later)
bp.pl011_uart1.out_file=tsp.output
Attaching the lava log outputs both with and without tsp component as reference.
It is clear to me that the images boots successfully, however LAVA seem to lose serial communication in between which makes it impossible to detect the login prompt.
Any obvious suspicions on this differing behaviour? Any help much appreciated.
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
