linaro-validation April 2012

linaro-validation@lists.linaro.org

13 participants
22 discussions

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, 6 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, 6 months

test data location

by Andy Doan

I noticed today while looking at a merge proposal that we store some test data files for LAVA on the wiki[1]. I'm sure that was chosen because it works and its easy to manage. However, I'm not a huge fan of this for a few reasons: * easy to delete an attachment * Moin provides no revision control over attachments * I took this job to get out of the wiki business :) I was thinking of two alternate ways to manage our data files: 1. Create something on people.linaro.org like the toolchain team did[2]. 2. Create something like validation.linaro.org/testdata Seems like option 1 is the easiest and has been done before. Any opinions? 1: https://wiki.linaro.org/TestDataLinkPage 2: http://people.linaro.org/~toolchain/

12 years, 7 months

identifying USB devices

by Michael Hudson-Doyle

Part of the whole SD card mux game involves finding the card reader the SD card for a particular board is plugged into. Following a lead provided by Zygmunt, it seems that you can address devices by USB topology by looking in /sys/bus/usb/devices/ -- for example, the front right USB port on my laptop seems to correspond to a directories called "1-1.2" and "1-1.2:1.0" in here, the back left port corresponds to "3-1" and "3-1:1.0" and a particular port on a USB hub plugged into the front left USB port seems to correspond to "2-1.2.3" and "2-1.2.3:1.0". So this seems to be reasonably straightforward (although I don't know if the mapping is necessarily stable across reboots or kernel upgrades -- seems like it should be though). The next fun is mapping this directory to a block device. Poking finds that (with the card reader plugged into the last location mentioned above) the directory at: /sys/bus/usb/devices/2-1.2.3:1.0/host31/target31:0:0/31:0:0:0/block/ contains a directory called 'sdb' and indeed the sd card is mounted as /dev/sdb. Playing around shows that the 31 here is a number that gets incremented each time you plug/unplug the reader (or maybe any USB device). So this suggests that we could address the card reader in this port as "2-1.2.3:1.0" and to e.g. run l-m-c targetting the card in the reader, we should look at /dev/$(ls /sys/bus/usb/devices/${address}/host*/target*/*:0:0:0/block) which seems like it would work but frankly also seems like a total hack. Do any of you know if this can be done in a cleaner way? Cheers, mwh

12 years, 8 months

RFC Patch: lava with no media files

by Andy Doan

I was trying to get my local LAVA instance to work with our lab's data base dump. So I had the DB, but not all the media files. LAVA almost works when you do this, but I hit two small issues that prevented me from looking at bundle streams and it their test runs. I realize this is an edge case, but its handy for when you want to test with a real database, but don't want all the media files. I'm not sure this is the exact way we want to fix this, so rather than do a merge proposal I thought I'd get your thoughts on the patch first. There were two main issues in the code: bundle_detail wants to get the "document format" for the media file associated with the bundle. Since the file didn't exist we hit an exception. I added a small check to the get_document_format to handle this by returning "n/a". bundle_detail and test_run_detail wanted to display the size of media files. This calls a new function content_size which will catch an error if the file doesn't exist and simply return 0. I'm not sure if this patch is doing to good a job of hiding the fact an error does exist. Maybe we should put a conditional in the template file to display an error when the file doesn't exist also? -andy

12 years, 8 months

master boot image and uboot commands

by Andy Doan

I've been setting up a local LAVA lab on my home network. I've used the lava-deployment-tool and lava-master-image-scripts to get my Beagle hooked up. I'm really close to having everything work. However, when I submit a job I hit a problem with the soft-reboot logic not being able to instruct u-boot to use the test image. I'm flashing a 12.01 pre-built nano image, but I don't think that matters. I think the real issue might be something with a newer uboot being used by the linaro-master-image-script and the device.conf for beagle not having the right stuff. Has anyone else run into this or have suggestions? I tried briefly updating the .conf file for beagle, but it didn't seem to stick. It almost looked like we were sending the commands before u-boot was ready, but that may just be how the output is displayed. -andy

12 years, 8 months

FYI: new disable suspend mechanism

by Andy Doan

The Android team has a new app that can disable suspend on a device: http://lists.linaro.org/pipermail/linaro-android/2012-April/000723.html It can be enabled with commands like: am start -W -a android.intent.action.MAIN -n \ com.android.disablesuspend/.DisableSuspendActivity input keyevent 61 #key code for <TAB> input keyevent 66 #key code for <Enter> Looking at the changes we made to support this[1], I wonder if this new method is safer. On the one hand this requires a change, and the change requires us to start an application. This seems slower. On the other hand, we are currently making sqlite3 calls and such that seem a bit dangerous. Thoughts? 1: http://bazaar.launchpad.net/~linaro-validation/lava-dispatcher/trunk/revisi…

12 years, 8 months

tjbench result

by YongQin Liu

Hi, Andy In the attached tjbench.tgz file, there are two files: tjbench_job.json tjbench_result.json tjbench_job.json is the job file I used, I defined 7 tjbench actions in that file. and tjbench_result.json is the result of the job, I use lava-dashboard-tool to get it from my local lava environment. you can use put to upload it to your lava serve to see the result. Thanks, Yongqin Liu

12 years, 8 months

Re: [Linaro-validation] UI driven test framework for Android

by Paul Larson

On Thu, Mar 22, 2012 at 9:26 AM, Le.chi Thu <le.chi.thu(a)linaro.org> wrote: > Hi Paul, > > I have worked with a UI driven test framework for Android earlier in > STE and would like to use it for Linaro Android test (ok from STE > side). We modified the code from open source TEMA project to work with > ICS and would like to upload it the changes to the community. > > I created a blueprint for that > https://blueprints.launchpad.net/lava-test/+spec/ui-drive-test-for-android > to has time to do it. > Can you tell me how this differs from monkey runner? Sounds similar, and Yongqin is already working on monkeyrunner support. > > Please priority. > > Here is the blueprints I would like to work with in next cycle and the > highest first > > * health-check-job-vexpress (very small task) > * Include STE kernel test suite in LAVA and CI > The above two are good ones, I know the STE kernel suite has some issues to sort out wrt building though. > * ui-drive-test-for-android > See above question. > * manually-health-check > What is this about?

12 years, 8 months

Fwd: How to integrate Connectivity Manager Test to LAVA?

by YongQin Liu

---------- Forwarded message ---------- From: Botao Sun <botao.sun(a)linaro.org> Date: 5 April 2012 20:31 Subject: Re: How to integrate Connectivity Manager Test to LAVA? To: YongQin Liu <yongqin.liu(a)linaro.org> Cc: Paul Larson <paul.larson(a)linaro.org>, Abhishek Paliwal < abhishek.paliwal(a)linaro.org>, linaro-android <linaro-android(a)linaro.org> Hi Yongqin, Yes, if the support for android command on android-build can be done, that will be cool. However, I'm afraid the Android team wants this test can be integrated as soon as possible, and I won't work on this since I'm not in Android team anymore. Basically I will provide some solutions or figure out a way to do something, but won't do it by myself except in some special conditions. Therefore, if LAVA team can do this, I will be very appreciated. I agree with you about re-pack an apk is not a good idea. This is just a temporary walk around way to do it, once we have an unique SSID for this test, the source code of this test apk will be modified, then the repacking work will be gone. This test is new to us, and nobody has deep knowledge about the source code inside. So there may be more changes in future according to our research. Thank you for your help! BR Botao Sun On Thu, Apr 5, 2012 at 10:18 PM, YongQin Liu <yongqin.liu(a)linaro.org> wrote: > Hi, Botao > > On 5 April 2012 17:06, Botao Sun <botao.sun(a)linaro.org> wrote: > >> Hi Yongqin, >> >> 1. Yes, it's already built in all Android images. >> >> 2. I think it should be submitted by android-build. >> >> I guess you can see > http://bazaar.launchpad.net/~linaro-validation/lava-android-test/trunk/view… for > a reference. > and write a wrapper like that for lava-android-test > > If you are not urgent, I think you can wait util the support for android > command on android-build, > then you don't need to write the simple wrapper again. > The discussion about it is now doing with the thread titled "Syntax for > custom LAVA tests", this will be implemented in this cycle. > > There is a configuration file may need to be modified to >> keep corresponding with the SSID information in the test command, and you >> may need to re-pack this apk after that. Abhishek did it yesterday and you >> can get more details from his side. >> >> > This is a cross platform apk, so once you finish the repacking, then you >> can re-install it on all our boards. >> > I don't think repacking a apk is a good way. > > https://wiki.linaro.org/Platform/QA/TestCases/Android#android-net- > ConnectivityManagerTest > In the above wiki, I saw you can pass the ssid to the "am instrument", so > I guess you can also pass it to lava from android-build page. > > Thanks, > Yongqin Liu > >> >> FYI. >> >> Thank you! >> >> >> BR >> Botao Sun >> >> >> On Thu, Apr 5, 2012 at 2:07 PM, YongQin Liu <yongqin.liu(a)linaro.org>wrote: >> >>> Hi, Botao >>> >>> First I have some questions about this. >>> >>> 1. is the ConnectivityManagerTest.apk is built into the android image by >>> default? >>> 2. is the test job submitted by android-build or by another system of >>> you QA Service Team? >>> >>> Thanks >>> Yongqin Liu >>> >>> On 4 April 2012 19:57, Botao Sun <botao.sun(a)linaro.org> wrote: >>> >>>> Hi Yongqin, >>>> >>>> Recently I'm investigating the Connectivity Manager test, and I finally >>>> summarized a command list here: >>>> >>>> >>>> https://wiki.linaro.org/Platform/QA/TestCases/Android#android-net-Connectiv… >>>> >>>> However, I have no idea about how to integrate it to our LAVA system. >>>> The analysis of source code can be found in attachment of this email. Would >>>> you provide some information about it? >>>> >>> >>>> Abhishek runs this apk manually, and I will analyze the output once he >>>> sends to me. >>>> >>>> Thank you for your help! >>>> >>>> >>>> BR >>>> Botao Sun >>>> >>> >>> >> >

12 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation April 2012