Re: xen | Failed pipeline for staging | b5b2f987

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 13/02/2025 21:18, Stefano Stabellini wrote:
> 
> 
> On Thu, 13 Feb 2025, Jan Beulich wrote:
>> On 13.02.2025 15:18, GitLab wrote:
>>>
>>>
>>> Pipeline #1669696445 has failed!
>>>
>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>> Branch: staging ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>>
>>> Commit: b5b2f987 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/commit/b5b2f9877a8777af6b78944407527e0a450389a2
>>>  )
>>> Commit Message: x86/HVM: use XVFREE() in hvmemul_cache_destroy(...
>>> Commit Author: Jan Beulich ( https://gitlab.com/jbeulich )
>>>
>>>
>>> Pipeline #1669696445 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/pipelines/1669696445 ) 
>>> triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>>> had 1 failed job.
>>>
>>> Job #9129817480 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/jobs/9129817480/raw )
>>>
>>> Stage: test
>>> Name: xilinx-smoke-dom0less-arm64-gcc-debug-gem-passthrough
>>
>> >From the log I can't spot what it is that failed. Stefano, given it's a
>> Xilinx test, any idea or hint?
> 
> Hi Jan,
> 
> Thank you for bringing this to our attention. Michal also mentioned it
> to us this morning.
> 
> As far as we can tell, it appears to be a transient networking
> issue. Specifically, U-Boot on the board was unable to successfully
> complete the TFTP transfer from the TFTP server. We are not sure why
> this happened, but everything is functioning properly again.
> 
> I have been considering whether switching to a TCP-based protocol might
> be a better approach. In any case, we are still investigating the root
> cause, but for now, everything is working again.

Issues with TFTP transfer in U-BOOT are difficult to debug because even if one
u-boot command fails, it proceeds to execute the following ones. That's bad. I
think we either need to set timeout retry to a very high value (> test timeout)
or add support in ImageBuilder to separate commands with && to fail on first
error. This will at least help the observer to easily spot the issue is network
related.

~Michal