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