Tests: 991 Failed: 13 Passed: 978 Build: next-20170627 Details: https://qa-reports.linaro.org/lkft/linux-next/build/next-20170627
kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git kernel-describe: next-20170627 build-url: https://ci.linaro.org/job/openembedded-lkft-linux-next/DISTRO=rpb,MACHINE=hi... kernel-commit: 89a39f3c7086301342175c461c4db43c68d34cc7 kernel-version: git kernel-branch: master series: lkft
Regressions (compared to build next-20170626) ------------------------------------------------------------------------
(none)
Failures ------------------------------------------------------------------------
hi6220-hikey:
* kselftest/ftracetest -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* kselftest/owner
* kselftest/raw_skew
* kselftest/test_maps -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* kselftest/test_execve -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* kselftest/pstore_tests
* kselftest/pidns
* kselftest/test_verifier -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* kselftest/test_kmod.sh -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* kselftest/test_lru_map -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* ltp-syscalls-tests/pselect01_64 -- failing since build next-20170623, from June 24, 2017, 7:37 a.m.
* ltp-syscalls-tests/add_key02 -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
* ltp-syscalls-tests/runltp_syscalls -- failing since build next-20170622, from June 23, 2017, 6:54 p.m.
All changes (compared to build next-20170626) ------------------------------------------------------------------------
+--- next-20170626, hi6220-hikey | +--- next-20170627, hi6220-hikey | | n/a pass kselftest/bitmap.sh n/a pass kselftest/cpu-on-off-test.sh n/a pass kselftest/efivarfs.sh n/a pass kselftest/execveat n/a fail kselftest/ftracetest n/a pass kselftest/fw_filesystem.sh n/a pass kselftest/fw_userhelper.sh n/a pass kselftest/get_size n/a pass kselftest/gpio-mockup.sh n/a pass kselftest/inconsistency-check n/a pass kselftest/kcmp_test n/a pass kselftest/membarrier_test n/a pass kselftest/memfd_test n/a pass kselftest/mqueue-lat n/a pass kselftest/msgque_test n/a pass kselftest/nanosleep n/a pass kselftest/nsleep-lat n/a fail kselftest/owner n/a pass kselftest/peeksiginfo n/a fail kselftest/pidns n/a pass kselftest/posix_timers n/a pass kselftest/printf.sh n/a pass kselftest/pstore_post_reboot_tests n/a fail kselftest/pstore_tests n/a fail kselftest/raw_skew n/a pass kselftest/rtctest n/a pass kselftest/run_afpackettests n/a pass kselftest/run_netsocktests n/a pass kselftest/run_numerictests n/a pass kselftest/run_stringtests n/a pass kselftest/run_vmtests n/a pass kselftest/sas n/a pass kselftest/seccomp_bpf n/a pass kselftest/set-timer-lat n/a pass kselftest/step_after_suspend_test n/a pass kselftest/sync_test n/a pass kselftest/test_bpf.sh n/a fail kselftest/test_execve n/a fail kselftest/test_kmod.sh n/a fail kselftest/test_lru_map n/a fail kselftest/test_maps n/a pass kselftest/test_static_keys.sh n/a pass kselftest/test_user_copy.sh n/a fail kselftest/test_verifier n/a pass kselftest/threadtest n/a pass kselftest/zram.sh pass n/a libhugetlbfs/HUGETLB_ELFMAP_-HUGETLB_MINIMAL_COPY_no-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_ELFMAP_R-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_ELFMAP_RW-HUGETLB_MINIMAL_COPY_no-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_ELFMAP_RW-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_ELFMAP_W-HUGETLB_MINIMAL_COPY_no-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_ELFMAP_W-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_ELFMAP_no-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHARE_0-HUGETLB_ELFMAP_R-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHARE_0-HUGETLB_ELFMAP_RW-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHARE_0-HUGETLB_ELFMAP_W-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHARE_1-HUGETLB_ELFMAP_R-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHARE_1-HUGETLB_ELFMAP_RW-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHARE_1-HUGETLB_ELFMAP_W-linkhuge_rw-2M-64 pass n/a libhugetlbfs/HUGETLB_SHM_yes-shmoverride_linked-2M-64 pass n/a libhugetlbfs/HUGETLB_VERBOSE_0-linkhuge_nofd-2M-64 pass n/a libhugetlbfs/HUGETLB_VERBOSE_1-HUGETLB_MORECORE_yes-heap-overflow-2M-64 pass n/a libhugetlbfs/HUGETLB_VERBOSE_1-empty_mounts-2M-64 pass n/a libhugetlbfs/HUGETLB_VERBOSE_1-large_mounts-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libheapshrink_so-HUGETLB_MORECORE_SHRINK_yes-HUGETLB_MORECORE_yes-heapshrink-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libheapshrink_so-heapshrink-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_MORECORE_yes-heapshrink-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_MORECORE_yes-malloc-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_MORECORE_yes-malloc_manysmall-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_RESTRICT_EXE_unknownmalloc-HUGETLB_MORECORE_yes-malloc-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_RESTRICT_EXE_unknownnone-HUGETLB_MORECORE_yes-malloc-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_SHM_yes-shmoverride_unlinked-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-HUGETLB_VERBOSE_0-linkhuge_nofd-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-libheapshrink_so-HUGETLB_MORECORE_SHRINK_yes-HUGETLB_MORECORE_yes-heapshrink-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-libheapshrink_so-HUGETLB_MORECORE_yes-heapshrink-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-linkhuge-2M-64 pass n/a libhugetlbfs/LD_PRELOAD_libhugetlbfs_so-shmoverride_unlinked-2M-64 pass n/a libhugetlbfs/alloc-instantiate-race-private-2M-64 pass n/a libhugetlbfs/alloc-instantiate-race-shared-2M-64 pass n/a libhugetlbfs/chunk-overcommit-2M-64 pass n/a libhugetlbfs/corrupt-by-cow-opt-2M-64 pass n/a libhugetlbfs/counters_sh-2M-64 skip/unknown n/a libhugetlbfs/direct-2M-64 pass n/a libhugetlbfs/fadvise_reserve_sh-2M-64 pass n/a libhugetlbfs/find_path-2M-64 pass n/a libhugetlbfs/fork-cow-2M-64 pass n/a libhugetlbfs/get_huge_pages-2M-64 pass n/a libhugetlbfs/gethugepagesize-2M-64 pass n/a libhugetlbfs/gethugepagesizes-2M-64 pass n/a libhugetlbfs/heapshrink-2M-64 pass n/a libhugetlbfs/huge_at_4GB_normal_below_static-2M-64 pass n/a libhugetlbfs/huge_below_4GB_normal_above_static-2M-64 pass n/a libhugetlbfs/icache-hygiene-2M-64 pass n/a libhugetlbfs/libhugetlb-pre-requirements pass n/a libhugetlbfs/linkhuge-2M-64 pass n/a libhugetlbfs/linkhuge_rw-2M-64 pass n/a libhugetlbfs/madvise_reserve_sh-2M-64 pass n/a libhugetlbfs/malloc-2M-64 pass n/a libhugetlbfs/malloc_manysmall-2M-64 pass n/a libhugetlbfs/map_high_truncate_2-2M-64 pass n/a libhugetlbfs/meminfo_nohuge-2M-64 pass n/a libhugetlbfs/misalign-2M-64 pass n/a libhugetlbfs/misaligned_offset-2M-64 pass n/a libhugetlbfs/mlock-2M-64 pass n/a libhugetlbfs/mmap-cow-199-200-2M-64 pass n/a libhugetlbfs/mmap-gettest-10-200-2M-64 pass n/a libhugetlbfs/mprotect-2M-64 pass n/a libhugetlbfs/mremap-expand-slice-collision_sh-2M-64 pass n/a libhugetlbfs/mremap-fixed-huge-near-normal_sh-2M-64 pass n/a libhugetlbfs/mremap-fixed-normal-near-huge_sh-2M-64 pass n/a libhugetlbfs/noresv-preserve-resv-page-2M-64 pass n/a libhugetlbfs/noresv-regarded-as-resv-2M-64 pass n/a libhugetlbfs/private-2M-64 pass n/a libhugetlbfs/ptrace-write-hugepage-2M-64 pass n/a libhugetlbfs/quota_sh-2M-64 pass n/a libhugetlbfs/readahead_reserve_sh-2M-64 pass n/a libhugetlbfs/readback-2M-64 pass n/a libhugetlbfs/shared-2M-64 pass n/a libhugetlbfs/shm-fork-10-100-2M-64 pass n/a libhugetlbfs/shm-fork-10-200-2M-64 pass n/a libhugetlbfs/shm-getraw-200--dev-full-2M-64 pass n/a libhugetlbfs/shm-perms-2M-64 pass n/a libhugetlbfs/shmoverride_linked-2M-64 pass n/a libhugetlbfs/slbpacaflush-2M-64 pass n/a libhugetlbfs/stack_grow_into_huge-2M-64 pass n/a libhugetlbfs/straddle_4GB_static-2M-64 pass n/a libhugetlbfs/task-size-overrun-2M-64 pass n/a libhugetlbfs/test_root-2M-64 pass n/a libhugetlbfs/truncate-2M-64 pass n/a libhugetlbfs/truncate_above_4GB-2M-64 pass n/a libhugetlbfs/truncate_reserve_wraparound-2M-64 pass n/a libhugetlbfs/truncate_sigbus_versus_oom-2M-64 pass n/a libhugetlbfs/unlinked_fd-2M-64 pass n/a libhugetlbfs/zero_filesize_segment-2M-64 fail pass ltp-syscalls-tests/pselect01
-- Linaro QA https://qa-reports.linaro.org
On Tue, Jun 27, 2017 at 12:03:01PM +0000, Linaro QA wrote:
Summary
• Tests: 991 • Failed: 13 • Passed: 978 • Build: next-20170627
linux-next? Wait, why do we care about that tree here at the moment? We have _so_ many other things to worry about first, right?
thanks,
greg k-h
On 27 June 2017 at 13:21, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 12:03:01PM +0000, Linaro QA wrote:
Summary
• Tests: 991 • Failed: 13 • Passed: 978 • Build: next-20170627
linux-next? Wait, why do we care about that tree here at the moment? We have _so_ many other things to worry about first, right?
It was cheap to add and it produces new build every day. This way it's easier to sort out the problems with infrastructure we currently have. Stable branches don't change that frequently.
milosz
On Tue, Jun 27, 2017 at 01:25:27PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:21, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 12:03:01PM +0000, Linaro QA wrote:
Summary
• Tests: 991 • Failed: 13 • Passed: 978 • Build: next-20170627
linux-next? Wait, why do we care about that tree here at the moment? We have _so_ many other things to worry about first, right?
It was cheap to add and it produces new build every day. This way it's easier to sort out the problems with infrastructure we currently have. Stable branches don't change that frequently.
Once a week is not enough? :)
And android-common changes a few times a week, if we should just be ignoring the linux-next testing for now, that's fine, but please let us know that...
thanks,
greg k-h
On 27 June 2017 at 13:27, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 01:25:27PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:21, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 12:03:01PM +0000, Linaro QA wrote:
Summary
• Tests: 991 • Failed: 13 • Passed: 978 • Build: next-20170627
linux-next? Wait, why do we care about that tree here at the moment? We have _so_ many other things to worry about first, right?
It was cheap to add and it produces new build every day. This way it's easier to sort out the problems with infrastructure we currently have. Stable branches don't change that frequently.
Once a week is not enough? :)
And android-common changes a few times a week, if we should just be ignoring the linux-next testing for now, that's fine, but please let us know that...
I think the easiest would be not to send these emails to lts-dev yet. I'll remove them if that's OK.
milosz
On Tue, Jun 27, 2017 at 01:32:52PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:27, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 01:25:27PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:21, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 12:03:01PM +0000, Linaro QA wrote:
Summary
• Tests: 991 • Failed: 13 • Passed: 978 • Build: next-20170627
linux-next? Wait, why do we care about that tree here at the moment? We have _so_ many other things to worry about first, right?
It was cheap to add and it produces new build every day. This way it's easier to sort out the problems with infrastructure we currently have. Stable branches don't change that frequently.
Once a week is not enough? :)
And android-common changes a few times a week, if we should just be ignoring the linux-next testing for now, that's fine, but please let us know that...
I think the easiest would be not to send these emails to lts-dev yet. I'll remove them if that's OK
Send stuff here that you want us to either pay attention to, or to let us know that you all are working on something, and that it's just a "look, the system is alive!" type of thing.
For the latter, mark it as such so we don't get worried if we see a lot of failures, like I did here :)
thanks,
greg k-h
On Tue, Jun 27, 2017 at 8:34 AM, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 01:32:52PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:27, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 01:25:27PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:21, Greg KH gregkh@google.com wrote:
On Tue, Jun 27, 2017 at 12:03:01PM +0000, Linaro QA wrote:
Summary
• Tests: 991 • Failed: 13 • Passed: 978 • Build: next-20170627
linux-next? Wait, why do we care about that tree here at the
moment?
We have _so_ many other things to worry about first, right?
It was cheap to add and it produces new build every day. This way it's easier to sort out the problems with infrastructure we currently have. Stable branches don't change that frequently.
Once a week is not enough? :)
And android-common changes a few times a week, if we should just be ignoring the linux-next testing for now, that's fine, but please let us know that...
I think the easiest would be not to send these emails to lts-dev yet. I'll remove them if that's OK
Send stuff here that you want us to either pay attention to, or to let us know that you all are working on something, and that it's just a "look, the system is alive!" type of thing.
For the latter, mark it as such so we don't get worried if we see a lot of failures, like I did here :)
Right. We want to keep the e-mails flowing for testing and sharing purposes.
Milosz: Can we append "Beta" or some other team to the subject lines for now so warning bells don't go off.
anmar
On Tue, Jun 27, 2017 at 08:38:24AM -0400, Anmar Oueja wrote:
Right. We want to keep the e-mails flowing for testing and sharing purposes.
Milosz: Can we append "Beta" or some other team to the subject lines for now so warning bells don't go off.
I think you just shouldn't be sending reports for things that aren't LTS (or at least LTS based if you want to include the Android stuff) to the lts-dev list, keep them flowing to the general build reports list only for now then as we acquire more confidence in the stability and usability of the reporting we can open that up to reporting directly to upstream. They're never going to be especially on topic for lts-dev.
On 27 June 2017 at 15:57, Mark Brown broonie@kernel.org wrote:
On Tue, Jun 27, 2017 at 08:38:24AM -0400, Anmar Oueja wrote:
Right. We want to keep the e-mails flowing for testing and sharing purposes.
Milosz: Can we append "Beta" or some other team to the subject lines for now so warning bells don't go off.
I think you just shouldn't be sending reports for things that aren't LTS (or at least LTS based if you want to include the Android stuff) to the lts-dev list, keep them flowing to the general build reports list only for now then as we acquire more confidence in the stability and usability of the reporting we can open that up to reporting directly to upstream. They're never going to be especially on topic for lts-dev.
OK. I removed lts-dev from linux-next notifications. It was my mistake to add it in a first place. These emails will still be sent to kernel-build-reports.
milosz
On Tue, Jun 27, 2017 at 01:25:27PM +0100, Milosz Wasilewski wrote:
On 27 June 2017 at 13:21, Greg KH gregkh@google.com wrote:
linux-next? Wait, why do we care about that tree here at the moment? We have _so_ many other things to worry about first, right?
It was cheap to add and it produces new build every day. This way it's easier to sort out the problems with infrastructure we currently have. Stable branches don't change that frequently.
There's also demand from other teams within Linaro that are engaged with upstream for results from mainline trees, this will both help mainline Linux development, start feeding the pipline to future stable releases and expand the pool of people providing feedback on the tooling.
One of the things we're going to be working on here is trying to make noise about the fact that we're running tests and care about the results. The aim with doing that is partly to try to keep things more stable in the same way that the existing focus on build and boot testing does and also to say to people who might work on testing that there's interest, hopefully helping more people do as the graphics and v4l people are currently doing and work on the testsuite development side. These are all long games.
-
Anmar Oueja -
Greg KH -
Linaro QA -
Mark Brown -
Milosz Wasilewski