From: Guenter Roeck <linux@roeck-us.net>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: QA: Monitor Linux log messages as port of release (candidate) testing
Date: Tue, 7 Sep 2021 08:28:08 -0700 [thread overview]
Message-ID: <0c445eca-4f15-f6a1-f098-64fe2c7d3c3a@roeck-us.net> (raw)
In-Reply-To: <6ff370ce-9905-b07e-99cf-4e2861d2872f@molgen.mpg.de>
Hi Paul,
On 9/7/21 8:18 AM, Paul Menzel wrote:
> Dear Guenter,
>
>
> Am 07.09.21 um 16:47 schrieb Guenter Roeck:
>
>> On Tue, Sep 07, 2021 at 03:50:39PM +0200, Paul Menzel wrote:
>
>>> Am 07.09.21 um 14:53 schrieb Guenter Roeck:
>>>> On Tue, Sep 07, 2021 at 10:40:31AM +0200, Paul Menzel wrote:
>>>
>>>>> Thank you for testing release candidates and releases [1]. Is your test
>>>>> setup documented somewhere?
>>>>>
>>>> Not really, except its source is available at github:
>>>> https://github.com/groeck/linux-build-test
>>>
>>> Thank you.
>>>
>>>>> If not happening already, could the Linux messages (at least up to log level
>>>>> warning) also be monitored? For example, in Linux 5.14, a new warning snuck
>>>>> in by cefc7ca462 (ACPI: PRM: implement OperationRegion handler for the
>>>>> PlatformRtMechanism subtype) [2], which could have been caught early on, and
>>>>> fixed before the release.
>>>>>
>>>>> The test summaries would then also notify about possible behavior change.
>>>>
>>>> Logs are available and can be examined at kerneltests.org/builders.
>>>
>>> Sorry for being blind. Under *qemu-tests*, looking at build #1831 [1],
>>> clicking on *stdio* [2] under *Steps and Logfiles*, I do not see any Linux
>>> logs.
>>>
>>>> Reports are generated manually, so it would be way too much effort to add
>>>> build warnings to those. Besides, logs are way too noisy to be useful in a
>>>> summary e-mail.
>>>
>>> Just to avoid misunderstandings, it’s about the Linux run-time logs.
>>
>> Run-time logs are only provided if there are errors or runtime issues
>> (crashes, warning tracebacks, or test failures).
>
> Could this be changed to always publish them? Or is that too demanding on storage?
>
It isn't a matter of storage, but of noise. It is mostly me looking at the data,
and I really don't want to see logs if nothing interesting is there. With 450+
builds per release I'd drown in noise otherwise. Sure, a large part of that
is a UI issue, but that is where systems like kernelci come in. If I ever
find the time to do it, I might report build and runtime results/logs to kernelci.
But that is a big IF.
>>>> Also, Geert's build reports already provide build warnings and errors.
>>>> The same applies to reports sent by 0-day. Indeed, I do see at least
>>>> one 0-day report against commit cefc7ca46235.
>>>
>>> How can I find that report?
>>>
>> I just searched for the SHA.
>>
>> https://www.spinics.net/lists/linux-acpi/msg101721.html
>
> Alright, that is a build time thing. I am looking for runtime things.
>
If there is nothing in my reports, you'd probably not find what you
are looking for (it would be reported if it results in a backtrace).
Guenter
prev parent reply other threads:[~2021-09-07 15:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-07 8:40 QA: Monitor Linux log messages as port of release (candidate) testing Paul Menzel
2021-09-07 12:53 ` Guenter Roeck
2021-09-07 13:50 ` Paul Menzel
2021-09-07 14:47 ` Guenter Roeck
2021-09-07 15:18 ` Paul Menzel
2021-09-07 15:28 ` Guenter Roeck [this message]
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=0c445eca-4f15-f6a1-f098-64fe2c7d3c3a@roeck-us.net \
--to=linux@roeck-us.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pmenzel@molgen.mpg.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;
as well as URLs for NNTP newsgroup(s).