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

[PATCH 05/75] perf env: Also consider env->arch == NULL as local operation

by Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <acme(a)redhat.com> We'll set a new machine field based on env->arch, which for live mode, like with 'perf top' means we need to use uname() to figure the name of the arch, fix perf_env__arch() to consider both (env == NULL) and (env->arch == NULL) as local operation. Cc: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Andi Kleen <ak(a)linux.intel.com> Cc: David Ahern <dsahern(a)gmail.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Leo Yan <leo.yan(a)linaro.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Wang Nan <wangnan0(a)huawei.com> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/n/tip-vcz4ufzdon7cwy8dm2ua53xk@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/util/env.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c index 59f38c7693f8..4c23779e271a 100644 --- a/tools/perf/util/env.c +++ b/tools/perf/util/env.c @@ -166,7 +166,7 @@ const char *perf_env__arch(struct perf_env *env) struct utsname uts; char *arch_name; - if (!env) { /* Assume local operation */ + if (!env || !env->arch) { /* Assume local operation */ if (uname(&uts) < 0) return NULL; arch_name = uts.machine; -- 2.19.2

6 years, 11 months

1
0
0 0

[PATCH 3/3] drm/i915/execlists: Apply a full mb before execution for Braswell

by Chris Wilson

Braswell is really picky about having our writes posted to memory before we execute or else the GPU may see stale values. A wmb() is insufficient as it only ensures the writes are visible to other cores, we need a full mb() to ensure the writes are in memory and visible to the GPU. The most frequent failure in flushing before execution is that we see stale PTE values and execute the wrong pages. References: 987abd5c62f9 ("drm/i915/execlists: Force write serialisation into context image vs execution") 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> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/intel_lrc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index de1e9dc6aec0..e6a86fa4502d 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -379,8 +379,13 @@ static u64 execlists_update_context(struct i915_request *rq) * may not be visible to the HW prior to the completion of the UC * register write and that we may begin execution from the context * before its image is complete leading to invalid PD chasing. + * + * Furthermore, Braswell, at least, wants a full mb to be sure that + * the writes are coherent in memory (visible to the GPU) prior to + * execution, and not just visible to other CPUs (as is the result of + * wmb). */ - wmb(); + mb(); return ce->lrc_desc; } -- 2.20.0.rc2

6 years, 11 months

2
2
0 0

stable-rc/linux-4.4.y boot: 102 boots: 1 failed, 100 passed with 1 offline (v4.4.166-57-g4e21c8c946b3)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 102 boots: 1 failed, 100 passed with 1 offline (v4.4.166-57-g4e21c8c946b3) 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.166-57-… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.166-57-g4e21c8c946b3 Git Commit: 4e21c8c946b3ad212abb91845378dbe0f3042ccd Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 45 unique boards, 21 SoC families, 15 builds out of 187 Boot Failure Detected: arm64: defconfig qcom-qdf2400: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 119 passed with 1 offline (v4.19.7-42-g62b84b3cf313)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 119 passed with 1 offline (v4.19.7-42-g62b84b3cf313) 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.7-42-… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.7-42-g62b84b3cf313 Git Commit: 62b84b3cf313e064c6ad249e95a5fb8feb22c77e Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 60 unique boards, 23 SoC families, 14 builds out of 202 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

[PATCH] ASoC: intel: cht_bsw_max98090_ti: Add pmc_plt_clk_0 quirk for Chromebook Gnawty

by Hans de Goede

The Gnawty model Chromebook uses pmc_plt_clk_0 instead of pmc_plt_clk_3 for the mclk, just like the Clapper and Swanky models. This commit adds a DMI based quirk for this. This fixing audio no longer working on these devices after commit 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") that commit fixes us unnecessary keeping unused clocks on, but in case of the Gnawty that was breaking audio support since we were not using the right clock in the cht_bsw_max98090_ti machine driver. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201787 Cc: stable(a)vger.kernel.org Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Reported-and-tested-by: Jaime Pérez <19.jaime.91(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/boards/cht_bsw_max98090_ti.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/intel/boards/cht_bsw_max98090_ti.c b/sound/soc/intel/boards/cht_bsw_max98090_ti.c index ad0c98383853..08a5152e635a 100644 --- a/sound/soc/intel/boards/cht_bsw_max98090_ti.c +++ b/sound/soc/intel/boards/cht_bsw_max98090_ti.c @@ -396,6 +396,13 @@ static const struct dmi_system_id cht_max98090_quirk_table[] = { }, .driver_data = (void *)QUIRK_PMC_PLT_CLK_0, }, + { + /* Gnawty model Chromebook (Acer Chromebook CB3-111) */ + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "Gnawty"), + }, + .driver_data = (void *)QUIRK_PMC_PLT_CLK_0, + }, { /* Swanky model Chromebook (Toshiba Chromebook 2) */ .matches = { -- 2.19.2

6 years, 11 months

3
2
0 0

stable-rc/linux-4.14.y boot: 117 boots: 1 failed, 114 passed with 1 offline, 1 untried/unknown (v4.14.86-56-g555f40d53cca)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 117 boots: 1 failed, 114 passed with 1 offline, 1 untried/unknown (v4.14.86-56-g555f40d53cca) 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.86-56… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.86-56-g555f40d53cca Git Commit: 555f40d53ccac2c84734383d6d86dba512b5e033 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 57 unique boards, 22 SoC families, 14 builds out of 197 Boot Regressions Detected: arm: tegra_defconfig: tegra124-nyan-big: lab-collabora: new failure (last pass: v4.14.86) Boot Failure Detected: arm: tegra_defconfig tegra124-nyan-big: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

stable-rc/linux-4.9.y boot: 105 boots: 0 failed, 104 passed with 1 offline (v4.9.143-102-gcf137e4b4373)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 105 boots: 0 failed, 104 passed with 1 offline (v4.9.143-102-gcf137e4b4373) 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.143-102… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.143-102-gcf137e4b4373 Git Commit: cf137e4b43737b5c238350d3e22f031c616dd9f9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 47 unique boards, 20 SoC families, 15 builds out of 193 Offline Platforms: arm: multi_v7_defconfig: stih410-b2120: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

PASS: Test report for kernel 4.19.8-rc1.skt+ (linux-stable-rc)

by CKI

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 62b84b3cf313 Linux 4.19.8-rc1 The results of these automated tests are provided below. Overall result: PASSED Patch merge: OK Compile: OK Kernel tests: OK 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 2 architectures: aarch64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/aarch64/62b84b3cf313e064c6ad249e95… x86_64: make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg configuration: https://artifacts.cki-project.org/builds/x86_64/62b84b3cf313e064c6ad249e95a… Hardware testing ---------------- We booted each kernel and ran the following tests: arm64: /distribution/kpkginstall (boot test) LTP lite - release 20180515 xfstests: ext4 xfstests: xfs /kernel/misc/amtu x86_64: /distribution/kpkginstall (boot test) LTP lite - release 20180515 xfstests: ext4 xfstests: xfs /kernel/misc/amtu

6 years, 11 months

1
0
0 0

stable-rc/linux-3.18.y boot: 62 boots: 5 failed, 57 passed (v3.18.128-34-g7642a7c148f7)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 62 boots: 5 failed, 57 passed (v3.18.128-34-g7642a7c148f7) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.128-3… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.128-34-g7642a7c148f7 Git Commit: 7642a7c148f75bee48d892128d79b0f7676114fe Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 25 unique boards, 12 SoC families, 14 builds out of 185 Boot Failures Detected: arm: exynos_defconfig exynos4412-odroidx2: 1 failed lab x86: x86_64_defconfig qemu: 3 failed labs x86-atom330: 1 failed lab --- For more info write to <info(a)kernelci.org>

6 years, 11 months

1
0
0 0

[PATCH][v2] btrfs: run delayed items before dropping the snapshot

by Josef Bacik

From: Josef Bacik <jbacik(a)fb.com> With my delayed refs patches in place we started seeing a large amount of aborts in __btrfs_free_extent BTRFS error (device sdb1): unable to find ref byte nr 91947008 parent 0 root 35964 owner 1 offset 0 Call Trace: ? btrfs_merge_delayed_refs+0xaf/0x340 __btrfs_run_delayed_refs+0x6ea/0xfc0 ? btrfs_set_path_blocking+0x31/0x60 btrfs_run_delayed_refs+0xeb/0x180 btrfs_commit_transaction+0x179/0x7f0 ? btrfs_check_space_for_delayed_refs+0x30/0x50 ? should_end_transaction.isra.19+0xe/0x40 btrfs_drop_snapshot+0x41c/0x7c0 btrfs_clean_one_deleted_snapshot+0xb5/0xd0 cleaner_kthread+0xf6/0x120 kthread+0xf8/0x130 ? btree_invalidatepage+0x90/0x90 ? kthread_bind+0x10/0x10 ret_from_fork+0x35/0x40 This was because btrfs_drop_snapshot depends on the root not being modified while it's dropping the snapshot. It will unlock the root node (and really every node) as it walks down the tree, only to re-lock it when it needs to do something. This is a problem because if we modify the tree we could cow a block in our path, which free's our reference to that block. Then once we get back to that shared block we'll free our reference to it again, and get ENOENT when trying to lookup our extent reference to that block in __btrfs_free_extent. This is ultimately happening because we have delayed items left to be processed for our deleted snapshot _after_ all of the inodes are closed for the snapshot. We only run the delayed inode item if we're deleting the inode, and even then we do not run the delayed insertions or delayed removals. These can be run at any point after our final inode does it's last iput, which is what triggers the snapshot deletion. We can end up with the snapshot deletion happening and then have the delayed items run on that file system, resulting in the above problem. This problem has existed forever, however my patches made it much easier to hit as I wake up the cleaner much more often to deal with delayed iputs, which made us more likely to start the snapshot dropping work before the transaction commits, which is when the delayed items would generally be run. Before, generally speaking, we would run the delayed items, commit the transaction, and wakeup the cleaner thread to start deleting snapshots, which means we were less likely to hit this problem. You could still hit it if you had multiple snapshots to be deleted and ended up with lots of delayed items, but it was definitely harder. Fix for now by simply running all the delayed items before starting to drop the snapshot. We could make this smarter in the future by making the delayed items per-root, and then simply drop any delayed items for roots that we are going to delete. But for now just a quick and easy solution is the safest. Cc: stable(a)vger.kernel.org Signed-off-by: Josef Bacik <josef(a)toxicpanda.com> --- v1->v2: - check for errors from btrfs_run_delayed_items. - Dave I can reroll the series, but the second version of patch 1 is the same, let me know what you want. fs/btrfs/extent-tree.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index dcb699dd57f3..473084eb7a2d 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -9330,6 +9330,10 @@ int btrfs_drop_snapshot(struct btrfs_root *root, goto out_free; } + err = btrfs_run_delayed_items(trans); + if (err) + goto out_end_trans; + if (block_rsv) trans->block_rsv = block_rsv; -- 2.14.3

6 years, 11 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror