From: Remi Duraffort <remi.duraffort@linaro.org>
Date: Tuesday, 19 February 2019 at 09:54
To: Diego Russo <Diego.Russo@arm.com>
Cc: Neil Williams <neil.williams@linaro.org>, "lava-users@lists.lavasoftware.org" <lava-users@lists.lavasoftware.org>
Subject: Re: [Lava-users] uboot ums flakiness

> On 8 Feb 2019, at 15:02, Neil Williams <neil.williams@linaro.org> wrote:
>
> On Fri, 8 Feb 2019 at 14:48, Diego Russo <Diego.Russo@arm.com> wrote:
>>
>> Hello,
>>
>> We've been using uboot-ums for WaRP7 but we've been having intermittent failures when it tried to run dd to flash the image.
>> Provided we need to look better into the root cause of this issue, we'd like to make the flashing phase a little more reliable.
>
> The fix for that would not seem to be within LAVA but within the
> firmware or the device.
>
>> I have few questions, coming from different angles:
>> * LAVA uses dd command to flash the image. Is there a way to specify the usage of bmap-tools?
>
> Not currently. It is set in
> https://git.lavasoftware.org/lava/lava/blob/master/lava_dispatcher/utils/storage.py#L54
>
> That could be looked at but bmap-tools isn't necessarily going to fix
> the problem with the hardware - it's trying to do something more
> complex and pushing things faster. What is the equivalent syntax?

We’ve seen bmap having less failure rate or at least it fails properly (dd instead just hangs)
The syntax is something similar

$ bmaptool copy image.wic.gz --bmap image.wic.bmap /dev/blockdevice

>
>> * let's say dd times out (this is what usually happen). Is there a mechanism to restart the actions (deploy and boot) in case of timeout?
>
> Not yet - there is related support in development to ensure that a
> timeout kills the process properly:
> https://git.lavasoftware.org/lava/lava/merge_requests/355
>
> However, a timeout on a deployment is still a fatal event. This isn't
> a third-party problem, as with downloads or creating an LXC, this is
> the device under test not being sufficiently reliable - that is a test
> job failure due to an infrastructure error. It's equivalent to TFTP
> timing out or fastboot failing to flash an image. LAVA is correctly
> halting at this point - the original test job will need to be
> resubmitted to attempt the deploy again before going on to a boot
> action. The solution for intermittent errors is not to ignore the
> error.

My intention is not to ignore errors, but to have a better re-try mechanism (instead of resubmit the whole job).

>
>>
>> If you have any other suggestion, let me know!
>>
>> Cheers
>> --
>> 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@lists.lavasoftware.org
>> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams@linaro.org
> http://www.linux.codehelp.co.uk/

--
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@lists.lavasoftware.org
https://lists.lavasoftware.org/mailman/listinfo/lava-users