All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <edubezval@gmail.com>
To: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Rui Zhang <rui.zhang@intel.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1
Date: Fri, 24 May 2019 06:54:00 -0700	[thread overview]
Message-ID: <20190524135358.GA2750@localhost.localdomain> (raw)
In-Reply-To: <CAAObsKB_CsPk5uFCCsQs+UD3EYzAwEAWZCiH1_L4t2rXmymjTQ@mail.gmail.com>

Hello,

On Fri, May 24, 2019 at 10:23:09AM +0200, Tomeu Vizoso wrote:
> On Fri, 24 May 2019 at 04:40, Eduardo Valentin <edubezval@gmail.com> wrote:
> >
> > On Thu, May 23, 2019 at 11:46:47AM +0200, Tomeu Vizoso wrote:
> > > Hi Eduardo,
> > >
> > > I saw that for 5.1 [0] you included a kernelci boot report for your
> > > tree, but not for 5.2. Have you found anything that should be improved
> > > in KernelCI for it to be more useful to maintainers like you?
> >
> > Honestly, I take a couple of automated testing as input before sending
> > my pulls to Linux: (a) my local test, (b) kernel-ci, and (c) 0-day.
> >
> > There was really no reason specifically for me to not add the report
> > from kernelci, except..
> > >
> > > [0] https://lore.kernel.org/lkml/20190306161207.GA7365@localhost.localdomain/
> > >
> > > I found about this when trying to understand why the boot on the
> > > veyron-jaq board has been broken in 5.2-rc1.
> > >
> >
> > I remember a report saying this failed, but from what I could tell from
> > the boot log, the board booted and hit terminal. But apparently, after
> > all reports from developers, the veyron-jaq boards were in a hang state.
> >
> > That was hard for me to tell from your logs, as they looked like
> > a regular boot that hits terminal.
> >
> > Maybe I should have looked for a specific output of a command you guys
> > run, saying "successful boot" somewhere?
> 
> I think what is easiest and clearest is to consider the bisection
> reports as a very strong indication that something is quite wrong in
> the branch.

OK. I hear you.

> 
> Because if a board stopped booting and the bisection found a
> suspicious patch, and reverting it gets the board booting again, then
> chances are very high that the patch in question broke that boot.
> 


Yeah, for sure If I had understood the report properly I could have
nacked the patch.

> Do you think the wording could be improved to make it clearer? Or
> maybe some other changes to make all this more useful to maintainers
> like you?
> 

Well, from my perspective, I need to judge if the failure on your report
is really related to my changes. Many times, specially on build errors,
we get failures that are unrelated. Build errors are more straight
forward do judge. Similarly, we need to find out if a boot issue is
caused by a change on the branch or something existing. On boot issues
from kernelci reports, I think the false negatives I have been seeing
is lab/boards failing to boot. Those can also be easy to spot as the
in most cases the kernel wont even load. 

For this particular case, as I described before, the kernel would
load and hit the shell command line, but in fact it was in hang state
IIRC. That is probably why it has not straight forward to understand
from the log. Maybe a successful boot message somewhere would have
helped to spot the problem (or the opposite of it, something
saying, I was expecting to execute a command and board was
unresponsive).


  reply	other threads:[~2019-05-24 13:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16  4:43 Eduardo Valentin
2019-05-16 15:07 ` Linus Torvalds
2019-05-16 16:11   ` Stefan Wahren
2019-05-17 12:25     ` Stefan Wahren
2019-05-16 16:55   ` Guenter Roeck
2019-05-24  2:37     ` Eduardo Valentin
2019-05-16 15:10 ` pr-tracker-bot
2019-05-23  9:46 ` Tomeu Vizoso
2019-05-24  2:40   ` Eduardo Valentin
2019-05-24  8:23     ` Tomeu Vizoso
2019-05-24 13:54       ` Eduardo Valentin [this message]
2019-05-27 11:26         ` Tomeu Vizoso

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=20190524135358.GA2750@localhost.localdomain \
    --to=edubezval@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=tomeu@tomeuvizoso.net \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.