- Linux-stable-mirror - lists.linaro.org

patch "tty: always relink the port" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: always relink the port to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-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 273f632912f1b24b642ba5b7eb5022e43a72f3b5 Mon Sep 17 00:00:00 2001 From: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> Date: Fri, 27 Dec 2019 17:44:34 +0000 Subject: tty: always relink the port If the serial device is disconnected and reconnected, it re-enumerates properly but does not link it. fwiw, linking means just saving the port index, so allow it always as there is no harm in saving the same value again even if it tries to relink with the same port. Fixes: fb2b90014d78 ("tty: link tty and port before configuring it as console") Reported-by: Kenneth R. Crudup <kenny(a)panix.com> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20191227174434.12057-1-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_port.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c index 5023c85ebc6e..044c3cbdcfa4 100644 --- a/drivers/tty/tty_port.c +++ b/drivers/tty/tty_port.c @@ -89,8 +89,7 @@ void tty_port_link_device(struct tty_port *port, { if (WARN_ON(index >= driver->num)) return; - if (!driver->ports[index]) - driver->ports[index] = port; + driver->ports[index] = port; } EXPORT_SYMBOL_GPL(tty_port_link_device); -- 2.24.1

5 years, 10 months

1
0
0 0

[tip: x86/urgent] x86/resctrl: Fix an imbalance in domain_remove_cpu()

by tip-bot2 for Qian Cai

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: e278af89f1ba0a9ef20947db6afc2c9afa37e85b Gitweb: https://git.kernel.org/tip/e278af89f1ba0a9ef20947db6afc2c9afa37e85b Author: Qian Cai <cai(a)lca.pw> AuthorDate: Tue, 10 Dec 2019 22:30:42 -05:00 Committer: Borislav Petkov <bp(a)suse.de> CommitterDate: Mon, 30 Dec 2019 19:25:59 +01:00 x86/resctrl: Fix an imbalance in domain_remove_cpu() A system that supports resource monitoring may have multiple resources while not all of these resources are capable of monitoring. Monitoring related state is initialized only for resources that are capable of monitoring and correspondingly this state should subsequently only be removed from these resources that are capable of monitoring. domain_add_cpu() calls domain_setup_mon_state() only when r->mon_capable is true where it will initialize d->mbm_over. However, domain_remove_cpu() calls cancel_delayed_work(&d->mbm_over) without checking r->mon_capable resulting in an attempt to cancel d->mbm_over on all resources, even those that never initialized d->mbm_over because they are not capable of monitoring. Hence, it triggers a debugobjects warning when offlining CPUs because those timer debugobjects are never initialized: ODEBUG: assert_init not available (active state 0) object type: timer_list hint: 0x0 WARNING: CPU: 143 PID: 789 at lib/debugobjects.c:484 debug_print_object Hardware name: HP Synergy 680 Gen9/Synergy 680 Gen9 Compute Module, BIOS I40 05/23/2018 RIP: 0010:debug_print_object Call Trace: debug_object_assert_init del_timer try_to_grab_pending cancel_delayed_work resctrl_offline_cpu cpuhp_invoke_callback cpuhp_thread_fun smpboot_thread_fn kthread ret_from_fork Fixes: e33026831bdb ("x86/intel_rdt/mbm: Handle counter overflow") Signed-off-by: Qian Cai <cai(a)lca.pw> Signed-off-by: Borislav Petkov <bp(a)suse.de> Acked-by: Reinette Chatre <reinette.chatre(a)intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: john.stultz(a)linaro.org Cc: sboyd(a)kernel.org Cc: <stable(a)vger.kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: tj(a)kernel.org Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vikas Shivappa <vikas.shivappa(a)linux.intel.com> Cc: x86-ml <x86(a)kernel.org> Link: https://lkml.kernel.org/r/20191211033042.2188-1-cai@lca.pw --- arch/x86/kernel/cpu/resctrl/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 03eb90d..89049b3 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -618,7 +618,7 @@ static void domain_remove_cpu(int cpu, struct rdt_resource *r) if (static_branch_unlikely(&rdt_mon_enable_key)) rmdir_mondata_subdir_allrdtgrp(r, d->id); list_del(&d->list); - if (is_mbm_enabled()) + if (r->mon_capable && is_mbm_enabled()) cancel_delayed_work(&d->mbm_over); if (is_llc_occupancy_enabled() && has_busy_rmid(r, d)) { /*

5 years, 10 months

1
0
0 0

Re: [PATCH v3] tools lib: Fix builds when glibc contains strlcpy

by Vitaly Chikunov

Sasha, On Mon, Dec 30, 2019 at 12:56:03AM +0000, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: ce99091730c9 ("perf tools: Move strlcpy() from perf to tools/lib/string.c"). > > The bot has tested the following trees: v5.4.6, v5.3.18, v4.19.91, v4.14.160, v4.9.207. > > v5.4.6: Build OK! > v5.3.18: Build OK! > v4.19.91: Failed to apply! Possible dependencies: > 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources") > > v4.14.160: Failed to apply! Possible dependencies: > 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources") > > v4.9.207: Failed to apply! Possible dependencies: > 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources") > 96395cbbc7e9 ("tools lib string: Adopt prefixcmp() from perf and subcmd") > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? Yes, there is a trivial conflict when this patch is applied to stable trees. Do you need any help in resolving it? Thanks,

5 years, 10 months

1
0
0 0

[PATCH] USB-PD tcpm: bad warning+size, PPS adapters

by Douglas Gilbert

Augmented Power Delivery Objects (A)PDO_s are used by USB-C PD power adapters to advertize the voltages and currents they support. There can be up to 7 PDO_s but before PPS (programmable power supply) there were seldom more than 4 or 5. Recently Samsung released an optional PPS 45 Watt power adapter (EP-TA485) that has 7 PDO_s. It is for the Galaxy 10+ tablet and charges it quicker than the adapter supplied at purchase. The EP-TA485 causes an overzealous WARN_ON to soil the log plus it miscalculates the number of bytes to read. So this bug has been there for some time but goes undetected for the majority of USB-C PD power adapters on the market today that have 6 or less PDO_s. That may soon change as more USB-C PD adapters with PPS come to market. Tested on a EP-TA485 and an older Lenovo PN: SA10M13950 USB-C 65 Watt adapter (without PPS and has 4 PDO_s) plus several other PD power adapters. Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com> --- drivers/usb/typec/tcpm/tcpci.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c index c1f7073a56de..8b4ff9fff340 100644 --- a/drivers/usb/typec/tcpm/tcpci.c +++ b/drivers/usb/typec/tcpm/tcpci.c @@ -432,20 +432,30 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci) if (status & TCPC_ALERT_RX_STATUS) { struct pd_message msg; - unsigned int cnt; + unsigned int cnt, payload_cnt; u16 header; regmap_read(tcpci->regmap, TCPC_RX_BYTE_CNT, &cnt); + /* + * 'cnt' corresponds to READABLE_BYTE_COUNT in section 4.4.14 + * of the TCPCI spec [Rev 2.0 Ver 1.0 October 2017] and is + * defined in table 4-36 as one greater than the number of + * bytes received. And that number includes the header. So: + */ + if (cnt > 3) + payload_cnt = cnt - (1 + sizeof(msg.header)); + else + payload_cnt = 0; tcpci_read16(tcpci, TCPC_RX_HDR, &header); msg.header = cpu_to_le16(header); - if (WARN_ON(cnt > sizeof(msg.payload))) - cnt = sizeof(msg.payload); + if (WARN_ON(payload_cnt > sizeof(msg.payload))) + payload_cnt = sizeof(msg.payload); - if (cnt > 0) + if (payload_cnt > 0) regmap_raw_read(tcpci->regmap, TCPC_RX_DATA, - &msg.payload, cnt); + &msg.payload, payload_cnt); /* Read complete, clear RX status alert bit */ tcpci_write16(tcpci, TCPC_ALERT, TCPC_ALERT_RX_STATUS); -- 2.24.1

5 years, 10 months

3
2
0 0

Re: [PATCH v6 3/8] media: v4l2-core: compat: ignore native command codes

by Arnd Bergmann

On Thu, Dec 26, 2019 at 12:55 AM Sasha Levin <sashal(a)kernel.org> wrote: > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.4.5, v5.3.18, v4.19.90, v4.14.159, v4.9.206, v4.4.206. > > v5.4.5: Build OK! > v5.3.18: Build OK! > v4.19.90: Build OK! > v4.14.159: Failed to apply! Possible dependencies: > 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers") > fef6cc6b3618 ("media: v4l2-compat-ioctl32: fix several __user annotations") > > v4.9.206: Failed to apply! Possible dependencies: > 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers") > a56bc171598c ("[media] v4l: compat: Prevent allocating excessive amounts of memory") > ba7ed691dcce ("[media] v4l2-compat-ioctl32: VIDIOC_S_EDID should return all fields on error") > fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format") > fef6cc6b3618 ("media: v4l2-compat-ioctl32: fix several __user annotations") > > v4.4.206: Failed to apply! Possible dependencies: > 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces") > 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc") > 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build") > 234d549662a7 ("doc-rst: video: use reference for VIDIOC_ENUMINPUT") > 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)") > 6dd0394f5fcd ("media: v4l2-compat-ioctl32: better name userspace pointers") > 7347081e8a52 ("doc-rst: linux_tv: simplify references") > 789818845202 ("doc-rst: audio: Fix some cross references") > 94fff0dc5333 ("doc-rst: dmx_fcalls: improve man-like format") > 9e00ffca8cc7 ("doc-rst: querycap: fix troubles on some references") > af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls") > c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables") > e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference") > fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format") > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? I think we need it to support users of musl on old kernels: musl is adding conversion functions for emulating the new (time64) ioctl commands on top of the old format, and without my patch, the new commands do not necessarily return an error that musl can catch. I can provide a backport of my patch to v4.4 and v4.9 for this when the patch has made it into mainline. Can you notify me again when the time has come? A related question that we should address is whether we want the v4l2 and alsa time64 ioctl patches backported as well, and to which kernels (if any). My feeling is that we don't want them those in v4.14 and earlier because that is rather pointless with musl already having emulation in user space and the rest of the kernel not being y2038 safe at all. For v5.4 I'd say we do want them, and possibly all the other remaining y2038 patches as well, I have a tree[1] that I try to keep up to date with the versions that got posted and/or merged, as I know there is demand for it. If you prefer not to have them in v5.4.y, I can keep them here myself and make sure it's possible to my branch into that instead. v4.19 is a bit borderline: if we decide to do the backports to v5.4 and there is demand for v4.19.y, I could also try to pick the most important patches from my tree and backport them to v4.19.0 (including a lot of work that went into v5.1) and then look at that tree to see if it should be part of the official v4.19.y or not. Arnd [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…

5 years, 10 months

1
0
0 0

[PATCH] drm/i915/gt: Detect if we miss WaIdleLiteRestore

by Chris Wilson

In order to avoid confusing the HW, we must never submit an empty ring during lite-restore, that is we should always advance the RING_TAIL before submitting to stay ahead of the RING_HEAD. Normally this is prevented by keeping a couple of spare NOPs in the request->wa_tail so that on resubmission we can advance the tail. This relies on the request only being resubmitted once, which is the normal condition as it is seen once for ELSP[1] and then later in ELSP[0]. On preemption, the requests are unwound and the tail reset back to the normal end point (as we know the request is incomplete and therefore its RING_HEAD is even earlier). However, if this w/a should fail we would try and resubmit the request with the RING_TAIL already set to the location of this request's wa_tail potentially causing a GPU hang. We can spot when we do try and incorrectly resubmit without advancing the RING_TAIL and spare any embarrassment by forcing the context restore. In the case of preempt-to-busy, we leave the requests running on the HW while we unwind. As the ring is still live, we cannot rewind our rq->tail without forcing a reload so leave it set to rq->wa_tail and only force a reload if we resubmit after a lite-restore. (Normally, the forced reload will be a part of the preemption event.) Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Closes: https://gitlab.freedesktop.org/drm/intel/issues/673 Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20191209023215.3519970-1-chri… (cherry picked from commit 82c69bf58650e644c61aa2bf5100b63a1070fd2f) --- drivers/gpu/drm/i915/gt/intel_lrc.c | 42 ++++++++++++++--------------- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 06a506c29463..6600b2e08fe3 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -471,12 +471,6 @@ lrc_descriptor(struct intel_context *ce, struct intel_engine_cs *engine) return desc; } -static void unwind_wa_tail(struct i915_request *rq) -{ - rq->tail = intel_ring_wrap(rq->ring, rq->wa_tail - WA_TAIL_BYTES); - assert_ring_tail_valid(rq->ring, rq->tail); -} - static struct i915_request * __unwind_incomplete_requests(struct intel_engine_cs *engine) { @@ -495,7 +489,6 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine) continue; /* XXX */ __i915_request_unsubmit(rq); - unwind_wa_tail(rq); /* * Push the request back into the queue for later resubmission. @@ -649,13 +642,29 @@ execlists_schedule_out(struct i915_request *rq) i915_request_put(rq); } -static u64 execlists_update_context(const struct i915_request *rq) +static u64 execlists_update_context(struct i915_request *rq) { struct intel_context *ce = rq->hw_context; - u64 desc; + u64 desc = ce->lrc_desc; + u32 tail; - ce->lrc_reg_state[CTX_RING_TAIL + 1] = - intel_ring_set_tail(rq->ring, rq->tail); + /* + * WaIdleLiteRestore:bdw,skl + * + * We should never submit the context with the same RING_TAIL twice + * just in case we submit an empty ring, which confuses the HW. + * + * We append a couple of NOOPs (gen8_emit_wa_tail) after the end of + * the normal request to be able to always advance the RING_TAIL on + * subsequent resubmissions (for lite restore). Should that fail us, + * and we try and submit the same tail again, force the context + * reload. + */ + tail = intel_ring_set_tail(rq->ring, rq->tail); + if (unlikely(ce->lrc_reg_state[CTX_RING_TAIL + 1] == tail)) + desc |= CTX_DESC_FORCE_RESTORE; + ce->lrc_reg_state[CTX_RING_TAIL + 1] = tail; + rq->tail = rq->wa_tail; /* * Make sure the context image is complete before we submit it to HW. @@ -674,7 +683,6 @@ static u64 execlists_update_context(const struct i915_request *rq) */ mb(); - desc = ce->lrc_desc; ce->lrc_desc &= ~CTX_DESC_FORCE_RESTORE; return desc; @@ -1149,16 +1157,6 @@ static void execlists_dequeue(struct intel_engine_cs *engine) if (!list_is_last(&last->sched.link, &engine->active.requests)) return; - - /* - * WaIdleLiteRestore:bdw,skl - * Apply the wa NOOPs to prevent - * ring:HEAD == rq:TAIL as we resubmit the - * request. See gen8_emit_fini_breadcrumb() for - * where we prepare the padding after the - * end of the request. - */ - last->tail = last->wa_tail; } } -- 2.25.0.rc0

5 years, 10 months

1
0
0 0

[PATCH v1 2/2] scsi: ufs: remove link_startup_again flow in ufshcd_link_startup

by Stanley Chu

link_startup_again flow in ufshcd_link_startup() is not necessary since currently device can be moved to "active" power mode during resume flow by commit as below, "scsi: ufs: set device as default active power mode during initialization only" Fixes: 7caf489b99a4 (scsi: ufs: issue link starup 2 times if device isn't active) Cc: Alim Akhtar <alim.akhtar(a)samsung.com> Cc: Avri Altman <avri.altman(a)wdc.com> Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: Bean Huo <beanhuo(a)micron.com> Cc: Can Guo <cang(a)codeaurora.org> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Subhash Jadavani <subhashj(a)codeaurora.org> Cc: stable(a)vger.kernel.org Signed-off-by: Stanley Chu <stanley.chu(a)mediatek.com> --- drivers/scsi/ufs/ufshcd.c | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 9abb7085a5d0..1900f811394a 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -4365,16 +4365,7 @@ static int ufshcd_link_startup(struct ufs_hba *hba) { int ret; int retries = DME_LINKSTARTUP_RETRIES; - bool link_startup_again = false; - /* - * If UFS device isn't active then we will have to issue link startup - * 2 times to make sure the device state move to active. - */ - if (!ufshcd_is_ufs_dev_active(hba)) - link_startup_again = true; - -link_startup: do { ufshcd_vops_link_startup_notify(hba, PRE_CHANGE); @@ -4408,12 +4399,6 @@ static int ufshcd_link_startup(struct ufs_hba *hba) goto out; } - if (link_startup_again) { - link_startup_again = false; - retries = DME_LINKSTARTUP_RETRIES; - goto link_startup; - } - /* Mark that link is up in PWM-G1, 1-lane, SLOW-AUTO mode */ ufshcd_init_pwr_info(hba); ufshcd_print_pwr_info(hba); -- 2.18.0

5 years, 10 months

1
0
0 0

stable-rc/linux-4.4.y boot: 59 boots: 1 failed, 48 passed with 10 offline (v4.4.207-89-g5a02460e9487)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 59 boots: 1 failed, 48 passed with 10 offline (v4.4.207-89-g5a02460e9487) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.207-89-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.207-89-g5a02460e9487 Git Commit: 5a02460e948743bd660340b3c20a592fc0a82a08 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 36 unique boards, 13 SoC families, 14 builds out of 190 Boot Regressions Detected: arm: bcm2835_defconfig: gcc-8: bcm2835-rpi-b: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.207 - first fail: v4.4.207-86-g789721385a38) davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.207 - first fail: v4.4.207-86-g789721385a38) dm365evm,legacy: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.207 - first fail: v4.4.207-86-g789721385a38) Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: omap3-beagle: 1 failed lab Offline Platforms: arm: bcm2835_defconfig: gcc-8 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

stable-rc/linux-4.14.y boot: 110 boots: 1 failed, 96 passed with 12 offline, 1 untried/unknown (v4.14.160-162-g9973cdd1885a)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 110 boots: 1 failed, 96 passed with 12 offline, 1 untried/unknown (v4.14.160-162-g9973cdd1885a) 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.160-1… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.160-162-g9973cdd1885a Git Commit: 9973cdd1885ac46b53c6db9f07b9e22003b8b1fd Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 65 unique boards, 20 SoC families, 15 builds out of 201 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: new failure (last pass: v4.14.160-151-gb53246546618) dm365evm,legacy: lab-baylibre-seattle: new failure (last pass: v4.14.160-151-gb53246546618) Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxm-q200: 1 failed lab Offline Platforms: arm64: defconfig: gcc-8 juno-r2: 1 offline lab mt7622-rfb1: 1 offline lab arm: bcm2835_defconfig: gcc-8 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

stable-rc/linux-4.9.y boot: 95 boots: 0 failed, 82 passed with 12 offline, 1 untried/unknown (v4.9.207-110-gaf5664cd41c2)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 95 boots: 0 failed, 82 passed with 12 offline, 1 untried/unknown (v4.9.207-110-gaf5664cd41c2) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.207-110… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.207-110-gaf5664cd41c2 Git Commit: af5664cd41c220ec7cbfb604852207264fabe7b0 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 52 unique boards, 18 SoC families, 16 builds out of 197 Boot Regressions Detected: arm: bcm2835_defconfig: gcc-8: bcm2835-rpi-b: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.207 - first fail: v4.9.207-106-g8425bd2da54f) davinci_all_defconfig: gcc-8: da850-evm: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.207 - first fail: v4.9.207-106-g8425bd2da54f) dm365evm,legacy: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.207 - first fail: v4.9.207-106-g8425bd2da54f) socfpga_defconfig: gcc-8: socfpga_cyclone5_de0_sockit: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.207 - first fail: v4.9.207-106-g8425bd2da54f) arm64: defconfig: gcc-8: juno-r2: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.207 - first fail: v4.9.207-106-g8425bd2da54f) Offline Platforms: arm64: defconfig: gcc-8 juno-r2: 1 offline lab arm: sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab bcm2835_defconfig: gcc-8 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab socfpga_defconfig: gcc-8 socfpga_cyclone5_de0_sockit: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab exynos_defconfig: gcc-8 exynos5800-peach-pi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror