public inbox for kernelci@lists.linux.dev
 help / color / mirror / Atom feed
From: "Kevin Hilman" <khilman@baylibre.com>
To: kernelci@groups.io, guillaume.tucker@gmail.com,
	kernelci@groups.io, Guillaume Tucker <guillaume.tucker@gmail.com>
Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Subject: Re: Baseline test plan and bootrr
Date: Thu, 14 Feb 2019 11:51:20 -0800	[thread overview]
Message-ID: <7hpnruno7b.fsf@baylibre.com> (raw)
In-Reply-To: <CAH1_8nCtNfBQwO=o3GCLfcrCc2L9==zRafZaULRT-5kwo995Kw@mail.gmail.com>

"Guillaume Tucker" <guillaume.tucker@gmail.com> writes:

> On Thu, Feb 7, 2019 at 6:55 PM Guillaume Tucker via Groups.Io
> <guillaume.tucker=gmail.com@groups.io> wrote:
>
>> Hi,
>>
>> Currently, boot tests entirely rely on the LAVA logic to detect
>> when a login prompt has been reached.  While this mostly works,
>> it does not guarantee that the platform is actually usable or
>> that everything went smoothly during the boot.
>>
>> For this reason, it would seem useful to introduce a "baseline"
>> test plan which would essentially boot and then do some fast
>> checks to verify that nothing is obviously broken.  This can
>> include things like grepping the kernel log for any errors and
>> checking that drivers have been initialised correctly.  There's a
>> lot that can be done in a few seconds with a basic ramdisk.
>>
>>
>> So we could have a list of regular expressions to detect any
>> issues in the kernel log and report a LAVA test case result for
>> each of them.  The log fragment associated with each match should
>> also be available to include the actual errors in a report.
>> Doing this on the device means we keep the test definition in the
>> same location as the other test plans, and we can run it like any
>> test suite.
>>
>
> Any thoughts on this part?  Does anyone see any issue with having
> a series of patterns to grep the kernel log and have a test case
> result for each of them in LAVA? (i.e. pass if pattern was not
> matched...)

I think this is a good idea.

The difficulty comes in looking for device/board specific stuff, but
that shouldn't stop us from doing something generic that looks for the
obvious stuff.

It could also look for (and count) kernel errors, warnings, backtraces,
etc. etc.

Kevin

  reply	other threads:[~2019-02-14 19:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <158129CBC2E3B0B8.7959@groups.io>
2019-02-12 13:46 ` Baseline test plan and bootrr Guillaume Tucker
2019-02-14 19:51   ` Kevin Hilman [this message]
2019-05-02 11:27     ` Guillaume Tucker
2019-02-07 18:54 Guillaume Tucker
2019-02-07 19:49 ` Anibal Limon
2019-02-11 13:16 ` Tomeu Vizoso
2019-02-11 17:18   ` eballetbo
2019-02-12  6:52     ` Tomeu Vizoso
2019-02-12 12:33       ` Mark Brown
2019-02-12 13:41       ` Guillaume Tucker

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=7hpnruno7b.fsf@baylibre.com \
    --to=khilman@baylibre.com \
    --cc=enric.balletbo@collabora.com \
    --cc=guillaume.tucker@gmail.com \
    --cc=kernelci@groups.io \
    /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