linaro-validation August 2014

linaro-validation@lists.linaro.org

17 participants
18 discussions

by Senthil Kumaran

# Progress # * Bug #211 - Bundle export needs to handle User.DoesNotExist * Bug #173 - Unclear reporting of parameterised tests * Code reviews * bugs / debugging - 50% * code reviews - 50% # Plan # * Continue with pending cards and bugs -- Senthil Kumaran http://www.stylesen.org/ http://www.sasenthilkumaran.com/

10 years, 5 months

Re: [Linaro-validation] Observed diff between how dd'ing juno.img and using linaro-android-media-create...

by Jon Medhurst (Tixy)

On Fri, 2014-08-08 at 16:08 +0100, Varun Sarwal wrote: > Hi all, > > >> But basically, if you want bigger partitions, I would just say use linaro-android-media-create (l-a-m-c), and if you specifically want a raw disk image to test, use l-a-m-c to create one (using the --image-file --image-size options instead of '--mmc /dev/sdX'). > > So I used this command to create bigger partitions: > > linaro-android-media-create --image-file /dev/sdb --image-size 6G --dev vexpress --boot boot.tar.bz2 --system system.tar.bz2 --userdata userdata.tar.bz2 (see attached image) > > However, the USB flash drive continues to have partitions as observed before (attached image) , and Android can see only 488 MB of internal memory. I think we may have been talking about different things. I guess by 'internal memory' means free space on the 'userdata' partition. Basil was saying that the prebuilt image gave him 14GB unallocated space, and using l-a-m-c with the three tarballs used all the disk which is what he wanted, and asked for the prebuilt images to be the same. However, the extra disk space get's allocated to the last 'sdcard' partition and doesn't change the sizes of the other partitions. Those are hardcoded in l-a-m-c I believe. -- Tixy

10 years, 5 months

Observed diff between how dd'ing juno.img and using linaro-android-media-create...

by Basil Eljuse

Hello All, Not sure if this is the right forum to raise this issue we observed. If not please redirect me to the right place. Problem observed:: With Juno release we have the option for creating a media device from the juno.img.bz2 or from the 3 tar balls provided for the android image. When I try to create the image from juno.img.bz2 and try to install a 'huge' benchmark apk like GFXBench3.0 (100+MB size apk and uses larger space on disk while execution too) it fails with disk space not sufficient error. Even if I use a 16GB usb device I hit this problem. Some interesting details:: Please see the attached screen shots. The first one is where I have the got the 16GB media formatted. When I use linaro-android-media-create then can see sdcard partition extending the remaining of the space on the disk. But if you look at the dd'ing 2.1GB juno image I can see 14GB shown as 'Unallocated. Please note that if I use linaro-android-media-create I never hit this problem of lack of space when GFXBench3.0 Any clue? Is this a bug? Is there a way juno.img can be made to 'have larger space'? Thanks Basil Eljuse... -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

10 years, 5 months

Juno android builds fails to locate lava-test-runner...

by Basil Eljuse

Hello All, I was trying to extend the use of LAVA for the execution of bigLITTLE test suites on Juno. I used both 14.06 and 14.07 builds from Linaro. However I get the following failure at the point where lava-test-shell is executing. root@linaro# /data/lava-lava-juno-butterfree/bin/lava-test-runner /data/lava-lava-juno-butterfree/bin/lava-test-runner /data/lava-l <ava-juno-butterfree /system/bin/sh: /data/lava-lava-juno-butterfree/bin/lava-test-runner: No such file or directory root@linaro# Guessing from the message it looks to me that the android builds for Juno does not have needed lava components packaged. Can anyone please confirm my assessment? Also how do we go about fixing this. Is this a LAVA issue or a builds issue? Naresh / Milosz, could you help? Thanks Basil Eljuse... -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782

10 years, 5 months

Re: [Linaro-validation] lava-tool

by Neil Williams

What distribution are you using? It looks like RHEL. lava-tool is in Debian: https://packages.debian.org/jessie/lava-tool and thereby in Ubuntu Utopic Unicorn. All of the dependency information is on that page. Currently, LAVA has no support for RHEL and we haven't found anyone who can prepare and maintain any of the LAVA packages for RHEL or Fedora. (We've asked various people and groups so far.) It looks like the xmlrpc support in RHEL does not match that available in Debian or Ubuntu. The actual source code for xmlrpclib as installed on Debian is here: http://sources.debian.net/src/python2.7/2.7.8-3/Lib/xmlrpclib.py That doesn't appear to have changed and has the same parse_response support. It sounds like this could actually be a problem in the URL handling code within python on RHEL. Details of python version already in Debian: 2.7.8-3 https://packages.debian.org/jessie/python2.7 What you can do is use the RHEL tools to create a Debian chroot or a VM. It is also possible to use XMLRPC directly, once a token has been created which may help reduce the amount of code involved: #!/usr/bin/python import xmlrpclib import json token = "<REPLACE_YOUR_TOKEN>" user = "<REPLACE_YOUR_USERNAME>" filename = "<REPLACE_JSON_FILE_PATH>" with open(filename, 'r') as file: config = json.load(file) server = xmlrpclib.ServerProxy("http://%s:%s@validation.linaro.org/RPC2/" % (user, token)) job_id = server.scheduler.submit_job(json.dumps(config)) print job_id Other XMLRPC calls can also be made to verify if the XMLRPC connection itself is working: https://validation.linaro.org/api/help/ Antonio is no longer part of Linaro, he has started a job working for the Brazilian government. He is still contactable via Debian but his Linaro email address will fail at some point. In terms of the right place for queries, Linaro Validation <linaro-validation(a)lists.linaro.org> would still be the correct place for this enquiry. Choosing people based on recent commits can be unreliable as those people may well simply be making minor updates to the setup of the package and not the package code itself. On 6 August 2014 13:57, Dean Arnold <Dean.Arnold(a)arm.com> wrote: > Hi Neil/Antonio, > > if lava-tool isn't something you are familiar with, please feel free to fob me off to somebody else. I just chose you as I saw you had made commits in git.linaro.org :) > > Do you know which version of python it is recommended to run lava-tool against please? I have installed version 0.11.1 along with python 2.7 but when attempting to run the auth-add command I am getting the following error.. > > $ lava-tool auth-add http://pdswauto@pdsw-lava.cambridge.arm.com > Paste token for http://pdswauto@pdsw-lava.cambridge.arm.com/RPC2/: > Traceback (most recent call last): > File "/arm/tools/python/lava-tool_py2.7/0.11.1/rhe6-x86_64/bin/lava-tool", line 9, in <module> > load_entry_point('lava-tool==0.11.1', 'console_scripts', 'lava-tool')() > File "build/bdist.linux-x86_64/egg/lava_tool/dispatcher.py", line 49, in main > File "build/bdist.linux-x86_64/egg/lava/tool/dispatcher.py", line 153, in run > File "build/bdist.linux-x86_64/egg/lava/tool/dispatcher.py", line 143, in dispatch > File "build/bdist.linux-x86_64/egg/lava_tool/commands/auth.py", line 102, in invoke > File "/arm/tools/python/python/2.7/rhe6-x86_64/lib/python2.7/xmlrpclib.py", line 1224, in __call__ > return self.__send(self.__name, args) > File "/arm/tools/python/python/2.7/rhe6-x86_64/lib/python2.7/xmlrpclib.py", line 1570, in __request > verbose=self.__verbose > File "build/bdist.linux-x86_64/egg/lava_tool/authtoken.py", line 91, in request > File "/arm/tools/python/python/2.7/rhe6-x86_64/lib/python2.7/xmlrpclib.py", line 1449, in parse_response > if response.getheader("Content-Encoding", "") == "gzip": > AttributeError: addinfourl instance has no attribute 'getheader' > > having had a quick google about, a few places have mentioned changes to xmlrpclib in Python 2.7 which may have caused this. Do you know if lava-tool works fine with python 2.6? Alternatively.. if I am just doing something stupid and this is nothing to do with the version, please let me know. > > Sorry if this is a daft question > Dean > > -- 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. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

10 years, 5 months

[Activity] Week #31

by Senthil Kumaran

# Progress # * LAVA-1192: Archive LAVA log files older than a time limit. * LAVA-1320: Archive root directory * LAVA-1321: Adjust UI to show job file is archived * Fix bug #210 - Omit retired devices from Devices passes health .. * kvm-pipeline example reviewed * Code reviews * Cards - 40% * bugs / debugging - 20% * code reviews - 40% # Plan # * Continue with pending cards and bugs -- Senthil Kumaran http://www.stylesen.org/ http://www.sasenthilkumaran.com/

10 years, 5 months

Re: [Linaro-validation] "Not enough permissions" to check lava Dashboard

by Neil Williams

Correct, you do not automatically have permissions to view all reports. Which parts of dashboard are you trying to view? A list is much more useful than a picture. Please ask your team lead about which reports you should be able to access for team requirements. On 4 Aug 2014 07:03, "Chase Qi" <chase.qi(a)linaro.org> wrote: > Hi, > > I can't check lava dashboard, prompted not enough permissions. Please > refer to the picture attached for more details. Anybody can help me solve > this problem? > > > Thanks, > Chase > >

10 years, 5 months

Re: [Linaro-validation] LAVA and s/w requirements

by Neil Williams

On 31 July 2014 14:44, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > Hi there, > > Do any of you fine people fancy talking to Liam at ARM about how to get a > new board set up in LAVA and about what he has to do? > > You can go direct to him or I can loop you into the email chain if you let > me know who to put in the firing line ;-) > The linaro-validation mailing list is the best place: Linaro Validation <linaro-validation(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-validation. > Hi Ryan, apologies I know you’re probably not the right person, but I’m > hoping you can put us in contact with the right guy. ... mailing list. > What I wanted to know (any maybe use TC2 as an example) is what s/w is > required to me running on a target platform for LAVA to work? > > Do you need Linux running, do you need DVFS, power gating supported etc. LAVA being written by Linaro is heavily based around the Linux kernel, so a kernel image with a CI loop outside LAVA to build new kernels is going to be the first thing. DVFS is not required, unless if the test writer (you) is going to want results relating to DVFS. Similar with power gating. Hardware wise, a serial connection is absolute - and it needs to not be interrupted or cause bootloader interference when the board is hard reset remotely. (LAVA will pull the power without warning and without using any on-board support from time to time. The board must react smoothly to these resets.) If all you are doing is booting a kernel, that is all that LAVA stipulates. To do more complex testing, some amount of writeable media connectivity, working ethernet support, a distribution with POSIX compatibility and a command line shell are going to be useful. LAVA developers don't write the tests for the boards in LAVA, those will need to be designed and tested by whoever wants the test results. Everything else that may become necessary is down to what tests need to run on the board. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

10 years, 5 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation August 2014