linaro-validation May 2012

linaro-validation@lists.linaro.org

21 participants
21 discussions

Is reboot necessary when andoid test timeout in lava

by YongQin Liu

Hi, Zach I am now working on a bp that adding the timeout process for android test action in lava. I am not sure if we should reboot the android image when the test run for a time longer than expected. so I'd like to know your opinion which you want to do. a. stop the test and restart the android image, then continue the next test b. stop the test and continue the next test c. others Like we submit a job to lava for running "monkey,glmark2,0xbench" test on android, while glmark2 test runs for a longer time than expected(like in which case if we don't stop it it will run for ever). In this case which one would you like? reboot the android and continue the next 0xbench test, or just stopped the glmark2 test and continue to run the next 0xbench test? Thanks, Yongqin Liu

12 years, 11 months

2012.05 planning: Move existing test defintions away from LAVA test to a dedicated project

by Zygmunt Krynicki

Hi, please have a look at [1] and discuss this on the mailing list. [1] https://blueprints.launchpad.net/lava-test/+spec/lava-test-dedicated-test-r… -- Zygmunt Krynicki Linaro Validation Team

12 years, 11 months

LAVA Core

by Zygmunt Krynicki

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I'd like to announce a new project in the LAVA family. (README file follows) http://xkcd.com/927/ Seriously, lava has way to many tiny pieces. It all started when we renamed launch-control to lava-dashboard and created lava-server in the process. Now it's getting in the way. So here we are, lava-core is the start of the merge. Subsequent projects will slowly merge into the core. Then one day we may just get a package that is called 'lava', that ships a program called 'lava' that does useful stuff. (End of readme file) The project has been registered on Launchpad already. I plan on proposing merge requests that move parts of the non-client pieces there. Existing projects shall remain as backwards compatible code imports from lava-core. Thanks ZK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPib6QAAoJEOvx/vtfL8ZXXgQP+QHhT/4beTTW7+yCFehDwe6i iDNZVPAhjrXxeh8TFisfdnPP+8z9khkcQTyXOgJnC3T4vbmWNBTjDQTpkSg/0lzS O8a0YBkcdQ5RPDr1NNiLG7PoAJDUts8yY2DXk2C1ykWmqOZBw7NcRVaX/gQ1Ym75 JODbrtcO1vT+E5rBNYiEgMEELStJZfMGbfGzFI+d4ONz702SJNVDHcY7FReKuTDc nvOZ8zfW03fHFNobAAR5F57lGBz6oLZjz/nblsCJjA9tf20LPsQTUxkv6EkkEyd1 0CTkjQt60kHQB/FYoxLofJ76CR12gGGNLauAf+fQPBa4CG5MvMsd7fdDbMVa3iZh MKzOv206SPTmB7GHRVTfTqoeFwsXNEc7CnFvEWA9GbCUboqBxuYnEw95m1137+/7 B3XHqsBmuJC1KJrwNIAFTl41oRuHchwEeZv72wBxoMU+4MKVpHFz6F0P3aR9da4s Uty9z+Nk8lUyQBGMOy6GMzqlPnNNYPM/v3f0CBZkA+D9mtdD/pFJGkhm/xmyE23S 5NskNi7CXZ+m+kyONAzL3JagLnB7PE+L8tHbap3IKbxkPbB5kzz/3eWqK6Evq+3t eQJZzuEq8gmIzyHVYjtnRvWXigv3m/vQrkcFC9Gs36tNXG0lEO07DbLpj3ZTlQ03 K+VSjvjsNhMvdhitIY7I =DKzA -----END PGP SIGNATURE-----

12 years, 11 months

Re: [Linaro-validation] omap2plus kernel CI hwpacks fails to boot

by Andy Doan

+1 the LAVA team On 05/11/2012 06:56 AM, Deepti Kalakeri wrote: > On Fri, May 11, 2012 at 4:19 PM, Venkatraman S <venkat(a)linaro.org > <mailto:venkat@linaro.org>> wrote: > > Checked that log. The boot log seems to be okay from the kernel. The > rootfs was mounted and fsck also succeeded. > > 2 interesting sections:- > > 1) mount: mounting udev on /dev failed: No such device > W: devtmpfs not available, falling back to tmpfs for /dev > > Do your scripts depend on udev ? > > > Not my scripts, but I guess the linaro-media-create used on LAVA does. Here's is a link to the scheduler's view of this, which is a little easier to read and has details like the job time out. http://validation.linaro.org/lava-server/scheduler/job/18287

13 years

Squid Analyzer

by Spring Zhang

Hi, I think we can deploy a Squid analyzer on the v.l.o, which will visualize the squid access log. Though it doesn't hit the big size tarball caching issue, but it's useful for the squid monitoring. I've deployed one on my own PC, seems cool. http://squidanalyzer.darold.net/<http://squidanalyzer.darold.net/install.html> -- Best wishes, Spring Zhang

13 years

release/production deployment

by Michael Hudson-Doyle

