Re: [llvm-dev] Timeout tests timing out

[Dan Liew]

Sorry I haven't had the time to dig into the issue but it looks
someone else already fixed it :)

On Thu, 3 Dec 2020 at 21:00, David Blaikie  wrote:
>
> This'll hopefully be addressed by https://reviews.llvm.org/D92563
>
> On Mon, Nov 30, 2020 at 6:28 AM Diana Picus  wrote:
>>
>> Ping again. We're seeing this on several aarch64 bots, what can we do about 
>> it?
>>
>> On Mon, 23 Nov 2020 at 21:19, David Blaikie via llvm-dev 
>>  wrote:
>>>
>>> Ping on this - Dan, any chance you could take a look here?
>>>
>>> On Mon, Nov 9, 2020 at 1:48 PM Arthur Eubanks  wrote:
>>> >
>>> > Another case: http://lab.llvm.org:8011/#/builders/43/builds/810
>>> > shtest-timeout.py seems to be fairly flaky on the 
>>> > clang-cmake-aarch64-quick bot: http://lab.llvm.org:8011/#/builders/43, I 
>>> > get notifications from it fairly often
>>> >
>>> > On Thu, Oct 22, 2020 at 7:15 PM David Blaikie via llvm-dev 
>>> >  wrote:
>>> >>
>>> >> Looks like there might still be some issues with the timeout tests? 
>>> >> http://lab.llvm.org:8011/#/builders/126/builds/226/steps/13/logs/FAIL__lit___shtest-timeout_py
>>> >>
>>> >> On Sun, Oct 4, 2020 at 2:44 PM Dan Liew  wrote:
>>> >>>
>>> >>> > > One thing we could do to remove fragility in the test is to remove 
>>> >>> > > the
>>> >>> > > running of `short.py` in the test. This is only invoked to check 
>>> >>> > > that
>>> >>> > > it's possible for a command to run to completion in the presence of 
>>> >>> > > a
>>> >>> > > fixed timeout. If we can live without testing that part (i.e. we 
>>> >>> > > only
>>> >>> > > test that a timeout can be reached) then the test should be much 
>>> >>> > > more
>>> >>> > > robust.
>>> >>> >
>>> >>> > If you're on board with that, it's a tradeoff I think is probably
>>> >>> > reasonable from a test coverage V reliability V development time
>>> >>> > tradeoff.
>>> >>>
>>> >>> Sorry for the delay here. I've put a patch up for review that goes
>>> >>> with this approach: https://reviews.llvm.org/D88807
>>> >>
>>> >> ___
>>> >> LLVM Developers mailing list
>>> >> llvm-...@lists.llvm.org
>>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending Dec. 6 2020

[Alex Bennée]

VirtIO Initiative ([STR-9])
===

  - started reviewing latest EPAM IOREQ/VirtIO patches Message-Id:
<1606732298-22107-1-git-send-email-olekst...@gmail.com>

VirtIO RPMB ([STR-5])
=

  - Continued working on Rust port of vhost-user-rpmb

VirtIO Portability Demo ([STR-13])
==

  - done and closed

QEMU Support for Xen ([STR-20])
===

  - re-based and continued to work on Xen development environment
- with my [current branch] I can now boot domU inside dom0
- also can now run qemu-aarch64 as a Dom0 PV backend

[current branch]



QEMU Device and Machine Models ([QEMU-418])
===

  - created new initiative for tracking work both in and outside group
- we don't want another watchdog duplication
  - worked on refining definition for [CPU model for QEMU]
- wrote to Linaro open discussion list to canvas members
  requirements Message-Id: <878saesi0x@linaro.org>


[CPU model for QEMU] 


QEMU Upstream Work ([UM-2])
===

  - posted [RFC PATCH] configure: add --without-default-features
Message-Id: <20201202153827.17446-1-alex.ben...@linaro.org>

Other work
==

  - bootstrapped gitdm metadata for GCC project


Completed Reviews [1/1]
===

[PATCH v4 00/11] hvf: Implement Apple Silicon Support
Message-Id: <20201203234857.21051-2-ag...@csgraf.de>

-- 
Alex Bennée
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain