October 2020 - Linux-stable-mirror

Re: [PATCH 1/2] usbcore: Check both id_table and match() when both available

by M. Vefa Bicakci

On 23/10/2020 03.08, Andy Shevchenko wrote: > > > On Thursday, October 22, 2020, M. Vefa Bicakci <m.v.b(a)runbox.com <mailto:m.v.b@runbox.com>> wrote: > > On 22/10/2020 09.55, M. Vefa Bicakci wrote: > > From: Bastien Nocera <hadess(a)hadess.net <mailto:hadess@hadess.net>> > > From: Bastien Nocera <hadess(a)hadess.net <mailto:hadess@hadess.net>> > > > Ah, sorry for this mistake. This is the first time I sent patches > authored by another person, with git-send-email. I should have > tested with my own e-mail address initially. > > I will fix this mistake with the next patch set version. > > > > Also you may use BugLink tag instead of Link. Thank you, Andy! I will revise the patch description with the next patch set to use the BugLink tag.

4 years, 3 months

1
0
0 0

[PATCH 1/2] drm/i915/gt: Use the local HWSP offset during submission

by Chris Wilson

We wrap the timeline on construction of the next request, but there may still be requests in flight that have not yet finalized the breadcrumb. (The breadcrumb is delayed as we need engine-local offsets, and for the virtual engine that is not known until execution.) As such, by the time we write to the timeline's HWSP offset it may have changed, and we should use the value we preserved in the request instead. Though the window is small and infrequent (at full flow we can expect a timeline's seqno to wrap once every 30 minutes), the impact of writing the old seqno into the new HWSP is severe: the old requests are never completed, and the new requests are completed before they are even submitted. Fixes: ebece7539242 ("drm/i915: Keep timeline HWSP allocated until idle across the system") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v5.2+ --- drivers/gpu/drm/i915/gt/intel_lrc.c | 22 ++++++++++++------- drivers/gpu/drm/i915/gt/intel_timeline.c | 18 ++++++++------- .../gpu/drm/i915/gt/intel_timeline_types.h | 2 ++ 3 files changed, 26 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index c22d47cc6701..84ba6cd70a2a 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -3597,6 +3597,14 @@ static const struct intel_context_ops execlists_context_ops = { .destroy = execlists_context_destroy, }; +static u32 hwsp_offset(struct i915_request *rq) +{ + if (rq->hwsp_cacheline) + return rq->hwsp_cacheline->ggtt_offset; + else + return i915_request_active_timeline(rq)->hwsp_offset; +} + static int gen8_emit_init_breadcrumb(struct i915_request *rq) { u32 *cs; @@ -3619,7 +3627,7 @@ static int gen8_emit_init_breadcrumb(struct i915_request *rq) *cs++ = MI_NOOP; *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT; - *cs++ = i915_request_timeline(rq)->hwsp_offset; + *cs++ = hwsp_offset(rq); *cs++ = 0; *cs++ = rq->fence.seqno - 1; @@ -4939,11 +4947,9 @@ gen8_emit_fini_breadcrumb_tail(struct i915_request *request, u32 *cs) return gen8_emit_wa_tail(request, cs); } -static u32 *emit_xcs_breadcrumb(struct i915_request *request, u32 *cs) +static u32 *emit_xcs_breadcrumb(struct i915_request *rq, u32 *cs) { - u32 addr = i915_request_active_timeline(request)->hwsp_offset; - - return gen8_emit_ggtt_write(cs, request->fence.seqno, addr, 0); + return gen8_emit_ggtt_write(cs, rq->fence.seqno, hwsp_offset(rq), 0); } static u32 *gen8_emit_fini_breadcrumb(struct i915_request *rq, u32 *cs) @@ -4962,7 +4968,7 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) /* XXX flush+write+CS_STALL all in one upsets gem_concurrent_blt:kbl */ cs = gen8_emit_ggtt_write_rcs(cs, request->fence.seqno, - i915_request_active_timeline(request)->hwsp_offset, + hwsp_offset(request), PIPE_CONTROL_FLUSH_ENABLE | PIPE_CONTROL_CS_STALL); @@ -4974,7 +4980,7 @@ gen11_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) { cs = gen8_emit_ggtt_write_rcs(cs, request->fence.seqno, - i915_request_active_timeline(request)->hwsp_offset, + hwsp_offset(request), PIPE_CONTROL_CS_STALL | PIPE_CONTROL_TILE_CACHE_FLUSH | PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | @@ -5044,7 +5050,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) { cs = gen12_emit_ggtt_write_rcs(cs, request->fence.seqno, - i915_request_active_timeline(request)->hwsp_offset, + hwsp_offset(request), PIPE_CONTROL0_HDC_PIPELINE_FLUSH, PIPE_CONTROL_CS_STALL | PIPE_CONTROL_TILE_CACHE_FLUSH | diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c index a2f74cefe4c3..7ea94d201fe6 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline.c +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c @@ -188,10 +188,14 @@ cacheline_alloc(struct intel_timeline_hwsp *hwsp, unsigned int cacheline) return cl; } -static void cacheline_acquire(struct intel_timeline_cacheline *cl) +static void cacheline_acquire(struct intel_timeline_cacheline *cl, + u32 ggtt_offset) { - if (cl) - i915_active_acquire(&cl->active); + if (!cl) + return; + + cl->ggtt_offset = ggtt_offset; + i915_active_acquire(&cl->active); } static void cacheline_release(struct intel_timeline_cacheline *cl) @@ -340,7 +344,7 @@ int intel_timeline_pin(struct intel_timeline *tl, struct i915_gem_ww_ctx *ww) GT_TRACE(tl->gt, "timeline:%llx using HWSP offset:%x\n", tl->fence_context, tl->hwsp_offset); - cacheline_acquire(tl->hwsp_cacheline); + cacheline_acquire(tl->hwsp_cacheline, tl->hwsp_offset); if (atomic_fetch_inc(&tl->pin_count)) { cacheline_release(tl->hwsp_cacheline); __i915_vma_unpin(tl->hwsp_ggtt); @@ -515,7 +519,7 @@ __intel_timeline_get_seqno(struct intel_timeline *tl, GT_TRACE(tl->gt, "timeline:%llx using HWSP offset:%x\n", tl->fence_context, tl->hwsp_offset); - cacheline_acquire(cl); + cacheline_acquire(cl, tl->hwsp_offset); tl->hwsp_cacheline = cl; *seqno = timeline_advance(tl); @@ -573,9 +577,7 @@ int intel_timeline_read_hwsp(struct i915_request *from, if (err) goto out; - *hwsp = i915_ggtt_offset(cl->hwsp->vma) + - ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) * CACHELINE_BYTES; - + *hwsp = cl->ggtt_offset; out: i915_active_release(&cl->active); return err; diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h b/drivers/gpu/drm/i915/gt/intel_timeline_types.h index 02181c5020db..4474f487f589 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h +++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h @@ -94,6 +94,8 @@ struct intel_timeline_cacheline { struct intel_timeline_hwsp *hwsp; void *vaddr; + u32 ggtt_offset; + struct rcu_head rcu; }; -- 2.20.1

4 years, 3 months

3
3
0 0

[PATCH v2] KVM: arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED

by Stephen Boyd

According to the SMCCC spec[1](7.5.2 Discovery) the ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and SMCCC_RET_NOT_SUPPORTED. 0 is "workaround required and safe to call this function" 1 is "workaround not required but safe to call this function" SMCCC_RET_NOT_SUPPORTED is "might be vulnerable or might not be, who knows, I give up!" SMCCC_RET_NOT_SUPPORTED might as well mean "workaround required, except calling this function may not work because it isn't implemented in some cases". Wonderful. We map this SMC call to 0 is SPECTRE_MITIGATED 1 is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE For KVM hypercalls (hvc), we've implemented this function id to return SMCCC_RET_NOT_SUPPORTED, 0, and SMCCC_RET_NOT_REQUIRED. One of those isn't supposed to be there. Per the code we call arm64_get_spectre_v2_state() to figure out what to return for this feature discovery call. 0 is SPECTRE_MITIGATED SMCCC_RET_NOT_REQUIRED is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE Let's clean this up so that KVM tells the guest this mapping: 0 is SPECTRE_MITIGATED 1 is SPECTRE_UNAFFECTED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE (Note: Moving SMCCC_RET_NOT_AFFECTED to a header is left out of this patch as it would need to move from proton-pack.c which isn't in stable trees and the name isn't actually part of the SMCCC spec) Cc: Andre Przywara <andre.przywara(a)arm.com> Cc: Steven Price <steven.price(a)arm.com> Cc: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://developer.arm.com/documentation/den0028/latest [1] Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests") Signed-off-by: Stephen Boyd <swboyd(a)chromium.org> --- I see that before commit c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests") we had this mapping: 0 is SPECTRE_MITIGATED SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE so the return value '1' wasn't there then. Once the commit was merged we introduced the notion of NOT_REQUIRED here when it shouldn't have been introduced. Changes from v1: * Way longer commit text, more background (sorry) * Dropped proton-pack part because it was wrong * Rebased onto other patch accepted upstream arch/arm64/kvm/hypercalls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c index 9824025ccc5c..6a62312d7813 100644 --- a/arch/arm64/kvm/hypercalls.c +++ b/arch/arm64/kvm/hypercalls.c @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu) val = SMCCC_RET_SUCCESS; break; case SPECTRE_UNAFFECTED: - val = SMCCC_RET_NOT_REQUIRED; + val = 1; break; } break; base-commit: 66dd3474702aa98d5844367e1577cdad78ef7c65 -- Sent by a computer, using git, on the internet

4 years, 3 months

2
1
0 0

+ hugetlb_cgroup-fix-reservation-accounting.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlb_cgroup: fix reservation accounting has been added to the -mm tree. Its filename is hugetlb_cgroup-fix-reservation-accounting.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/hugetlb_cgroup-fix-reservation-ac… and later at https://ozlabs.org/~akpm/mmotm/broken-out/hugetlb_cgroup-fix-reservation-ac… 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: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlb_cgroup: fix reservation accounting Michal Privoznik was using "free page reporting" in QEMU/virtio-balloon with hugetlbfs and hit the warning below. QEMU with free page hinting uses fallocate(FALLOC_FL_PUNCH_HOLE) to discard pages that are reported as free by a VM. The reporting granularity is in pageblock granularity. So when the guest reports 2M chunks, we fallocate(FALLOC_FL_PUNCH_HOLE) one huge page in QEMU. [ 315.251417] ------------[ cut here ]------------ [ 315.251424] WARNING: CPU: 7 PID: 6636 at mm/page_counter.c:57 page_counter_uncharge+0x4b/0x50 [ 315.251425] Modules linked in: ... [ 315.251466] CPU: 7 PID: 6636 Comm: qemu-system-x86 Not tainted 5.9.0 #137 [ 315.251467] Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS PRO/X570 AORUS PRO, BIOS F21 07/31/2020 [ 315.251469] RIP: 0010:page_counter_uncharge+0x4b/0x50 ... [ 315.251479] Call Trace: [ 315.251485] hugetlb_cgroup_uncharge_file_region+0x4b/0x80 [ 315.251487] region_del+0x1d3/0x300 [ 315.251489] hugetlb_unreserve_pages+0x39/0xb0 [ 315.251492] remove_inode_hugepages+0x1a8/0x3d0 [ 315.251495] ? tlb_finish_mmu+0x7a/0x1d0 [ 315.251497] hugetlbfs_fallocate+0x3c4/0x5c0 [ 315.251519] ? kvm_arch_vcpu_ioctl_run+0x614/0x1700 [kvm] [ 315.251522] ? file_has_perm+0xa2/0xb0 [ 315.251524] ? inode_security+0xc/0x60 [ 315.251525] ? selinux_file_permission+0x4e/0x120 [ 315.251527] vfs_fallocate+0x146/0x290 [ 315.251529] __x64_sys_fallocate+0x3e/0x70 [ 315.251531] do_syscall_64+0x33/0x40 [ 315.251533] entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... [ 315.251542] ---[ end trace 4c88c62ccb1349c9 ]--- Investigation of the issue uncovered bugs in hugetlb cgroup reservation accounting. This patch addresses the found issues. Link: https://lkml.kernel.org/r/20201021204426.36069-1-mike.kravetz@oracle.com Fixes: 075a61d07a8e ("hugetlb_cgroup: add accounting for shared mappings") Cc: <stable(a)vger.kernel.org> Reported-by: Michal Privoznik <mprivozn(a)redhat.com> Co-developed-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Tested-by: Michal Privoznik <mprivozn(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Mina Almasry <almasrymina(a)google.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: "Aneesh Kumar K . V" <aneesh.kumar(a)linux.vnet.ibm.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) --- a/mm/hugetlb.c~hugetlb_cgroup-fix-reservation-accounting +++ a/mm/hugetlb.c @@ -648,6 +648,8 @@ retry: } del += t - f; + hugetlb_cgroup_uncharge_file_region( + resv, rg, t - f); /* New entry for end of split region */ nrg->from = t; @@ -660,9 +662,6 @@ retry: /* Original entry is trimmed */ rg->to = f; - hugetlb_cgroup_uncharge_file_region( - resv, rg, nrg->to - nrg->from); - list_add(&nrg->link, &rg->link); nrg = NULL; break; @@ -678,17 +677,17 @@ retry: } if (f <= rg->from) { /* Trim beginning of region */ - del += t - rg->from; - rg->from = t; - hugetlb_cgroup_uncharge_file_region(resv, rg, t - rg->from); - } else { /* Trim end of region */ - del += rg->to - f; - rg->to = f; + del += t - rg->from; + rg->from = t; + } else { /* Trim end of region */ hugetlb_cgroup_uncharge_file_region(resv, rg, rg->to - f); + + del += rg->to - f; + rg->to = f; } } @@ -2443,6 +2442,9 @@ struct page *alloc_huge_page(struct vm_a rsv_adjust = hugepage_subpool_put_pages(spool, 1); hugetlb_acct_memory(h, -rsv_adjust); + if (deferred_reserve) + hugetlb_cgroup_uncharge_page_rsvd(hstate_index(h), + pages_per_huge_page(h), page); } return page; _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are hugetlb_cgroup-fix-reservation-accounting.patch

4 years, 3 months

1
0
0 0

[merged] ia64-fix-build-error-with-coredump.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ia64: fix build error with !COREDUMP has been removed from the -mm tree. Its filename was ia64-fix-build-error-with-coredump.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Krzysztof Kozlowski <krzk(a)kernel.org> Subject: ia64: fix build error with !COREDUMP Fix linkage error when CONFIG_BINFMT_ELF is selected but CONFIG_COREDUMP is not: ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function `elf_core_write_extra_phdrs': elfcore.c:(.text+0x172): undefined reference to `dump_emit' ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function `elf_core_write_extra_data': elfcore.c:(.text+0x2b2): undefined reference to `dump_emit' Link: https://lkml.kernel.org/r/20200819064146.12529-1-krzk@kernel.org Fixes: 1fcccbac89f5 ("elf coredump: replace ELF_CORE_EXTRA_* macros by functions") Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Reported-by: kernel test robot <lkp(a)intel.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/ia64/kernel/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/ia64/kernel/Makefile~ia64-fix-build-error-with-coredump +++ a/arch/ia64/kernel/Makefile @@ -40,7 +40,7 @@ obj-y += esi_stub.o # must be in kern endif obj-$(CONFIG_INTEL_IOMMU) += pci-dma.o -obj-$(CONFIG_BINFMT_ELF) += elfcore.o +obj-$(CONFIG_ELF_CORE) += elfcore.o # fp_emulate() expects f2-f5,f16-f31 to contain the user-level state. CFLAGS_traps.o += -mfixed-range=f2-f5,f16-f31 _ Patches currently in -mm which might be from krzk(a)kernel.org are

4 years, 3 months

1
0
0 0

[PATCH] usb: dwc3: ep0: Fix delay status handling

by Thinh Nguyen

If we want to send a control status on our own time (through delayed_status), make sure to handle a case where we may queue the delayed status before the host requesting for it (when XferNotReady is generated). Otherwise, the driver won't send anything because it's not EP0_STATUS_PHASE yet. To resolve this, regardless whether dwc->ep0state is EP0_STATUS_PHASE, make sure to clear the dwc->delayed_status flag if dwc3_ep0_send_delayed_status() is called. The control status can be sent when the host requests it later. Cc: <stable(a)vger.kernel.org> Fixes: d97c78a1908e ("usb: dwc3: gadget: END_TRANSFER before CLEAR_STALL command") Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> --- drivers/usb/dwc3/ep0.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 7be3903cb842..8b668ef46f7f 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -1058,10 +1058,11 @@ void dwc3_ep0_send_delayed_status(struct dwc3 *dwc) { unsigned int direction = !dwc->ep0_expect_in; + dwc->delayed_status = false; + if (dwc->ep0state != EP0_STATUS_PHASE) return; - dwc->delayed_status = false; __dwc3_ep0_do_control_status(dwc, dwc->eps[direction]); } base-commit: 270315b8235e3d10c2e360cff56c2f9e0915a252 -- 2.28.0

4 years, 3 months

1
0
0 0

stable-rc/queue/5.4 baseline: 180 runs, 3 regressions (v5.4.72-24-g088b4440ff14)

by kernelci.org bot

stable-rc/queue/5.4 baseline: 180 runs, 3 regressions (v5.4.72-24-g088b4440ff14) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------+-------+---------------+----------+-----------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-8 | defconfig | 3 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.4/kernel/v5.4.72-2… Test: baseline Tree: stable-rc Branch: queue/5.4 Describe: v5.4.72-24-g088b4440ff14 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 088b4440ff14b5ccab572077650642dfb5113f1c Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------+-------+---------------+----------+-----------+------------ rk3399-gru-kevin | arm64 | lab-collabora | gcc-8 | defconfig | 3 Details: https://kernelci.org/test/plan/id/5f91a86478c441215e11095e Results: 85 PASS, 5 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.72-24-g088b4440ff14/… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.72-24-g088b4440ff14/… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-3-g27eeeac7… * baseline.bootrr.cros-ec-sensors-accel0-probed: https://kernelci.org/test/case/id/5f91a86478c441215e110972 failing since 22 days (last pass: v5.4.68-384-g856fa448539c, first fail: v5.4.68-388-gcf92ab7a7853) * baseline.bootrr.cros-ec-sensors-accel1-probed: https://kernelci.org/test/case/id/5f91a86478c441215e110973 failing since 22 days (last pass: v5.4.68-384-g856fa448539c, first fail: v5.4.68-388-gcf92ab7a7853) 2020-10-22 15:42:20.722000+00:00 /lava-2740803/1/../bin/lava-test-case 2020-10-22 15:42:20.731000+00:00 <8>[ 23.353458] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=cros-ec-sensors-accel1-probed RESULT=fail> * baseline.bootrr.cros-ec-sensors-gyro0-probed: https://kernelci.org/test/case/id/5f91a86478c441215e110974 failing since 22 days (last pass: v5.4.68-384-g856fa448539c, first fail: v5.4.68-388-gcf92ab7a7853) 2020-10-22 15:42:21.752000+00:00 <8>[ 24.374792] <LAVA_SIGNAL_TESTCASE TEST_CASE_ID=cros-ec-sensors-gyro0-probed RESULT=fail>

4 years, 3 months

1
0
0 0

stable-rc/queue/5.8 baseline: 177 runs, 1 regressions (v5.8.16-29-g7f7c35e6fb34)

by kernelci.org bot

stable-rc/queue/5.8 baseline: 177 runs, 1 regressions (v5.8.16-29-g7f7c35e6fb34) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.8/kernel/v5.8.16-2… Test: baseline Tree: stable-rc Branch: queue/5.8 Describe: v5.8.16-29-g7f7c35e6fb34 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 7f7c35e6fb344bb03b90db9a4ad6346b8fe7c87e Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/5f91a9e7d03ca1e60311095c Results: 4 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.8/v5.8.16-29-g7f7c35e6fb34/… HTML log: https://storage.kernelci.org//stable-rc/queue-5.8/v5.8.16-29-g7f7c35e6fb34/… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-3-g27eeeac7… * baseline.dmesg.crit: https://kernelci.org/test/case/id/5f91a9e7d03ca1e603110961 failing since 1 day (last pass: v5.8.16-29-g970dd0292df8, first fail: v5.8.16-29-g94b8033e99d8) 3 lines 2020-10-22 15:46:12.965000+00:00 Connected to bcm2837-rpi-3-b console [channel connected] (~$quit to exit) 2020-10-22 15:46:12.966000+00:00 (user:khilman) is already connected 2020-10-22 15:46:28.136000+00:00 2020-10-22 15:46:28.137000+00:00 2020-10-22 15:46:28.137000+00:00 U-Boot 2018.11 (Dec 04 2018 - 10:54:32 -0800) 2020-10-22 15:46:28.137000+00:00 2020-10-22 15:46:28.137000+00:00 DRAM: 948 MiB 2020-10-22 15:46:28.152000+00:00 RPI 3 Model B (0xa02082) 2020-10-22 15:46:28.240000+00:00 MMC: mmc@7e202000: 0, sdhci@7e300000: 1 2020-10-22 15:46:28.273000+00:00 Loading Environment from FAT... *** Warning - bad CRC, using default environment ... (392 line(s) more)

4 years, 3 months

1
0
0 0

stable-rc/queue/4.14 baseline: 148 runs, 1 regressions (v4.14.202-10-g429275e47906)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 148 runs, 1 regressions (v4.14.202-10-g429275e47906) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.20… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.202-10-g429275e47906 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 429275e4790673e7124526ffcd6382f0b1eff9c1 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ---------+------+---------------+----------+---------------------+------------ panda | arm | lab-collabora | gcc-8 | omap2plus_defconfig | 1 Details: https://kernelci.org/test/plan/id/5f91a8fd916d15f5b9110961 Results: 3 PASS, 1 FAIL, 1 SKIP Full config: omap2plus_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.202-10-g429275e479… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.202-10-g429275e479… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-3-g27eeeac7… * baseline.dmesg.emerg: https://kernelci.org/test/case/id/5f91a8fd916d15f5b9110968 new failure (last pass: v4.14.202-10-ged048399782c) 2 lines 2020-10-22 15:44:57.694000+00:00 [ 20.408294] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-4a064c00.ehci-1.1, smsc95xx USB 2.0 Ethernet, a2:17:83:8c:79:e3 2020-10-22 15:44:57.701000+00:00 [ 20.420715] usbcore: registered new interface driver smsc95xx

4 years, 3 months

1
0
0 0

stable-rc/queue/4.19 baseline: 153 runs, 1 regressions (v4.19.152-15-gc47f727e21ba)

by kernelci.org bot

stable-rc/queue/4.19 baseline: 153 runs, 1 regressions (v4.19.152-15-gc47f727e21ba) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.19/kernel/v4.19.15… Test: baseline Tree: stable-rc Branch: queue/4.19 Describe: v4.19.152-15-gc47f727e21ba URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: c47f727e21ba96c0e5e395e6e28d26fc708137bf Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+--------------+----------+-----------+------------ bcm2837-rpi-3-b | arm64 | lab-baylibre | gcc-8 | defconfig | 1 Details: https://kernelci.org/test/plan/id/5f91a19d6e487bc993110954 Results: 4 PASS, 1 FAIL, 0 SKIP Full config: defconfig Compiler: gcc-8 (aarch64-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.152-15-gc47f727e21… HTML log: https://storage.kernelci.org//stable-rc/queue-4.19/v4.19.152-15-gc47f727e21… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-3-g27eeeac7… * baseline.dmesg.crit: https://kernelci.org/test/case/id/5f91a19d6e487bc993110959 new failure (last pass: v4.19.152-15-g0ea747efc059) 2 lines

4 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2020