Hi all,
I'm running CTS tests on Android 9, with LAVA.
I noticed the CTS module CtsUsbTests failed because of the error:
"usb serial != adb serial expected:<[]> but was:<[a266fa0a5c85d6ee]>"
This module is a hostsidetest, and checks if usb serial matches adb serial
by running "lsusb -v" on the host and checking the iSerial returned by the
command. (
https://android.googlesource.com/platform/cts/+/refs/heads/master/hostsidet…
)
And this test fails when I run it with LAVA so I checked on my local PC and
the test passes. Indeed, if I run the command "lsusb -v" I get this output
for iSerial:
iSerial 3 351d5a0a5c85d936
The third field is the adb serial, so it matches well.
So I suspected the LXC container to not give the usb serial. So I checked
directly in the container and after running "lsusb -v" I got:
iSerial 3
The adb serial is missing.
So, do you know a way to make the LXC see correctly the usb serial ?
Regards,
Axel
Hello,
We've been using uboot-ums deploy mechanism for quite some time but we really want to move away from dd and star using bmap-tools.
I guess lava does not support it (yet) but I was wondering if there is a way where we can use uboot-ums with bmap-tools.
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
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.
Right, it is not the first time I ask a similar question (I did ask it last February) and a lava issue has been created: https://git.lavasoftware.org/lava/lava/issues/234
Unfortunately there are no progress on this and actually it has been removed from the milestones.
Can we ask to reconsider it? (
Cheers
-----Original Message-----
From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> on behalf of Diego Russo <Diego.Russo(a)arm.com>
Date: Tuesday, 6 August 2019 at 13:32
To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org>
Subject: [Lava-users] uboot-ums with bmap-tools
Hello,
We've been using uboot-ums deploy mechanism for quite some time but we really want to move away from dd and star using bmap-tools.
I guess lava does not support it (yet) but I was wondering if there is a way where we can use uboot-ums with bmap-tools.
Thanks
--
Diego Russo | Staff Software Engineer | Mbed Linux OS
ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom
http://www.diegor.co.uk - https://os.mbed.com/linux-os/
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.
_______________________________________________
Lava-users mailing list
Lava-users(a)lists.lavasoftware.org
https://lists.lavasoftware.org/mailman/listinfo/lava-users
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.
Hello LAVA experts,
I have a device which can boot up to android/linux.
The device is connected with two USB cables.
One USB cable is used for flashing images (fastboot flash) and doing some adb shell commands. Via another USB cable, I can use minicom to check uart logs and directly interact with the device (/dev/ttyUSB0).
Can you share some examples (jobs, job definitions) or configurations (like ser2net conf) or any suggestion for doing below test steps on my device with LAVA?
Scenario 1:
1. Flash images using fastboot
2. After android boots up or linux boots up, reboot and then stop at uboot
3. Do some tests in uboot.
Scenario 2:
1. Flash images using fastboot
2. After android boots up or linux boots up, interact with the device via uart (/dev/ttyUSB0) (suppose adb is disconnected)
3. Do some tests via uart.
Best regards,
Kingboli
Hi all,
I cancelled a test job but it still running on my device and showing testjob state as "cancelling". Is there any way to restart the device ,so that I can submit some other job .
Killing the specific job id on lava-master using lava-cli also not solving the problem.
Regards,
Smita Gumansingh
[cid:image001.jpg@01D2E5A8.A6033460]
Senior test Engineer, EPS PBU Software QA/Dev Ops
Mentor Graphics,
Nalapad Brigade Centre, Unit No:301 & 302
Mahadevapura, Bengaluru, Karnataka 560048, India
Office: +91 8067624338 |Cell: +91 9538349245
www.mentor.com<http://www.mentor.com/>
Hi all,
Our lava instance has been upgraded from 2019.03 to 2019.07 today.
Some of our teams need extra job context variables to be allowed, so I
added in /etc/lava-server/settings.conf the following parameter, as
described in one of your releases:
EXTRA_CONTEXT_VARIABLE: ["variable_1", "variable_2", "variable_3"]
It seems to work, but when I want to submit a job, sometimes I get the
warning "extra key not allowed" and if I hit the button "validate" many
times I finally get "valid definition". But sometimes I get "valid
definition" directly.
Is it a known issue?
Best regards,
Axel
Hello,
if the prompt is "# " without more characters then in the lava job
definition you have to put "# ".
In fact, this won't work well because this string can be seen on other
places (like kernel logs).
The only solution here would be to change the prompt of the root filesystem
to make it a bit more unique.
Rgds
Le mer. 31 juil. 2019 à 13:53, Hemanth K V <kv.hemanth.mys(a)gmail.com> a
écrit :
> Hello Remi,
>
> First of all Thanks for support.Trying for matching the string "# "
> If we don't specify any escape or brackets then it is matching one of the
> kernel message logs and sending the username .Following is reference of
> auto_login defined in yaml.
> ***** hwi path: hwi version/minor get_device_info->hwi_get_value: read
> STRING value:
> device name Matched prompt #4: #
>
> auto_login:
> login_prompt: "buildroot login:"
> username: root
> password_prompt: "Password:"
> password: root
> prompts:
> - '# '
>
> On including escape it is waiting for
> auto-login-action: Wait for prompt ['\\(# \\)', 'Login incorrect', 'Login
> timed out'] (timeout 00:07:53). Following is reference of auto_login
> defined in yaml.
>
> auto_login:
> login_prompt: "buildroot login:"
> username: root
> password_prompt: "Password:"
> password: root
> prompts:
> - '\(# \)'
>
> Thanks,
> Hemanth.
>
> On Wed, Jul 31, 2019 at 3:25 PM Remi Duraffort <remi.duraffort(a)linaro.org>
> wrote:
>
>> Hello,
>>
>> which strin are you trying to match? " #", "#", "# "?
>> Just put that (without any escaping or brackets) in the list of prompts.
>>
>> Rgds
>>
>> Le mar. 30 juil. 2019 à 14:20, Hemanth K V <kv.hemanth.mys(a)gmail.com> a
>> écrit :
>>
>>>
>>> Hello Lava Users,
>>>
>>> The target on which I am trying to run tests from LAVA has # prompt
>>> after login.
>>> As specified in Documentation
>>> https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro…
>>>
>>> - boot:
>>> prompts:
>>> # escape the brackets to ensure that the prompt does not match
>>> # kernel debug lines which may mention initramfs
>>> - '\(initramfs\)'
>>>
>>> in the job definition I am including -
>>> boot:
>>> .....
>>> failure_retry: 4
>>> prompts:
>>> - '\(# \)'
>>>
>>> But in the job execution log getting "*auto-login-action: Wait for prompt ['\\(# \\)', 'Login incorrect', 'Login timed out'] (timeout 00:07:52)*".
>>>
>>> Also if we want to debug while running the job which will be the best possible approach to follow.
>>> In the Documentation got information on "Debugging Django issues" which states two settings are required in/etc/lava-server/settings.conf
>>>
>>>
>>> - "DEBUG": true,
>>> - "USE_DEBUG_TOOLBAR": true,
>>>
>>> Thanks,
>>> Hemanth.
>>>
>>> _______________________________________________
>>> Lava-users mailing list
>>> Lava-users(a)lists.lavasoftware.org
>>> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>>
>>
>>
>> --
>> Rémi Duraffort
>> LAVA Team, Linaro
>>
>
--
Rémi Duraffort
LAVA Team, Linaro
Hello Lava Users,
The target on which I am trying to run tests from LAVA has # prompt after
login.
As specified in Documentation
https://lava.collabora.co.uk/static/docs/v2/actions-boot.html?highlight=pro…
- boot:
prompts:
# escape the brackets to ensure that the prompt does not match
# kernel debug lines which may mention initramfs
- '\(initramfs\)'
in the job definition I am including -
boot:
.....
failure_retry: 4
prompts:
- '\(# \)'
But in the job execution log getting "*auto-login-action: Wait for
prompt ['\\(# \\)', 'Login incorrect', 'Login timed out'] (timeout
00:07:52)*".
Also if we want to debug while running the job which will be the best
possible approach to follow.
In the Documentation got information on "Debugging Django issues"
which states two settings are required
in/etc/lava-server/settings.conf
- "DEBUG": true,
- "USE_DEBUG_TOOLBAR": true,
Thanks,
Hemanth.
Hello Denis,
in the timeouts dictionary, you can specify a connections dictionary.
So something like this should work:
timeouts:
connections:
overlay-unpack:
minutes: 10
See
https://docs.lavasoftware.org/lava/actions-timeout.html#connection-timeout
Le mer. 24 juil. 2019 à 14:30, Denis HUMEAU <denis.humeau(a)st.com> a écrit :
> Hi Rémi,
>
>
>
> Where do you set a connection timeout? In the job, in the device
> description?
>
> I didn’t find anything explicit in LAVA help.
>
>
>
> Denis
>
>
>
> *From:* Remi Duraffort <remi.duraffort(a)linaro.org>
> *Sent:* mercredi 24 juillet 2019 14:23
> *To:* Denis HUMEAU <denis.humeau(a)st.com>
> *Cc:* Lava-users(a)lists.lavasoftware.org
> *Subject:* Re: [Lava-users] overlay-unpack timeout error
>
>
>
> Hello Denis,
>
>
>
> have you tried settings the connection timeout? IIRC lava is expecting the
> board to send something and will timeout if not receiving anything during
> "connection timeout" seconds.
>
>
>
>
>
> Rgds
>
>
>
> Le mar. 23 juil. 2019 à 08:58, Denis HUMEAU <denis.humeau(a)st.com> a
> écrit :
>
> Hello Rémi,
>
>
>
> Here is a plain log corresponding to the case described by Philippe.
>
> Let me know if you need more.
>
>
>
> Denis
>
>
>
> *From:* Lava-users <lava-users-bounces(a)lists.lavasoftware.org> *On Behalf
> Of *Remi Duraffort
> *Sent:* lundi 22 juillet 2019 17:42
> *To:* Philippe BEGNIC <philippe.begnic(a)st.com>
> *Cc:* Lava-users(a)lists.lavasoftware.org
> *Subject:* Re: [Lava-users] overlay-unpack timeout error
>
>
>
> Hello Philippe,
>
>
>
> could you send the raw logs?
>
>
>
>
>
> Rgds
>
>
>
> Le ven. 19 juil. 2019 à 09:34, Philippe BEGNIC <philippe.begnic(a)st.com> a
> écrit :
>
> Hello everyone,
>
>
>
>
>
> I have got an error in a lava job during to overlay unpacking operations.
>
>
>
> This happen with jobs that flash the DUT before executing the tests. When the partitions are flashed on the DUT, I reboot the boards.
>
>
>
> After kernel has started, the kernel boot prompt is detected. Then the commands to downloads the tests overlay are launched. ( wget ... )
>
> But in my case, these commands are not immediately executed, because the DUT is beeing resizing the root filesystem to fit available disk space
>
> on the SDCard.
>
>
>
> This operation take time ( depending on capacity and characteristics of the SDCard), and cause overlay-unpack <https://citools.st.com/results/testcase/2039053> to fail with a timeout error,
>
> because the command wget is not executed in the expected time ( 30 sec is the default time ).
>
>
>
> I have tried to add a time out settings in the transfer_overlay part of my jobs, but this has no effect.
>
>
>
>
>
> Is it possible to set specific "timeout trigger" for the "overlay-unpack" operation ?
>
>
>
> My Lava version: *2019.01+stretch*
>
>
>
> Best regards
>
>
>
> Philippe Begnic
>
> STMicroelectronics
>
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.lavasoftware.org
> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
>
> --
>
> Rémi Duraffort
>
> LAVA Team, Linaro
>
>
>
>
> --
>
> Rémi Duraffort
>
> LAVA Team, Linaro
>
--
Rémi Duraffort
LAVA Team, Linaro
