* [igt-dev] ✓ Fi.CI.BAT: success for tests/i915/userptr: fix mapping type
From: Patchwork @ 2022-01-05 19:05 UTC (permalink / raw)
To: Matthew Auld; +Cc: igt-dev
In-Reply-To: <20220105172106.154217-1-matthew.auld@intel.com>
[-- Attachment #1: Type: text/plain, Size: 8456 bytes --]
== Series Details ==
Series: tests/i915/userptr: fix mapping type
URL : https://patchwork.freedesktop.org/series/98511/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11049 -> IGTPW_6539
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
Participating hosts (44 -> 37)
------------------------------
Additional (2): fi-kbl-soraka fi-icl-u2
Missing (9): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 fi-pnv-d510 bat-rpls-1 fi-bdw-samus bat-jsl-2 bat-jsl-1
Known issues
------------
Here are the changes found in IGTPW_6539 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@amdgpu/amd_cs_nop@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271]) +18 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-skl-6600u/igt@amdgpu/amd_cs_nop@sync-fork-gfx0.html
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +25 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@gem_exec_fence@basic-busy@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#2190])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@gem_lmem_swapping@parallel-random-engines.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick: [PASS][8] -> [INCOMPLETE][9] ([i915#2940])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-nick/igt@i915_selftest@live@execlists.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-nick/igt@i915_selftest@live@execlists.html
- fi-bsw-kefka: [PASS][10] -> [INCOMPLETE][11] ([i915#2940])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
- fi-bsw-n3050: [PASS][12] -> [INCOMPLETE][13] ([i915#2940])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][14] ([i915#1886] / [i915#2291])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][16] ([fdo#111827]) +8 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][17] -> [DMESG-WARN][18] ([i915#1982])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][19] ([fdo#109278]) +2 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][20] ([fdo#109285])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#533])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][22] ([i915#3301])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-icl-u2/igt@prime_vgem@basic-userptr.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][23] ([fdo#109271] / [i915#1436] / [i915#2722] / [i915#3428] / [i915#4312])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-kefka/igt@runner@aborted.html
- fi-bsw-nick: NOTRUN -> [FAIL][24] ([fdo#109271] / [i915#1436] / [i915#2722] / [i915#3428] / [i915#4312])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-bsw-nick/igt@runner@aborted.html
#### Possible fixes ####
* igt@i915_pm_rpm@module-reload:
- {fi-tgl-dsi}: [DMESG-WARN][25] ([i915#1982] / [i915#2411]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-tgl-dsi/igt@i915_pm_rpm@module-reload.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-tgl-dsi/igt@i915_pm_rpm@module-reload.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [FAIL][27] ([i915#4547]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11049/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_6323 -> IGTPW_6539
CI-20190529: 20190529
CI_DRM_11049: 3d3993f1fe1bb5ca43cd787b753db177cd9d48ab @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_6539: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
IGT_6323: 9dbaa0d5be7a859cda9b7d54c20ba96a596f43bd @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_6539/index.html
[-- Attachment #2: Type: text/html, Size: 10696 bytes --]
^ permalink raw reply
* Re: [PATCH][TRIVIAL] btrfs-progs: Allow autodetect_object_types() to handle the link.
From: Boris Burkov @ 2022-01-05 19:05 UTC (permalink / raw)
To: kreijack; +Cc: linux-btrfs
In-Reply-To: <d4132584-faef-713e-aa7f-542257de3cfd@libero.it>
On Wed, Jan 05, 2022 at 07:23:33PM +0100, Goffredo Baroncelli wrote:
> On 05/01/2022 18.50, Boris Burkov wrote:
> > On Wed, Jan 05, 2022 at 02:32:58PM +0100, Goffredo Baroncelli wrote:
> > > From: Goffredo Baroncelli <kreijack@inwind.it>
> [...]
> >
> > I took a look at the original lstat and it doesn't seem super strongly
> > motivated. It is used to detect a subvolume object (ino==256) so I don't
> > see why we would hate to have property get/set work on a symlink to a
> > subvol.
>
> It is not so simple: think about a case where the symlink points to a
> subvolume of *another* filesystem.
>
> Now, "btrfs prop get" returns the property (e.g. the label) of the *underlining*
> filesystem. If we change statl to stat, it still return the property of the
> underlining filesystem, thinking that it is a subvolume (of a foreign filesystem).
>
> If fact I added an exception of that rule, because if we pass a block device, we
> don't consider the underling filesystem, but the filesystem contained in the block
> device. But there is a precedence in get/set label.
>
> Anyway, symlink created some confusion, and I bet that in btrfs there are areas
> with incoherence around symlink between the pointed object and the underling
> filesystem.
Good point. I agree that btrfs (the tool) is not the most rigorous with
symlinks. In this very function, we check if it is a btrfs object by
opening the file without O_NOFOLLOW, but then we do this lstat.
I'm not exactly sure what you are alluding to regarding the precedent set
by label, but I tested links and labels and it seems to exhibit the link
following behavior.
mkfs.btrfs -f /dev/loop0
mkfs.btrfs -f -L LOOP /dev/loop1
mount /dev/loop0 /mnt/0
mount /dev/loop1 /mnt/1
ln -s /mnt/1 /mnt/0/lnk
btrfs property get /mnt/0 label
label=
btrfs property get /mnt/1 label
label=LOOP
btrfs property get /mnt/0/lnk label
label=LOOP
btrfs property get /mnt/0/lnk ro
ERROR: object is not compatible with property: ro
So it looks like root detection follows links but subvol detection does
not. Without testing, but judging by the code, I think inode follows
symlinks too. So with all that said, I think the most consistent is to
make subvol follow the symlink, unless you have a really confusing
unexpected behavior in mind with links out to another btrfs that I am
failing to see.
Thanks,
Boris
>
> BR
> G.Baroncelli
>
> --
> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
^ permalink raw reply
* Re: [syzbot] kernel BUG in __page_mapcount
From: Yang Shi @ 2022-01-05 19:05 UTC (permalink / raw)
To: Matthew Wilcox
Cc: syzbot, Andrew Morton, Alistair Popple, chinwen.chang, fgheet255t,
Jann Horn, Konstantin Khlebnikov, Kirill A. Shutemov,
Kirill A. Shutemov, Linux FS-devel Mailing List,
Linux Kernel Mailing List, Linux MM, Peter Xu, Peter Zijlstra,
syzkaller-bugs, tonymarislogistics, Vlastimil Babka, walken,
Zi Yan
In-Reply-To: <YcIfj3nfuL0kzkFO@casper.infradead.org>
On Tue, Dec 21, 2021 at 10:40 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Dec 21, 2021 at 10:24:27AM -0800, Yang Shi wrote:
> > It seems the THP is split during smaps walk. The reproducer does call
> > MADV_FREE on partial THP which may split the huge page.
> >
> > The below fix (untested) should be able to fix it.
>
> Did you read the rest of the thread on this? If the page is being
I just revisited this. Now I see what you mean about "the rest of the
thread". My gmail client doesn't put them in the same thread, sigh...
Yeah, try_get_compound_head() seems like the right way.
Or we just simply treat migration entries as mapcount == 1 as Kirill
suggested or just skip migration entries since they are transient or
show migration entries separately.
> migrated, we should still account it ... also, you've changed the
> refcount, so this:
>
> if (page_count(page) == 1) {
> smaps_page_accumulate(mss, page, size, size << PSS_SHIFT, dirty,
> locked, true);
> return;
> }
>
> will never trigger.
^ permalink raw reply
* Re: [PATCH 1/1] RDMA/rxe: Remove the unused variable
From: Jason Gunthorpe @ 2022-01-05 19:06 UTC (permalink / raw)
To: yanjun.zhu; +Cc: zyjzyj2000, dledford, linux-rdma, leon
In-Reply-To: <20211216054842.1099428-1-yanjun.zhu@linux.dev>
On Thu, Dec 16, 2021 at 12:48:42AM -0500, yanjun.zhu@linux.dev wrote:
> From: Zhu Yanjun <yanjun.zhu@linux.dev>
>
> The member variable xmit_errors can be replaced with
> rxe_counter_inc(rxe, RXE_CNT_SEND_ERR) totally. So
> remove it.
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
> Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/infiniband/sw/rxe/rxe_net.c | 1 -
> drivers/infiniband/sw/rxe/rxe_verbs.h | 2 --
> 2 files changed, 3 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH v9 04/10] pagemap,pmem: Introduce ->memory_failure()
From: Darrick J. Wong @ 2022-01-05 19:06 UTC (permalink / raw)
To: Shiyang Ruan
Cc: linux-kernel, linux-xfs, nvdimm, linux-mm, linux-fsdevel,
dan.j.williams, david, hch, jane.chu, Christoph Hellwig
In-Reply-To: <20211226143439.3985960-5-ruansy.fnst@fujitsu.com>
On Sun, Dec 26, 2021 at 10:34:33PM +0800, Shiyang Ruan wrote:
> When memory-failure occurs, we call this function which is implemented
> by each kind of devices. For the fsdax case, pmem device driver
> implements it. Pmem device driver will find out the filesystem in which
> the corrupted page located in.
>
> With dax_holder notify support, we are able to notify the memory failure
> from pmem driver to upper layers. If there is something not support in
> the notify routine, memory_failure will fall back to the generic hanlder.
>
> Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/nvdimm/pmem.c | 16 ++++++++++++++++
> include/linux/memremap.h | 9 +++++++++
> mm/memory-failure.c | 14 ++++++++++++++
> 3 files changed, 39 insertions(+)
>
> diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
> index 4190c8c46ca8..2114554358eb 100644
> --- a/drivers/nvdimm/pmem.c
> +++ b/drivers/nvdimm/pmem.c
> @@ -386,6 +386,20 @@ static void pmem_release_disk(void *__pmem)
> blk_cleanup_disk(pmem->disk);
> }
>
> +static int pmem_pagemap_memory_failure(struct dev_pagemap *pgmap,
> + unsigned long pfn, u64 len, int mf_flags)
> +{
> + struct pmem_device *pmem =
> + container_of(pgmap, struct pmem_device, pgmap);
> + loff_t offset = PFN_PHYS(pfn) - pmem->phys_addr - pmem->data_offset;
Use u64 here ^^^ because this isn't a file offset, this is a physical
offset. Also, loff_t is signed, which you probably don't want.
> +
> + return dax_holder_notify_failure(pmem->dax_dev, offset, len, mf_flags);
> +}
> +
> +static const struct dev_pagemap_ops fsdax_pagemap_ops = {
> + .memory_failure = pmem_pagemap_memory_failure,
> +};
> +
> static int pmem_attach_disk(struct device *dev,
> struct nd_namespace_common *ndns)
> {
> @@ -448,6 +462,7 @@ static int pmem_attach_disk(struct device *dev,
> pmem->pfn_flags = PFN_DEV;
> if (is_nd_pfn(dev)) {
> pmem->pgmap.type = MEMORY_DEVICE_FS_DAX;
> + pmem->pgmap.ops = &fsdax_pagemap_ops;
> addr = devm_memremap_pages(dev, &pmem->pgmap);
> pfn_sb = nd_pfn->pfn_sb;
> pmem->data_offset = le64_to_cpu(pfn_sb->dataoff);
> @@ -461,6 +476,7 @@ static int pmem_attach_disk(struct device *dev,
> pmem->pgmap.range.end = res->end;
> pmem->pgmap.nr_range = 1;
> pmem->pgmap.type = MEMORY_DEVICE_FS_DAX;
> + pmem->pgmap.ops = &fsdax_pagemap_ops;
> addr = devm_memremap_pages(dev, &pmem->pgmap);
> pmem->pfn_flags |= PFN_MAP;
> bb_range = pmem->pgmap.range;
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index c0e9d35889e8..820c2f33b163 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -87,6 +87,15 @@ struct dev_pagemap_ops {
> * the page back to a CPU accessible page.
> */
> vm_fault_t (*migrate_to_ram)(struct vm_fault *vmf);
> +
> + /*
> + * Handle the memory failure happens on a range of pfns. Notify the
> + * processes who are using these pfns, and try to recover the data on
> + * them if necessary. The mf_flags is finally passed to the recover
> + * function through the whole notify routine.
Might want to state here that the generic implementation will be used if
->memory_failure is NULL or calling the function returns -EOPNOTSUPP.
--D
> + */
> + int (*memory_failure)(struct dev_pagemap *pgmap, unsigned long pfn,
> + u64 len, int mf_flags);
> };
>
> #define PGMAP_ALTMAP_VALID (1 << 0)
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 1ee7d626fed7..3cc612b29f89 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1625,6 +1625,20 @@ static int memory_failure_dev_pagemap(unsigned long pfn, int flags,
> if (!pgmap_pfn_valid(pgmap, pfn))
> goto out;
>
> + /*
> + * Call driver's implementation to handle the memory failure, otherwise
> + * fall back to generic handler.
> + */
> + if (pgmap->ops->memory_failure) {
> + rc = pgmap->ops->memory_failure(pgmap, pfn, PAGE_SIZE, flags);
> + /*
> + * Fall back to generic handler too if operation is not
> + * supported inside the driver/device/filesystem.
> + */
> + if (rc != -EOPNOTSUPP)
> + goto out;
> + }
> +
> rc = mf_generic_kill_procs(pfn, flags, pgmap);
> out:
> /* drop pgmap ref acquired in caller */
> --
> 2.34.1
>
>
>
^ permalink raw reply
* Re: [PATCH] RDMA/rxe: fix a typo in opcode name
From: Jason Gunthorpe @ 2022-01-05 19:06 UTC (permalink / raw)
To: Chengguang Xu; +Cc: zyjzyj2000, linux-rdma, linux-kernel
In-Reply-To: <20211218112320.3558770-1-cgxu519@mykernel.net>
On Sat, Dec 18, 2021 at 07:23:20PM +0800, Chengguang Xu wrote:
> There is a redundant ']' in the name of opcode IB_OPCODE_RC_SEND_MIDDLE,
> so just fix it.
>
> Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
> Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com>
> Reviewed-by: Bob Pearson <rpearsonhpe@gmail.com>
> ---
> drivers/infiniband/sw/rxe/rxe_opcode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next, thanks
I added a fixes line
Jason
^ permalink raw reply
* Re: [oe] [meta-networking][PATCH v2] ifupdown-ng: Add recipe
From: Khem Raj @ 2022-01-05 19:06 UTC (permalink / raw)
To: Ross Burton, Alex Kiernan
Cc: Otavio Salvador, OpenEmbedded Devel List, Alex Kiernan
In-Reply-To: <1097f292-fa38-e981-4d4e-b3f3c0f21a2e@gmail.com>
btw. it fails to compile with musl
https://errors.yoctoproject.org/Errors/Details/621451/
On Wed, Jan 5, 2022 at 8:37 AM Khem Raj <raj.khem@gmail.com> wrote:
>
>
>
> On 1/5/22 8:36 AM, Ross Burton wrote:
> > On Wed, 5 Jan 2022 at 12:51, Alex Kiernan <alex.kiernan@gmail.com> wrote:
> >> Smaller if anything (though I've just realised I've not dealt the
> >> ALTERNATIVES paths correctly):
> >
> > There's a case to be made for just conflicting with ifupdown and not
> > bothering with alternatives.
>
> thats works for me.
>
> >
> > Ross
> >
> >
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#94662): https://lists.openembedded.org/g/openembedded-devel/message/94662
> > Mute This Topic: https://lists.openembedded.org/mt/88115930/1997914
> > Group Owner: openembedded-devel+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [raj.khem@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
^ permalink raw reply
* Re: [PATCH rdma-next] RDMA/mlx5: print wc status on CQE error and dump needed
From: Jason Gunthorpe @ 2022-01-05 19:06 UTC (permalink / raw)
To: Dust Li; +Cc: linux-rdma, linux-kernel, Leon Romanovsky
In-Reply-To: <20211227123806.47530-1-dust.li@linux.alibaba.com>
On Mon, Dec 27, 2021 at 08:38:06PM +0800, Dust Li wrote:
> mlx5_handle_error_cqe() only dump the content of the CQE
> which is raw hex data, and not straighforward for debug.
> Print WC status message when we got CQE error and dump is
> need.
>
> Here is an example of how the dmesg log looks like with this:
> [166755.330649] infiniband mlx5_0: mlx5_handle_error_cqe:333:(pid 0): WC error: 10, message: remote access error
> [166755.332323] infiniband mlx5_0: dump_cqe:272:(pid 0): dump error cqe
> [166755.332944] 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [166755.333574] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [166755.334202] 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [166755.334837] 00000030: 00 00 00 00 00 00 88 13 08 03 61 b3 1e a1 42 d3
>
> Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
> Acked-by: Leon Romanovsky <leonro@nvidia.com>
> ---
> drivers/infiniband/hw/mlx5/cq.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH BlueZ] Use audio-card-bluetooth icon
From: Luiz Augusto von Dentz @ 2022-01-05 19:07 UTC (permalink / raw)
To: Nicolas Fella; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20211223175005.52976-1-nicolas.fella@gmx.de>
Hi Nicolas,
On Fri, Dec 24, 2021 at 5:06 PM Nicolas Fella <nicolas.fella@gmx.de> wrote:
>
> PulseAudio uses this icon for this kind of device
>
> Let's be consistent
>
> Users will gracefully fall back to audio-card if audio-card-bluetooth
> is not found
> ---
> src/dbus-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/dbus-common.c b/src/dbus-common.c
> index 5e2c83d52..3611cb013 100644
> --- a/src/dbus-common.c
> +++ b/src/dbus-common.c
> @@ -80,7 +80,7 @@ const char *class_to_icon(uint32_t class)
> case 0x0d: /* Camcorder */
> return "camera-video";
> default:
> - return "audio-card"; /* Other audio device */
> + return "audio-card-bluetooth"; /* Other audio device */
> }
> break;
> case 0x05:
> --
> 2.34.1
It doesn't seem to be part of
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html,
does the icon themes really have such icon?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: psi_trigger_poll() is completely broken
From: Linus Torvalds @ 2022-01-05 19:07 UTC (permalink / raw)
To: Eric Biggers, Tejun Heo, Zefan Li
Cc: Johannes Weiner, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Ingo Molnar, Hillf Danton, syzbot, linux-fsdevel,
Linux Kernel Mailing List, syzkaller-bugs, Linux-MM
In-Reply-To: <CAHk-=wjqh_R9w4-=wfegut2C0Bg=sJaPrayk39JRCkZc=O+gsw@mail.gmail.com>
On Wed, Jan 5, 2022 at 10:50 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That would require that 'psi_trigger_replace()' serialize with the
> waitqueue lock (easy)
I take the "easy" back. The other side of that serialization would
require that the poll() side also re-lookup the trigger pointer under
that same lock.
And you can't do that with the waitqueue lock, because 'poll_wait()'
does the add_wait_queue() internally, and that will take the waitqueue
lock. So you can't take and hold the waitqueue lock in the caller in
poll, it would just deadlock.
And not holding the lock over the call would mean that you'd have a
small race between adding a new poll waiter, and checking that the
trigger is still the same one.
We could use another lock - the code in kernel/sched/psi.c already does
mutex_lock(&seq->lock);
psi_trigger_replace(&seq->private, new);
mutex_unlock(&seq->lock);
and could use that same lock around the poll sequence too.
But the cgroup_pressure_write() code doesn't even do that, and
concurrent writes aren't serialized at all (much less concurrent
poll() calls).
Side note: it looks like concurrent writes in the
cgroup_pressure_write() is literally broken. Because
psi_trigger_replace() is *not* handling concurrency, and does that
struct psi_trigger *old = *trigger_ptr;
....
if (old)
kref_put(&old->refcount, psi_trigger_destroy);
assuming that the caller holds some lock that makes '*trigger_ptr' a
stable thing.
Again, kernel/sched/psi.c itself does that already, but the cgroup
code doesn't seem to.
So the bugs in this area go deeper than "just" poll(). The whole
psi_trigger_replace() thing is literally broken even ignoring the
poll() interactions.
Whoever came up with that stupid "replace existing trigger with a
write()" model should feel bad. It's garbage, and it's actively buggy
in multiple ways.
Linus
^ permalink raw reply
* Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for More preparation for multi gt patches (rev4)
From: Matt Roper @ 2022-01-05 19:08 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <164136695171.25402.13838167692358518273@emeril.freedesktop.org>
On Wed, Jan 05, 2022 at 07:15:51AM +0000, Patchwork wrote:
> == Series Details ==
>
> Series: More preparation for multi gt patches (rev4)
> URL : https://patchwork.freedesktop.org/series/98215/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11047_full -> Patchwork_21923_full
> ====================================================
>
> Summary
> -------
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21923_full absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21923_full, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (13 -> 12)
> ------------------------------
>
> Missing (1): shard-dg1
>
> Possible new issues
> -------------------
>
> Here are the unknown changes that may have been introduced in Patchwork_21923_full:
>
> ### IGT changes ###
>
> #### Possible regressions ####
>
> * igt@i915_selftest@perf@region:
> - shard-snb: [PASS][1] -> [DMESG-FAIL][2]
> [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-snb5/igt@i915_selftest@perf@region.html
> [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-snb5/igt@i915_selftest@perf@region.html
Looks to be the same as
https://gitlab.freedesktop.org/drm/intel/-/issues/4610
>
> * igt@kms_plane_alpha_blend@pipe-d-alpha-opaque-fb:
> - shard-tglb: [PASS][3] -> [INCOMPLETE][4]
> [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb7/igt@kms_plane_alpha_blend@pipe-d-alpha-opaque-fb.html
> [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb3/igt@kms_plane_alpha_blend@pipe-d-alpha-opaque-fb.html
Random system crash / connection loss? Incomplete result doesn't appear
to be related to the series here.
Series applied to drm-intel-gt-next. Thanks for the patches.
Matt
>
>
> #### Suppressed ####
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@gem_exec_flush@basic-wb-prw-default:
> - {shard-rkl}: [PASS][5] -> [INCOMPLETE][6] +1 similar issue
> [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-2/igt@gem_exec_flush@basic-wb-prw-default.html
> [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-5/igt@gem_exec_flush@basic-wb-prw-default.html
>
> * igt@gem_exec_schedule@u-submit-early-slice@bcs0:
> - {shard-tglu}: [PASS][7] -> [INCOMPLETE][8]
> [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-8/igt@gem_exec_schedule@u-submit-early-slice@bcs0.html
> [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglu-7/igt@gem_exec_schedule@u-submit-early-slice@bcs0.html
>
> * igt@gem_exec_whisper@basic-contexts-forked-all:
> - {shard-rkl}: [PASS][9] -> ([PASS][10], [INCOMPLETE][11])
> [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-1/igt@gem_exec_whisper@basic-contexts-forked-all.html
> [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-4/igt@gem_exec_whisper@basic-contexts-forked-all.html
> [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-5/igt@gem_exec_whisper@basic-contexts-forked-all.html
>
> * igt@i915_pm_dc@dc6-psr:
> - {shard-tglu}: NOTRUN -> [SKIP][12]
> [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglu-3/igt@i915_pm_dc@dc6-psr.html
>
> * igt@testdisplay:
> - {shard-tglu}: [PASS][13] -> [DMESG-WARN][14]
> [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-1/igt@testdisplay.html
> [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglu-5/igt@testdisplay.html
>
>
> Known issues
> ------------
>
> Here are the changes found in Patchwork_21923_full that come from known issues:
>
> ### IGT changes ###
>
> #### Issues hit ####
>
> * igt@gem_create@create-massive:
> - shard-tglb: NOTRUN -> [DMESG-WARN][15] ([i915#3002])
> [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@gem_create@create-massive.html
> - shard-skl: NOTRUN -> [DMESG-WARN][16] ([i915#3002])
> [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl1/igt@gem_create@create-massive.html
>
> * igt@gem_eio@in-flight-contexts-10ms:
> - shard-tglb: [PASS][17] -> [TIMEOUT][18] ([i915#3063])
> [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb7/igt@gem_eio@in-flight-contexts-10ms.html
> [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb2/igt@gem_eio@in-flight-contexts-10ms.html
>
> * igt@gem_exec_balancer@parallel-contexts:
> - shard-iclb: NOTRUN -> [SKIP][19] ([i915#4525])
> [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@gem_exec_balancer@parallel-contexts.html
>
> * igt@gem_exec_fair@basic-none@vcs0:
> - shard-apl: [PASS][20] -> [FAIL][21] ([i915#2842])
> [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl4/igt@gem_exec_fair@basic-none@vcs0.html
> [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl3/igt@gem_exec_fair@basic-none@vcs0.html
>
> * igt@gem_exec_fair@basic-none@vecs0:
> - shard-kbl: [PASS][22] -> [FAIL][23] ([i915#2842])
> [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl1/igt@gem_exec_fair@basic-none@vecs0.html
> [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl7/igt@gem_exec_fair@basic-none@vecs0.html
>
> * igt@gem_exec_fair@basic-throttle@rcs0:
> - shard-iclb: [PASS][24] -> [FAIL][25] ([i915#2842])
> [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb5/igt@gem_exec_fair@basic-throttle@rcs0.html
> [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html
>
> * igt@gem_exec_suspend@basic-s3@smem:
> - shard-kbl: [PASS][26] -> [DMESG-WARN][27] ([i915#180]) +2 similar issues
> [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl3/igt@gem_exec_suspend@basic-s3@smem.html
> [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl4/igt@gem_exec_suspend@basic-s3@smem.html
>
> * igt@gem_huc_copy@huc-copy:
> - shard-kbl: NOTRUN -> [SKIP][28] ([fdo#109271] / [i915#2190])
> [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl7/igt@gem_huc_copy@huc-copy.html
>
> * igt@gem_lmem_swapping@parallel-random:
> - shard-apl: NOTRUN -> [SKIP][29] ([fdo#109271] / [i915#4613])
> [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl2/igt@gem_lmem_swapping@parallel-random.html
> - shard-kbl: NOTRUN -> [SKIP][30] ([fdo#109271] / [i915#4613]) +1 similar issue
> [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@gem_lmem_swapping@parallel-random.html
>
> * igt@gem_lmem_swapping@parallel-random-verify:
> - shard-iclb: NOTRUN -> [SKIP][31] ([i915#4613])
> [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@gem_lmem_swapping@parallel-random-verify.html
>
> * igt@gem_lmem_swapping@random:
> - shard-skl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#4613])
> [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl10/igt@gem_lmem_swapping@random.html
>
> * igt@gem_lmem_swapping@smem-oom:
> - shard-tglb: NOTRUN -> [SKIP][33] ([i915#4613])
> [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@gem_lmem_swapping@smem-oom.html
>
> * igt@gem_softpin@allocator-evict@rcs0:
> - shard-iclb: NOTRUN -> [DMESG-WARN][34] ([i915#4391])
> [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@gem_softpin@allocator-evict@rcs0.html
>
> * igt@gem_userptr_blits@vma-merge:
> - shard-skl: NOTRUN -> [FAIL][35] ([i915#3318])
> [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl1/igt@gem_userptr_blits@vma-merge.html
>
> * igt@i915_pm_dc@dc6-dpms:
> - shard-kbl: NOTRUN -> [FAIL][36] ([i915#454])
> [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@i915_pm_dc@dc6-dpms.html
>
> * igt@i915_pm_rpm@modeset-pc8-residency-stress:
> - shard-apl: NOTRUN -> [SKIP][37] ([fdo#109271]) +102 similar issues
> [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl8/igt@i915_pm_rpm@modeset-pc8-residency-stress.html
>
> * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
> - shard-skl: NOTRUN -> [FAIL][38] ([i915#3743])
> [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl4/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
>
> * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
> - shard-kbl: NOTRUN -> [SKIP][39] ([fdo#109271] / [i915#3777]) +1 similar issue
> [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl7/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
>
> * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
> - shard-skl: NOTRUN -> [FAIL][40] ([i915#3763])
> [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl4/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
>
> * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
> - shard-apl: NOTRUN -> [SKIP][41] ([fdo#109271] / [i915#3777])
> [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl2/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
>
> * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip:
> - shard-skl: NOTRUN -> [SKIP][42] ([fdo#109271] / [i915#3777])
> [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl3/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
>
> * igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
> - shard-kbl: NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#3886]) +8 similar issues
> [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
>
> * igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
> - shard-skl: NOTRUN -> [SKIP][44] ([fdo#109271] / [i915#3886]) +5 similar issues
> [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl3/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
>
> * igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
> - shard-apl: NOTRUN -> [SKIP][45] ([fdo#109271] / [i915#3886]) +4 similar issues
> [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl1/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
>
> * igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
> - shard-iclb: NOTRUN -> [SKIP][46] ([fdo#109278] / [i915#3886])
> [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
>
> * igt@kms_chamelium@dp-hpd-storm-disable:
> - shard-apl: NOTRUN -> [SKIP][47] ([fdo#109271] / [fdo#111827]) +6 similar issues
> [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl2/igt@kms_chamelium@dp-hpd-storm-disable.html
>
> * igt@kms_color@pipe-d-ctm-0-25:
> - shard-iclb: NOTRUN -> [SKIP][48] ([fdo#109278] / [i915#1149])
> [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@kms_color@pipe-d-ctm-0-25.html
>
> * igt@kms_color_chamelium@pipe-a-ctm-blue-to-red:
> - shard-kbl: NOTRUN -> [SKIP][49] ([fdo#109271] / [fdo#111827]) +12 similar issues
> [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@kms_color_chamelium@pipe-a-ctm-blue-to-red.html
>
> * igt@kms_color_chamelium@pipe-b-ctm-max:
> - shard-skl: NOTRUN -> [SKIP][50] ([fdo#109271] / [fdo#111827]) +10 similar issues
> [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl10/igt@kms_color_chamelium@pipe-b-ctm-max.html
>
> * igt@kms_content_protection@atomic-dpms:
> - shard-apl: NOTRUN -> [TIMEOUT][51] ([i915#1319])
> [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl8/igt@kms_content_protection@atomic-dpms.html
>
> * igt@kms_cursor_crc@pipe-d-cursor-512x170-random:
> - shard-tglb: NOTRUN -> [SKIP][52] ([fdo#109279] / [i915#3359])
> [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@kms_cursor_crc@pipe-d-cursor-512x170-random.html
>
> * igt@kms_cursor_crc@pipe-d-cursor-512x512-sliding:
> - shard-iclb: NOTRUN -> [SKIP][53] ([fdo#109278]) +1 similar issue
> [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@kms_cursor_crc@pipe-d-cursor-512x512-sliding.html
>
> * igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic:
> - shard-tglb: NOTRUN -> [SKIP][54] ([fdo#109274] / [fdo#111825])
> [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic.html
>
> * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
> - shard-skl: [PASS][55] -> [FAIL][56] ([i915#2346] / [i915#533])
> [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl7/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
> [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
>
> * igt@kms_fbcon_fbt@fbc-suspend:
> - shard-kbl: NOTRUN -> [INCOMPLETE][57] ([i915#180] / [i915#636])
> [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl6/igt@kms_fbcon_fbt@fbc-suspend.html
>
> * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
> - shard-skl: [PASS][58] -> [FAIL][59] ([i915#79]) +1 similar issue
> [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
> [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl6/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
>
> * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
> - shard-apl: [PASS][60] -> [DMESG-WARN][61] ([i915#180]) +4 similar issues
> [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
> [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl3/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
>
> * igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1:
> - shard-skl: [PASS][62] -> [FAIL][63] ([i915#2122]) +1 similar issue
> [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl6/igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1.html
> [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl9/igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1.html
>
> * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling:
> - shard-glk: [PASS][64] -> [FAIL][65] ([i915#4911])
> [64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-glk3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
> [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-upscaling.html
>
> * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling:
> - shard-iclb: [PASS][66] -> [SKIP][67] ([i915#3701]) +1 similar issue
> [66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb8/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
> [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
>
> * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt:
> - shard-kbl: NOTRUN -> [SKIP][68] ([fdo#109271]) +163 similar issues
> [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html
>
> * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-wc:
> - shard-tglb: NOTRUN -> [SKIP][69] ([fdo#109280] / [fdo#111825]) +1 similar issue
> [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-mmap-wc.html
>
> * igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack-mmap-gtt:
> - shard-skl: NOTRUN -> [SKIP][70] ([fdo#109271]) +123 similar issues
> [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl4/igt@kms_frontbuffer_tracking@fbcpsr-1p-shrfb-fliptrack-mmap-gtt.html
>
> * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-mmap-cpu:
> - shard-iclb: NOTRUN -> [SKIP][71] ([fdo#109280]) +3 similar issues
> [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-mmap-cpu.html
>
> * igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d:
> - shard-apl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#533])
> [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl2/igt@kms_pipe_crc_basic@disable-crc-after-crtc-pipe-d.html
>
> * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
> - shard-skl: [PASS][73] -> [FAIL][74] ([fdo#108145] / [i915#265])
> [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
> [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
>
> * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
> - shard-skl: NOTRUN -> [FAIL][75] ([fdo#108145] / [i915#265]) +1 similar issue
> [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl3/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
>
> * igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
> - shard-apl: NOTRUN -> [SKIP][76] ([fdo#109271] / [i915#658])
> [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl1/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
>
> * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
> - shard-kbl: NOTRUN -> [SKIP][77] ([fdo#109271] / [i915#658]) +1 similar issue
> [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
>
> * igt@kms_psr@psr2_sprite_blt:
> - shard-iclb: [PASS][78] -> [SKIP][79] ([fdo#109441])
> [78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
> [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb5/igt@kms_psr@psr2_sprite_blt.html
>
> * igt@kms_psr@psr2_sprite_render:
> - shard-iclb: NOTRUN -> [SKIP][80] ([fdo#109441])
> [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@kms_psr@psr2_sprite_render.html
>
> * igt@kms_vblank@pipe-d-wait-idle:
> - shard-kbl: NOTRUN -> [SKIP][81] ([fdo#109271] / [i915#533]) +2 similar issues
> [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@kms_vblank@pipe-d-wait-idle.html
>
> * igt@kms_writeback@writeback-invalid-parameters:
> - shard-kbl: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#2437])
> [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl3/igt@kms_writeback@writeback-invalid-parameters.html
> - shard-apl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#2437])
> [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl2/igt@kms_writeback@writeback-invalid-parameters.html
>
> * igt@kms_writeback@writeback-pixel-formats:
> - shard-skl: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#2437])
> [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl10/igt@kms_writeback@writeback-pixel-formats.html
>
> * igt@nouveau_crc@pipe-a-ctx-flip-skip-current-frame:
> - shard-iclb: NOTRUN -> [SKIP][85] ([i915#2530])
> [85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb7/igt@nouveau_crc@pipe-a-ctx-flip-skip-current-frame.html
>
> * igt@nouveau_crc@pipe-b-ctx-flip-detection:
> - shard-tglb: NOTRUN -> [SKIP][86] ([i915#2530])
> [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@nouveau_crc@pipe-b-ctx-flip-detection.html
>
> * igt@sysfs_clients@create:
> - shard-skl: NOTRUN -> [SKIP][87] ([fdo#109271] / [i915#2994])
> [87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl3/igt@sysfs_clients@create.html
>
> * igt@sysfs_clients@split-10:
> - shard-apl: NOTRUN -> [SKIP][88] ([fdo#109271] / [i915#2994])
> [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl4/igt@sysfs_clients@split-10.html
>
> * igt@sysfs_clients@split-50:
> - shard-kbl: NOTRUN -> [SKIP][89] ([fdo#109271] / [i915#2994]) +1 similar issue
> [89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl7/igt@sysfs_clients@split-50.html
>
>
> #### Possible fixes ####
>
> * igt@feature_discovery@psr2:
> - shard-iclb: [SKIP][90] ([i915#658]) -> [PASS][91]
> [90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb4/igt@feature_discovery@psr2.html
> [91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb2/igt@feature_discovery@psr2.html
>
> * igt@gem_eio@in-flight-contexts-10ms:
> - shard-skl: [TIMEOUT][92] ([i915#3063]) -> [PASS][93]
> [92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-skl4/igt@gem_eio@in-flight-contexts-10ms.html
> [93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-skl4/igt@gem_eio@in-flight-contexts-10ms.html
>
> * igt@gem_eio@unwedge-stress:
> - shard-iclb: [TIMEOUT][94] ([i915#2481] / [i915#3070]) -> [PASS][95]
> [94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb2/igt@gem_eio@unwedge-stress.html
> [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb8/igt@gem_eio@unwedge-stress.html
>
> * igt@gem_exec_balancer@parallel-out-fence:
> - shard-iclb: [SKIP][96] ([i915#4525]) -> [PASS][97] +1 similar issue
> [96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb8/igt@gem_exec_balancer@parallel-out-fence.html
> [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb2/igt@gem_exec_balancer@parallel-out-fence.html
>
> * igt@gem_exec_fair@basic-none-share@rcs0:
> - shard-iclb: [FAIL][98] ([i915#2842]) -> [PASS][99] +1 similar issue
> [98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb1/igt@gem_exec_fair@basic-none-share@rcs0.html
> [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb2/igt@gem_exec_fair@basic-none-share@rcs0.html
>
> * igt@gem_exec_fair@basic-none@rcs0:
> - shard-kbl: [FAIL][100] ([i915#2842]) -> [PASS][101]
> [100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl1/igt@gem_exec_fair@basic-none@rcs0.html
> [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl7/igt@gem_exec_fair@basic-none@rcs0.html
>
> * igt@gem_exec_fair@basic-none@vecs0:
> - shard-apl: [FAIL][102] ([i915#2842]) -> [PASS][103]
> [102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl4/igt@gem_exec_fair@basic-none@vecs0.html
> [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl3/igt@gem_exec_fair@basic-none@vecs0.html
>
> * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-tglb: [FAIL][104] ([i915#2842]) -> [PASS][105]
> [104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
> [105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglb6/igt@gem_exec_fair@basic-pace-share@rcs0.html
>
> * igt@gem_exec_parallel@fds@bcs0:
> - {shard-rkl}: [INCOMPLETE][106] -> ([PASS][107], [PASS][108])
> [106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@gem_exec_parallel@fds@bcs0.html
> [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-4/igt@gem_exec_parallel@fds@bcs0.html
> [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-2/igt@gem_exec_parallel@fds@bcs0.html
>
> * igt@gem_exec_suspend@basic@smem:
> - {shard-rkl}: [INCOMPLETE][109] -> [PASS][110] +2 similar issues
> [109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@gem_exec_suspend@basic@smem.html
> [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@gem_exec_suspend@basic@smem.html
>
> * igt@gem_exec_whisper@basic-contexts-priority:
> - shard-glk: [DMESG-WARN][111] ([i915#118]) -> [PASS][112] +1 similar issue
> [111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-glk8/igt@gem_exec_whisper@basic-contexts-priority.html
> [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-glk4/igt@gem_exec_whisper@basic-contexts-priority.html
>
> * igt@gem_ppgtt@blt-vs-render-ctxn:
> - {shard-tglu}: [INCOMPLETE][113] ([i915#750]) -> [PASS][114] +1 similar issue
> [113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-7/igt@gem_ppgtt@blt-vs-render-ctxn.html
> [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglu-8/igt@gem_ppgtt@blt-vs-render-ctxn.html
>
> * igt@gem_workarounds@suspend-resume-context:
> - shard-apl: [DMESG-WARN][115] ([i915#180]) -> [PASS][116] +3 similar issues
> [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-apl3/igt@gem_workarounds@suspend-resume-context.html
> [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-apl4/igt@gem_workarounds@suspend-resume-context.html
>
> * igt@i915_pm_rc6_residency@rc6-fence:
> - {shard-tglu}: [WARN][117] ([i915#2681]) -> [PASS][118]
> [117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-1/igt@i915_pm_rc6_residency@rc6-fence.html
> [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglu-5/igt@i915_pm_rc6_residency@rc6-fence.html
>
> * igt@i915_pm_rpm@gem-mmap-type@uc:
> - {shard-rkl}: [SKIP][119] ([fdo#109308]) -> [PASS][120] +3 similar issues
> [119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@i915_pm_rpm@gem-mmap-type@uc.html
> [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@i915_pm_rpm@gem-mmap-type@uc.html
>
> * igt@i915_selftest@live@gt_pm:
> - {shard-tglu}: [DMESG-FAIL][121] ([i915#3987]) -> [PASS][122]
> [121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-tglu-8/igt@i915_selftest@live@gt_pm.html
> [122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-tglu-7/igt@i915_selftest@live@gt_pm.html
>
> * igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs:
> - {shard-rkl}: [SKIP][123] ([i915#1845] / [i915#4098]) -> [PASS][124]
> [123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs.html
> [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs.html
>
> * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
> - {shard-rkl}: ([PASS][125], [SKIP][126]) ([fdo#112022]) -> [PASS][127]
> [125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html
> [126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-4/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html
> [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html
>
> * igt@kms_cursor_crc@pipe-c-cursor-suspend:
> - shard-kbl: [DMESG-WARN][128] ([i915#180]) -> [PASS][129] +3 similar issues
> [128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
> [129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-kbl6/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
>
> * igt@kms_cursor_legacy@flip-vs-cursor-toggle:
> - shard-iclb: [FAIL][130] ([i915#2346]) -> [PASS][131] +1 similar issue
> [130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
> [131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb8/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
>
> * igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled:
> - {shard-rkl}: [SKIP][132] ([fdo#111314]) -> [PASS][133]
> [132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled.html
> [133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled.html
>
> * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling:
> - shard-iclb: [SKIP][134] ([i915#3701]) -> [PASS][135] +1 similar issue
> [134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling.html
> [135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-iclb5/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling.html
>
> * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
> - {shard-rkl}: [SKIP][136] ([i915#4098]) -> [PASS][137]
> [136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html
> [137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html
>
> * igt@kms_frontbuffer_tracking@fbcpsr-tiling-y:
> - {shard-rkl}: [SKIP][138] ([i915#1849]) -> [PASS][139] +3 similar issues
> [138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/shard-rkl-5/igt@kms_frontbuffer_tracking@fbcpsr-tiling-y.html
> [139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/shard-rkl-6/igt@kms_frontbuff
>
> == Logs ==
>
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21923/index.html
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
^ permalink raw reply
* [PATCH] meson.build: Print gtk version in the summary info
From: Thomas Huth @ 2022-01-05 19:08 UTC (permalink / raw)
To: qemu-devel; +Cc: qemu-trivial, Paolo Bonzini
The "gtk" variable is re-declared as "dependencies: [gtk, gtkx11]",
so there is just a "YES" in the summary info if gtk has been found.
Let's use the info from the library detection instead so that the
library version is printed in the summary instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
meson.build | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meson.build b/meson.build
index 82769749db..798811dfbb 100644
--- a/meson.build
+++ b/meson.build
@@ -1058,11 +1058,11 @@ gtk = not_found
gtkx11 = not_found
vte = not_found
if not get_option('gtk').auto() or (have_system and not cocoa.found())
- gtk = dependency('gtk+-3.0', version: '>=3.22.0',
- method: 'pkg-config',
- required: get_option('gtk'),
- kwargs: static_kwargs)
- if gtk.found()
+ libgtk = dependency('gtk+-3.0', version: '>=3.22.0',
+ method: 'pkg-config',
+ required: get_option('gtk'),
+ kwargs: static_kwargs)
+ if libgtk.found()
gtkx11 = dependency('gtk+-x11-3.0', version: '>=3.22.0',
method: 'pkg-config',
required: false,
@@ -3410,7 +3410,7 @@ if targetos == 'darwin'
endif
summary_info += {'SDL support': sdl}
summary_info += {'SDL image support': sdl_image}
-summary_info += {'GTK support': gtk}
+summary_info += {'GTK support': libgtk}
summary_info += {'pixman': pixman}
summary_info += {'VTE support': vte}
summary_info += {'slirp support': slirp_opt == 'internal' ? slirp_opt : slirp}
--
2.27.0
^ permalink raw reply related
* Re: mkimage_fit_atf.sh: not found
From: Tim Harvey @ 2022-01-05 19:08 UTC (permalink / raw)
To: ZHIZHIKIN Andrey
Cc: u-boot, Stefano Babic, Fabio Estevam, Schrempf Frieder, Adam Ford,
Marcel Ziswiler, Jagan Teki
In-Reply-To: <AM6PR06MB469167D132403B1818D380F8A64B9@AM6PR06MB4691.eurprd06.prod.outlook.com>
On Wed, Jan 5, 2022 at 3:34 AM ZHIZHIKIN Andrey
<andrey.zhizhikin@leica-geosystems.com> wrote:
>
> Hello Tim,
>
> > -----Original Message-----
> > From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Tim Harvey
> > Sent: Tuesday, January 4, 2022 11:48 PM
> > To: u-boot <u-boot@lists.denx.de>; Stefano Babic <sbabic@denx.de>; Fabio Estevam
> > <festevam@gmail.com>
> > Cc: Schrempf Frieder <frieder.schrempf@kontron.de>; Adam Ford
> > <aford173@gmail.com>; Marcel Ziswiler <marcel@ziswiler.com>; Jagan Teki
> > <jagan@amarulasolutions.com>
> > Subject: mkimage_fit_atf.sh: not found
> >
> > Stefano and Fabio,
> >
> > I'm seeing the imx8mm_venice_defconfig target failing to build on
> > master due to mkimage_fit_atf.sh not found:
> > ./"arch/arm/mach-imx/mkimage_fit_atf.sh" \
> > arch/arm/dts/imx8mm-venice-gw71xx-0x.dtb
> > arch/arm/dts/imx8mm-venice-gw72xx-0x.dtb
> > arch/arm/dts/imx8mm-venice-gw73xx-0x.dtb
> > arch/arm/dts/imx8mm-venice-gw7901.dtb
> > arch/arm/dts/imx8mm-venice-gw7902.dtb > u-boot.its
> > /bin/sh: 1: ./arch/arm/mach-imx/mkimage_fit_atf.sh: not found
> >
>
> This has been dropped in d9a6f0eed6 ("tree: imx: remove old fit generator script")
So why was that merged when it breaks several boards that are not
switched to binman because of the CI issue?
>
> > As far as I can tell the other boards that are still using
> > SPL_FIT_GENERATOR also fail due to this (ie imx8mm_beacon_defconfig,
> > imx8mq_evk_defconfig, imx8mm-icore-mx8mm-edimm2.2_defconfig, etc).
>
> imx8mq_evk is already converted and I've sent a patch for it, see [1].
>
> >
> > What is the state of the binman conversion? I submitted a series to
> > convert my boards to binman and it has just been sitting without any
> > response for months now [1].
>
> I believe that the reason for your series sitting in the queue is the same as
> for imx8mq_evk: missing binary blobs (ATF and DDR) are failing CI builds.
>
Right, so imx8mq_evk (and others) are completely broken for the
pending release correct?
Sounds like we need to revert d9a6f0eed6 ("tree: imx: remove old fit
generator script")
Tim
> >
> > I'm not sure when the above breakage occurred but the conversion to
> > binman resolves it and other things.
> >
> > Please let me know what you expect me to do to resolve this as there
> > is a release pending.
> >
> > Best regards,
> >
> > Tim
> > [1] https://patchwork.ozlabs.org/project/uboot/patch/20211006201700.3018-1-
> > tharvey@gateworks.com/
>
> -- andrey
>
> Link: [1]: http://patchwork.ozlabs.org/project/uboot/patch/20211203161802.12699-1-andrey.zhizhikin@leica-geosystems.com/
^ permalink raw reply
* Re: [PATCH v2 8/8] merge-tree: provide an easy way to access which files have conflicts
From: Ramsay Jones @ 2022-01-05 19:09 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget, git
Cc: Christian Couder, Taylor Blau, Johannes Altmanninger,
Elijah Newren
In-Reply-To: <01364bb020ee2836016ec0e8eafa2261fb7800ab.1641403655.git.gitgitgadget@gmail.com>
On 05/01/2022 17:27, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
>
> Callers of `git merge-tree --real` might want an easy way to determine
> which files conflicted. While they could potentially use the --messages
> option and parse the resulting messages written to that file, those
> messages are not meant to be machine readable. Provide a simpler
> mechanism of having the user specify --unmerged-list=$FILENAME, and then
s/unmerged-list/conflicted-list/
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Revert "net: usb: r8152: Add MAC passthrough support for more Lenovo Docks"
From: Henning Schild @ 2022-01-05 19:09 UTC (permalink / raw)
To: Aaron Ma
Cc: Oliver Neukum, kuba, linux-usb, netdev, linux-kernel, davem,
hayeswang, tiwai
In-Reply-To: <fa192218-4fc8-678f-8b40-95b85e36097e@canonical.com>
Am Thu, 6 Jan 2022 00:05:28 +0800
schrieb Aaron Ma <aaron.ma@canonical.com>:
> On 1/6/22 00:01, Oliver Neukum wrote:
> >
> > On 05.01.22 16:51, Aaron Ma wrote:
> >> This reverts commit f77b83b5bbab53d2be339184838b19ed2c62c0a5.
> >>
> >> This change breaks multiple usb to ethernet dongles attached on
> >> Lenovo USB hub.
> >
> > Hi,
> >
> > now we should maybe discuss a sensible way to identify device
> > that should use passthrough. Are your reasons to not have a list
> > of devices maintainability or is it impossible?
> >
>
> The USB to ethernet ID is 0bda:8153. It's is original Realtek 8153 ID.
> It's impossible.
>
> And ocp data are 0.
> No way to identify it's from dock.
Is that revert you giving up on the other one? Maybe these IDs offer a
way after all.
One of my offending devices is a idVendor=13b1, idProduct=0041 from
Linksys so probably clearly not Lenovo, was just plugged into a Lenovo
hub.
The other one is a idVendor=17ef, idProduct=7214 so actually a Lenovo
travel hub. And probably rightfully getting a pass-thru ... if we want
to keep that feature in the kernel and not push it out to udev (for all
vendors)
Anyhow, it seems like the revert is coming. And i will disable that
feature in the BIOS to be sure. But i will be happy to test further
patches.
regards,
Henning
> Aaron
>
> > Regards
> > Oliver
> >
^ permalink raw reply
* Re: [PATCH] xfs/014: try a few times to create speculative preallocations
From: Darrick J. Wong @ 2022-01-05 19:09 UTC (permalink / raw)
To: Eryu Guan, fstests, xfs, zlang
In-Reply-To: <20220105161905.jaobft32wosjy3fv@zlang-mailbox>
On Thu, Jan 06, 2022 at 12:19:05AM +0800, Zorro Lang wrote:
> On Mon, Jan 03, 2022 at 06:04:17PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > This test checks that speculative file preallocations are transferred to
> > threads writing other files when space is low. Since we have background
> > threads to clear those preallocations, it's possible that the test
> > program might not get a speculative preallocation on the first try.
> >
> > This problem has become more pronounced since the introduction of
> > background inode inactivation since userspace no longer has direct
> > control over the timing of file blocks being released from unlinked
> > files. As a result, the author has seen an increase in sporadic
> > warnings from this test about speculative preallocations not appearing.
> >
> > Therefore, modify the function to try up to five times to create the
> > speculative preallocation before emitting warnings that then cause
> > golden output failures.
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> > tests/xfs/014 | 41 +++++++++++++++++++++++++----------------
> > 1 file changed, 25 insertions(+), 16 deletions(-)
> >
> > diff --git a/tests/xfs/014 b/tests/xfs/014
> > index a605b359..1f0ebac3 100755
> > --- a/tests/xfs/014
> > +++ b/tests/xfs/014
> > @@ -33,27 +33,36 @@ _cleanup()
> > # failure.
> > _spec_prealloc_file()
> > {
> > - file=$1
> > + local file=$1
> > + local prealloc_size=0
> > + local i=0
> >
> > - rm -f $file
> > + # Now that we have background garbage collection processes that can be
> > + # triggered by low space/quota conditions, it's possible that we won't
> > + # succeed in creating a speculative preallocation on the first try.
> > + for ((tries = 0; tries < 5 && prealloc_size == 0; tries++)); do
> > + rm -f $file
> >
> > - # a few file extending open-write-close cycles should be enough to
> > - # trigger the fs to retain preallocation. write 256k in 32k intervals to
> > - # be sure
> > - for i in $(seq 0 32768 262144); do
> > - $XFS_IO_PROG -f -c "pwrite $i 32k" $file >> $seqres.full
> > + # a few file extending open-write-close cycles should be enough
> > + # to trigger the fs to retain preallocation. write 256k in 32k
> > + # intervals to be sure
> > + for i in $(seq 0 32768 262144); do
> > + $XFS_IO_PROG -f -c "pwrite $i 32k" $file >> $seqres.full
> > + done
> > +
> > + # write a 4k aligned amount of data to keep the calculations
> > + # simple
> > + $XFS_IO_PROG -c "pwrite 0 128m" $file >> $seqres.full
> > +
> > + size=`_get_filesize $file`
> > + blocks=`stat -c "%b" $file`
> > + blocksize=`stat -c "%B" $file`
> > +
> > + prealloc_size=$((blocks * blocksize - size))
>
> So we only try same pwrite operations 5 times, and only check the prealloc_size after 5
> times done? Should we break from this loop once prealloc_size > 0?
The second clause of the for loop tests for that, does it not?
--D
>
> Thanks,
> Zorro
>
> > done
> >
> > - # write a 4k aligned amount of data to keep the calculations simple
> > - $XFS_IO_PROG -c "pwrite 0 128m" $file >> $seqres.full
> > -
> > - size=`_get_filesize $file`
> > - blocks=`stat -c "%b" $file`
> > - blocksize=`stat -c "%B" $file`
> > -
> > - prealloc_size=$((blocks * blocksize - size))
> > if [ $prealloc_size -eq 0 ]; then
> > - echo "Warning: No speculative preallocation for $file." \
> > + echo "Warning: No speculative preallocation for $file after $tries iterations." \
> > "Check use of the allocsize= mount option."
> > fi
> >
> >
>
^ permalink raw reply
* RE: [PATCH net-next 1/1] ice: Simplify tracking status of RDMA support
From: Ertman, David M @ 2022-01-05 19:10 UTC (permalink / raw)
To: Leon Romanovsky, Nguyen, Anthony L
Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Saleem, Shiraz, Ismail, Mustafa,
Kaliszczuk, Leszek
In-Reply-To: <YdVGaK1uMUv7frZ1@unreal>
> -----Original Message-----
> From: Leon Romanovsky <leon@kernel.org>
> Sent: Tuesday, January 4, 2022 11:19 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
> Cc: davem@davemloft.net; kuba@kernel.org; Ertman, David M
> <david.m.ertman@intel.com>; netdev@vger.kernel.org; linux-
> rdma@vger.kernel.org; Saleem, Shiraz <shiraz.saleem@intel.com>; Ismail,
> Mustafa <mustafa.ismail@intel.com>; Kaliszczuk, Leszek
> <leszek.kaliszczuk@intel.com>
> Subject: Re: [PATCH net-next 1/1] ice: Simplify tracking status of RDMA
> support
>
> On Tue, Jan 04, 2022 at 04:04:56PM -0800, Tony Nguyen wrote:
> > From: Dave Ertman <david.m.ertman@intel.com>
> >
> > The status of support for RDMA is currently being tracked with two
> > separate status flags. This is unnecessary with the current state of
> > the driver.
> >
> > Simplify status tracking down to a single flag.
> >
> > Rename the helper function to denote the RDMA specific status and
> > universally use the helper function to test the status bit.
> >
> > Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> > Tested-by: Leszek Kaliszczuk <leszek.kaliszczuk@intel.com>
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> > ---
> > drivers/net/ethernet/intel/ice/ice.h | 3 ---
> > drivers/net/ethernet/intel/ice/ice_idc.c | 6 +++---
> > drivers/net/ethernet/intel/ice/ice_lib.c | 8 ++++----
> > drivers/net/ethernet/intel/ice/ice_lib.h | 2 +-
> > drivers/net/ethernet/intel/ice/ice_main.c | 13 +++++--------
> > 5 files changed, 13 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice.h
> b/drivers/net/ethernet/intel/ice/ice.h
> > index 4e16d185077d..6f445cc3390f 100644
> > --- a/drivers/net/ethernet/intel/ice/ice.h
> > +++ b/drivers/net/ethernet/intel/ice/ice.h
> > @@ -468,7 +468,6 @@ enum ice_pf_flags {
> > ICE_FLAG_FD_ENA,
> > ICE_FLAG_PTP_SUPPORTED, /* PTP is supported by NVM
> */
> > ICE_FLAG_PTP, /* PTP is enabled by software */
> > - ICE_FLAG_AUX_ENA,
> > ICE_FLAG_ADV_FEATURES,
> > ICE_FLAG_TC_MQPRIO, /* support for Multi queue TC
> */
> > ICE_FLAG_CLS_FLOWER,
> > @@ -886,7 +885,6 @@ static inline void ice_set_rdma_cap(struct ice_pf
> *pf)
> > {
> > if (pf->hw.func_caps.common_cap.rdma && pf->num_rdma_msix) {
> > set_bit(ICE_FLAG_RDMA_ENA, pf->flags);
> > - set_bit(ICE_FLAG_AUX_ENA, pf->flags);
> > ice_plug_aux_dev(pf);
> > }
> > }
> > @@ -899,6 +897,5 @@ static inline void ice_clear_rdma_cap(struct ice_pf
> *pf)
> > {
> > ice_unplug_aux_dev(pf);
> > clear_bit(ICE_FLAG_RDMA_ENA, pf->flags);
> > - clear_bit(ICE_FLAG_AUX_ENA, pf->flags);
> > }
> > #endif /* _ICE_H_ */
> > diff --git a/drivers/net/ethernet/intel/ice/ice_idc.c
> b/drivers/net/ethernet/intel/ice/ice_idc.c
> > index fc3580167e7b..9493a38182f5 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_idc.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_idc.c
> > @@ -79,7 +79,7 @@ int ice_add_rdma_qset(struct ice_pf *pf, struct
> iidc_rdma_qset_params *qset)
> >
> > dev = ice_pf_to_dev(pf);
> >
> > - if (!test_bit(ICE_FLAG_RDMA_ENA, pf->flags))
> > + if (!ice_is_rdma_ena(pf))
> > return -EINVAL;
> >
> > vsi = ice_get_main_vsi(pf);
> > @@ -236,7 +236,7 @@ EXPORT_SYMBOL_GPL(ice_get_qos_params);
> > */
> > static int ice_reserve_rdma_qvector(struct ice_pf *pf)
> > {
> > - if (test_bit(ICE_FLAG_RDMA_ENA, pf->flags)) {
> > + if (ice_is_rdma_ena(pf)) {
> > int index;
> >
> > index = ice_get_res(pf, pf->irq_tracker, pf-
> >num_rdma_msix,
> > @@ -274,7 +274,7 @@ int ice_plug_aux_dev(struct ice_pf *pf)
> > /* if this PF doesn't support a technology that requires auxiliary
> > * devices, then gracefully exit
> > */
> > - if (!ice_is_aux_ena(pf))
> > + if (!ice_is_rdma_ena(pf))
> > return 0;
>
> This check is redundant, you already checked it in ice_probe.
>
This function is called from other places besides ice_probe (after a reset for instance).
This central check stops the creation of the auxiliary device if it has been determined if
RDMA functionality should not be allowed whenever ice_plug_aux_dev is called. The first
check in ice_probe stops even allocating the memory for the device if RDMA is not supported
at all.
> >
> > iadev = kzalloc(sizeof(*iadev), GFP_KERNEL);
> > diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c
> b/drivers/net/ethernet/intel/ice/ice_lib.c
> > index 0c187cf04fcf..b1c164b8066c 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_lib.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_lib.c
> > @@ -732,14 +732,14 @@ bool ice_is_safe_mode(struct ice_pf *pf)
> > }
> >
> > /**
> > - * ice_is_aux_ena
> > + * ice_is_rdma_ena
> > * @pf: pointer to the PF struct
> > *
> > - * returns true if AUX devices/drivers are supported, false otherwise
> > + * returns true if RDMA is currently supported, false otherwise
> > */
> > -bool ice_is_aux_ena(struct ice_pf *pf)
> > +bool ice_is_rdma_ena(struct ice_pf *pf)
> > {
> > - return test_bit(ICE_FLAG_AUX_ENA, pf->flags);
> > + return test_bit(ICE_FLAG_RDMA_ENA, pf->flags);
> > }
> >
> > /**
> > diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h
> b/drivers/net/ethernet/intel/ice/ice_lib.h
> > index b2ed189527d6..a2f54fbdc170 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_lib.h
> > +++ b/drivers/net/ethernet/intel/ice/ice_lib.h
> > @@ -110,7 +110,7 @@ void ice_set_q_vector_intrl(struct ice_q_vector
> *q_vector);
> > int ice_vsi_cfg_mac_fltr(struct ice_vsi *vsi, const u8 *macaddr, bool set);
> >
> > bool ice_is_safe_mode(struct ice_pf *pf);
> > -bool ice_is_aux_ena(struct ice_pf *pf);
> > +bool ice_is_rdma_ena(struct ice_pf *pf);
> > bool ice_is_dflt_vsi_in_use(struct ice_sw *sw);
> >
> > bool ice_is_vsi_dflt_vsi(struct ice_sw *sw, struct ice_vsi *vsi);
> > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> b/drivers/net/ethernet/intel/ice/ice_main.c
> > index e29176889c23..078eb588f41e 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > @@ -3653,11 +3653,8 @@ static void ice_set_pf_caps(struct ice_pf *pf)
> > struct ice_hw_func_caps *func_caps = &pf->hw.func_caps;
> >
> > clear_bit(ICE_FLAG_RDMA_ENA, pf->flags);
> > - clear_bit(ICE_FLAG_AUX_ENA, pf->flags);
> > - if (func_caps->common_cap.rdma) {
> > + if (func_caps->common_cap.rdma)
> > set_bit(ICE_FLAG_RDMA_ENA, pf->flags);
> > - set_bit(ICE_FLAG_AUX_ENA, pf->flags);
> > - }
> > clear_bit(ICE_FLAG_DCB_CAPABLE, pf->flags);
> > if (func_caps->common_cap.dcb)
> > set_bit(ICE_FLAG_DCB_CAPABLE, pf->flags);
> > @@ -3785,7 +3782,7 @@ static int ice_ena_msix_range(struct ice_pf *pf)
> > v_left -= needed;
> >
> > /* reserve vectors for RDMA auxiliary driver */
> > - if (test_bit(ICE_FLAG_RDMA_ENA, pf->flags)) {
> > + if (ice_is_rdma_ena(pf)) {
> > needed = num_cpus + ICE_RDMA_NUM_AEQ_MSIX;
> > if (v_left < needed)
> > goto no_hw_vecs_left_err;
> > @@ -3826,7 +3823,7 @@ static int ice_ena_msix_range(struct ice_pf *pf)
> > int v_remain = v_actual - v_other;
> > int v_rdma = 0, v_min_rdma = 0;
> >
> > - if (test_bit(ICE_FLAG_RDMA_ENA, pf->flags)) {
> > + if (ice_is_rdma_ena(pf)) {
> > /* Need at least 1 interrupt in addition to
> > * AEQ MSIX
> > */
> > @@ -3860,7 +3857,7 @@ static int ice_ena_msix_range(struct ice_pf *pf)
> > dev_notice(dev, "Enabled %d MSI-X vectors for LAN
> traffic.\n",
> > pf->num_lan_msix);
> >
> > - if (test_bit(ICE_FLAG_RDMA_ENA, pf->flags))
> > + if (ice_is_rdma_ena(pf))
> > dev_notice(dev, "Enabled %d MSI-X vectors
> for RDMA.\n",
> > pf->num_rdma_msix);
> > }
> > @@ -4688,7 +4685,7 @@ ice_probe(struct pci_dev *pdev, const struct
> pci_device_id __always_unused *ent)
> >
> > /* ready to go, so clear down state bit */
> > clear_bit(ICE_DOWN, pf->state);
>
> Why don't you clear this bit after RDMA initialization?
We want the interface to be completely ready before we initialize RDMA
communication. Also, this bit is not relevant to the RDMA queues, so before
or after RDMA initialization doesn't matter since RDMA traffic doesn't go through
the LAN netdev anyway.
>
> > - if (ice_is_aux_ena(pf)) {
> > + if (ice_is_rdma_ena(pf)) {
> > pf->aux_idx = ida_alloc(&ice_aux_ida, GFP_KERNEL);
> > if (pf->aux_idx < 0) {
> > dev_err(dev, "Failed to allocate device ID for AUX
> driver\n");
> > --
> > 2.31.1
> >
^ permalink raw reply
* Re: [RFC PATCH 00/10] KVM: selftests: Add support for test-selectable ucall implementations
From: Michael Roth @ 2022-01-05 19:11 UTC (permalink / raw)
To: Sean Christopherson
Cc: linux-kselftest, kvm, linux-kernel, x86, Nathan Tempelman,
Marc Orr, Steve Rutherford, Mingwei Zhang, Brijesh Singh,
Tom Lendacky, Varad Gautam, Shuah Khan, Vitaly Kuznetsov,
David Woodhouse, Ricardo Koller, Jim Mattson, Joerg Roedel,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H . Peter Anvin,
Christian Borntraeger, Janosch Frank, David Hildenbrand,
Claudio Imbrenda, Marc Zyngier, James Morse, Alexandru Elisei,
Suzuki K Poulose, kvmarm
In-Reply-To: <YdXYuaoXJux6lHrF@google.com>
On Wed, Jan 05, 2022 at 05:43:21PM +0000, Sean Christopherson wrote:
> On Wed, Jan 05, 2022, Michael Roth wrote:
> > On Wed, Jan 05, 2022 at 12:17:33AM +0000, Sean Christopherson wrote:
> > > PIO shouldn't require instruction decoding or a #VC handler. What I was thinking
> > > is that the guest in the selftest would make a direct #VMGEXIT/TDCALL to request
> > > PIO instead of executing an OUT.
> >
> > That seems like a nicer approach. But it sort of lends itself to having
> > test-specific ucall implementations in some form. How are you thinking
> > vm_create() should decide what implementation to use? With this series
> > in place it could be something like:
> >
> > vm_create(..., struct ucall_ops *ops)
> > ucall_init_ops(ops)
> >
> > and with the SEV selftests in their current form it would look something
> > like:
> >
> > sev_vm_create(...)
> > vm_create_with_ucall(..., ops=ucall_ops_pio_vmgexit)
> > ucall_init_ops(ops)
> >
> > is that sort of what you're thinking, or something else?
>
> I keep forgetting ucall() doesn't have access to the VM. But, since we're
> restricing ucall() to a single VM, we can have a global that sets ucall_ops during
> ucall_init() based on the VM type, or skip an ops and just open code the behavior
> in x86's ucall() by snapshotting the VM type. Either way, the goal is to avoid
> having to pass in ucall_ops at the test level.
>
> > > Yeah, I was thinking it could be done at the lowest level vm_create() helper.
> > > We'll need to expand vm_create() (or add yet another layer to avoid modifying a
> > > pile of tests) to allow opting out of initializing ucall, e.g. sev_migrate_tests.c
> > > needs to create multiple concurrent VMs, but happily doesn't need ucall support.
> >
> > Why does sev_migrate_tests need to opt out? Couldn't it use
> > ucall_ops_pio_vmgexit like that SEV case above?
>
> Because it uses multiple VMs, and my rough sketch only allows for a single VM to
> use ucall. Though I suppose we could simply keep appending to the ucall list for
> every VM. The requirement would then be that all VMs are of the same type, i.e.
> utilize the same ucall_ops.
Hmm, maybe I misread your patch. Not supporting multiple VMs was the
reason I gave up on having the ucall structs allocated on-demand and
went with requiring them to be passed as arguments to ucall().
I thought with your patch you had solved that by having each vm have it's
own pool, via vm->ucall_list, and then mapping each pool into each guest
separately via:
ucall_init(vm):
ucall_list = vm->ucall_list
sync_global_to_guest(ucall_list).
then as long as that ucall_init() is done *after* the guest calls
kvm_vm_elf_load(), it will end up with a 'ucall_list' global that points
to it's own specific vm->ucall_list. Then on the test side it doesn't
matter what the 'ucall_list' global is currently set to since you have
the GPA and know what vm exited.
Or am I missing something there?
Although even if that is the case, now that we're proposing doing the
ucall_init() inside vm_create(), then we run the risk of a test calling
kvm_vm_elf_load() after, which might clobber the guest's copy of
ucall_list global if ucall_init() had since been called for another VM.
But that could maybe be worked around by having whatever vm_create()
variant we use also do the kvm_vm_elf_load() unconditionally as part of
creation.
>
> > I ask because there is a ucall() in the exception handling code where
> > some unhandled exceptions result in the guest automatically issuing a
> > ucall(UCALL_UNHANDLED), so even when tests don't use ucall() they
> > might still rely on it if they enable exception handling. So that might
> > be an argument for always setting up at least the default ucall_ops_pio
> > implementation and creating a pool just in case. (or an argument for
> > dropping the UCALL_HANDLED handling).
>
> The sev_migrate_tests don't even run a guest, hence the quick-and-dirty "solution".
> Though thinking toward the future, that may be too dirty as it would prevent tests
> from having multiple "real" VMs.
>
> > > > > To reduce the burden on tests and avoid ordering issues with creating vCPUs,
> > > > > allocate a ucall struct for every possible vCPU when the VM is created and stuff
> > > > > the GPA of the struct in the struct itself so that the guest can communicate the
> > > > > GPA instead of the GVA. Then confidential VMs just need to make all structs shared.
> > > >
> > > > So a separate call like:
> > > >
> > > > ucall_make_shared(vm->ucall_list)
> > > >
> > > > ? Might need some good documentation/assertions to make sure it gets
> > > > called at the right place for confidential VMs, and may need some extra
> > > > hooks in SEV selftest implementation for switching from private to shared
> > > > after the memory has already been allocated, but seems reasonable.
> > >
> > > Again, I was thinking that it would be done unconditionally by ucall_init(), i.e.
> > > would be automatically handled by the selftest framework and would Just Work for
> > > individual tests.
> >
> > Ok, I'll have to think that through more. Currently with the SEV
> > selftests as they we have:
> >
> > sev_vm_create(policy, npages)
> > vm = vm_create(...)
> > vm_set_memory_encryption(vm, encrypt_by_default, enc_bit)
> > //vm_vaddr_alloc_shared() can be used now
> >
> > The ucall struct allocations would need to go through
> > vm_vaddr_alloc_shared() to make sure the selftest library tracks/maps
> > the pages as shared, but that vm_set_memory_encryption() happens too
> > late if the ucall_init() stuff is done in vm_create(). It should be
> > possible to pass the vm_set_memory_encryption() arguments directly to
> > vm_create() to allow for what you're proposing, but I guess we'd need
> > a new vm_create() wrapper that handles both the
> > vm_set_memory_encryption() args, along with the ucall_ops above,
> > something like:
> >
> > sev_vm_create(policy, npages)
> > vm = vm_create_coco(..., encrypt_by_default, enc_bit/shared_bit, ucall_ops)
> >
> > Or were you thinking something else? Just trying to get an idea of how
> > this will all need to tie in with the SEV selftests and what needs to
> > change on that end.
>
> Hmm, I was thinking the selftest framework would only need to be told the VM type,
> e.g. DEFAULT, SEV, SEV-ES, SEV-SNP, or TDX, and would then handle setting everything
> up, e.g. enumerating the C-bit location and encrypting memory as needed.
>
> One thought would be to extend "enum vm_guest_mode" with flags above NUM_VM_MODES
> to specify the VM type. That way tests that use VM_MODE_DEFAULT would continue to
> work without any updates.
Ok, let me see what that approach looks like on the SEV selftest side.
^ permalink raw reply
* Re: [PATCH v2] xfs: Remove redundant assignment of mp
From: Darrick J. Wong @ 2022-01-05 19:11 UTC (permalink / raw)
To: Jiapeng Chong; +Cc: linux-xfs, linux-kernel, Abaci Robot
In-Reply-To: <20220105151536.39062-1-jiapeng.chong@linux.alibaba.com>
On Wed, Jan 05, 2022 at 11:15:36PM +0800, Jiapeng Chong wrote:
> mp is being initialized to log->l_mp but this is never read
> as record is overwritten later on. Remove the redundant
> assignment.
>
> Cleans up the following clang-analyzer warning:
>
> fs/xfs/xfs_log_recover.c:3543:20: warning: Value stored to 'mp' during
> its initialization is never read [clang-analyzer-deadcode.DeadStores].
>
> Reported-by: Abaci Robot <abaci@linux.alibaba.com>
> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Much improved, thank you.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> ---
> Changes in v2:
> -Remove mp = log->l_mp.
>
> fs/xfs/xfs_log_recover.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> index 8ecb9a8567b7..96c997ed2ec8 100644
> --- a/fs/xfs/xfs_log_recover.c
> +++ b/fs/xfs/xfs_log_recover.c
> @@ -3550,8 +3550,6 @@ xlog_recover_check_summary(
> uint64_t ifree;
> int error;
>
> - mp = log->l_mp;
> -
> freeblks = 0LL;
> itotal = 0LL;
> ifree = 0LL;
> --
> 2.20.1.7.g153144c
>
^ permalink raw reply
* [diamon-discuss] [RELEASE] LTTng-modules 2.12.7 and 2.13.1 (Linux kernel tracer)
From: Mathieu Desnoyers @ 2022-01-05 19:11 UTC (permalink / raw)
To: lttng-dev, diamon-discuss, linux-trace-users, linux-kernel
Hi,
This is a release announcement for the LTTng Linux kernel tracer 2.12.7 and
2.13.1 releases. Both are bug fix releases in the lttng-modules stable branches.
They also enable support for the most recent Linux kernel releases.
LTTng-modules 2.12.7 contains instrumentation fixes for the 5.14, 5.15 and
5.16-rc Linux kernels. Kernel version ranges were adjusted for instrumentation
of the RHEL 8.4 kernel.
LTTng-modules 2.13.1 fixes scenarios where trigger actions are missing:
There is an issue when associating multiple actions to a single system
call, where the first action is effectively added, but the following
actions are silently ignored.
The affected on-event trigger is a feature newly introduced in 2.13.
This 2.13.1 release also contains instrumentation fixes for the 5.15 and 5.16-rc
Linux kernels. It now emits a warning in the kernel console whenever registration
of events internally fails within LTTng-modules, for example in case of
out-of-memory error.
As always, feedback is welcome!
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [lttng-dev] [RELEASE] LTTng-modules 2.12.7 and 2.13.1 (Linux kernel tracer)
From: Mathieu Desnoyers via lttng-dev @ 2022-01-05 19:11 UTC (permalink / raw)
To: lttng-dev, diamon-discuss, linux-trace-users, linux-kernel
Hi,
This is a release announcement for the LTTng Linux kernel tracer 2.12.7 and
2.13.1 releases. Both are bug fix releases in the lttng-modules stable branches.
They also enable support for the most recent Linux kernel releases.
LTTng-modules 2.12.7 contains instrumentation fixes for the 5.14, 5.15 and
5.16-rc Linux kernels. Kernel version ranges were adjusted for instrumentation
of the RHEL 8.4 kernel.
LTTng-modules 2.13.1 fixes scenarios where trigger actions are missing:
There is an issue when associating multiple actions to a single system
call, where the first action is effectively added, but the following
actions are silently ignored.
The affected on-event trigger is a feature newly introduced in 2.13.
This 2.13.1 release also contains instrumentation fixes for the 5.15 and 5.16-rc
Linux kernels. It now emits a warning in the kernel console whenever registration
of events internally fails within LTTng-modules, for example in case of
out-of-memory error.
As always, feedback is welcome!
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
^ permalink raw reply
* [RELEASE] LTTng-modules 2.12.7 and 2.13.1 (Linux kernel tracer)
From: Mathieu Desnoyers @ 2022-01-05 19:11 UTC (permalink / raw)
To: lttng-dev, diamon-discuss, linux-trace-users, linux-kernel
Hi,
This is a release announcement for the LTTng Linux kernel tracer 2.12.7 and
2.13.1 releases. Both are bug fix releases in the lttng-modules stable branches.
They also enable support for the most recent Linux kernel releases.
LTTng-modules 2.12.7 contains instrumentation fixes for the 5.14, 5.15 and
5.16-rc Linux kernels. Kernel version ranges were adjusted for instrumentation
of the RHEL 8.4 kernel.
LTTng-modules 2.13.1 fixes scenarios where trigger actions are missing:
There is an issue when associating multiple actions to a single system
call, where the first action is effectively added, but the following
actions are silently ignored.
The affected on-event trigger is a feature newly introduced in 2.13.
This 2.13.1 release also contains instrumentation fixes for the 5.15 and 5.16-rc
Linux kernels. It now emits a warning in the kernel console whenever registration
of events internally fails within LTTng-modules, for example in case of
out-of-memory error.
As always, feedback is welcome!
Thanks,
Mathieu
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: Trying to understand QOM object creation and property linking
From: Philippe Mathieu-Daudé @ 2022-01-05 19:03 UTC (permalink / raw)
To: Alex Bennée, Paolo Bonzini, Daniel P. Berrange,
Eduardo Habkost
Cc: Peter Maydell, qemu-devel
In-Reply-To: <87czl6jb79.fsf@linaro.org>
Hi Alex,
On 5/1/22 19:03, Alex Bennée wrote:
> Hi,
>
> I'm having a hell of a time trying to create a new SoC+Board model from
> scratch. The problem comes down to trying to expose some properties to
> the underlying CPU from my board model. So I have:
>
> static const TypeInfo pipico_machine_types[] = {
> {
> .name = TYPE_PIPICO_MACHINE,
> .parent = TYPE_MACHINE,
> .instance_size = sizeof(PiPicoMachineState),
> .class_size = sizeof(PiPicoMachineClass),
> .class_init = pipico_machine_class_init,
> }
> };
>
> and the class init sets:
>
> MachineClass *mc = MACHINE_CLASS(oc);
> ...
> mc->desc = g_strdup_printf("Raspberry Pi Pico");
> mc->init = pipico_machine_init;
> ...
>
> and finally when I init the machine I do the following:
>
> static void pipico_machine_init(MachineState *machine)
> {
> PiPicoMachineState *s = PIPICO_MACHINE(machine);
> ...
> MemoryRegion *system_memory = get_system_memory();
>
> ...
>
> /* initialize external Flash device */
> memory_region_init_rom(&s->flash, NULL,
> "pico.flash0", 256 * KiB, &error_fatal);
> memory_region_add_subregion(system_memory, 0, &s->flash);
>
> /* Setup the SOC */
> object_initialize_child(OBJECT(machine), "soc", &s->soc, TYPE_RP2040);
>
> /* link properties from machine the SoC needs */
> object_property_set_link(OBJECT(&s->soc), "memory",
> OBJECT(system_memory), &error_fatal);
>
> sysbus_realize(SYS_BUS_DEVICE(&s->soc), &error_fatal);
>
>
> The initialisation of the SoC is simple because I can't do much until
> things are realised:
>
> static void rp2040_init(Object *obj)
> {
> RP2040State *s = RP2040(obj);
> int n;
>
> fprintf(stderr, "%s: %p\n", __func__, obj);
>
> for (n = 0; n < RP2040_NCPUS; n++) {
> object_initialize_child(obj, "cpu[*]", &s->armv7m[n], TYPE_ARMV7M);
> qdev_prop_set_string(DEVICE(&s->armv7m[n]), "cpu-type",
> ARM_CPU_TYPE_NAME("cortex-m0"));
Here for each core you need to initialize a MemoryRegion container, ...
> }
> }
>
>
> However when I get to realize the SoC itself:
>
> static void rp2040_realize(DeviceState *dev, Error **errp)
> {
> RP2040State *s = RP2040(dev);
> Object *obj = OBJECT(dev);
> int n;
>
> if (!s->board_memory) {
> error_setg(errp, "%s: memory property was not set", __func__);
> return;
> }
>
> /* initialize internal 16 KB internal ROM */
> memory_region_init_rom(&s->rom, obj, "rp2040.rom0", 16 * KiB, errp);
> memory_region_add_subregion(s->board_memory, 0, &s->rom);
>
> /* SRAM (Main 256k bank + two 4k banks)*/
> memory_region_init_ram(&s->sram03, obj, "rp2040.sram03", 256 * KiB, errp);
> memory_region_add_subregion(s->board_memory, RP2040_SRAM_BASE, &s->sram03);
>
> memory_region_init_ram(&s->sram4, obj, "rp2040.sram4", 4 * KiB, errp);
> memory_region_add_subregion(s->board_memory, RP2040_SRAM4_BASE, &s->sram4);
>
> memory_region_init_ram(&s->sram5, obj, "rp2040.sram5", 4 * KiB, errp);
> memory_region_add_subregion(s->board_memory, RP2040_SRAM5_BASE, &s->sram5);
>
> ...
>
> for (n = 0; n < RP2040_NCPUS; n++) {
> /* DeviceState *cpudev = DEVICE(&s->armv7m[i]); */
> Object *cpuobj = OBJECT(&s->armv7m[n]);
then you add the board_memory in the per-CPU container as subregion, ...
> object_property_set_link(cpuobj, "memory",
> OBJECT(&s->board_memory), errp);
and finally each CPU links its container as its memory bus.
> And this passing of the link down to the CPU I segfault:
>
> rp2040_init: 0x555556d08710
>
> Thread 1 "qemu-system-arm" received signal SIGSEGV, Segmentation fault.
> object_get_canonical_path_component (obj=0x555556d0ea28) at ../../qom/object.c:1999
> 1999 g_hash_table_iter_init(&iter, obj->parent->properties);
> (gdb) bt
> #0 object_get_canonical_path_component (obj=0x555556d0ea28) at ../../qom/object.c:1999
> #1 0x0000555555fb27ea in object_get_canonical_path (obj=0x555556d0ea28) at ../../qom/object.c:2025
> #2 0x0000555555fb1250 in object_property_set_link (obj=0x555556d087a0, name=0x5555563190a2 "memory", value=0x555556d0ea28, errp=0x7fffffffe0f0) at ../../qom/object.c:1445
> #3 0x0000555555cf3c23 in rp2040_realize (dev=0x555556d08710, errp=0x7fffffffe0f0) at ../../hw/arm/rp2040.c:85
> #4 0x0000555555fa9323 in device_set_realized (obj=0x555556d08710, value=true, errp=0x7fffffffe200) at ../../hw/core/qdev.c:532
> #5 0x0000555555fb300d in property_set_bool (obj=0x555556d08710, v=0x555556dced10, name=0x5555563822b9 "realized", opaque=0x555556a3a6d0, errp=0x7fffffffe200) at ../../qom/object.c:2268
> #6 0x0000555555fb1054 in object_property_set (obj=0x555556d08710, name=0x5555563822b9 "realized", v=0x555556dced10, errp=0x7fffffffe200) at ../../qom/object.c:1403
> #7 0x0000555555fb53ff in object_property_set_qobject (obj=0x555556d08710, name=0x5555563822b9 "realized", value=0x555556e79bc0, errp=0x555556918de0 <error_fatal>) at ../../qom/qom-qobject.c:28
> #8 0x0000555555fb13b9 in object_property_set_bool (obj=0x555556d08710, name=0x5555563822b9 "realized", value=true, errp=0x555556918de0 <error_fatal>) at ../../qom/object.c:1472
> #9 0x0000555555fa8beb in qdev_realize (dev=0x555556d08710, bus=0x555556d0f240, errp=0x555556918de0 <error_fatal>) at ../../hw/core/qdev.c:334
> #10 0x00005555559f0e28 in sysbus_realize (dev=0x555556d08710, errp=0x555556918de0 <error_fatal>) at ../../hw/core/sysbus.c:256
> #11 0x0000555555cf3f0e in pipico_machine_init (machine=0x555556d08600) at ../../hw/arm/raspi_pico.c:74
> #12 0x00005555559ed71b in machine_run_board_init (machine=0x555556d08600) at ../../hw/core/machine.c:1184
> #13 0x0000555555e67f2c in qemu_init_board () at ../../softmmu/vl.c:2655
> #14 0x0000555555e6814a in qmp_x_exit_preconfig (errp=0x555556918de0 <error_fatal>) at ../../softmmu/vl.c:2743
> #15 0x0000555555e6a811 in qemu_init (argc=3, argv=0x7fffffffe6b8, envp=0x7fffffffe6d8) at ../../softmmu/vl.c:3778
> #16 0x0000555555884ebd in main (argc=3, argv=0x7fffffffe6b8, envp=0x7fffffffe6d8) at ../../softmmu/main.c:49
>
> So have I discovered a bug in QOM handling or misunderstood the way
> properties are meant to be shared from the main machine to the
> underlying CPU?
>
> Follow-up questions, does only creating the main memory aliases as part
> of the SoC make sense? My rational is most of the memory is part of the
> SoC not the board. I assume later RP2040 based boards may have different
> flash configs or even external memory.
>
> The current (messy) state of my tree can be seen at:
>
> https://gitlab.com/stsquad/qemu/-/commits/arm/picopi-rfc
>
^ permalink raw reply
* Re: [PATCH v3] thermal: rcar_thermal: Use platform_get_irq_optional() to get the interrupt
From: Niklas Söderlund @ 2022-01-05 19:13 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, Rafael J. Wysocki, Daniel Lezcano,
Amit Kucheria, Zhang Rui, Rob Herring, Andy Shevchenko, Prabhakar,
linux-renesas-soc, linux-pm, linux-kernel
In-Reply-To: <20220104145212.4608-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Lad,
Thanks for your work.
On 2022-01-04 14:52:11 +0000, Lad Prabhakar wrote:
> platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static
> allocation of IRQ resources in DT core code, this causes an issue
> when using hierarchical interrupt domains using "interrupts" property
> in the node as this bypasses the hierarchical setup and messes up the
> irq chaining.
>
> In preparation for removal of static setup of IRQ resource from DT core
> code use platform_get_irq_optional().
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v2-v3:
> * Fixed review comment pointed by Andy
>
> v1->v2
> * Simplified checking error code
> * Break loop earlier if no interrupts are seen
>
> v1: https://lkml.org/lkml/2021/12/18/163
> ---
> drivers/thermal/rcar_thermal.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
> index b49f04daaf47..e480f7290ccf 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -445,7 +445,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
> struct rcar_thermal_common *common;
> struct rcar_thermal_priv *priv;
> struct device *dev = &pdev->dev;
> - struct resource *res, *irq;
> + struct resource *res;
> const struct rcar_thermal_chip *chip = of_device_get_match_data(dev);
> int mres = 0;
> int i;
> @@ -467,9 +467,16 @@ static int rcar_thermal_probe(struct platform_device *pdev)
> pm_runtime_get_sync(dev);
>
> for (i = 0; i < chip->nirqs; i++) {
> - irq = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> - if (!irq)
> - continue;
> + int irq;
> +
> + irq = platform_get_irq_optional(pdev, i);
> + if (irq < 0 && irq != -ENXIO) {
> + ret = irq;
> + goto error_unregister;
> + }
> + if (!irq || irq == -ENXIO)
> + break;
This do not look correct and differs form v1.
In the old code if we can't get an IRQ the loop is continued. This is
used to detect if interrupts are supported or not on the platform. This
change will fail on all systems that don't describes interrupts in DT
while the driver can function without interrupts.
Is there a reason you wish to do this change in addition to the switch
to platform_get_irq_optional()? If so I think that should be done in a
separate patch.
> +
> if (!common->base) {
> /*
> * platform has IRQ support.
> @@ -487,7 +494,7 @@ static int rcar_thermal_probe(struct platform_device *pdev)
> idle = 0; /* polling delay is not needed */
> }
>
> - ret = devm_request_irq(dev, irq->start, rcar_thermal_irq,
> + ret = devm_request_irq(dev, irq, rcar_thermal_irq,
> IRQF_SHARED, dev_name(dev), common);
> if (ret) {
> dev_err(dev, "irq request failed\n ");
> --
> 2.17.1
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH net-next v2] net/smc: Reduce overflow of smc clcsock listen queue
From: Karsten Graul @ 2022-01-05 19:13 UTC (permalink / raw)
To: D. Wythe; +Cc: dust.li, kuba, davem, netdev, linux-s390, linux-rdma
In-Reply-To: <20220105150612.GA75522@e02h04389.eu6sqa>
On 05/01/2022 16:06, D. Wythe wrote:
> LGTM. Fallback makes the restrictions on SMC dangling
> connections more meaningful to me, compared to dropping them.
>
> Overall, i see there are two scenario.
>
> 1. Drop the overflow connections limited by userspace application
> accept.
>
> 2. Fallback the overflow connections limited by the heavy process of
> current SMC handshake. ( We can also control its behavior through
> sysctl.)
>
I vote for (2) which makes the behavior from user space applications point of view more like TCP.
One comment to sysctl: our current approach is to add new switches to the existing
netlink interface which can be used with the smc-tools package (or own implementations of course).
Is this prereq problematic in your environment?
We tried to avoid more sysctls and the netlink interface keeps use more flexible.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.