public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets
Date: Mon, 4 Dec 2017 10:30:06 -0500	[thread overview]
Message-ID: <20171204153006.GF3587@bill-the-cat> (raw)
In-Reply-To: <fdcad4f1-8e7e-4c58-51f9-2a17ffca3d09@xilinx.com>

On Mon, Dec 04, 2017 at 03:21:04PM +0100, Michal Simek wrote:
> On 4.12.2017 15:03, Tom Rini wrote:
> > On Mon, Dec 04, 2017 at 02:55:45PM +0100, Michal Simek wrote:
> >> On 1.12.2017 23:44, Tom Rini wrote:
> >>> On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:
> >>>> On 12/01/2017 08:19 AM, Michal Simek wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 1.12.2017 16:06, Heinrich Schuchardt wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 12/01/2017 03:46 PM, Michal Simek wrote:
> >>>>>>> Qemu for arm32/arm64 has a problem with time setup.
> >>>>>>
> >>>>>> Wouldn't it be preferable to fix the root cause?
> >>>>>
> >>>>> Definitely that would be the best and IIRC I have tried to convince our
> >>>>> qemu guy to do that but they have never done that.
> >>>>
> >>>> What is the exact failure condition? Is it simply that the test is still
> >>>> slightly too strict about which delays it accepts, or is sleep outright
> >>>> broken?
> >>>>
> >>>> You can use command-line option -k to avoid some tests. For example "-k not
> >>>> sleep". That way, we don't have to hard-code the dependency into the test
> >>>> source. Depending on the root cause (issue in U-Boot, or issue in just your
> >>>> local version of qemu, or something that will never work) this might be
> >>>> better?
> >>>
> >>> Even with the most recent relaxing of the sleep test requirements, I can
> >>> still (depending on overall system load) have 'sleep' take too long, on
> >>> QEMU.  I think it might have been half a second slow, but I don't have
> >>> the log handy anymore.  Both locally and in travis we -k not sleep all
> >>> of the qemu instances.
> >>
> >> ok. By locally do you mean just using -k not sleep?
> > 
> > Yes, I have that in my CI scripts and similar.
> 
> Wouldn't be easier to keep this in uboot-test-hooks repo with other
> target setting?

Or do as you did did and mark the tests as not allowed for qemu, yes.

> What we are trying to do is that our testing group will run these tests
> for me that's why it is just easier for me to change local
> uboot-test-hooks repo instead of communicate with them what -k not XXX
> parameters to add to certain scripts.
> 
> It means in loop they will just run all tests on qemu, local targets and
> in boardfarm. It is probably not big deal to tell them to add -k not
> sleep for all qemu runs but I know that for some i2c testing qemu
> doesn't emulate these devices that's why these tests fails. And the
> amount of tests which we shouldn't run on qemu will probably grow.

Well, I'm still open to possibly tweaking the allowed variance in the
sleep test.  OTOH, if we just say "no QEMU" here, we can then go back to
"sleep should be pretty darn accurate on HW" for the test too, and
perhaps that's best.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171204/fd43c499/attachment.sig>

  reply	other threads:[~2017-12-04 15:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 14:46 [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets Michal Simek
2017-12-01 15:06 ` Heinrich Schuchardt
2017-12-01 15:19   ` Michal Simek
2017-12-01 17:07     ` Stephen Warren
2017-12-01 22:44       ` Tom Rini
2017-12-04 13:55         ` Michal Simek
2017-12-04 14:03           ` Tom Rini
2017-12-04 14:21             ` Michal Simek
2017-12-04 15:30               ` Tom Rini [this message]
2017-12-04 17:14                 ` Stephen Warren
2017-12-04 23:21                   ` Tom Rini
2017-12-05 18:20                     ` Stephen Warren
2017-12-05 18:38                       ` Tom Rini
2017-12-05 20:46                         ` Daniel Schwierzeck
2017-12-06  9:49                         ` Michal Simek
2017-12-05 12:10                   ` Michal Simek
2017-12-05 15:13                     ` Tom Rini
2017-12-06  9:53                       ` Michal Simek
2017-12-06 12:17                         ` Tom Rini
2017-12-08 13:08                           ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171204153006.GF3587@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox