October 2019 - Linux-stable-mirror

❌ FAIL: Test report for kernel 5.4.0-rc5-7c766e8.cki (stable-next)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git Commit: 7c766e8c2b50 - mm: drop mmap_sem before calling balance_dirty_pages() in write fault The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: FAILED All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/259259 We attempted to compile the kernel for multiple architectures, but the compile failed on one or more architectures: aarch64: FAILED (see build-aarch64.log.xz attachment) ppc64le: FAILED (see build-ppc64le.log.xz attachment) s390x: FAILED (see build-s390x.log.xz attachment) x86_64: FAILED (see build-x86_64.log.xz attachment) We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg s390x: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg

5 years

1
0
0 0

❌ FAIL: Test report for kernel 5.4.0-rc5-da374e3.cki (stable-next)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git Commit: da374e3f03b9 - nl80211: fix validation of mesh path nexthop The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: FAILED All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/259194 We attempted to compile the kernel for multiple architectures, but the compile failed on one or more architectures: aarch64: FAILED (see build-aarch64.log.xz attachment) ppc64le: FAILED (see build-ppc64le.log.xz attachment) s390x: FAILED (see build-s390x.log.xz attachment) x86_64: FAILED (see build-x86_64.log.xz attachment) We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg s390x: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg

5 years

1
0
0 0

voice message

by Admin

Dear Sir/Madam, We require the following items please quote best price, with weight and size of shipment, minimum delivery period, maximum validity and other terms of sales. If required quantity is not fulfilling your requirement; please quote on MOV (Minimum order value) & MOQ (Minimum order quantity) basis. Kindly quote items which are in your scope of supply only, if you have any representative / distributor / stockist in our area please forward to relevant company /personal and Cc to us. Please confirm your company have any sales, supply & stock agreement with any other company (i.e. Grainger, RS, CPC-Farnell, Digi-Key, McMater-Carr, 3M, PVL, Transcat, Maida International, etc), from where we can purchase your products with best prices and minimum delivery period. Technical data sheet, material safety data sheet (for chemicals) required along with quotation and confirm make and origin, also confirm required material manufacturing, assembling & packing (confirm origin). Please confirm shipment status: Ex stock / Manufacture on firm order / import on firm order (third country) If you cannot quote, please inform us by telephone, e-mail, or facsimile with reason Kindly confirm us with evidence that you are manufacturer / distributor / stockist, etc. also confirm warrantee and guarantee of items offering. Note: Advance Payment is not provided as per policy of SBP & FBR for Foreign & Local Bidders but against bank guarantee. In case any quoted item falls in dangerous / harmonized goods category, please mention in your quotation with packing detail. Please confirm shipment through LCL/FCL; also confirm type & size (20’ or 40’) of container. Kindly send company registration certificate (CNIC/NTN/VAT, GST, Trade & Manufacturing License) with quotation. Certificates: Material Certificates, Calibration Certificates, Factory Test Certificates or Certificates of Conformity, Third party Inspection certificate, OEM certificate, Certificate of origin from local/foreign Chamber and FTA Certificate (China & Sri Lanka etc) MUST be provided along with shipment, please confirm all related charges. If you have any query, please feel free to contact us, enquiry closing date is 24-09-2018 Kindly send quotation before this date, by email and facsimile, if you need more time please apply for extension. Kindly acknowledge the receipt Note: Please do not remove enquiry Ref # 262-0918 for future correspondence; this is our general enquiry.

5 years

1
0
0 0

+ mm-memcontrol-fix-network-errors-from-failing-__gfp_atomic-charges.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: memcontrol: fix network errors from failing __GFP_ATOMIC charges has been added to the -mm tree. Its filename is mm-memcontrol-fix-network-errors-from-failing-__gfp_atomic-charges.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memcontrol-fix-network-errors-f… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcontrol-fix-network-errors-f… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Johannes Weiner <hannes(a)cmpxchg.org> Subject: mm: memcontrol: fix network errors from failing __GFP_ATOMIC charges While upgrading from 4.16 to 5.2, we noticed these allocation errors in the log of the new kernel: [ 8642.253395] SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC) [ 8642.269170] cache: tw_sock_TCPv6(960:helper-logs), object size: 232, buffer size: 240, default order: 1, min order: 0 [ 8642.293009] node 0: slabs: 5, objs: 170, free: 0 slab_out_of_memory+1 ___slab_alloc+969 __slab_alloc+14 kmem_cache_alloc+346 inet_twsk_alloc+60 tcp_time_wait+46 tcp_fin+206 tcp_data_queue+2034 tcp_rcv_state_process+784 tcp_v6_do_rcv+405 __release_sock+118 tcp_close+385 inet_release+46 __sock_release+55 sock_close+17 __fput+170 task_work_run+127 exit_to_usermode_loop+191 do_syscall_64+212 entry_SYSCALL_64_after_hwframe+68 accompanied by an increase in machines going completely radio silent under memory pressure. One thing that changed since 4.16 is e699e2c6a654 ("net, mm: account sock objects to kmemcg"), which made these slab caches subject to cgroup memory accounting and control. The problem with that is that cgroups, unlike the page allocator, do not maintain dedicated atomic reserves. As a cgroup's usage hovers at its limit, atomic allocations - such as done during network rx - can fail consistently for extended periods of time. The kernel is not able to operate under these conditions. We don't want to revert the culprit patch, because it indeed tracks a potentially substantial amount of memory used by a cgroup. We also don't want to implement dedicated atomic reserves for cgroups. There is no point in keeping a fixed margin of unused bytes in the cgroup's memory budget to accomodate a consumer that is impossible to predict - we'd be wasting memory and get into configuration headaches, not unlike what we have going with min_free_kbytes. We do this for physical mem because we have to, but cgroups are an accounting game. Instead, account these privileged allocations to the cgroup, but let them bypass the configured limit if they have to. This way, we get the benefits of accounting the consumed memory and have it exert pressure on the rest of the cgroup, but like with the page allocator, we shift the burden of reclaimining on behalf of atomic allocations onto the regular allocations that can block. Link: http://lkml.kernel.org/r/20191022233708.365764-1-hannes@cmpxchg.org Fixes: e699e2c6a654 ("net, mm: account sock objects to kmemcg") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reviewed-by: Shakeel Butt <shakeelb(a)google.com> Cc: Suleiman Souhlal <suleiman(a)google.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: <stable(a)vger.kernel.org> [4.18+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/mm/memcontrol.c~mm-memcontrol-fix-network-errors-from-failing-__gfp_atomic-charges +++ a/mm/memcontrol.c @@ -2535,6 +2535,15 @@ retry: } /* + * Memcg doesn't have a dedicated reserve for atomic + * allocations. But like the global atomic pool, we need to + * put the burden of reclaim on regular allocation requests + * and let these go through as privileged allocations. + */ + if (gfp_mask & __GFP_ATOMIC) + goto force; + + /* * Unlike in global OOM situations, memcg is not in a physical * memory shortage. Allow dying and OOM-killed tasks to * bypass the last charges so that they can exit quickly and _ Patches currently in -mm which might be from hannes(a)cmpxchg.org are mm-rate-limit-allocation-failure-warnings-more-aggressively.patch mm-memcontrol-fix-network-errors-from-failing-__gfp_atomic-charges.patch mm-memcontrol-remove-dead-code-from-memory_max_write.patch mm-memcontrol-try-harder-to-set-a-new-memoryhigh.patch mm-drop-mmap_sem-before-calling-balance_dirty_pages-in-write-fault.patch

5 years

1
0
0 0

+ mm-sparse-consistently-do-not-zero-memmap.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/sparse: consistently do not zero memmap has been added to the -mm tree. Its filename is mm-sparse-consistently-do-not-zero-memmap.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-sparse-consistently-do-not-zero… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-sparse-consistently-do-not-zero… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Vincent Whitchurch <vincent.whitchurch(a)axis.com> Subject: mm/sparse: consistently do not zero memmap sparsemem without VMEMMAP has two allocation paths to allocate the memory needed for its memmap (done in sparse_mem_map_populate()). In one allocation path (sparse_buffer_alloc() succeeds), the memory is not zeroed (since it was previously allocated with memblock_alloc_try_nid_raw()). In the other allocation path (sparse_buffer_alloc() fails and sparse_mem_map_populate() falls back to memblock_alloc_try_nid()), the memory is zeroed. AFAICS this difference does not appear to be on purpose. If the code is supposed to work with non-initialized memory (__init_single_page() takes care of zeroing the struct pages which are actually used), we should consistently not zero the memory, to avoid masking bugs. (I noticed this because on my ARM64 platform, with 1 GiB of memory the first [and only] section is allocated from the zeroing path while with 2 GiB of memory the first 1 GiB section is allocated from the non-zeroing path.) Link: http://lkml.kernel.org/r/20191030131122.8256-1-vincent.whitchurch@axis.com Signed-off-by: Vincent Whitchurch <vincent.whitchurch(a)axis.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Reviewed-by: Pavel Tatashin <pasha.tatashin(a)soleen.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c~mm-sparse-consistently-do-not-zero-memmap +++ a/mm/sparse.c @@ -458,7 +458,7 @@ struct page __init *__populate_section_m if (map) return map; - map = memblock_alloc_try_nid(size, + map = memblock_alloc_try_nid_raw(size, PAGE_SIZE, addr, MEMBLOCK_ALLOC_ACCESSIBLE, nid); if (!map) _ Patches currently in -mm which might be from vincent.whitchurch(a)axis.com are mm-sparse-consistently-do-not-zero-memmap.patch

5 years

1
0
0 0

❌ FAIL: Stable queue: queue-5.3

by CKI Project

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 95180e47e77a - Linux 5.3.8 The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: OK Tests: FAILED All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/256896 One or more kernel tests failed: ppc64le: ❌ LTP lite ❌ selinux-policy: serge-testsuite aarch64: ❌ LTP lite We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out the following commit: Repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 95180e47e77a - Linux 5.3.8 We grabbed the bf0d6892ea52 commit of the stable queue repository. We then merged the patchset with `git am`: io_uring-fix-up-o_nonblock-handling-for-sockets.patch dm-snapshot-introduce-account_start_copy-and-account.patch dm-snapshot-rework-cow-throttling-to-fix-deadlock.patch btrfs-fix-inode-cache-block-reserve-leak-on-failure-.patch btrfs-qgroup-always-free-prealloc-meta-reserve-in-bt.patch iio-adc-meson_saradc-fix-memory-allocation-order.patch iio-fix-center-temperature-of-bmc150-accel-core.patch libsubcmd-make-_fortify_source-defines-dependent-on-.patch perf-tests-avoid-raising-segv-using-an-obvious-null-.patch perf-map-fix-overlapped-map-handling.patch perf-script-brstackinsn-fix-recovery-from-lbr-binary.patch perf-jevents-fix-period-for-intel-fixed-counters.patch perf-tools-propagate-get_cpuid-error.patch perf-annotate-propagate-perf_env__arch-error.patch perf-annotate-fix-the-signedness-of-failure-returns.patch perf-annotate-propagate-the-symbol__annotate-error-r.patch perf-annotate-fix-arch-specific-init-failure-errors.patch perf-annotate-return-appropriate-error-code-for-allo.patch perf-annotate-don-t-return-1-for-error-when-doing-bp.patch staging-rtl8188eu-fix-null-dereference-when-kzalloc-.patch rdma-siw-fix-serialization-issue-in-write_space.patch rdma-hfi1-prevent-memory-leak-in-sdma_init.patch rdma-iw_cxgb4-fix-srq-access-from-dump_qp.patch rdma-iwcm-fix-a-lock-inversion-issue.patch hid-hyperv-use-in-place-iterator-api-in-the-channel-.patch kselftest-exclude-failed-targets-from-runlist.patch selftests-kselftest-runner.sh-add-45-second-timeout-.patch nfs-fix-nfsi-nrequests-count-error-on-nfs_inode_remo.patch arm64-cpufeature-effectively-expose-frint-capability.patch arm64-fix-incorrect-irqflag-restore-for-priority-mas.patch arm64-ftrace-ensure-synchronisation-in-plt-setup-for.patch tty-serial-owl-fix-the-link-time-qualifier-of-owl_ua.patch tty-serial-rda-fix-the-link-time-qualifier-of-rda_ua.patch serial-sifive-select-serial_earlycon.patch tty-n_hdlc-fix-build-on-sparc.patch misc-fastrpc-prevent-memory-leak-in-fastrpc_dma_buf_.patch rdma-core-fix-an-error-handling-path-in-res_get_comm.patch rdma-cm-fix-memory-leak-in-cm_add-remove_one.patch rdma-nldev-reshuffle-the-code-to-avoid-need-to-rebin.patch rdma-mlx5-do-not-allow-rereg-of-a-odp-mr.patch rdma-mlx5-order-num_pending_prefetch-properly-with-s.patch rdma-mlx5-add-missing-synchronize_srcu-for-mw-cases.patch gpio-max77620-use-correct-unit-for-debounce-times.patch fs-cifs-mute-wunused-const-variable-message.patch arm64-vdso32-fix-broken-compat-vdso-build-warnings.patch arm64-vdso32-detect-binutils-support-for-dmb-ishld.patch serial-mctrl_gpio-check-for-null-pointer.patch serial-8250_omap-fix-gpio-check-for-auto-rts-cts.patch arm64-default-to-building-compat-vdso-with-clang-whe.patch arm64-vdso32-don-t-use-kbuild_cppflags-unconditional.patch efi-cper-fix-endianness-of-pcie-class-code.patch efi-x86-do-not-clean-dummy-variable-in-kexec-path.patch mips-include-mark-__cmpxchg-as-__always_inline.patch riscv-avoid-kernel-hangs-when-trapped-in-bug.patch riscv-avoid-sending-a-sigtrap-to-a-user-thread-trapp.patch riscv-correct-the-handling-of-unexpected-ebreak-in-d.patch x86-xen-return-from-panic-notifier.patch ocfs2-clear-zero-in-unaligned-direct-io.patch fs-ocfs2-fix-possible-null-pointer-dereferences-in-o.patch fs-ocfs2-fix-a-possible-null-pointer-dereference-in-.patch fs-ocfs2-fix-a-possible-null-pointer-dereference-in-.patch btrfs-silence-maybe-uninitialized-warning-in-clone_r.patch arm64-armv8_deprecated-checking-return-value-for-mem.patch x86-cpu-add-comet-lake-to-the-intel-cpu-models-heade.patch sched-fair-scale-bandwidth-quota-and-period-without-.patch sched-vtime-fix-guest-system-mis-accounting-on-task-.patch perf-core-rework-memory-accounting-in-perf_mmap.patch perf-core-fix-corner-case-in-perf_rotate_context.patch perf-x86-amd-change-fix-nmi-latency-mitigation-to-us.patch drm-amdgpu-fix-memory-leak.patch iio-imu-adis16400-release-allocated-memory-on-failur.patch iio-imu-adis16400-fix-memory-leak.patch iio-imu-st_lsm6dsx-fix-waitime-for-st_lsm6dsx-i2c-co.patch mips-include-mark-__xchg-as-__always_inline.patch mips-fw-sni-fix-out-of-bounds-init-of-o32-stack.patch s390-cio-fix-virtio-ccw-dma-without-pv.patch virt-vbox-fix-memory-leak-in-hgcm_call_preprocess_li.patch nbd-fix-possible-sysfs-duplicate-warning.patch nfsv4-fix-leak-of-clp-cl_acceptor-string.patch sunrpc-fix-race-to-sk_err-after-xs_error_report.patch s390-uaccess-avoid-false-positive-compiler-warnings.patch tracing-initialize-iter-seq-after-zeroing-in-tracing.patch perf-annotate-fix-multiple-memory-and-file-descripto.patch perf-aux-fix-tracking-of-auxiliary-trace-buffer-allo.patch usb-legousbtower-fix-a-signedness-bug-in-tower_probe.patch nbd-verify-socket-is-supported-during-setup.patch Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ selinux-policy: serge-testsuite ✅ storage: software RAID testing 🚧 ✅ xfstests: xfs 🚧 ✅ Storage blktests Host 2: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ❌ LTP lite ✅ Loopdev Sanity ✅ jvm test suite ✅ AMTU (Abstract Machine Test Utility) ✅ LTP: openposix test suite ✅ Ethernet drivers sanity ✅ Networking socket: fuzz ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ iotop: sanity ✅ tuned: tune-processes-through-perf ✅ Usex - version 1.9-29 ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ storage: dm/common ppc64le: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ❌ LTP lite ✅ Loopdev Sanity ✅ jvm test suite ✅ AMTU (Abstract Machine Test Utility) ✅ LTP: openposix test suite ✅ Ethernet drivers sanity ✅ Networking socket: fuzz ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ iotop: sanity ✅ tuned: tune-processes-through-perf ✅ Usex - version 1.9-29 ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ❌ selinux-policy: serge-testsuite ⚡⚡⚡ storage: software RAID testing 🚧 ⚡⚡⚡ xfstests: xfs 🚧 ⚡⚡⚡ Storage blktests x86_64: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ selinux-policy: serge-testsuite ✅ storage: software RAID testing 🚧 ✅ xfstests: xfs 🚧 ⚡⚡⚡ Storage blktests Host 2: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP lite ✅ Loopdev Sanity ✅ jvm test suite ✅ AMTU (Abstract Machine Test Utility) ✅ LTP: openposix test suite ✅ Ethernet drivers sanity ✅ Networking socket: fuzz ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ iotop: sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ Usex - version 1.9-29 ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ storage: dm/common Host 3: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test 🚧 ⚡⚡⚡ /kernel/infiniband/env_setup 🚧 ⚡⚡⚡ /kernel/infiniband/sanity Host 4: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test 🚧 ⚡⚡⚡ /kernel/infiniband/env_setup 🚧 ⚡⚡⚡ /kernel/infiniband/sanity Host 5: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test 🚧 ⚡⚡⚡ /kernel/infiniband/env_setup 🚧 ⚡⚡⚡ /kernel/infiniband/sanity Host 6: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test 🚧 ⚡⚡⚡ /kernel/infiniband/env_setup 🚧 ⚡⚡⚡ /kernel/infiniband/sanity Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running are marked with ⏱. Reports for non-upstream kernels have a Beaker recipe linked to next to each host.

5 years

1
0
0 0

❌ FAIL: Test report for kernel 5.4.0-rc5-c15dde9.cki (stable-next)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git Commit: c15dde9190b4 - scsi: zfcp: trace channel log even for FCP command responses The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: OK Tests: FAILED All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/256777 One or more kernel tests failed: x86_64: ❌ LTP lite We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ Storage blktests 🚧 ✅ xfstests: ext4 🚧 ✅ xfstests: xfs Host 2: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP lite ✅ Loopdev Sanity ✅ jvm test suite ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ LTP: openposix test suite ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ Networking tunnel: vxlan basic ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ iotop: sanity ✅ tuned: tune-processes-through-perf ✅ Usex - version 1.9-29 ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ Networking bridge: sanity 🚧 ✅ Networking route_func: local ✅ Networking route_func: forward 🚧 ✅ L2TP basic test 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ ALSA PCM loopback test 🚧 ✅ ALSA Control (mixer) Userspace Element test 🚧 ✅ storage: dm/common 🚧 ✅ Networking ipsec: basic netns transport 🚧 ✅ Networking ipsec: basic netns tunnel ppc64le: Host 1: ✅ Boot test ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ Storage blktests 🚧 ✅ xfstests: ext4 🚧 ✅ xfstests: xfs Host 2: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ✅ LTP lite ✅ Loopdev Sanity ✅ jvm test suite ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ LTP: openposix test suite ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ Networking tunnel: vxlan basic ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ iotop: sanity ✅ tuned: tune-processes-through-perf ✅ Usex - version 1.9-29 ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ Networking bridge: sanity 🚧 ✅ Networking route_func: local ✅ Networking route_func: forward 🚧 ✅ L2TP basic test 🚧 ✅ Networking ipsec: basic netns tunnel 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ ALSA PCM loopback test 🚧 ✅ ALSA Control (mixer) Userspace Element test 🚧 ✅ storage: dm/common x86_64: Host 1: ✅ Boot test ✅ Podman system integration test (as root) ✅ Podman system integration test (as user) ❌ LTP lite ✅ Loopdev Sanity ✅ jvm test suite ✅ Memory function: memfd_create ✅ Memory function: kaslr ✅ AMTU (Abstract Machine Test Utility) ✅ LTP: openposix test suite ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ Networking tunnel: vxlan basic ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ iotop: sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ Usex - version 1.9-29 ✅ storage: SCSI VPD ✅ stress: stress-ng ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ Networking bridge: sanity 🚧 ✅ Networking route_func: local ✅ Networking route_func: forward 🚧 ✅ L2TP basic test 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ ALSA PCM loopback test 🚧 ✅ ALSA Control (mixer) Userspace Element test 🚧 ✅ storage: dm/common 🚧 ✅ Networking ipsec: basic netns transport 🚧 ✅ Networking ipsec: basic netns tunnel Host 2: ✅ Boot test ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ❌ IOMMU boot test 🚧 ✅ Storage blktests 🚧 ✅ xfstests: ext4 🚧 ✅ xfstests: xfs Host 3: ✅ Boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running are marked with ⏱. Reports for non-upstream kernels have a Beaker recipe linked to next to each host.

5 years

2
1
0 0

[PATCH AUTOSEL 4.4 01/13] regulator: ti-abb: Fix timeout in ti_abb_wait_txdone/ti_abb_clear_all_txdone

by Sasha Levin

From: Axel Lin <axel.lin(a)ingics.com> [ Upstream commit f64db548799e0330897c3203680c2ee795ade518 ] ti_abb_wait_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns true in the latest iteration of the while loop because the timeout value is abb->settling_time + 1. Similarly, ti_abb_clear_all_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns false in the latest iteration of the while loop. Fix it. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> Acked-by: Nishanth Menon <nm(a)ti.com> Link: https://lore.kernel.org/r/20190929095848.21960-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/regulator/ti-abb-regulator.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/drivers/regulator/ti-abb-regulator.c b/drivers/regulator/ti-abb-regulator.c index d2f9942987535..6d17357b3a248 100644 --- a/drivers/regulator/ti-abb-regulator.c +++ b/drivers/regulator/ti-abb-regulator.c @@ -173,19 +173,14 @@ static int ti_abb_wait_txdone(struct device *dev, struct ti_abb *abb) while (timeout++ <= abb->settling_time) { status = ti_abb_check_txdone(abb); if (status) - break; + return 0; udelay(1); } - if (timeout > abb->settling_time) { - dev_warn_ratelimited(dev, - "%s:TRANXDONE timeout(%duS) int=0x%08x\n", - __func__, timeout, readl(abb->int_base)); - return -ETIMEDOUT; - } - - return 0; + dev_warn_ratelimited(dev, "%s:TRANXDONE timeout(%duS) int=0x%08x\n", + __func__, timeout, readl(abb->int_base)); + return -ETIMEDOUT; } /** @@ -205,19 +200,14 @@ static int ti_abb_clear_all_txdone(struct device *dev, const struct ti_abb *abb) status = ti_abb_check_txdone(abb); if (!status) - break; + return 0; udelay(1); } - if (timeout > abb->settling_time) { - dev_warn_ratelimited(dev, - "%s:TRANXDONE timeout(%duS) int=0x%08x\n", - __func__, timeout, readl(abb->int_base)); - return -ETIMEDOUT; - } - - return 0; + dev_warn_ratelimited(dev, "%s:TRANXDONE timeout(%duS) int=0x%08x\n", + __func__, timeout, readl(abb->int_base)); + return -ETIMEDOUT; } /** -- 2.20.1

5 years

1
12
0 0

[PATCH AUTOSEL 4.9 01/18] regulator: ti-abb: Fix timeout in ti_abb_wait_txdone/ti_abb_clear_all_txdone

by Sasha Levin

From: Axel Lin <axel.lin(a)ingics.com> [ Upstream commit f64db548799e0330897c3203680c2ee795ade518 ] ti_abb_wait_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns true in the latest iteration of the while loop because the timeout value is abb->settling_time + 1. Similarly, ti_abb_clear_all_txdone() may return -ETIMEDOUT when ti_abb_check_txdone() returns false in the latest iteration of the while loop. Fix it. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> Acked-by: Nishanth Menon <nm(a)ti.com> Link: https://lore.kernel.org/r/20190929095848.21960-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/regulator/ti-abb-regulator.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/drivers/regulator/ti-abb-regulator.c b/drivers/regulator/ti-abb-regulator.c index d2f9942987535..6d17357b3a248 100644 --- a/drivers/regulator/ti-abb-regulator.c +++ b/drivers/regulator/ti-abb-regulator.c @@ -173,19 +173,14 @@ static int ti_abb_wait_txdone(struct device *dev, struct ti_abb *abb) while (timeout++ <= abb->settling_time) { status = ti_abb_check_txdone(abb); if (status) - break; + return 0; udelay(1); } - if (timeout > abb->settling_time) { - dev_warn_ratelimited(dev, - "%s:TRANXDONE timeout(%duS) int=0x%08x\n", - __func__, timeout, readl(abb->int_base)); - return -ETIMEDOUT; - } - - return 0; + dev_warn_ratelimited(dev, "%s:TRANXDONE timeout(%duS) int=0x%08x\n", + __func__, timeout, readl(abb->int_base)); + return -ETIMEDOUT; } /** @@ -205,19 +200,14 @@ static int ti_abb_clear_all_txdone(struct device *dev, const struct ti_abb *abb) status = ti_abb_check_txdone(abb); if (!status) - break; + return 0; udelay(1); } - if (timeout > abb->settling_time) { - dev_warn_ratelimited(dev, - "%s:TRANXDONE timeout(%duS) int=0x%08x\n", - __func__, timeout, readl(abb->int_base)); - return -ETIMEDOUT; - } - - return 0; + dev_warn_ratelimited(dev, "%s:TRANXDONE timeout(%duS) int=0x%08x\n", + __func__, timeout, readl(abb->int_base)); + return -ETIMEDOUT; } /** -- 2.20.1

5 years

1
17
0 0

[PATCH AUTOSEL 4.14 01/24] arm64: dts: Fix gpio to pinmux mapping

by Sasha Levin

From: Rayagonda Kokatanur <rayagonda.kokatanur(a)broadcom.com> [ Upstream commit 965f6603e3335a953f4f876792074cb36bf65f7f ] There are total of 151 non-secure gpio (0-150) and four pins of pinmux (91, 92, 93 and 94) are not mapped to any gpio pin, hence update same in DT. Fixes: 8aa428cc1e2e ("arm64: dts: Add pinctrl DT nodes for Stingray SOC") Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur(a)broadcom.com> Reviewed-by: Ray Jui <ray.jui(a)broadcom.com> Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi | 5 +++-- arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 3 +-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi index 15214d05fec1c..8c20d4a0cb4ed 100644 --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-pinctrl.dtsi @@ -42,13 +42,14 @@ pinmux: pinmux@0014029c { compatible = "pinctrl-single"; - reg = <0x0014029c 0x250>; + reg = <0x0014029c 0x26c>; #address-cells = <1>; #size-cells = <1>; pinctrl-single,register-width = <32>; pinctrl-single,function-mask = <0xf>; pinctrl-single,gpio-range = < - &range 0 154 MODE_GPIO + &range 0 91 MODE_GPIO + &range 95 60 MODE_GPIO >; range: gpio-range { #pinctrl-single,gpio-range-cells = <3>; diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi index 2b76293b51c83..3d2921ef29351 100644 --- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi @@ -444,8 +444,7 @@ <&pinmux 108 16 27>, <&pinmux 135 77 6>, <&pinmux 141 67 4>, - <&pinmux 145 149 6>, - <&pinmux 151 91 4>; + <&pinmux 145 149 6>; }; i2c1: i2c@000e0000 { -- 2.20.1

5 years

1
23
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2019