linaro-validation

linaro-validation@lists.linaro.org

818 discussions

Start a nNew thread

Booting procedure of linaro test images.

by Prakash Ranjan

13 years, 4 months

How to access control from gateway?

by YongQin Liu

Hi, Andy I can log into gateway via command "ssh liuyq0307(a)validation.linaro.org", but how can I access the control from gateway? I run the following commands, but they failed: liuyq0307@linaro-gateway:~$ ssh control The authenticity of host 'control (192.168.1.10)' can't be established. RSA key fingerprint is 8d:cf:f3:19:40:94:99:9c:1d:f3:1d:b9:47:f7:c7:22. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'control' (RSA) to the list of known hosts. Permission denied (publickey). liuyq0307@linaro-gateway:~$ ssh liuyq@control Permission denied (publickey). liuyq0307@linaro-gateway:~$ ssh liuyq0307@control Permission denied (publickey). liuyq0307@linaro-gateway:~$ -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation

13 years, 5 months

Android black-box testing with lava-blackbox (aka android-lava-wrapper)

by Zygmunt Krynicki

Hey everyone. I'd like to interest you in my progress on black-box testing for Android. The relevant code lives in: 1) Github: https://github.com/zyga/android-lava-wrapper/tree/develop Note that the develop branch will soon land to master. Currently master is an unusable older copy. I will also rename this repository to lava-blackbox or lava-android-blackbox (to be determined later) 2) Launchpad: https://code.launchpad.net/~zkrynicki/lava-android-test/blackbox This branch is almost ready to land. I will finish the details tomorrow or on Monday. The project history and up-to-date status is in this blueprint: https://blueprints.launchpad.net/linaro-android/+spec/aosp-tests-on-jb You can observe the latest results I've produced this way here: http://validation.linaro.org/lava-server/dashboard/streams/anonymous/zyga/b… Best regards ZK -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/

13 years, 5 months

dashboard_app on staging

by YongQin Liu

Hi, All The dashboard on staging seems use the test-run-filter-subscription, but it seems have problem. when access the following url: http://staging.validation.linaro.org/dashboard/streams/private/team/linaro/… I got the following errors so I will change it to use the trunk branch of lavadashboard for staging. -------------------------------LOG on Page Cause local variable 'test_run' referenced before assignment Deserialization failure traceback Traceback (most recent call last): File "/home/instance-manager/test-run-filter-subscription/dashboard_app/models.py", line 496, in deserializebundle_was_deserialized.send(sender=self,bundle=self) File "/srv/lava/.cache/eggs/Django-1.4.1-py2.7.egg/django/dispatch/dispatcher.py", line 172, in sendresponse=receiver(signal=self,sender=sender,**named) File "/home/instance-manager/test-run-filter-subscription/dashboard_app/models.py", line 1946, in send_bundle_notificationsrecipients=TestRunFilterSubscription.recipients_for_bundle(bundle) File "/home/instance-manager/test-run-filter-subscription/dashboard_app/models.py", line 1925, in recipients_for_bundlematches=TestRunFilter.matches_against_bundle(bundle) File "/home/instance-manager/test-run-filter-subscription/dashboard_app/models.py", line 1875, in matches_against_bundlematch.test_run=test_runUnboundLocalError: local variable 'test_run' referenced before assignment ------------------------------- -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation

13 years, 5 months

improving usability of the bundle detail view

by Andy Doan

I was looking into improving the bundle detail view today. At first I thought this would be easy, but I'm wondering if my ideas are just going to be worse. Some background. Take a view like: http://tinyurl.com/9bhkud5 For those without proper permission you roughly have a table like: <test run> <test> <passes> <fail> ..... "wifi-enablement results" wifi-enablement 28 2 "perf results" perf 3 5 "lava results" lava 19 1 .... There are a couple of problems with this: 1) people have always been confused by "lava results". ie - whether or not lava was actually able to perform a test run. 2) The "why doesn't this table include testXXX" question. Where the answer is look at "lava results" and it shows testXXX failed to run. My current thought is to update the table to include all the "lava_test_install (XXX)" test cases from the lava_results run that have failed. This way they show up (maybe bolded or highlighted in some way). Thoughts on that? I worry the approach is going to be a bit too hard-coded. ie, you have to query something like: models.TestResult.objects.filter( test_run = b.test_runs.filter(test__test_id='lava') ).exclude( result=0 ) You might even want to add test_case__test_case_id__contains='lava_test' to the exclude filter. Which means we are hard coding for "lava" as a test id and "lava_test*" as test cases.

13 years, 5 months

Health checks

by Dave Pigott

----------------- beaglexm02 ----------------- http://validation.linaro.org/lava-server/scheduler/job/29737 Absolutely enormous log file. The board was in a very strange state, spewing out loads of exceptions. Went onto the board and it was still throwing out exceptions. Did a hard reset and it came back cleanly. Not clear why hard reset didn't work from the LAVA session. Put back online to retest. ------------ origen04 ------------ http://validation.linaro.org/lava-server/scheduler/job/28745 Failed to get root.tgz. I may be missing something, but if you look at http://validation.linaro.org/lava-server/scheduler/job/28745/log_file#entry… you'll see that it says it's waiting 60 seconds to retry, but doesn't seem to actually retry. Anyone any ideas? Put back online to retest -------------------------------------- panda01-05/09/10/12/14-23 -------------------------------------- http://validation.linaro.org/lava-server/scheduler/job/29825 (as an example) This is just odd. It says it couldn't get the android artefact (http://validation.linaro.org/lava-server/scheduler/job/29825/log_file#entry…) but it doesn't appear to have even issued a wget! Looking at the time stamps, something happened between 14:00UTC and 20:00UTC that stopped things working. Whatever it was, I'm retesting panda01 to see if it went away, or if (as I suspect) all the other boards will fail when they run their health check. ---------------- panda-es01 ---------------- http://validation.linaro.org/lava-server/scheduler/job/29548 Looks like the master image got corrupted somehow. I'll reflash the sd card. ---------------- snowball02 ---------------- http://validation.linaro.org/lava-server/scheduler/job/29617 wget timeout on system for android. Put back online to re-test. Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years, 5 months

Re: [Linaro-validation] origen10 on staging is damaged

by YongQin Liu

Hi, Dave Could you help to recreate the master image of origen10 when you get on line today? Thanks, Yongqin Liu On 14 August 2012 18:37, YongQin Liu <yongqin.liu(a)linaro.org> wrote: > I run mkfs.ext3 -L testrootfs /dev/mmcblk0p6 on the master, > not know if this works. > > Thanks, > Yongqin Liu > > On 14 August 2012 18:19, YongQin Liu <yongqin.liu(a)linaro.org> wrote: >> Hi, All >> >> origen10 on staging need to be recreated. >> >> here is the job >> http://staging.validation.linaro.org/scheduler/job/25433/log_file >> and in the job there is following error: >> >> Gave up waiting for root device. Common problems: >> - Boot args (cat /proc/cmdline) >> - Check rootdelay= (did the system wait long enough?) >> - Check root= (did the system wait for the right device?) >> - Missing modules (cat /proc/modules; ls /dev) >> ALERT! /dev/disk/by-label/testrootfs does not exist. Dropping to a shell! >> >> >> -- >> Thanks, >> Yongqin Liu >> --------------------------------------------------------------- >> #mailing list >> linaro-android(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-android >> linaro-validation(a)lists.linaro.org >> http://lists.linaro.org/pipermail/linaro-validation > > > > -- > Thanks, > Yongqin Liu > --------------------------------------------------------------- > #mailing list > linaro-android(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-android > linaro-validation(a)lists.linaro.org > http://lists.linaro.org/pipermail/linaro-validation -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation

13 years, 5 months

Re: [Linaro-validation] [PATCH] Run panda jobs on 4430 and 4460

by Dave Pigott

On 20 Aug 2012, at 15:48, Andy Doan wrote: > On 08/17/2012 02:34 PM, Paul Larson wrote: >> Andy recommended splitting this into a reversion of the previous tag >> handling patch, and the new stuff. Here's the result. > > +1 for me. Ricardo - you want me to merge this? OK, so two jobs are in the system that are a bit odd: http://validation.linaro.org/lava-server/scheduler/job/29811 - LT-TI-working-tree_panda-es-omap4plus_20120821-0058_daily test It's not caught up with the fact that panda-es is a new device type, and not a device tag any more And http://validation.linaro.org/lava-server/scheduler/job/29823 - https://android-build.linaro.org/jenkins/job/linaro-android_panda-jb-gcc47-… Which is not a panda-es issue, but has specifically been targeted at panda09. Anybody know why that might be? Thanks Dave

13 years, 5 months

LAVA Virtual Connect Follow-up

by Andy Doan

In response to the connect session: http://pad.linaro.org/lava-test-next-gen I've put together a phased plan with Michael that will hopefully address the major points raised. Please let us know if you have comments/questions/concerns/etc. The first phase of the approach will simply be getting this new "lava-test-shell" action working for FastModel on Android with the bigLITTLE test suite. As you'll see below, the idea's a little more baked for the stand-alone usage, but it should give us enough flexibility for host/test-buddy interactions in the future. I'm also inlining some Michael question/answer notes that should help this make more sense. LAVA Test Shell =============== lava-test-shell is a lightweight application that can execute test suites in a way that works well with the LAVA architecture, specifically the lava-dispatcher. //MWHUDSON: I presume lava-test-shell would already be installed in the images we test? //DOANAC: ultimately, however for now, I think including this code in the dispatcher and adding it to the FM image will be the best way to sort things out initially, There are two modes this can be used under, stand-alone and host->target. Under most cases, the shell can run as a simple standalone application on the target device under test. However, for some tests may require host-side side interactions which can be run with a host->target approach. Stand-alone Usage ----------------- Basic usage to execute a test suite: lava-test-shell --output_dir <output directory> [test args to run] Basic usage to send signal to host: lava-test-shell --signal <SIGNAL_NAME> Basic usage to create hardware and software context info files needed by LAVA for bundle results: lava-test-shell --output_dir <output directory> --hwcontext --swcontext Host->Target Usage ------------------ The host->target usage is done by launching a server on the target: lava-test-shell --server The server code on the target will then await the host's commands. The usage will be the same as the stand-alone usage but will use: "--target <ip>:<port>" bigLITTLE Example ----------------- The dispatcher JSON action will look like: { "command": "lava_test_shell", "parameters": { "cmd": "/usr/bin/run_stress_switcher_tests.sh -a", "pattern": "(?P<test_case_id>.*-*)\s+:\s+(?P<result>(PASS|FAIL))", "etc_part_no": 2, "timeout": OPTIONAL, "num_reboots": OPTIONAL(do we allow this to reboot and how many) } } The customization logic in our deploy (android/ubuntu) actions will ensure we have the proper system modification to launch lava-test-shell with the proper arguments after the system has booted. //MWHUDSON: So, to be clear, as far as a job submitter is concerned, lava-test-shell is an implementation detail? //DOANAC: Yes - just wanted to outline the mechanics of how this works. Ubuntu might be an upstart job that reads the etc file created by the lava_test_shell action above, while Android could do something similar as well. //MWHUDSON: How will we handle boot failure? //DOANAC: I think we'll have to make it a failed result in the "lava_results" bundle similar to how we currently do for a lava-test-run action. After setting the etc file, the dispatcher will boot the device and wait for: * the lava-test-shell binary to send a signal over serial saying the command has completed. * the timeout has occurred * num_reboots has occurred -andy

13 years, 5 months

About the ValidationError on all test build

by YongQin Liu

Hi, All Most of the jobs submitted today will have the following error: ERROR: Test execution error: ValidationError: Object has incorrect type (expected string) object_expr='object.test_runs[0].attributes.run_options', schema_expr='schema.properties.test_runs.items.properties.attributes.additionalProperties.type') This is caused by this bug: https://bugs.launchpad.net/lava-android-test/+bug/1037936 And I have fixed it and merged it into the branch. Hi, Andy when you are on line, could you help to deploy the latest lava-android-test to production, then the above problem should not occur again. -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org http://lists.linaro.org/pipermail/linaro-validation

13 years, 5 months

← Newer
1
...
61
62
63
64
65
66
67
...
82
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation