xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org
Subject: [linux-linus bisection] complete build-arm64-pvops
Date: Mon, 05 Feb 2018 01:05:42 +0000	[thread overview]
Message-ID: <E1eiVE6-0005Jc-Nr@osstest.test-lab.xenproject.org> (raw)

branch xen-unstable
xenbranch xen-unstable
job build-arm64-pvops
testid kernel-build

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  23c35f48f5fbe33f68904138b23fee64df7d2f0f
  Bug not present: d3581c8ef718ae1b03e9106446ddf76b77026895
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118579/


  commit 23c35f48f5fbe33f68904138b23fee64df7d2f0f
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Feb 2 16:44:14 2018 -0800
  
      pinctrl: remove include file from <linux/device.h>
      
      When pulling the recent pinctrl merge, I was surprised by how a
      pinctrl-only pull request ended up rebuilding basically the whole
      kernel.
      
      The reason for that ended up being that <linux/device.h> included
      <linux/pinctrl/devinfo.h>, so any change to that file ended up causing
      pretty much every driver out there to be rebuilt.
      
      The reason for that was because 'struct device' has this in it:
      
          #ifdef CONFIG_PINCTRL
              struct dev_pin_info     *pins;
          #endif
      
      but we already avoid header includes for these kinds of things in that
      header file, preferring to just use a forward-declaration of the
      structure instead.  Exactly to avoid this kind of header dependency.
      
      Since some drivers seem to expect that <linux/pinctrl/devinfo.h> header
      to come in automatically, move the include to <linux/pinctrl/pinctrl.h>
      instead.  It might be better to just make the includes more targeted,
      but I'm not going to review every driver.
      
      It would definitely be good to have a tool for finding and minimizing
      header dependencies automatically - or at least help with them.  Right
      now we almost certainly end up having way too many of these things, and
      it's hard to test every single configuration.
      
      FWIW, you can get a sense of the "hotness" of a header file with something
      like this after doing a full build:
      
          find . -name '.*.o.cmd' -print0 |
              xargs -0 tail --lines=+2 |
              grep -v 'wildcard ' |
              tr ' \\' '\n' |
              sort | uniq -c | sort -n | less -S
      
      which isn't exact (there are other things in those '*.o.cmd' than just
      the dependencies, and the "--lines=+2" only removes the header), but
      might a useful approximation.
      
      With this patch, <linux/pinctrl/devinfo.h> drops to "only" having 833
      users in the current x86-64 allmodconfig.  In contrast, <linux/device.h>
      has 14857 build files including it directly or indirectly.
      
      Of course, the headers that absolutely _everybody_ includes (things like
      <linux/types.h> etc) get a score of 23000+.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


For bisection revision-tuple graph see:
   http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/build-arm64-pvops.kernel-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/build-arm64-pvops.kernel-build --summary-out=tmp/118579.bisection-summary --basis-template=118324 --blessings=real,real-bisect linux-linus build-arm64-pvops kernel-build
Searching for failure / basis pass:
 118566 fail [host=laxton1] / 118538 ok.
Failure / basis pass flights: 118566 / 118538
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Latest 617aebe6a97efa539cc4b8a52adccd89596e6be0 c530a75c1e6a472b0eb9558310b518f0dfcd8860
Basis pass 4bf772b14675411a69b3c807f73006de0fe4b649 c530a75c1e6a472b0eb9558310b518f0dfcd8860
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#4bf772b14675411a69b3c807f73006de0fe4b649-617aebe6a97efa539cc4b8a52adccd89596e6be0 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
Loaded 1213 nodes in revision graph
Searching for test results:
 118538 pass 4bf772b14675411a69b3c807f73006de0fe4b649 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118573 fail 23c35f48f5fbe33f68904138b23fee64df7d2f0f c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118572 pass d3581c8ef718ae1b03e9106446ddf76b77026895 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118556 fail 23c35f48f5fbe33f68904138b23fee64df7d2f0f c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118569 fail 23c35f48f5fbe33f68904138b23fee64df7d2f0f c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118578 pass d3581c8ef718ae1b03e9106446ddf76b77026895 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118567 pass 4bf772b14675411a69b3c807f73006de0fe4b649 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118570 pass b89e32ccd1be92a3643df3908d3026b09e271616 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118571 pass ef991796be0e65b644fe60198bd1112830eff173 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118566 fail 617aebe6a97efa539cc4b8a52adccd89596e6be0 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118574 fail 617aebe6a97efa539cc4b8a52adccd89596e6be0 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118575 pass d3581c8ef718ae1b03e9106446ddf76b77026895 c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118577 fail 23c35f48f5fbe33f68904138b23fee64df7d2f0f c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118579 fail 23c35f48f5fbe33f68904138b23fee64df7d2f0f c530a75c1e6a472b0eb9558310b518f0dfcd8860
