linaro-validation February 2013

linaro-validation@lists.linaro.org

22 participants
32 discussions

by Axel Fagerstedt

Hi guys, Are there any plans to deploy a fresher version lava-android-test? When can we expect it to happen next? (the currently deployed version is about a month old I think) There are a number of tests which have been developed for juice, (with corresponding wrappers added to lava-android-test). We would like to verify that we get the same results in automation as we get when running manually but are unable to do that until we get a fresher version of lava-android-test deployed. BR, Axel

12 years, 11 months

big.LITTLE MP Scheduler test summary-(week-9)-13.02

by Naresh Kamboju

Hi, Release test report (week-9) 13.02: Here is test result summary for big.LITTLE MP Scheduler test on TC2 platform with Android image sched_tests.git No of Test Cases Tests Run Tests Pass Tests Fail Absolute pass rate (%) Failure Analysis/Comments Regression 20 19 19 0 100 - mpbasicsuite 10 9 9 1 90 - mpcoresuite 4 4 4 0 75 - mpextendedsuite 6 6 4 2 66.7 - mploadbalance 2 2 2 0 100 - Android Build: https://android-build.linaro.org/builds/~linaro-android/vexpress-linaro-mp-… Linux kernel: Linux version 3.8.0-00928-g7d866cd (jenkins-build@ip-10-10-66-148 ) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02) ) #1 SMP Sat Feb 23 11:31:29 UTC 2013 Results spread sheet: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0Ai9ggMs8bsGJdER3a… summary: No regression or new bugs found in this test cycle. Results are same as week-8. Best regards Naresh Kamboju

13 years

Latest attempt of handling automated license-protected downloads

by Paul Sokolovsky

Hello, Short background: 1. We need to access license-protected files as hosted on snapshots.linaro.org in automated (or mediated) way as part if our CI workflow. 2. We used to have multiple ways to handle that, mostly adhoc, and most of which have bitrotted by now. 3. There were also concerns of specific means they're implemented (supposedly as not providing due diligence of license acceptance handling comparing to default procedure of browser download). So, after confirming that we still have more than one client usage for this, I proceeded to implement what is intended to be single tool to handle this matter. The requirements are at: https://bugs.launchpad.net/linaro-license-protection/+bug/1130810 . The tool can be got as: bzr branch lp:linaro-license-protection/download or by following "download file" link at http://bazaar.launchpad.net/~linaro-automation/linaro-license-protection/do… (unfortunately, Launchpad Bzr browser doesn't seem to have means of getting download link to HEAD revision of a file, which is misfeature). Please review both requirements collected and implementation, any suggestion for improvements are welcome. -- Best Regards, Paul 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

13 years

update-initramfs issues in 13.01 master image

by Dean Arnold

Hi all, I am working on updating the firmware on our LAVA TC2 boards to enable PSCI support for the 13.03 release, and for this I wanted to use a master image a little more recent than the 12.06 image we currently have on our boards. I have created a LAVA master image using the vexpresstc2.conf file attached. All seems to boot OK but I get the following during the LAVA first-boot setup process: update-initramfs: Generating /boot/initrd.img-3.8.0-1-linaro-vexpress Unsupported platform. Is this something you have seen before and if so, do you know how I can get past this please? I have attached my full first-boot.log. Thanks for your time, Dean -- 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.

13 years

status of calxeda-highbank-support blueprint

by Michael Hudson-Doyle

[some of you got a version of this by private mail, but there's no real reason to limit the distribution...] Hi guys, I had this blueprint assigned for 2013.02: https://blueprints.launchpad.net/lava-dispatcher/+spec/calxeda-highbank-sup… and unfortunately I didn't get time to implement it completely. I did make some progress, in terms of a general idea and a start of an implementation. I'm braindumping here so that if someone tries to work on this while I'm on leave they don't have to start from scratch. The general idea is similar to the way master images work for developer boards, but instead of the master image living in another partition of the device's storage it lives in an initrd that can be booted via PXE. If you poke around on gateway starting with /etc/dnsmasq.conf you can see how this works. The way I've been producing the initrd's so far is by having this: http://paste.ubuntu.com/5563262/ in a file called /usr/share/initramfs-tools/hooks/master-extras on calxeda02-00-00 (it has quantal installed, user: ubuntu, password: mypassword), running sudo update-initramfs -k all -c and scp-ing the generated initrd into the appropriate location on gateway. This is all very tedious, but it's worked so far... The other side of course is some dispatcher code to drive it all. I have started this here: http://bazaar.launchpad.net/~mwhudson/lava-dispatcher/highbank-support/view… but I haven't even tried to run this once so it's probably full of all sorts of stupid errors. It also contains a good deal of cut-and-paste from master.py -- probably some kind of base class would make sense in the end there. I didn't want to put a web server in the initrd so my plan was to use netcat -- but http provides a little more guarantee that the transfer actually worked, so maybe getting _some_ kind of httpd in the initrd is worth it, I dunno. Currently it expects the "hwpack" to just be a deb of the kernel which is installed via dpkg -i chrooted into the unpacked rootfs to generate the initrd and put the dtb in the right place and all that sort of thing. It's unclear if there will ever be "real" hwpacks and linaro-media-create support for highbank -- and dpkg -i-ing the kernel deb is all this would do anyway really. Some random follow on points: * Bootloaders are loaded via a completely different mechanism for highbank, so support for bootloader testing will have to be done differently (in very vague outline it would be a bit like vexpress I suppose) * There has been some interest in automatic testing of netinstallers. The above wouldn't enable this. * Testing netinstallers and PXE booting in general will require some level of dynamism in the configuration of network booting, obviously. There are a few ways this could be done: * Do netbooting explicitly by talking to u-boot (i.e. no PXE) * Have dnsmasq point at a tftp service that is not backed by the filesystem so we can generate PXE configs on the fly according to how we want to test a device at a particular time (MAAS, Canonical's metal-as-a-service product, works like this). * Somehow put each device being tested in an isolated vlan/broadcast domain with a per-test DHCP implementation. Would be nice but sounds hard in many ways. * There's no inherent reason why we couldn't put the master image in an initrd for developer boards, which would relieve us of the need to muck about with partition indices. Cheers, mwh

13 years

hackish test automation & thoughts about writing multi-node jobs

by Michael Hudson-Doyle

[be wary of the cross post when replying!] Hi all, Seeing as LAVA isn't going to support multi-node tests or highbank in the super near future, I spent a while today hacking up a script to run some tests automatically on the calxeda nodes in the lab. You can see it in all its gory detail here: http://bazaar.launchpad.net/~mwhudson/+junk/highbank-bench-scripts/view/hea… (probably best read from the bottom up, come to think of it) To do things like power cycle and prepare instances in parallel, it's written in an asynchronous style using the Twisted event-driven framework. This was a bit of an experiment and I'm not sure what I think of the result -- it's /reasonably/ clear and it works, but perhaps just using one thread per node being tested and writing blocking code (and using semaphores or whatever to synchronize) would have been clearer. So I guess before I do any more hacking like this, it would be good to hear what you guys (especially Ard I suppose!) think of this style. In general, how to express a job that consists of a number of steps, some of which can be executed in parallel and some of which have dependencies is an interesting one. I suppose my eventy one is more on the side of one-step-at-a-time by default with explicit parallelization and threads + locks would be more on the side of parallel by default and explicit serialization. This has implications for how we write the job descriptions we give to a hypothetical multi-node test supporting LAVA -- has anyone thought about this yet? I think I prefer the explicit parallelism style myself (makes me think of cilk and grand central dispatch and csp...). Cheers, mwh

13 years

Adding new LAVA device types for TC2 PSCI support

by Dean Arnold

Hi Dave, We are looking to test using the latest firmware configuration which has PSCI enabled. I should hopefully have this up and running this week so I can provide you with a tarball of the firmware etc and details on how to set this up for your boards if you would like? We would like to test this configuration and the current one (already in LAVA) in parallel, so if I created another device type config under /srv/lava/instances/<instance>/etc/lava-dispatcher/device-types called vexpress-tc2-psci is this allowed in LAVA, or are there a set list of device types you can choose from? I attempted this on Friday, adding vexpress-tc2-psci as a new device type in the admin UI, then, also in the admin UI, switched the existing device to use the vexpress-tc2-psci device type. I then created the following config files: ----------------------------------------------------------------------------------------------- $ ls -l /srv/lava/instances/production/etc/lava-dispatcher/devices/pdswlava-vetc2-1.conf -rw-r--r-- 1 pdswauto pdswauto 168 Feb 22 12:20 pdswlava-vetc2-1.conf $ cat /srv/lava/instances/production/etc/lava-dispatcher/devices/pdswlava-vetc2-1.conf device_type = vexpress-tc2-psci hostname = pdswlava-vetc2-1 connection_command = telnet pdtl-tt1 6002 hard_reset_command = /usr/share/conmux/drivers/reboot-ap7952 pdtl-pdu-5 08 ----------------------------------------------------------------------------------------------- $ ls -l /srv/lava/instances/production/etc/lava-dispatcher/device-types/vexpress-tc2-psci.conf -rw-rw-r-- 1 pdswauto pdswauto 131 Feb 8 10:20 /srv/lava/instances/production/etc/lava-dispatcher/device-types/vexpress-tc2-psci.conf $ cat /srv/lava/instances/production/etc/lava-dispatcher/device-types/vexpress-tc2-psci.conf boot_cmds = 2 boot_cmds_android = 3 interrupt_boot_prompt = The default boot selection will start in bootloader_prompt = Start: ----------------------------------------------------------------------------------------------- My vexpress-tc2-psci.conf is identical to my vexpress-tc2.conf but I created it so not to cause any confusion This resulted in the same issue I saw when we had a config mismatch before. The board boots the master image then sits waiting at the prompt not knowing what to do until the reboot process times out. It looks as though LAVA doesn't know what device type to use and as a result doesn't know what prompt it should be waiting for. Am I doing something daft? Cheers Dean -- 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.

13 years

Please update section "Including Your Test In Daily Automation"

by Abhijeet Padole

Hi All, Requesting you to update the section "Including Your Test In Daily Automation" on page "https://wiki.linaro.org/Platform/Validation/LAVA/LavaTestTutorial" and also on "https://wiki.linaro.org/Platform/Validation/LAVA/LavaAndroidTestTutorial" This sections are in "TO DO" State from long time. Hence requesting it. :) Regards, Abhijeet SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

13 years

big.LITTLE MP Scheduler test summary-Week-8

by Naresh Kamboju

Hi, Calendar Week 8, 2013: Here is test result summary for big.LITTLE MP Scheduler test on TC2 platform with Android image sched_tests.git No of Test Cases Tests Run Tests Pass Tests Fail Absolute pass rate (%) Failure Analysis/Comments Regression 20 19 19 0 100 - mpbasicsuite 10 9 9 1 90 - mpcoresuite 4 4 4 0 75 - mpextendedsuite 6 6 4 2 66.7 - mploadbalance 2 2 2 0 100 - Android Build: https://android-build.linaro.org/builds/~linaro-android-restricted/vexpress… Linux kernel: Linux version 3.8.0-00922-ge33868e (jenkins-build@ip-10-10-27-33) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-1~dev) ) #1 SMP Wed Feb 20 04:49:44 UTC 2013 Results spread sheet: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0Ai9ggMs8bsGJdER3a… Best regards Naresh Kamboju

13 years

[LAVA] question about LAVA instance upgrade

by Chulyoon Jung

Dear validation team, My name is Chulyoon Jung, LG electronics. I want to know exact procedure for upgrading lava instance according your release. As you know, linaro release source code and tools regularly. So, We want our lava server to upgrade as your release (example 13.01). But, I don't know how I can upgrade each eggs's tool version according your release. (currently we use code/r75 and lava-android-test is 0.11) (release 13.01 has code/r112 and lava-android-test is 0.14) I receive Michael's e-mail. Yes, I can upgrade to the latest version using this CMD. ./bin/buildout -n Could you provide the method how I can upgrade lava server as 13.01 release? Thank you. C. Y. Jung -----Original Message----- From: Michael Hudson-Doyle [mailto:michael.hudson@linaro.org] Sent: Friday, February 15, 2013 9:46 AM To: Chulyoon Jung; 'Andy Doan' Cc: bernard.park(a)linaro.org; ka.chun(a)lge.com Subject: Re: [LAVA] question about LAVA instance ulgrade Hi. In general, it would be best to email the linaro-validation(a)lists.linaro.org list about this sort of thing. Chulyoon Jung <chulyoon.jung(a)lge.com> writes: > Dear Andy, Michael, > > > > Do you remember me? > > I have a question about LAVA platform upgrade. > > > > Currently, I try to upgrade LAVA using lava-deployment-tool (13.01 release). > > But, I have met two problems. > > > > 1. After upgrading, eggs’s tool version is not upgraded. > > - As your document(http://lava-deployment-tool.readthedocs.org/en/latest/index.html), we try to upgrade instance using lava-deployment-tool. > > - Lava-deployment-tool upgrade Instance > > - After that, ~~/instance/code/current is changed > > - But eggs’s tool version is not changed. > > - If we want to upgrade the tool in eggs, what I do? It depends. If you are using a buildout config that specifies exact versions of the dependencies, you need to edit your buildout config. If the versions are floating, running rebuildout -n will update all to the lastest version. > 2. When I try to upgrade instance using lava-deployment-tool, I have met version conflicts in eggs > > - linaro_dashboard_bundle-1.8 and so on. > > - In this case, how can we do? > I don't understand what you mean here. Can you show me the error message you got? Cheers, mwh

13 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation February 2013