Closing out one of my 2012.05 items requires deploying lava-server and lava-scheduler, so I think I may as well release all components with interesting changes, make a 2012.04.1 bundle and update production to that. Here's the list of unreleased revisions: lava-android-test 0.4 1 unreleased revisions 157 merge with branch that add cache-coherency iozone memtester test lava-scheduler-tool 0.4 1 unreleased revisions 18 Add the lava-scheduler-tool command to go with the resubmit api (Paul Larson) lava-tool 0.4 1 unreleased revisions 175 Open 0.5 for development lava-test 0.7 4 unreleased revisions 148 fix bug 1002285: set DEBIAN_FRONTEND=noninteractive when installing test dependencies 147 Fix pwrmgmt test dependencies. 146 Merge support for bundle format version 1.3 145 Bump version to 0.8 dev lava-kernel-ci-views 0.4.0 no unreleased revisions lava-scheduler 0.13 5 unreleased revisions 170 Add support for looping of health care jobs 169 ensure job_summary_mail.txt is included in the sdist 168 add resubmit_job to the api (Paul Larson) 167 move static files around to be in line with what django.contrib.staticfiles expects 166 post release version bump lava-dashboard-tool 0.7 1 unreleased revisions 159 Open 0.8 for development lava-dashboard 0.15 1 unreleased revisions 314 merge with the Bug #877984 fix branch lava-dispatcher 0.7.1 5 unreleased revisions 298 skip raising exception when home screen if it is health check jobs 297 Fixed reboot issues 296 Add support to install extra debian packages from lava_test_install (Luis Araujo) 295 Added the config option LAVA_TEST_DEB, to allow the installation of lava-test with apt-get. (Rafael 294 post release bump lava-raven 0.1.1 no unreleased revisions lava-server 0.12 8 unreleased revisions 370 fix bug #1002526 by correcting the arguments to the {% url %} tag (Rafael Martins) 369 read SERVER_EMAIL from the settings.conf file 368 Display OpenID login forms only if OpenID auth is enabled (Jean-François Fortin Tam) 367 one more 1.4 thing, just a comment this time 366 more django 1.4ness: admin needs to be in STATICFILES_PREPEND_LABEL_APPS iff we are running before 1 365 another Django 1.4 compatibility thing: django.contrib.messages.middleware.MessageMiddleware is now 364 small fixes to work with django 1.4 363 bump version post release Does anything look particularly scary to anyone here? Note that it feels like it's time to upgrade to Django 1.4 now, which is a little scary -- but staging has been on 1.4 for weeks now. Cheers, mwh

13 years

HDMI capture tech & Mozilla's project Eideticker

by Michael Hudson-Doyle

Hi all, Earlier in the week in a call Loic mentioned that he had looked at a Mozilla/Boot2Gecko project that did HDMI capture and we could look at it for two reasons: 1) (the obvious) because we want to do HDMI capture ourselves, and 2) (slightly less obvious) to see how they specify tests that involve running code on a device and capturing data from an external source. I don't know if this is what he had in mind, but google found for me "project eideticker": https://wiki.mozilla.org/Project_Eideticker (the reason I'm not sure if this is what Loic had in mind is that it's more a Fennec/Firefox thing than a B2G thing). I haven't dug into the test specification side yet, but I did think this page was interesting: https://wiki.mozilla.org/Project_Eideticker/DeckLink_Primer IIRC, we had considered Blackmagic cards before (supported on Linux, relatively cheap). The limitations on this page look a bit less than ideal though... Anyway, interesting reading for you all. Cheers, mwh

13 years

job error - have you seen this before?

by Andy Doan

Something weird with job. The files should have been cached by Squid, but it looks like something odd happened when it tried to pull them: http://validation.linaro.org/lava-server/scheduler/job/20360/log_file any thoughts/ideas?

13 years

The future of lava-test

by Michael Hudson-Doyle

Multiple conversations over the last week have convinced me that lava-test, as it currently is, is not well suited to the way LAVA is changing. I should say that I'm writing this email more to start us thinking about where we're going rather han any immediate plans to start coding. The fundamental problem is that it runs solely on the device under test (DUT). This has two problems: 1) It seems ill-suited to tests where the not all of the data produced by the test originates from the device being tested (think power measurement or hdmi capture here). 2) We do too much work on the DUT. As Zygmunt can tell you, just installing lava-test on a fast model is quite a trial; doing the test result parsing and bundle formatting there is just silly. I think that both of these things suggest that the 'brains' of the test running process should run on the host side, somewhat as lava-android-test does already. Surprisingly enough, I don't think this necessarily requires changing much at all about how we specify the tests. At the end of the day, a test definition defines a bunch of shell commands to run, and we could move to a model where lava-test sends these to the board[1] to be executed rather than running them through os.system or whatever it runs now (parsing is different I guess, but if we can get the output onto the the host, we can just run parsing there). To actually solve the problems of 1 and 2 above though we will want some extensions I think. For point 1, we clearly need some way to specify how to get the data from the other data source. I don't have any bright ideas here :-) In the theme of point 2, if we can specify installation in a more declarative way than "run these shell commands" there is a change we can perform some of these steps on the host -- for example, stream installation could really just drop a pre-compiled binary at a particular location on the testrootfs before flashing it to the SD card. Tests can already depend on debian packages to be installed, which I guess is a particular case of this (and "apt-get install" usually works fine when chrooted into a armel or armhf rootfs with qemu-arm-static in the right place). We might want to take different approaches for different backends -- for example, running the install steps on real hardware might not be any slower and certainly parallizes better than running them on the host via qemu, but the same is emphatically not the case for fast models. Comments? Thoughts? Cheers, mwh [1] One way of doing this would be to create (on the testrootfs) a shell script that runs all the tests and an upstart job that runs the tests on boot -- this would avoid depending on a reliable network or serial console in the test image (although producing output on the serial console would still be useful for people watching the job).

13 years

time to move away from conmux?

by Michael Hudson-Doyle

Hi, After the last few days of poking at things, I think it's time to finally move fully away from conmux to a connection_command / hard_reset_command based approach. I think the actual config file mangling can be done with a short shell script. Although lava-core will fix this properly, I can spend a quick 10 minutes hacking up lava console and lava powerstab commands to get around the loss of easy conmux-console based command lines. Thoughts? Cheers, mwh

13 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation May 2012