dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[PULL] drm-misc-fixes
by Maxime Ripard 13 May '22

13 May '22

Hi Dave, Daniel, Here's this week drm-misc-fixes. drm-misc-next-fixes is empty at the moment, so there won't be a PR for it this week. Thanks! Maxime drm-misc-fixes-2022-05-13: Multiple fixes to fbdev to address a regression at unregistration, an iommu detection improvement for nouveau, a memory leak fix for nouveau, pointer dereference fix for dma_buf_file_release(), and a build breakage fix for vc4 The following changes since commit c5eb0a61238dd6faf37f58c9ce61c9980aaffd7a: Linux 5.18-rc6 (2022-05-08 13:54:17 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-05-13 for you to fetch changes up to 6fed53de560768bde6d701a7c79c253b45b259e3: drm/vc4: hdmi: Fix build error for implicit function declaration (2022-05-12 11:01:19 +0200) ---------------------------------------------------------------- Multiple fixes to fbdev to address a regression at unregistration, an iommu detection improvement for nouveau, a memory leak fix for nouveau, pointer dereference fix for dma_buf_file_release(), and a build breakage fix for vc4 ---------------------------------------------------------------- Charan Teja Reddy (1): dma-buf: call dma_buf_stats_setup after dmabuf is in valid list Christophe JAILLET (1): drm/nouveau: Fix a potential theorical leak in nouveau_get_backlight_name() Daniel Vetter (1): fbdev: Prevent possible use-after-free in fb_release() Hui Tang (1): drm/vc4: hdmi: Fix build error for implicit function declaration Javier Martinez Canillas (5): Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered" fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove fbdev: efifb: Fix a use-after-free due early fb_info cleanup Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes Robin Murphy (1): drm/nouveau/tegra: Stop using iommu_present() drivers/dma-buf/dma-buf.c | 8 ++++---- drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 +++++---- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 1 + drivers/video/fbdev/core/fbmem.c | 5 +---- drivers/video/fbdev/core/fbsysfs.c | 4 ++++ drivers/video/fbdev/efifb.c | 9 ++++++++- drivers/video/fbdev/simplefb.c | 8 +++++++- drivers/video/fbdev/vesafb.c | 8 +++++++- 9 files changed, 38 insertions(+), 16 deletions(-)

1 0

[RESEND, v4] media: mediatek: vcodec: Fix v4l2 compliance decoder cmd test fail
by Yunfei Dong 13 May '22

13 May '22

Will return -EINVAL using standard framework api when test stateless decoder with cmd VIDIOC_(TRY)DECODER_CMD. Disable them to adjust v4l2 compliance test for user driver(GStreamer/Chrome) won't use decoder cmd. Fixes: 8cdc3794b2e3 ("media: mtk-vcodec: vdec: support stateless API") Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> --- resend v4: - add Reviewed-by tag for patch v4. changes compared with v3: - using v4l2_disable_ioctl to replace return -ENOTTY changes compared with v2: - add reviewed-by tag changes compared with v1: - add Fixes: tag --- .../media/platform/mediatek/vcodec/mtk_vcodec_dec.c | 13 +------------ .../platform/mediatek/vcodec/mtk_vcodec_dec_drv.c | 3 +++ 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c index 3859e4c651c6..52e5d36aa912 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c @@ -47,14 +47,7 @@ static struct mtk_q_data *mtk_vdec_get_q_data(struct mtk_vcodec_ctx *ctx, static int vidioc_try_decoder_cmd(struct file *file, void *priv, struct v4l2_decoder_cmd *cmd) { - struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv); - - /* Use M2M stateless helper if relevant */ - if (ctx->dev->vdec_pdata->uses_stateless_api) - return v4l2_m2m_ioctl_stateless_try_decoder_cmd(file, priv, - cmd); - else - return v4l2_m2m_ioctl_try_decoder_cmd(file, priv, cmd); + return v4l2_m2m_ioctl_try_decoder_cmd(file, priv, cmd); } @@ -69,10 +62,6 @@ static int vidioc_decoder_cmd(struct file *file, void *priv, if (ret) return ret; - /* Use M2M stateless helper if relevant */ - if (ctx->dev->vdec_pdata->uses_stateless_api) - return v4l2_m2m_ioctl_stateless_decoder_cmd(file, priv, cmd); - mtk_v4l2_debug(1, "decoder cmd=%u", cmd->cmd); dst_vq = v4l2_m2m_get_vq(ctx->m2m_ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE); diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c index b417a6ab2176..995e6e2fb1ab 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c @@ -395,6 +395,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev) } if (dev->vdec_pdata->uses_stateless_api) { + v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD); + v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD); + dev->mdev_dec.dev = &pdev->dev; strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME, sizeof(dev->mdev_dec.model)); -- 2.18.0

1 0

[PATCH v12, 00/17] media: mtk-vcodec: support for M8192 decoder
by Yunfei Dong 13 May '22

13 May '22

This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly, refactor power/clock/interrupt interfaces for mt8192 is lat and core architecture. Secondly, add new functions to get frame buffer size and resolution according to decoder capability from scp side. Then add callback function to get/put capture buffer in order to enable lat and core decoder in parallel, need to adjust GStreamer at the same time. Then add to support MT21C compressed mode and fix v4l2-compliance fail. Next, extract H264 request api driver to let mt8183 and mt8192 use the same code, and adds mt8192 frame based h264 driver for stateless decoder. Lastly, add vp8 and vp9 stateless decoder drivers. Patches 1 refactor power/clock/interrupt interface. Patches 2~4 get frame buffer size and resolution according to decoder capability. Patches 5 set capture queue bytesused. Patches 6 adjust GStreamer. Patch 7~11 add to support MT21C compressed mode and fix v4l2-compliance fail. patch 12 record capture queue format type. Patch 13~14 extract h264 driver and add mt8192 frame based driver for h264 decoder. Patch 15~16 add vp8 and vp9 stateless decoder drivers. Patch 17 prevent kernel crash when rmmod mtk-vcodec-dec.ko --- changes compared with v11: - fix __iomem not reasonable, align share memory to dram. changes compared with v10: - fix sparse and smatch check fail for patch 13/14/16 - fix 32bit build fail for patch 14 changes compared with v9: - fix kernel robot build fail for patch 16 changes compared with v8: - fix vp9 build error - fix kernel-doc fail changes compared with v7: - adjust GStreamer, separate src buffer done with v4l2_ctrl_request_complete for patch 6. - remove v4l2_m2m_set_dst_buffered. - add new patch to set each plane bytesused in buf prepare for patch 5. - using upstream interface to update vp9 prob tables for patch 16. - fix maintainer comments. - test the driver with chrome VD and GStreamer(H264/VP9/VP8/AV1). changes compared with v6: - rebase to the latest media stage and fix conficts - fix memcpy to memcpy_fromio or memcpy_toio - fix h264 crash when test field bitstream changes compared with v5: - fix vp9 comments for patch 15 - fix vp8 comments for patch 14. - fix comments for patch 12. - fix build errors. changes compared with v4: - fix checkpatch.pl fail. - fix kernel-doc fail. - rebase to the latest media codec driver. changes compared with v3: - remove enum mtk_chip for patch 2. - add vp8 stateless decoder drivers for patch 14. - add vp9 stateless decoder drivers for patch 15. changes compared with v2: - add new patch 11 to record capture queue format type. - separate patch 4 according to tzung-bi's suggestion. - re-write commit message for patch 5 according to tzung-bi's suggestion. changes compared with v1: - rewrite commit message for patch 12. - rewrite cover-letter message. --- Yunfei Dong (17): media: mediatek: vcodec: Add vdec enable/disable hardware helpers media: mediatek: vcodec: Using firmware type to separate different firmware architecture media: mediatek: vcodec: get capture queue buffer size from scp media: mediatek: vcodec: Read max resolution from dec_capability media: mediatek: vcodec: set each plane bytesused in buf prepare media: mediatek: vcodec: Refactor get and put capture buffer flow media: mediatek: vcodec: Refactor supported vdec formats and framesizes media: mediatek: vcodec: Getting supported decoder format types media: mediatek: vcodec: Add format to support MT21C media: mediatek: vcodec: disable vp8 4K capability media: mediatek: vcodec: Fix v4l2-compliance fail media: mediatek: vcodec: record capture queue format type media: mediatek: vcodec: Extract H264 common code media: mediatek: vcodec: support stateless H.264 decoding for mt8192 media: mediatek: vcodec: support stateless VP8 decoding media: mediatek: vcodec: support stateless VP9 decoding media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.ko .../media/platform/mediatek/vcodec/Kconfig | 1 + .../media/platform/mediatek/vcodec/Makefile | 4 + .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 62 +- .../mediatek/vcodec/mtk_vcodec_dec_drv.c | 8 +- .../mediatek/vcodec/mtk_vcodec_dec_pm.c | 166 +- .../mediatek/vcodec/mtk_vcodec_dec_pm.h | 6 +- .../mediatek/vcodec/mtk_vcodec_dec_stateful.c | 19 +- .../vcodec/mtk_vcodec_dec_stateless.c | 257 ++- .../platform/mediatek/vcodec/mtk_vcodec_drv.h | 41 +- .../mediatek/vcodec/mtk_vcodec_enc_drv.c | 5 - .../platform/mediatek/vcodec/mtk_vcodec_fw.c | 6 + .../platform/mediatek/vcodec/mtk_vcodec_fw.h | 1 + .../vcodec/vdec/vdec_h264_req_common.c | 310 +++ .../vcodec/vdec/vdec_h264_req_common.h | 274 +++ .../mediatek/vcodec/vdec/vdec_h264_req_if.c | 438 +--- .../vcodec/vdec/vdec_h264_req_multi_if.c | 626 +++++ .../mediatek/vcodec/vdec/vdec_vp8_req_if.c | 437 ++++ .../vcodec/vdec/vdec_vp9_req_lat_if.c | 2030 +++++++++++++++++ .../platform/mediatek/vcodec/vdec_drv_if.c | 37 +- .../platform/mediatek/vcodec/vdec_drv_if.h | 3 + .../platform/mediatek/vcodec/vdec_ipi_msg.h | 36 + .../platform/mediatek/vcodec/vdec_msg_queue.c | 2 + .../platform/mediatek/vcodec/vdec_msg_queue.h | 2 + .../platform/mediatek/vcodec/vdec_vpu_if.c | 53 +- .../platform/mediatek/vcodec/vdec_vpu_if.h | 15 + .../platform/mediatek/vcodec/venc_vpu_if.c | 2 +- include/linux/remoteproc/mtk_scp.h | 2 + 27 files changed, 4242 insertions(+), 601 deletions(-) create mode 100644 drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_common.c create mode 100644 drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_common.h create mode 100644 drivers/media/platform/mediatek/vcodec/vdec/vdec_h264_req_multi_if.c create mode 100644 drivers/media/platform/mediatek/vcodec/vdec/vdec_vp8_req_if.c create mode 100644 drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c -- 2.18.0

4 20

[PATCH v2 0/8] arm64: dts: qcom: initial Inforce IFC6560 board support
by Dmitry Baryshkov 12 May '22

12 May '22

This work is largely based on the previous work by Bjorn Andersson ([1]) Changes since v1 (mostly based on Kondrad's review): - Also disabled dsi0/dsi0 phy in sdm630.dtsi - Removed the clock from BAM DMA devices rather than disabling them completely - Replaced numbers with symbolic names for interconnects in sdm630.dtsi - Switched to "qcom,sda660" as a fallback compatible string - Added dt-bindings for the qcom,sda660 compat - Removed extra nesting level from the adsp firmware path - Replaced numbers with proper symbolic names in the board file - Added chassis-type property - Changed the order of blsp entries in the board file - Removed spurious newlines - Changed the order of regulator properties - Changed the DSI data-lines to list all four lanes. Still use just three lanes for the adv bridge (and describe the reason in the comment) Changes since Bjorn's v2: - Disable dsi1, dsi1 phy, GPU by default in sdm660.dtsi/sdm630.dtsi - Fix qusb2phy ref clock - Added USB2 host support to sdm630.dtsi - Renamed DTS to follow SoC-vendor-board pattern - Fixed vph_pwr voltage - Removed extra/unrelated comments - Added keys, USB2, USB3, - Added configuration for the attached HDMI bridge - Enabled MDP, MDSS and DSI0/DSI0 PHY devices - Removed uart pinctrl and /reserved-mem nodes (present in main dtsi file) - Added card detection for the SDCC2 - Disabled BLSP BAM DMA devices, they make the board reset during boot [1] https://lore.kernel.org/linux-arm-msm/20210825221110.1498718-1-bjorn.anders… Dmitry Baryshkov (8): arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default arm64: dts: qcom: sdm630: disable dsi1/dsi1_phy by default arm64: dts: qcom: sdm630: disable GPU by default arm64: dts: qcom: sdm630: fix the qusb2phy ref clock arm64: dts: qcom: sdm630: add second (HS) USB host support arm64: dts: qcom: sdm630: use defined symbols for interconnects arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support dt-bindings: arm: qcom: document sda660 SoC and ifc6560 board .../devicetree/bindings/arm/qcom.yaml | 6 + arch/arm64/boot/dts/qcom/Makefile | 1 + .../boot/dts/qcom/sda660-inforce-ifc6560.dts | 459 ++++++++++++++++++ arch/arm64/boot/dts/qcom/sdm630.dtsi | 85 +++- arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 + 5 files changed, 542 insertions(+), 12 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts -- 2.35.1

1 8

[PATCH v4] drm/msm/dsi: don't powerup at modeset time for parade-ps8640
by Douglas Anderson 12 May '22

12 May '22

Commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") caused sc7180 Chromebooks that use the parade-ps8640 bridge chip to fail to turn the display back on after it turns off. Unfortunately, it doesn't look easy to fix the parade-ps8640 driver to handle the new power sequence. The Linux driver has almost nothing in it and most of the logic for this bridge chip is in black-box firmware that the bridge chip uses. Also unfortunately, reverting the patch will break "tc358762". The long term solution here is probably Dave Stevenson's series [1] that would give more flexibility. However, that is likely not a quick fix. For the short term, we'll look at the compatible of the next bridge in the chain and go back to the old way for the Parade PS8640 bridge chip. If it's found that other bridge chips also need this workaround then we can add them to the list or consider inverting the condition. [1] https://lore.kernel.org/r/cover.1646406653.git.dave.stevenson@raspberrypi.c… Fixes: 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") Suggested-by: Rob Clark <robdclark(a)gmail.com> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- Note that, unlike `struct device`, `struct drm_bridge` still has a `#ifdef` around the `of_node`. The extra stub function in this patch is to make sure that we can pass COMPILE_TEST, not because I expect that we'll actually run into real users who are running this driver without device tree. Changes in v4: - Use the compatible string of the next bridge as per Rob. Changes in v3: - No longer a revert; now a module parameter. Changes in v2: - Remove the mud from my face. drivers/gpu/drm/msm/dsi/dsi_manager.c | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c index 50b987658b1f..2cabba65a8f1 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c @@ -34,6 +34,26 @@ static struct msm_dsi_manager msm_dsim_glb; #define IS_SYNC_NEEDED() (msm_dsim_glb.is_sync_needed) #define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id) +#ifdef CONFIG_OF +static bool dsi_mgr_power_on_early(struct drm_bridge *bridge) +{ + struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge); + + /* + * If the next bridge in the chain is the Parade ps8640 bridge chip + * then don't power on early since it seems to violate the expectations + * of the firmware that the bridge chip is running. + */ + return !(next_bridge && next_bridge->of_node && + of_device_is_compatible(next_bridge->of_node, "parade,ps8640")); +} +#else +static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge) +{ + return true; +} +#endif + static inline struct msm_dsi *dsi_mgr_get_dsi(int id) { return msm_dsim_glb.dsi[id]; @@ -389,6 +409,9 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge) if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id)) return; + if (!dsi_mgr_power_on_early(bridge)) + dsi_mgr_bridge_power_on(bridge); + /* Always call panel functions once, because even for dual panels, * there is only one drm_panel instance. */ @@ -570,7 +593,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge *bridge, if (is_bonded_dsi && other_dsi) msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode); - dsi_mgr_bridge_power_on(bridge); + if (dsi_mgr_power_on_early(bridge)) + dsi_mgr_bridge_power_on(bridge); } static enum drm_mode_status dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge, -- 2.36.0.550.gb090851708-goog

