May 2020 - Linux-stable-mirror

[git:media_tree/master] media: Revert "staging: imgu: Address a compiler warning on alignment"

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: Revert "staging: imgu: Address a compiler warning on alignment" Author: Sakari Ailus <sakari.ailus(a)linux.intel.com> Date: Wed Apr 15 17:34:05 2020 +0200 This reverts commit c9d52c114a9fcc61c30512c7f810247a9f2812af. The patch being reverted changed the memory layout of struct ipu3_uapi_acc_param. Revert it, and address the compiler warning issues in further patches. Fixes: commit c9d52c114a9f ("media: staging: imgu: Address a compiler warning on alignment") Reported-by: Tomasz Figa <tfiga(a)chromium.org> Tested-by: Bingbu Cao <bingbu.cao(a)intel.com> Cc: stable(a)vger.kernel.org # for v5.3 and up Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org> drivers/staging/media/ipu3/include/intel-ipu3.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/staging/media/ipu3/include/intel-ipu3.h b/drivers/staging/media/ipu3/include/intel-ipu3.h index 1c9c3ba4d518..5f43f631cf62 100644 --- a/drivers/staging/media/ipu3/include/intel-ipu3.h +++ b/drivers/staging/media/ipu3/include/intel-ipu3.h @@ -2477,7 +2477,7 @@ struct ipu3_uapi_acc_param { struct ipu3_uapi_yuvp1_yds_config yds2 __attribute__((aligned(32))); struct ipu3_uapi_yuvp2_tcc_static_config tcc __attribute__((aligned(32))); struct ipu3_uapi_anr_config anr; - struct ipu3_uapi_awb_fr_config_s awb_fr __attribute__((aligned(32))); + struct ipu3_uapi_awb_fr_config_s awb_fr; struct ipu3_uapi_ae_config ae; struct ipu3_uapi_af_config_s af; struct ipu3_uapi_awb_config awb;

4 years, 8 months

1
0
0 0

patch "usb: usbfs: correct kernel->user page attribute mismatch" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: usbfs: correct kernel->user page attribute mismatch to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 2bef9aed6f0e22391c8d4570749b1acc9bc3981e Mon Sep 17 00:00:00 2001 From: Jeremy Linton <jeremy.linton(a)arm.com> Date: Mon, 4 May 2020 15:13:48 -0500 Subject: usb: usbfs: correct kernel->user page attribute mismatch On some architectures (e.g. arm64) requests for IO coherent memory may use non-cachable attributes if the relevant device isn't cache coherent. If these pages are then remapped into userspace as cacheable, they may not be coherent with the non-cacheable mappings. In particular this happens with libusb, when it attempts to create zero-copy buffers for use by rtl-sdr (https://github.com/osmocom/rtl-sdr/). On low end arm devices with non-coherent USB ports, the application will be unexpectedly killed, while continuing to work fine on arm machines with coherent USB controllers. This bug has been discovered/reported a few times over the last few years. In the case of rtl-sdr a compile time option to enable/disable zero copy was implemented to work around it. Rather than relaying on application specific workarounds, dma_mmap_coherent() can be used instead of remap_pfn_range(). The page cache/etc attributes will then be correctly set in userspace to match the kernel mapping. Signed-off-by: Jeremy Linton <jeremy.linton(a)arm.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200504201348.1183246-1-jeremy.linton@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/devio.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 6833c918abce..b9db9812d6c5 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -217,6 +217,7 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma) { struct usb_memory *usbm = NULL; struct usb_dev_state *ps = file->private_data; + struct usb_hcd *hcd = bus_to_hcd(ps->dev->bus); size_t size = vma->vm_end - vma->vm_start; void *mem; unsigned long flags; @@ -250,9 +251,7 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma) usbm->vma_use_count = 1; INIT_LIST_HEAD(&usbm->memlist); - if (remap_pfn_range(vma, vma->vm_start, - virt_to_phys(usbm->mem) >> PAGE_SHIFT, - size, vma->vm_page_prot) < 0) { + if (dma_mmap_coherent(hcd->self.sysdev, vma, mem, dma_handle, size)) { dec_usb_memory_use_count(usbm, &usbm->vma_use_count); return -EAGAIN; } -- 2.26.2

4 years, 8 months

1
0
0 0

[PATCH 04/55] drm/i915/gt: Treat idling as a RPS downclock event

by Chris Wilson

If we park/unpark faster than we can respond to RPS events, we never will process a downclock event after expiring a waitboost, and thus we will forever restart the GPU at max clocks even if the workload switches and doesn't justify full power. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1500 Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti(a)intel.com> Cc: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Andi Shyti <andi.shyti(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200322163225.28791-1-chris@… Cc: <stable(a)vger.kernel.org> # v5.5+ (cherry picked from commit 21abf0bf168dffff1192e0f072af1dc74ae1ff0e) --- drivers/gpu/drm/i915/gt/intel_rps.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c index 3a3f49a71974..8accea06185b 100644 --- a/drivers/gpu/drm/i915/gt/intel_rps.c +++ b/drivers/gpu/drm/i915/gt/intel_rps.c @@ -765,6 +765,19 @@ void intel_rps_park(struct intel_rps *rps) intel_uncore_forcewake_get(rps_to_uncore(rps), FORCEWAKE_MEDIA); rps_set(rps, rps->idle_freq, false); intel_uncore_forcewake_put(rps_to_uncore(rps), FORCEWAKE_MEDIA); + + /* + * Since we will try and restart from the previously requested + * frequency on unparking, treat this idle point as a downclock + * interrupt and reduce the frequency for resume. If we park/unpark + * more frequently than the rps worker can run, we will not respond + * to any EI and never see a change in frequency. + * + * (Note we accommodate Cherryview's limitation of only using an + * even bin by applying it to all.) + */ + rps->cur_freq = + max_t(int, round_down(rps->cur_freq - 1, 2), rps->min_freq); } void intel_rps_boost(struct i915_request *rq) --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

4 years, 8 months

1
0
0 0

[PATCH 02/55] drm/i915/gt: Update PMINTRMSK holding fw

by Chris Wilson

If we use a non-forcewaked write to PMINTRMSK, it does not take effect until much later, if at all, causing a loss of RPS interrupts and no GPU reclocking, leaving the GPU running at the wrong frequency for long periods of time. Reported-by: Francisco Jerez <currojerez(a)riseup.net> Suggested-by: Francisco Jerez <currojerez(a)riseup.net> Fixes: 35cc7f32c298 ("drm/i915/gt: Use non-forcewake writes for RPS") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Francisco Jerez <currojerez(a)riseup.net> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Cc: Andi Shyti <andi.shyti(a)intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti(a)intel.com> Reviewed-by: Francisco Jerez <currojerez(a)riseup.net> Cc: <stable(a)vger.kernel.org> # v5.6+ Link: https://patchwork.freedesktop.org/patch/msgid/20200415170318.16771-2-chris@… (cherry picked from commit a080bd994c4023042a2b605c65fa10a25933f636) --- drivers/gpu/drm/i915/gt/intel_rps.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c index d2a3d935d186..3a3f49a71974 100644 --- a/drivers/gpu/drm/i915/gt/intel_rps.c +++ b/drivers/gpu/drm/i915/gt/intel_rps.c @@ -83,7 +83,8 @@ static void rps_enable_interrupts(struct intel_rps *rps) gen6_gt_pm_enable_irq(gt, rps->pm_events); spin_unlock_irq(&gt->irq_lock); - set(gt->uncore, GEN6_PMINTRMSK, rps_pm_mask(rps, rps->cur_freq)); + intel_uncore_write(gt->uncore, + GEN6_PMINTRMSK, rps_pm_mask(rps, rps->last_freq)); } static void gen6_rps_reset_interrupts(struct intel_rps *rps) @@ -117,7 +118,8 @@ static void rps_disable_interrupts(struct intel_rps *rps) rps->pm_events = 0; - set(gt->uncore, GEN6_PMINTRMSK, rps_pm_sanitize_mask(rps, ~0u)); + intel_uncore_write(gt->uncore, + GEN6_PMINTRMSK, rps_pm_sanitize_mask(rps, ~0u)); spin_lock_irq(&gt->irq_lock); gen6_gt_pm_disable_irq(gt, GEN6_PM_RPS_EVENTS); --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

4 years, 8 months

1
0
0 0

patch "staging: gasket: Check the return value of gasket_get_bar_index()" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: gasket: Check the return value of gasket_get_bar_index() to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 769acc3656d93aaacada814939743361d284fd87 Mon Sep 17 00:00:00 2001 From: Oscar Carter <oscar.carter(a)gmx.com> Date: Fri, 1 May 2020 17:51:18 +0200 Subject: staging: gasket: Check the return value of gasket_get_bar_index() Check the return value of gasket_get_bar_index function as it can return a negative one (-EINVAL). If this happens, a negative index is used in the "gasket_dev->bar_data" array. Addresses-Coverity-ID: 1438542 ("Negative array index read") Fixes: 9a69f5087ccc2 ("drivers/staging: Gasket driver framework + Apex driver") Signed-off-by: Oscar Carter <oscar.carter(a)gmx.com> Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Richard Yeh <rcy(a)google.com> Link: https://lore.kernel.org/r/20200501155118.13380-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/gasket/gasket_core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/staging/gasket/gasket_core.c b/drivers/staging/gasket/gasket_core.c index 8e0575fcb4c8..67325fbaf760 100644 --- a/drivers/staging/gasket/gasket_core.c +++ b/drivers/staging/gasket/gasket_core.c @@ -925,6 +925,10 @@ do_map_region(const struct gasket_dev *gasket_dev, struct vm_area_struct *vma, gasket_get_bar_index(gasket_dev, (vma->vm_pgoff << PAGE_SHIFT) + driver_desc->legacy_mmap_address_offset); + + if (bar_index < 0) + return DO_MAP_REGION_INVALID; + phys_base = gasket_dev->bar_data[bar_index].phys_base + phys_offset; while (mapped_bytes < map_length) { /* -- 2.26.2

4 years, 8 months

1
0
0 0

[PATCH] usb: xhci: Fix NULL pointer dereference as part of completion

by Sriharsha Allenki

On platforms with IOMMU enabled, multiple SGs can be coalesced into one by the IOMMU driver. In that case the SG list processing as part of the completion of a urb on a bulk endpoint can result into a NULL pointer dereference with the below stack dump. <6> Unable to handle kernel NULL pointer dereference at virtual address 0000000c <6> pgd = c0004000 <6> [0000000c] *pgd=00000000 <6> Internal error: Oops: 5 [#1] PREEMPT SMP ARM <2> PC is at xhci_queue_bulk_tx+0x454/0x80c <2> LR is at xhci_queue_bulk_tx+0x44c/0x80c <2> pc : [<c08907c4>] lr : [<c08907bc>] psr: 000000d3 <2> sp : ca337c80 ip : 00000000 fp : ffffffff <2> r10: 00000000 r9 : 50037000 r8 : 00004000 <2> r7 : 00000000 r6 : 00004000 r5 : 00000000 r4 : 00000000 <2> r3 : 00000000 r2 : 00000082 r1 : c2c1a200 r0 : 00000000 <2> Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none <2> Control: 10c0383d Table: b412c06a DAC: 00000051 <6> Process usb-storage (pid: 5961, stack limit = 0xca336210) <snip> <2> [<c08907c4>] (xhci_queue_bulk_tx) <2> [<c0881b3c>] (xhci_urb_enqueue) <2> [<c0831068>] (usb_hcd_submit_urb) <2> [<c08350b4>] (usb_sg_wait) <2> [<c089f384>] (usb_stor_bulk_transfer_sglist) <2> [<c089f2c0>] (usb_stor_bulk_srb) <2> [<c089fe38>] (usb_stor_Bulk_transport) <2> [<c089f468>] (usb_stor_invoke_transport) <2> [<c08a11b4>] (usb_stor_control_thread) <2> [<c014a534>] (kthread) The above NULL pointer dereference is the result of block_len and the sent_len set to zero after the first SG of the list when IOMMU driver is enabled. Because of this the loop of processing the SGs has run more than num_sgs which resulted in a sg_next on the last SG of the list which has SG_END set. Fix this by check for the sg before any attributes of the sg are accessed. Fixes: f9c589e142d04 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer") Cc: stable(a)vger.kernel.org Signed-off-by: Sriharsha Allenki <sallenki(a)codeaurora.org> --- drivers/usb/host/xhci-ring.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index a78787bb5133..18141b38f7bf 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3399,8 +3399,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags, /* New sg entry */ --num_sgs; sent_len -= block_len; - if (num_sgs != 0) { - sg = sg_next(sg); + sg = sg_next(sg); + if (num_sgs != 0 && sg) { block_len = sg_dma_len(sg); addr = (u64) sg_dma_address(sg); addr += sent_len; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

4 years, 8 months

2
1
0 0

stable-rc/linux-5.4.y boot: 158 boots: 0 failed, 146 passed with 5 offline, 6 untried/unknown, 1 conflict (v5.4.38-58-g29ca49e0243b)

by kernelci.org bot

stable-rc/linux-5.4.y boot: 158 boots: 0 failed, 146 passed with 5 offline, 6 untried/unknown, 1 conflict (v5.4.38-58-g29ca49e0243b) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.4.y/kernel/v5.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.4.y/kernel/v5.4.38-58-g… Tree: stable-rc Branch: linux-5.4.y Git Describe: v5.4.38-58-g29ca49e0243b Git Commit: 29ca49e0243b0d2bb55a2ee418f3cdc1fae69627 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 98 unique boards, 26 SoC families, 21 builds out of 200 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 86 days (last pass: v5.4.17-99-gbd0c6624a110 - first fail: v5.4.17-238-gbffcaa93483d) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v5.4.38) arm64: defconfig: gcc-8: meson-gxl-s805x-p241: lab-baylibre: new failure (last pass: v5.4.38) x86_64: x86_64_defconfig: gcc-8: qemu_x86_64: lab-collabora: new failure (last pass: v5.4.38) Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu_x86_64: lab-baylibre: PASS (gcc-8) lab-collabora: FAIL (gcc-8) --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

stable-rc/linux-4.19.y boot: 138 boots: 0 failed, 127 passed with 5 offline, 5 untried/unknown, 1 conflict (v4.19.120-38-g2e3613309d93)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 138 boots: 0 failed, 127 passed with 5 offline, 5 untried/unknown, 1 conflict (v4.19.120-38-g2e3613309d93) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.120-3… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.120-38-g2e3613309d93 Git Commit: 2e3613309d936ae445288baa881ca1775f300f6f Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 81 unique boards, 22 SoC families, 19 builds out of 206 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 86 days (last pass: v4.19.101 - first fail: v4.19.102-96-g0632821fe218) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.19.120) Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu_x86_64: lab-baylibre: PASS (gcc-8) lab-collabora: FAIL (gcc-8) --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

stable-rc/linux-4.14.y boot: 126 boots: 1 failed, 114 passed with 5 offline, 5 untried/unknown, 1 conflict (v4.14.178-27-g6d39cf919746)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 126 boots: 1 failed, 114 passed with 5 offline, 5 untried/unknown, 1 conflict (v4.14.178-27-g6d39cf919746) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.178-2… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.178-27-g6d39cf919746 Git Commit: 6d39cf91974673a74d6d976ecc107e43bb5c3eb4 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 72 unique boards, 20 SoC families, 17 builds out of 201 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 86 days (last pass: v4.14.169-92-gb4137330c582 - first fail: v4.14.170-62-gd6856e4a2c23) versatile_defconfig: gcc-8: versatile-pb: lab-collabora: new failure (last pass: v4.14.178) Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxbb-p200: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu_x86_64: lab-baylibre: PASS (gcc-8) lab-collabora: FAIL (gcc-8) --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

stable-rc/linux-5.6.y boot: 156 boots: 1 failed, 143 passed with 5 offline, 5 untried/unknown, 2 conflicts (v5.6.10-74-g6cd4bcd666cd)

by kernelci.org bot

stable-rc/linux-5.6.y boot: 156 boots: 1 failed, 143 passed with 5 offline, 5 untried/unknown, 2 conflicts (v5.6.10-74-g6cd4bcd666cd) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.6.y/kernel/v5.6.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.6.y/kernel/v5.6.10-74-g… Tree: stable-rc Branch: linux-5.6.y Git Describe: v5.6.10-74-g6cd4bcd666cd Git Commit: 6cd4bcd666cd831acf192bd7350b94121469ebcb Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 97 unique boards, 25 SoC families, 21 builds out of 200 Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: bcm2836-rpi-2-b: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab stih410-b2120: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab Conflicting Boot Failures Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) i386: i386_defconfig: qemu_i386: lab-baylibre: PASS (gcc-8) lab-collabora: FAIL (gcc-8) x86_64: x86_64_defconfig: qemu_x86_64: lab-baylibre: PASS (gcc-8) lab-collabora: FAIL (gcc-8) --- For more info write to <info(a)kernelci.org>

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2020