Searching for interesting versions
 Result found: flight 118538 (pass), for basis pass
 Result found: flight 118566 (fail), for basis failure
 Repro found: flight 118567 (pass), for basis pass
 Repro found: flight 118574 (fail), for basis failure
 0 revisions at d3581c8ef718ae1b03e9106446ddf76b77026895 c530a75c1e6a472b0eb9558310b518f0dfcd8860
No revisions left to test, checking graph state.
 Result found: flight 118572 (pass), for last pass
 Result found: flight 118573 (fail), for first failure
 Repro found: flight 118575 (pass), for last pass
 Repro found: flight 118577 (fail), for first failure
 Repro found: flight 118578 (pass), for last pass
 Repro found: flight 118579 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  23c35f48f5fbe33f68904138b23fee64df7d2f0f
  Bug not present: d3581c8ef718ae1b03e9106446ddf76b77026895
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118579/


  commit 23c35f48f5fbe33f68904138b23fee64df7d2f0f
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Fri Feb 2 16:44:14 2018 -0800
  
      pinctrl: remove include file from <linux/device.h>
      
      When pulling the recent pinctrl merge, I was surprised by how a
      pinctrl-only pull request ended up rebuilding basically the whole
      kernel.
      
      The reason for that ended up being that <linux/device.h> included
      <linux/pinctrl/devinfo.h>, so any change to that file ended up causing
      pretty much every driver out there to be rebuilt.
      
      The reason for that was because 'struct device' has this in it:
      
          #ifdef CONFIG_PINCTRL
              struct dev_pin_info     *pins;
          #endif
      
      but we already avoid header includes for these kinds of things in that
      header file, preferring to just use a forward-declaration of the
      structure instead.  Exactly to avoid this kind of header dependency.
      
      Since some drivers seem to expect that <linux/pinctrl/devinfo.h> header
      to come in automatically, move the include to <linux/pinctrl/pinctrl.h>
      instead.  It might be better to just make the includes more targeted,
      but I'm not going to review every driver.
      
      It would definitely be good to have a tool for finding and minimizing
      header dependencies automatically - or at least help with them.  Right
      now we almost certainly end up having way too many of these things, and
      it's hard to test every single configuration.
      
      FWIW, you can get a sense of the "hotness" of a header file with something
      like this after doing a full build:
      
          find . -name '.*.o.cmd' -print0 |
              xargs -0 tail --lines=+2 |
              grep -v 'wildcard ' |
              tr ' \\' '\n' |
              sort | uniq -c | sort -n | less -S
      
      which isn't exact (there are other things in those '*.o.cmd' than just
      the dependencies, and the "--lines=+2" only removes the header), but
      might a useful approximation.
      
      With this patch, <linux/pinctrl/devinfo.h> drops to "only" having 833
      users in the current x86-64 allmodconfig.  In contrast, <linux/device.h>
      has 14857 build files including it directly or indirectly.
      
      Of course, the headers that absolutely _everybody_ includes (things like
      <linux/types.h> etc) get a score of 23000+.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Revision graph left in /home/logs/results/bisect/linux-linus/build-arm64-pvops.kernel-build.{dot,ps,png,html,svg}.
----------------------------------------
118579: tolerable ALL FAIL

flight 118579 linux-linus real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/118579/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-arm64-pvops             6 kernel-build            fail baseline untested


jobs:
 build-arm64-pvops                                            fail    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

             reply	other threads:[~2018-02-05  1:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-05  1:05 osstest service owner [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-04-02 22:38 [linux-linus bisection] complete build-arm64-pvops osstest service owner

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=E1eiVE6-0005Jc-Nr@osstest.test-lab.xenproject.org \
    --to=osstest-admin@xenproject.org \
    --cc=xen-devel@lists.xenproject.org \
    /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).