4 4

[PATCH v3] drm/msm/dsi: only powerup at modeset time if "early_poweron" modparam
by Douglas Anderson 12 May '22

12 May '22

Commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") caused sc7180 Chromebooks that use the parade-ps8640 bridge chip to fail to turn the display back on after it turns off. Unfortunately, it doesn't look easy to fix the parade-ps8640 driver to handle the new power sequence. The Linux driver has almost nothing in it and most of the logic for this bridge chip is in black-box firmware that the bridge chip uses. Also unfortunately, reverting the patch will break "tc358762". The long term solution here is probably Dave Stevenson's series [1] that would give more flexibility. However, that is likely not a quick fix. For the short term, let's introduce a module parameter that selects between the two behaviors. This is a short term hack but at least can keep both users working. We'll default the value of the module parameter to the old behavior. Given that the old behavior has existed for longer it's probably a safer default. [1] https://lore.kernel.org/r/cover.1646406653.git.dave.stevenson@raspberrypi.c… Fixes: 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") Suggested-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- Changes in v3: - No longer a revert; now a module parameter. Changes in v2: - Remove the mud from my face. drivers/gpu/drm/msm/dsi/dsi_manager.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c index 50b987658b1f..2bf4123ef5df 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c @@ -34,6 +34,10 @@ static struct msm_dsi_manager msm_dsim_glb; #define IS_SYNC_NEEDED() (msm_dsim_glb.is_sync_needed) #define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id) +bool early_poweron; +MODULE_PARM_DESC(early_poweron, "Power DSI controller early"); +module_param(early_poweron, bool, 0600); + static inline struct msm_dsi *dsi_mgr_get_dsi(int id) { return msm_dsim_glb.dsi[id]; @@ -389,6 +393,9 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge) if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id)) return; + if (!early_poweron) + dsi_mgr_bridge_power_on(bridge); + /* Always call panel functions once, because even for dual panels, * there is only one drm_panel instance. */ @@ -570,7 +577,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge *bridge, if (is_bonded_dsi && other_dsi) msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode); - dsi_mgr_bridge_power_on(bridge); + if (early_poweron) + dsi_mgr_bridge_power_on(bridge); } static enum drm_mode_status dsi_mgr_bridge_mode_valid(struct drm_bridge *bridge, -- 2.36.0.550.gb090851708-goog

3 2

[PATCH] drm/amdgpu: Move mutex_init(&smu->message_lock) to smu_early_init()
by Hans de Goede 12 May '22

12 May '22

Lockdep complains about the smu->message_lock mutex being used before it is initialized through the following call path: amdgpu_device_init() amdgpu_dpm_mode2_reset() smu_mode2_reset() smu_v12_0_mode2_reset() smu_cmn_send_smc_msg_with_param() Move the mutex_init() call to smu_early_init() to fix the mutex being used before it is initialized. This fixes the following lockdep splat: [ 3.867331] ------------[ cut here ]------------ [ 3.867335] fbcon: Taking over console [ 3.867338] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 3.867340] WARNING: CPU: 14 PID: 491 at kernel/locking/mutex.c:579 __mutex_lock+0x44c/0x830 [ 3.867349] Modules linked in: amdgpu(+) crct10dif_pclmul drm_ttm_helper crc32_pclmul ttm crc32c_intel ghash_clmulni_intel hid_lg_g15 iommu_v2 sp5100_tco nvme gpu_sched drm_dp_helper nvme_core ccp wmi video hid_logitech_dj ip6_tables ip_tables ipmi_devintf ipmi_msghandler fuse i2c_dev [ 3.867363] CPU: 14 PID: 491 Comm: systemd-udevd Tainted: G I 5.18.0-rc5+ #33 [ 3.867366] Hardware name: Micro-Star International Co., Ltd. MS-7C95/B550M PRO-VDH WIFI (MS-7C95), BIOS 2.90 12/23/2021 [ 3.867369] RIP: 0010:__mutex_lock+0x44c/0x830 [ 3.867372] Code: ff 85 c0 0f 84 33 fc ff ff 8b 0d b7 50 25 01 85 c9 0f 85 25 fc ff ff 48 c7 c6 fb 41 82 99 48 c7 c7 6b 63 80 99 e8 88 2a f8 ff <0f> 0b e9 0b fc ff ff f6 83 b9 0c 00 00 01 0f 85 64 ff ff ff 4c 89 [ 3.867377] RSP: 0018:ffffaef8c0fc79f0 EFLAGS: 00010286 [ 3.867380] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000027 [ 3.867382] RDX: ffff9ccc0dda0928 RSI: 0000000000000001 RDI: ffff9ccc0dda0920 [ 3.867384] RBP: ffffaef8c0fc7a80 R08: 0000000000000000 R09: ffffaef8c0fc7820 [ 3.867386] R10: 0000000000000003 R11: ffff9ccc2a2fffe8 R12: 0000000000000002 [ 3.867388] R13: ffff9cc990808058 R14: 0000000000000000 R15: ffff9cc98bfc0000 [ 3.867390] FS: 00007fc4d830f580(0000) GS:ffff9ccc0dd80000(0000) knlGS:0000000000000000 [ 3.867394] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.867396] CR2: 0000560a77031410 CR3: 000000010f522000 CR4: 0000000000750ee0 [ 3.867398] PKRU: 55555554 [ 3.867399] Call Trace: [ 3.867401] <TASK> [ 3.867403] ? smu_cmn_send_smc_msg_with_param+0x98/0x240 [amdgpu] [ 3.867533] ? __mutex_lock+0x90/0x830 [ 3.867535] ? amdgpu_dpm_mode2_reset+0x37/0x60 [amdgpu] [ 3.867653] ? smu_cmn_send_smc_msg_with_param+0x98/0x240 [amdgpu] [ 3.867758] smu_cmn_send_smc_msg_with_param+0x98/0x240 [amdgpu] [ 3.867857] smu_mode2_reset+0x2b/0x50 [amdgpu] [ 3.867953] amdgpu_dpm_mode2_reset+0x46/0x60 [amdgpu] [ 3.868096] amdgpu_device_init.cold+0x1069/0x1e78 [amdgpu] [ 3.868219] ? _raw_spin_unlock_irqrestore+0x30/0x50 [ 3.868222] ? pci_conf1_read+0x9b/0xf0 [ 3.868226] amdgpu_driver_load_kms+0x15/0x110 [amdgpu] [ 3.868314] amdgpu_pci_probe+0x1a9/0x3c0 [amdgpu] [ 3.868398] local_pci_probe+0x41/0x80 [ 3.868401] pci_device_probe+0xab/0x200 [ 3.868404] really_probe+0x1a1/0x370 [ 3.868407] __driver_probe_device+0xfc/0x170 [ 3.868410] driver_probe_device+0x1f/0x90 [ 3.868412] __driver_attach+0xbf/0x1a0 [ 3.868414] ? __device_attach_driver+0xe0/0xe0 [ 3.868416] bus_for_each_dev+0x65/0x90 [ 3.868419] bus_add_driver+0x151/0x1f0 [ 3.868421] driver_register+0x89/0xd0 [ 3.868423] ? 0xffffffffc0bd4000 [ 3.868425] do_one_initcall+0x5d/0x300 [ 3.868428] ? do_init_module+0x22/0x240 [ 3.868431] ? rcu_read_lock_sched_held+0x3c/0x70 [ 3.868434] ? trace_kmalloc+0x30/0xe0 [ 3.868437] ? kmem_cache_alloc_trace+0x1e6/0x3a0 [ 3.868440] do_init_module+0x4a/0x240 [ 3.868442] __do_sys_finit_module+0x93/0xf0 [ 3.868446] do_syscall_64+0x5b/0x80 [ 3.868449] ? rcu_read_lock_sched_held+0x3c/0x70 [ 3.868451] ? lockdep_hardirqs_on_prepare+0xd9/0x180 [ 3.868454] ? do_syscall_64+0x67/0x80 [ 3.868456] ? do_syscall_64+0x67/0x80 [ 3.868458] ? do_syscall_64+0x67/0x80 [ 3.868460] ? do_syscall_64+0x67/0x80 [ 3.868462] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3.868465] RIP: 0033:0x7fc4d8ec1ced [ 3.868467] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fb 70 0e 00 f7 d8 64 89 01 48 [ 3.868472] RSP: 002b:00007fff687ae6b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 3.868475] RAX: ffffffffffffffda RBX: 0000560a76fbca60 RCX: 00007fc4d8ec1ced [ 3.868477] RDX: 0000000000000000 RSI: 00007fc4d902343c RDI: 0000000000000011 [ 3.868479] RBP: 00007fc4d902343c R08: 0000000000000000 R09: 0000560a76fb59c0 [ 3.868481] R10: 0000000000000011 R11: 0000000000000246 R12: 0000000000020000 [ 3.868484] R13: 0000560a76f8bfd0 R14: 0000000000000000 R15: 0000560a76fc2d10 [ 3.868487] </TASK> [ 3.868489] irq event stamp: 120617 [ 3.868490] hardirqs last enabled at (120617): [<ffffffff9817169e>] __up_console_sem+0x5e/0x70 [ 3.868494] hardirqs last disabled at (120616): [<ffffffff98171683>] __up_console_sem+0x43/0x70 [ 3.868497] softirqs last enabled at (119684): [<ffffffff980ee83a>] __irq_exit_rcu+0xca/0x100 [ 3.868501] softirqs last disabled at (119679): [<ffffffff980ee83a>] __irq_exit_rcu+0xca/0x100 [ 3.868504] ---[ end trace 0000000000000000 ]--- Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c index f1544755d8b4..a44a6f41fa1e 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c @@ -576,6 +576,8 @@ static int smu_early_init(void *handle) smu->smu_baco.platform_support = false; smu->user_dpm_profile.fan_mode = -1; + mutex_init(&smu->message_lock); + adev->powerplay.pp_handle = smu; adev->powerplay.pp_funcs = &swsmu_pm_funcs; @@ -975,8 +977,6 @@ static int smu_sw_init(void *handle) bitmap_zero(smu->smu_feature.supported, SMU_FEATURE_MAX); bitmap_zero(smu->smu_feature.allowed, SMU_FEATURE_MAX); - mutex_init(&smu->message_lock); - INIT_WORK(&smu->throttling_logging_work, smu_throttling_logging_work_fn); INIT_WORK(&smu->interrupt_work, smu_interrupt_work_fn); atomic64_set(&smu->throttle_int_counter, 0); -- 2.36.0

2 1

[PATCH v5] drm/msm/dp: Always clear mask bits to disable interrupts at dp_ctrl_reset_irq_ctrl()
by Kuogee Hsieh 12 May '22

12 May '22

dp_catalog_ctrl_reset() will software reset DP controller. But it will not reset programmable registers to default value. DP driver still have to clear mask bits to interrupt status registers to disable interrupts after software reset of controller. At current implementation, dp_ctrl_reset_irq_ctrl() will software reset dp controller but did not call dp_catalog_ctrl_enable_irq(false) to clear hpd related interrupt mask bits to disable hpd related interrupts due to it mistakenly think hpd related interrupt mask bits will be cleared by software reset of dp controller automatically. This mistake may cause system to crash during suspending procedure due to unexpected irq fired and trigger event thread to access dp controller registers with controller clocks are disabled. This patch fixes system crash during suspending problem by removing "enable" flag condition checking at dp_ctrl_reset_irq_ctrl() so that hpd related interrupt mask bits are cleared to prevent unexpected from happening. In addition, this patch also add suspended flag to prevent new events be added into event Q to wake up event thread after system suspended. Changes in v2: -- add more details commit text Changes in v3: -- add synchrons_irq() -- add atomic_t suspended Changes in v4: -- correct Fixes's commit ID -- remove synchrons_irq() Changes in v5: -- revise commit text Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt received") Signed-off-by: Kuogee Hsieh <quic_khsieh(a)quicinc.com> --- drivers/gpu/drm/msm/dp/dp_ctrl.c | 9 +++++++-- drivers/gpu/drm/msm/dp/dp_display.c | 11 +++++++++++ 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c index af7a80c..f3e333e 100644 --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c @@ -1389,8 +1389,13 @@ void dp_ctrl_reset_irq_ctrl(struct dp_ctrl *dp_ctrl, bool enable) dp_catalog_ctrl_reset(ctrl->catalog); - if (enable) - dp_catalog_ctrl_enable_irq(ctrl->catalog, enable); + /* + * all dp controller programmable registers will not + * be reset to default value after DP_SW_RESET + * therefore interrupt mask bits have to be updated + * to enable/disable interrupts + */ + dp_catalog_ctrl_enable_irq(ctrl->catalog, enable); } void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index c388323..79439b8 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -98,6 +98,8 @@ struct dp_display_private { struct dp_ctrl *ctrl; struct dp_debug *debug; + atomic_t suspended; + struct dp_usbpd_cb usbpd_cb; struct dp_display_mode dp_mode; struct msm_dp dp_display; @@ -187,6 +189,11 @@ static int dp_add_event(struct dp_display_private *dp_priv, u32 event, int pndx; spin_lock_irqsave(&dp_priv->event_lock, flag); + if (atomic_read(&dp_priv->suspended)) { + spin_unlock_irqrestore(&dp_priv->event_lock, flag); + return -EPERM; + } + pndx = dp_priv->event_pndx + 1; pndx %= DP_EVENT_Q_MAX; if (pndx == dp_priv->event_gndx) { @@ -1362,6 +1369,8 @@ static int dp_pm_resume(struct device *dev) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized, dp_display->power_on); + atomic_set(&dp->suspended, 0); + /* start from disconnected state */ dp->hpd_state = ST_DISCONNECTED; @@ -1431,6 +1440,8 @@ static int dp_pm_suspend(struct device *dev) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized, dp_display->power_on); + atomic_inc(&dp->suspended); + /* mainlink enabled */ if (dp_power_clk_status(dp->power, DP_CTRL_PM)) dp_ctrl_off_link_stream(dp->ctrl); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 5

[PATCH v4 0/7] Make the rest of the VFIO driver interface use vfio_device
by Jason Gunthorpe 12 May '22

12 May '22

Prior series have transformed other parts of VFIO from working on struct device or struct vfio_group into working directly on struct vfio_device. Based on that work we now have vfio_device's readily available in all the drivers. Update the rest of the driver facing API to use vfio_device as an input. The following are switched from struct device to struct vfio_device: vfio_register_notifier() vfio_unregister_notifier() vfio_pin_pages() vfio_unpin_pages() vfio_dma_rw() The following group APIs are obsoleted and removed by just using struct vfio_device with the above: vfio_group_pin_pages() vfio_group_unpin_pages() vfio_group_iommu_domain() vfio_group_get_external_user_from_dev() To retain the performance of the new device APIs relative to their group versions optimize how vfio_group_add_container_user() is used to avoid calling it when the driver must already guarantee the device is open and the container_users incrd. The remaining exported VFIO group interfaces are only used by kvm, and are addressed by a parallel series. This series is based on Christoph's gvt rework here: https://lore.kernel.org/all/5a8b9f48-2c32-8177-1c18-e3bd7bfde558@intel.com/ and so will need the PR merged first. I have a followup series that needs this. This is also part of the iommufd work - moving the driver facing interface to vfio_device provides a much cleaner path to integrate with iommufd. v4: - Use 'device' as the argument name for a struct vfio_device in vfio.c v3: https://lore.kernel.org/r/0-v3-e131a9b6b467+14b6-vfio_mdev_no_group_jgg@nvi… - Based on VFIO's gvt/iommu merge - Remove mention of mdev_legacy_get_vfio_device() from commit message - Clarify commit message for vfio_dma_rw() conversion - Talk about the open_count change in the commit message - No code change v2: https://lore.kernel.org/r/0-v2-6011bde8e0a1+5f-vfio_mdev_no_group_jgg@nvidi… - Based on Christoph's series so mdev_legacy_get_vfio_device() is removed - Reflow indenting - Use vfio_assert_device_open() and WARN_ON_ONCE instead of open coding the assertion v1: https://lore.kernel.org/r/0-v1-a8faf768d202+125dd-vfio_mdev_no_group_jgg@nv… Jason Gunthorpe (7): vfio: Make vfio_(un)register_notifier accept a vfio_device vfio/ccw: Remove mdev from struct channel_program vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages() vfio/mdev: Pass in a struct vfio_device * to vfio_dma_rw() drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pages vfio: Remove dead code vfio: Remove calls to vfio_group_add_container_user() .../driver-api/vfio-mediated-device.rst | 4 +- drivers/gpu/drm/i915/gvt/gvt.h | 5 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 51 ++- drivers/s390/cio/vfio_ccw_cp.c | 47 +-- drivers/s390/cio/vfio_ccw_cp.h | 4 +- drivers/s390/cio/vfio_ccw_fsm.c | 3 +- drivers/s390/cio/vfio_ccw_ops.c | 7 +- drivers/s390/crypto/vfio_ap_ops.c | 23 +- drivers/vfio/vfio.c | 299 +++--------------- include/linux/vfio.h | 21 +- 10 files changed, 109 insertions(+), 355 deletions(-) base-commit: 676d7cda1a3c19872428a9bc818577a1aafafdd5 -- 2.36.0

3 9

[BUG] Warning and NULL-ptr dereference in amdgpu driver with 5.18
by Jörg Rödel 12 May '22

12 May '22

Hi, since recently I started to experience warnings and NULL-ptr dereferences in the amdgpu driver with kernel 5.18-rc5+. Earlier 5.18-based kernels might be affected as well, but I havn't seen this with 5.17. The kernel was built from the iommu-next branch, based on 5.18-rc5. The messages start with some PCIe error being reported: [20389.984993] pcieport 0000:00:03.1: AER: Multiple Corrected error received: 0000:0a:00.0 [20389.985005] amdgpu 0000:0a:00.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) [20389.985007] amdgpu 0000:0a:00.0: device [1002:6995] error status/mask=000000c0/00002000 [20389.985010] amdgpu 0000:0a:00.0: [ 6] BadTLP [20389.985013] amdgpu 0000:0a:00.0: [ 7] BadDLLP Directly followed by a waring: [81829.087101] ------------[ cut here ]------------ [81829.087105] WARNING: CPU: 4 PID: 644 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce110/dce110_clk_mgr.c:140 dce110_fill_display_configs+0x4a/0x150 [amdgpu] [81829.087461] Modules linked in: snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) rfcomm(E) af_packet(E) ocrdma(E) ib_uverbs(E) ib_core(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_tables(E) ebtable_nat(E) ebtable_broute(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ip_set(E) nfnetlink(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) bpfilter(E) cmac(E) algif_hash(E) algif_skcipher(E) af_alg(E) bnep(E) dmi_sysfs(E) intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E) eeepc_wmi(E) btusb(E) asus_wmi(E) kvm_amd(E) btrtl(E) snd_hda_codec_generic(E) nls_iso8859_1(E) battery(E) uvcvideo(E) sparse_keymap(E) ledtrig_audio(E) btbcm(E) video(E) wmi_bmof(E) [81829.087502] platform_profile(E) mxm_wmi(E) snd_hda_codec_hdmi(E) nls_cp437(E) videobuf2_vmalloc(E) btintel(E) asus_wmi_sensors(E) btmtk(E) vfat(E) snd_hda_intel(E) videobuf2_memops(E) videobuf2_v4l2(E) snd_intel_dspcfg(E) bluetooth(E) kvm(E) videobuf2_common(E) fat(E) snd_usb_audio(E) snd_virtuoso(E) irqbypass(E) snd_usbmidi_lib(E) snd_hda_codec(E) snd_oxygen_lib(E) videodev(E) snd_hwdep(E) snd_mpu401_uart(E) mc(E) snd_hda_core(E) ecdh_generic(E) snd_rawmidi(E) snd_pcm(E) snd_seq_device(E) rfkill(E) pcspkr(E) i2c_piix4(E) efi_pstore(E) k10temp(E) snd_timer(E) ext4(E) igb(E) snd(E) dca(E) soundcore(E) mbcache(E) be2net(E) jbd2(E) wmi(E) gpio_amdpt(E) gpio_generic(E) tiny_power_button(E) button(E) acpi_cpufreq(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) dm_crypt(E) essiv(E) authenc(E) trusted(E) asn1_encoder(E) tee(E) hid_logitech_hidpp(E) hid_logitech_dj(E) hid_generic(E) usbhid(E) sr_mod(E) cdrom(E) uas(E) usb_storage(E) amdgpu(E) [81829.087551] drm_ttm_helper(E) ttm(E) iommu_v2(E) gpu_sched(E) i2c_algo_bit(E) crct10dif_pclmul(E) drm_dp_helper(E) crc32_pclmul(E) crc32c_intel(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) drm(E) xhci_pci(E) cec(E) ghash_clmulni_intel(E) xhci_pci_renesas(E) aesni_intel(E) crypto_simd(E) cryptd(E) sp5100_tco(E) xhci_hcd(E) ccp(E) rc_core(E) nvme(E) usbcore(E) nvme_core(E) sg(E) br_netfilter(E) bridge(E) stp(E) llc(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) ledtrig_timer(E) msr(E) efivarfs(E) [81829.087581] CPU: 4 PID: 644 Comm: kworker/4:1H Tainted: G E 5.18.0-rc5-iommu-next+ #1 4d1b12f73ec264927e45e8f2e5d1c0c8e280bc7d [81829.087585] Hardware name: System manufacturer System Product Name/PRIME X470-PRO, BIOS 5406 11/13/2019 [81829.087588] Workqueue: events_highpri dm_irq_work_func [amdgpu] [81829.087928] RIP: 0010:dce110_fill_display_configs+0x4a/0x150 [amdgpu] [81829.088274] Code: 31 ff 4d 8d 98 f0 01 00 00 49 8b 0c f8 4c 89 da 31 c0 48 39 0a 0f 84 e4 00 00 00 83 c0 01 48 81 c2 10 08 00 00 83 f8 06 75 e8 <0f> 0b 31 c0 80 b9 48 03 00 00 00 0f 85 a9 00 00 00 48 8b 50 08 8b [81829.088277] RSP: 0018:ffffb891810c3be0 EFLAGS: 00010246 [81829.088280] RAX: 0000000000000006 RBX: ffff9719a6b60000 RCX: ffff971d08e07800 [81829.088282] RDX: ffff9719a6b63250 RSI: ffff9719a6b72980 RDI: 0000000000000001 [81829.088284] RBP: ffff971a812f0000 R08: ffff9719a6b60000 R09: 0000000000000000 [81829.088286] R10: ffff9719a6b72980 R11: ffff9719a6b601f0 R12: ffff9719a6b72980 [81829.088287] R13: ffff9719a6b60000 R14: 0000000000000006 R15: 0000000000003258 [81829.088289] FS: 0000000000000000(0000) GS:ffff97285eb00000(0000) knlGS:0000000000000000 [81829.088291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81829.088293] CR2: 00007fbc4800bb28 CR3: 00000002909c0000 CR4: 00000000003506e0 [81829.088295] Call Trace: [81829.088298] <TASK> [81829.088300] dce11_pplib_apply_display_requirements+0x129/0x200 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.088646] dce112_update_clocks+0x8d/0xf0 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.088992] dc_commit_updates_for_stream+0x1a91/0x1ef0 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.089330] ? detect_link_and_local_sink+0x3b4/0xb40 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.089665] set_all_streams_dpms_off_for_link+0x10e/0x120 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.090002] dc_link_detect+0x187/0x420 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.090336] handle_hpd_irq_helper+0xe9/0x190 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.090701] process_one_work+0x217/0x3e0 [81829.090707] worker_thread+0x4d/0x3c0 [81829.090712] ? rescuer_thread+0x380/0x380 [81829.090715] kthread+0xd9/0x100 [81829.090719] ? kthread_complete_and_exit+0x20/0x20 [81829.090722] ret_from_fork+0x22/0x30 [81829.090728] </TASK> [81829.090729] ---[ end trace 0000000000000000 ]--- And this NULL-ptr dereference: [81829.090732] BUG: kernel NULL pointer dereference, address: 0000000000000008 [81829.090737] #PF: supervisor read access in kernel mode [81829.090741] #PF: error_code(0x0000) - not-present page [81829.090744] PGD 0 P4D 0 [81829.090747] Oops: 0000 [#1] PREEMPT SMP NOPTI [81829.090751] CPU: 4 PID: 644 Comm: kworker/4:1H Tainted: G W E 5.18.0-rc5-iommu-next+ #1 4d1b12f73ec264927e45e8f2e5d1c0c8e280bc7d [81829.090756] Hardware name: System manufacturer System Product Name/PRIME X470-PRO, BIOS 5406 11/13/2019 [81829.090758] Workqueue: events_highpri dm_irq_work_func [amdgpu] [81829.091111] RIP: 0010:dce110_fill_display_configs+0x5b/0x150 [amdgpu] [81829.091455] Code: c0 48 39 0a 0f 84 e4 00 00 00 83 c0 01 48 81 c2 10 08 00 00 83 f8 06 75 e8 0f 0b 31 c0 80 b9 48 03 00 00 00 0f 85 a9 00 00 00 <48> 8b 50 08 8b 9a 44 03 00 00 49 63 d1 41 83 c1 01 48 8d 14 92 49 [81829.091458] RSP: 0018:ffffb891810c3be0 EFLAGS: 00010246 [81829.091461] RAX: 0000000000000000 RBX: ffff9719a6b60000 RCX: ffff971d08e07800 [81829.091463] RDX: ffff9719a6b63250 RSI: ffff9719a6b72980 RDI: 0000000000000001 [81829.091465] RBP: ffff971a812f0000 R08: ffff9719a6b60000 R09: 0000000000000000 [81829.091467] R10: ffff9719a6b72980 R11: ffff9719a6b601f0 R12: ffff9719a6b72980 [81829.091469] R13: ffff9719a6b60000 R14: 0000000000000006 R15: 0000000000003258 [81829.091471] FS: 0000000000000000(0000) GS:ffff97285eb00000(0000) knlGS:0000000000000000 [81829.091474] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81829.091476] CR2: 0000000000000008 CR3: 00000002909c0000 CR4: 00000000003506e0 [81829.091479] Call Trace: [81829.091480] <TASK> [81829.091482] dce11_pplib_apply_display_requirements+0x129/0x200 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.091828] dce112_update_clocks+0x8d/0xf0 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.092173] dc_commit_updates_for_stream+0x1a91/0x1ef0 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.092509] ? detect_link_and_local_sink+0x3b4/0xb40 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.092844] set_all_streams_dpms_off_for_link+0x10e/0x120 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.093180] dc_link_detect+0x187/0x420 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.093514] handle_hpd_irq_helper+0xe9/0x190 [amdgpu 1a7cfa9f14a3ef2ba289fa21a3c241108d69cd98] [81829.093853] process_one_work+0x217/0x3e0 [81829.093858] worker_thread+0x4d/0x3c0 [81829.093861] ? rescuer_thread+0x380/0x380 [81829.093865] kthread+0xd9/0x100 [81829.093868] ? kthread_complete_and_exit+0x20/0x20 [81829.093872] ret_from_fork+0x22/0x30 [81829.093876] </TASK> [81829.093878] Modules linked in: snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) rfcomm(E) af_packet(E) ocrdma(E) ib_uverbs(E) ib_core(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_tables(E) ebtable_nat(E) ebtable_broute(E) ip6table_nat(E) ip6table_mangle(E) ip6table_raw(E) ip6table_security(E) iptable_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) iptable_mangle(E) iptable_raw(E) iptable_security(E) ip_set(E) nfnetlink(E) ebtable_filter(E) ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E) bpfilter(E) cmac(E) algif_hash(E) algif_skcipher(E) af_alg(E) bnep(E) dmi_sysfs(E) intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E) eeepc_wmi(E) btusb(E) asus_wmi(E) kvm_amd(E) btrtl(E) snd_hda_codec_generic(E) nls_iso8859_1(E) battery(E) uvcvideo(E) sparse_keymap(E) ledtrig_audio(E) btbcm(E) video(E) wmi_bmof(E) [81829.093913] platform_profile(E) mxm_wmi(E) snd_hda_codec_hdmi(E) nls_cp437(E) videobuf2_vmalloc(E) btintel(E) asus_wmi_sensors(E) btmtk(E) vfat(E) snd_hda_intel(E) videobuf2_memops(E) videobuf2_v4l2(E) snd_intel_dspcfg(E) bluetooth(E) kvm(E) videobuf2_common(E) fat(E) snd_usb_audio(E) snd_virtuoso(E) irqbypass(E) snd_usbmidi_lib(E) snd_hda_codec(E) snd_oxygen_lib(E) videodev(E) snd_hwdep(E) snd_mpu401_uart(E) mc(E) snd_hda_core(E) ecdh_generic(E) snd_rawmidi(E) snd_pcm(E) snd_seq_device(E) rfkill(E) pcspkr(E) i2c_piix4(E) efi_pstore(E) k10temp(E) snd_timer(E) ext4(E) igb(E) snd(E) dca(E) soundcore(E) mbcache(E) be2net(E) jbd2(E) wmi(E) gpio_amdpt(E) gpio_generic(E) tiny_power_button(E) button(E) acpi_cpufreq(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) dm_crypt(E) essiv(E) authenc(E) trusted(E) asn1_encoder(E) tee(E) hid_logitech_hidpp(E) hid_logitech_dj(E) hid_generic(E) usbhid(E) sr_mod(E) cdrom(E) uas(E) usb_storage(E) amdgpu(E) [81829.093952] drm_ttm_helper(E) ttm(E) iommu_v2(E) gpu_sched(E) i2c_algo_bit(E) crct10dif_pclmul(E) drm_dp_helper(E) crc32_pclmul(E) crc32c_intel(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) drm(E) xhci_pci(E) cec(E) ghash_clmulni_intel(E) xhci_pci_renesas(E) aesni_intel(E) crypto_simd(E) cryptd(E) sp5100_tco(E) xhci_hcd(E) ccp(E) rc_core(E) nvme(E) usbcore(E) nvme_core(E) sg(E) br_netfilter(E) bridge(E) stp(E) llc(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E) ledtrig_timer(E) msr(E) efivarfs(E) [81829.093978] CR2: 0000000000000008 [81829.093980] ---[ end trace 0000000000000000 ]--- [81829.338958] RIP: 0010:dce110_fill_display_configs+0x5b/0x150 [amdgpu] [81829.339333] Code: c0 48 39 0a 0f 84 e4 00 00 00 83 c0 01 48 81 c2 10 08 00 00 83 f8 06 75 e8 0f 0b 31 c0 80 b9 48 03 00 00 00 0f 85 a9 00 00 00 <48> 8b 50 08 8b 9a 44 03 00 00 49 63 d1 41 83 c1 01 48 8d 14 92 49 [81829.339336] RSP: 0018:ffffb891810c3be0 EFLAGS: 00010246 [81829.339340] RAX: 0000000000000000 RBX: ffff9719a6b60000 RCX: ffff971d08e07800 [81829.339343] RDX: ffff9719a6b63250 RSI: ffff9719a6b72980 RDI: 0000000000000001 [81829.339345] RBP: ffff971a812f0000 R08: ffff9719a6b60000 R09: 0000000000000000 [81829.339347] R10: ffff9719a6b72980 R11: ffff9719a6b601f0 R12: ffff9719a6b72980 [81829.339349] R13: ffff9719a6b60000 R14: 0000000000000006 R15: 0000000000003258 [81829.339352] FS: 0000000000000000(0000) GS:ffff97285eb00000(0000) knlGS:0000000000000000 [81829.339355] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81829.339357] CR2: 0000000000000008 CR3: 00000002909c0000 CR4: 00000000003506e0 Usually one of the displays does not power on anymore after this and the machine locks up pretty soon as well, probably because the worker thread is dead. My GPU device is: 0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa XT [Radeon PRO WX 2100] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 0b0c Flags: bus master, fast devsel, latency 0, IRQ 90, IOMMU group 15 Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f0000000 (64-bit, prefetchable) [size=2M] I/O ports at e000 [size=256] Memory at fce00000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: amdgpu Kernel modules: amdgpu Please let me know if anything else is needed to debug this. Bisection is not really feasible, because the issue happens at random, sometimes after one or two days of uptime. Regards, -- Jörg Rödel jroedel(a)suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

2 9

← Newer
1
...
45
46
47
48
49
50
51
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022