linaro-validation

linaro-validation@lists.linaro.org

818 discussions

by Andy Doan

Hey Guys, I've noticed my own Panda/Android jobs were failing. ex: <http://validation.linaro.org/lava-server/scheduler/job/17089> I've also noticed the official builds aren't working either: <http://validation.linaro.org/lava-server/scheduler/job/17092> I've personally booted my image, so I think we have a problem. Is anyone aware of this or looking into it already? -andy

14 years

[crazy] Novacom and novacomd for LAVA?

by Zygmunt Krynicki

Hi, random, _crazy_ idea. I've found two [1] [2] interesting artifacts from WebOS. We could consider using them as adb replacements for ubuntu. This could allow us to control master/test images with minimal footprint and without installing python (to do just that, we may still need python for other workloads). It seems to be able to connect over plain USB as well as over TCP/IP. [1] https://github.com/openwebos/novacomd [2] https://github.com/openwebos/novacom Best regards ZK -- Zygmunt Krynicki Linaro Validation Team

14 years

I gave the linaro team the testjob_add permission

by Michael Hudson-Doyle

We talked about this in our meeting last week. We should probably set up a lava-job-submitters team in Launchpad, but until we do I gave the permission to the group in lp. Cheers, mwh

14 years

lava-test - update ltp to 20120401

by Fathi Boudra

Hi, I prepared a merge request to update lava-test LTP test to the latest released version 20120401 [1]. However, the new LTP test suite hanged on creat08 and waitid02 tests when running on PandaBoard. Same tests don't hang and even pass successfully on Snowball. How do we proceed in this case? off-topic question, why don't we provide an up-to-date LTP package from Overlay PPA instead of building LTP on device during the test? Cheers, Fathi [1] https://code.launchpad.net/~fboudra/lava-test/update-ltp-test-20120104

14 years

Re: [Linaro-validation] deploy timeouts

by Fathi Boudra

On 20 March 2012 16:22, Dave Pigott wrote: > Hi, > > I think we need to seriously look at allowing a timeout parameter around > "deploy_linaro_image", because vexpress is going to need around 4 hours to > deploy a full desktop, and it seems crazy that we should hard code that big > a timeout into master.py for *all* platforms. > > I realise there is an issue as to which part the timeout is applied to and > how it's apportioned, but even if we just allowed to pass through the whole > timeout to each stage it would be better than what we have at the moment. > > Thoughts? Follow up to Dave initial thread, we didn't have reached a conclusion. He reported https://bugs.launchpad.net/lava-dispatcher/+bug/961926 Could we plan (and assign someone) to land a fix for this bug? Cheers, Fathi

14 years

De-emphasize serial connection for LAVA Dispatcher, introduce LAVA Master Agent, LAVA Test Agent

by Zygmunt Krynicki

I've registered another blueprint. This time on LAVA Dispatcher. The goal is similar as the previous blueprint about device manager, to gather feedback and to propose some small steps sub-blueprints that could be scheduled in 2012.04. The general goal is to improve the way we run tests by making them more reliable and more featureful (richer in state) at the same time. Please read and comment on the mailing list https://blueprints.launchpad.net/lava-dispatcher/+spec/lava-dispatcher-de-e… Thanks ZK -- Zygmunt Krynicki Linaro Validation Team

14 years

Re: [Linaro-validation] Pluggable LAVA bundle specification

by Zygmunt Krynicki

W dniu 30.03.2012 02:00, Michael Hudson-Doyle pisze: > On Thu, 29 Mar 2012 10:49:21 +0200, Zygmunt Krynicki <zygmunt.krynicki(a)linaro.org> wrote: >> W dniu 29.03.2012 06:36, Michael Hudson-Doyle pisze: >>> On Tue, 27 Mar 2012 23:10:37 +0200, Zygmunt Krynicki <zygmunt.krynicki(a)linaro.org> wrote: >>>> Hi. >>>> >>>> Another specification for the backlog and your feedback. Please read >>>> this as I'd like to move towards planning dependency blueprints (even if >>>> they also end up in a backlog). >>>> >>>> https://blueprints.launchpad.net/linaro-python-dashboard-bundle/+spec/plugg… >>> >>> Hi, >>> >>> Can you motivate this one a bit? It seems sort of vaguely reasonable >>> (although I feel the creeping horrors of SGML and DTDs and things on the >>> horizon), but I would like to know the problem you are solving here. >> >> I actually wanted to avoid SGML that feels to be slowly creeping in. The >> motivation is to allow the core format to remain small and lean and to >> allow users to experiment with custom data sets. For example, if I want >> to include accurate kernel data it could go into a linux-specific >> section. If I want to include apt/dpkg data it could go into a >> dpkg-specific section. Likewise if I want to include some trace / >> profiler data specific to my application I could create my own >> representation and store the data there. >> >> This goes hand in hand with plugs support in lava-test. I'd like to be >> able to say, run that test and capture this side band data with plugs A, >> B and C. Some ideas are: sampling CPU, memory, network and IO load, >> capturing GPU performance data, power measurement data. Capturing >> package data for non-apt systems. > > I like the idea in general, although I can't convince myself it's a > priority. It's not, it's pretty low now. I just need an excuse to release a new format with this big empty "plugs" dictionary that does not have additionalProperties: false. > I'm also not sure how some details will work in practice, like how would > the data associated with a plug be stored in postgres? Also > experimentation sort of implies versioning, would you have a version for > a plug, or would the diplay of older data sometimes break when you > install a new version of a plug? So you are right and the only solution is, we don't. We'll keep the raw data as it was provided. Specialized extensions can track any deserialized / denormalized / normalized models of that data. As for versions, we keep our current policy, every third party extension can do whatever the author desires, including shooting themselves in the foot if they want. We'll give people a sandbox to play in, I hope. ZK PS: CC-ing the list again -- Zygmunt Krynicki Linaro Validation Team

14 years

Deployment report/fallout

by Michael Hudson-Doyle

Hi, Just a quick note about today's deployment. The good news is that things are all working :) There were a few wrinkles along the way. A few were due to the fact that replacing which package provides a certain module (lava.utils.interface in this case, which moved from lava-server to its own package) appears to confuse things a bit. Once the new code was in place, I prepared to run health check jobs. I used the new admin action to mark all 'passing' boards as 'unknown' health state, cleared out /linaro/image enough to have plenty of disk space while the health jobs ran and then turned the scheduler back on. As desired, all boards started running health check jobs. This meant that there were 30 odd processes uncompressing disk images, loopback mounting them and tarring bits of them up -- load went up to 90, and stayed there for a few hours! Although the machine was still quite usable in this state, it's probably not a good situation. I filed a couple of bugs about this: https://bugs.launchpad.net/lava-scheduler/+bug/967849 https://bugs.launchpad.net/lava-dispatcher/+bug/967877 Thankfully, the large majority of health jobs passed. We had a few issues: 3 jobs on panda hit the serial truncation thing: http://validation.linaro.org/lava-server/scheduler/job/16932/log_file http://validation.linaro.org/lava-server/scheduler/job/16946/log_file http://validation.linaro.org/lava-server/scheduler/job/16956/log_file The last was a different command though -- "mount /dev/disk/by-label/testbo" -- could it be getting worse? 1 job on origen02 (had deployment time out for reasons that are not clear: http://validation.linaro.org/lava-server/scheduler/job/16961/log_file 1 job on origen03 failed: http://validation.linaro.org/lava-server/scheduler/job/16951 but because the board was spamming the serial line when the job started, I haven't actually loaded enough of the log to find the problem yet... (maybe we should hard reset the board when we terminate a badly behaving job?). Cheers, mwh

14 years

Fwd: Networking on the fast model

by Paul Larson

Here's the other way to do it... ---------- Forwarded message ---------- From: Vishal Bhoj <vishal.bhoj(a)linaro.org> Date: Tue, Mar 27, 2012 at 11:52 AM Subject: Fwd: Networking on the fast model To: Paul Larson <paul.larson(a)linaro.org>, Zygmunt Krynicki < zygmunt.krynicki(a)linaro.org> ---------- Forwarded message ---------- From: Dave Martin <dave.martin(a)linaro.org> Date: 22 March 2012 16:56 Subject: Networking on the fast model To: Vishal Bhoj <vishal.bhoj(a)linaro.org> git clone git://git.linaro.org/people/dmart/tunsetup.git cd tunsetup make sudo ./tunsetup -c -t tap -o `id -u` tap%d >/tmp/tunsetup.conf # ^ this creates a fake ethernet device which can be accessed by you . /tmp/tunsetup.conf -C motherboard.hostbridge.interfaceName=$TUN_IF Random link-local addresses are generated automatically. You can configure boot-time networking on the model by putting: ip=$TUN_REMOTEIP::$TUN_LOCALIP:$TUN_NETMASK ...on the kernel command line If you want to allow the model to talk to the Internet, you also need to enable NAT: sudo /bin/sh -c 'echo 1 >/proc/sys/net/ipv4/ip_forward' sudo iptables -t nat -A POSTROUTING -s $TUN_REMOTEIP -j MASQUERADE ...and copy/paste the contents of /etc/resolv.conf into the model filesystem's /etc/resolv.conf The IP and DNS setup stuff could be handled by having a local DHCP server, but I was too lazy to set that up... Let me know how you get on! Cheers ---Dave

14 years

Fwd: [Linaro-big-little] RTSM user networking support

by Paul Larson

Forwarded email 1/2 - usermode networking in android on fast models. This should cover 99% of what we want, unfortunately if you ever want to ping something, it will not work. ---------- Forwarded message ---------- From: Chris Redpath <Chris.Redpath(a)arm.com> Date: Thu, Mar 29, 2012 at 5:24 AM Subject: [Linaro-big-little] RTSM user networking support To: "linaro-big-little(a)lists.linaro.org" <linaro-big-little(a)lists.linaro.org > Hi all,**** ** ** I don’t know if its generally known about, but you can use user mode networking with models from v 7 onwards. There are some limitations and (at least in my experience so far) connections occasionally drop, but personally I could not configure TAP and a bridge without my desktop locking up, so it was a vast improvement for me. When it connects, ADB works over this connection and you can use that to set up other forwarding tunnels as necessary.**** ** ** More details at the arm infocenter here: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.arn0001a/index.… **** ** ** This is the setup I’ve been using:**** ** ** additional model command line options:**** -C motherboard.hostbridge.userNetworking=true -C motherboard.hostbridge.userNetPorts="5555=6565" -C motherboard.smsc_91c111.enabled=1**** ** ** adb options on guest os:**** (taken from https://wiki.linaro.org/Platform/Android/SetupAdbOverTcp - can be added to the init script too)**** stop adbd**** setprop service.adb.tcp.port 6565**** start adbd**** ** ** adb options on host OS:**** export ADBHOST=127.0.0.1**** sudo android-sdk-linux_x86/platform-tools/adb start-server**** adb connect localhost**** ** ** ** ** Best Regards,**** Chris**** -- 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. _______________________________________________ linaro-big-little mailing list linaro-big-little(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-big-little

14 years

← Newer
1
...
72
73
74
75
76
77
78
...
82
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation