dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH AUTOSEL 5.4 01/74] drm/etnaviv: fix NULL check before some freeing functions is not needed
by Sasha Levin 06 Jul '21

06 Jul '21

From: Tian Tao <tiantao6(a)hisilicon.com> [ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ] fixed the below warning: drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index f24dd21c2363..9e657a096f45 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -77,8 +77,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (etnaviv_obj->pages) - kvfree(etnaviv_obj->pages); + kvfree(etnaviv_obj->pages); drm_prime_gem_destroy(&etnaviv_obj->base, etnaviv_obj->sgt); } -- 2.30.2

1 16

[PATCH AUTOSEL 5.10 001/137] drm/etnaviv: fix NULL check before some freeing functions is not needed
by Sasha Levin 06 Jul '21

06 Jul '21

From: Tian Tao <tiantao6(a)hisilicon.com> [ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ] fixed the below warning: drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index 4aa3426a9ba4..059ec31d532d 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -77,8 +77,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (etnaviv_obj->pages) - kvfree(etnaviv_obj->pages); + kvfree(etnaviv_obj->pages); drm_prime_gem_destroy(&etnaviv_obj->base, etnaviv_obj->sgt); } -- 2.30.2

1 33

[PATCH AUTOSEL 5.12 001/160] drm/etnaviv: fix NULL check before some freeing functions is not needed
by Sasha Levin 06 Jul '21

06 Jul '21

From: Tian Tao <tiantao6(a)hisilicon.com> [ Upstream commit 7d614ab2f20503ed8766363d41f8607337571adf ] fixed the below warning: drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao <tiantao6(a)hisilicon.com> Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index b390dd4d60b7..d741b1d735f7 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -80,8 +80,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (etnaviv_obj->pages) - kvfree(etnaviv_obj->pages); + kvfree(etnaviv_obj->pages); drm_prime_gem_destroy(&etnaviv_obj->base, etnaviv_obj->sgt); } -- 2.30.2

1 40

[PATCH] drm/hisilicon/hibmc: Convert to Linux IRQ interfaces
by Thomas Zimmermann 06 Jul '21

06 Jul '21

Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index d2628956dca3..f73a8e0ea12e 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -19,7 +19,6 @@ #include <drm/drm_drv.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_gem_vram_helper.h> -#include <drm/drm_irq.h> #include <drm/drm_managed.h> #include <drm/drm_vblank.h> @@ -28,7 +27,7 @@ DEFINE_DRM_GEM_FOPS(hibmc_fops); -static irqreturn_t hibmc_drm_interrupt(int irq, void *arg) +static irqreturn_t hibmc_interrupt(int irq, void *arg) { struct drm_device *dev = (struct drm_device *)arg; struct hibmc_drm_private *priv = to_hibmc_drm_private(dev); @@ -63,7 +62,6 @@ static const struct drm_driver hibmc_driver = { .dumb_create = hibmc_dumb_create, .dumb_map_offset = drm_gem_ttm_dumb_map_offset, .gem_prime_mmap = drm_gem_prime_mmap, - .irq_handler = hibmc_drm_interrupt, }; static int __maybe_unused hibmc_pm_suspend(struct device *dev) @@ -251,9 +249,12 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv) static int hibmc_unload(struct drm_device *dev) { + struct hibmc_drm_private *priv = to_hibmc_drm_private(dev); + struct pci_dev *pdev = to_pci_dev(dev->dev); + drm_atomic_helper_shutdown(dev); - drm_irq_uninstall(dev); + free_irq(pdev->irq, dev); pci_disable_msi(to_pci_dev(dev->dev)); @@ -290,7 +291,9 @@ static int hibmc_load(struct drm_device *dev) if (ret) { drm_warn(dev, "enabling MSI failed: %d\n", ret); } else { - ret = drm_irq_install(dev, pdev->irq); + /* PCI devices require shared interrupts. */ + ret = request_irq(pdev->irq, hibmc_interrupt, IRQF_SHARED, + dev->driver->name, dev); if (ret) drm_warn(dev, "install irq failed: %d\n", ret); } -- 2.32.0

3 2

XDC 2021: Registration & Call for Proposals now open!
by Szwichtenberg, Radoslaw 06 Jul '21

06 Jul '21

Hello! Registration & Call for Proposals are now open for XDC 2021, which will take place on September 15-17, 2021. This year we will repeat as virtual event. https://indico.freedesktop.org/event/1/ As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to register via the XDC website. As XDC moved to a new Indico infrastructure, if you previously registered on the XDC website, you need to create a new account again. https://indico.freedesktop.org/event/1/registrations/1/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2021. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/1/abstracts/ The deadline for submissions is Sunday, 4 July 2021. Last year we modified our Reimbursement Policy to accept speaker expenses for X.Org virtual events like XDC 2021. Check it out here: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to radoslaw.szwichtenberg(a)intel.com<mailto:radoslaw.szwichtenberg@intel.com>, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best, Radek P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please use the mentioned links for the moment. Radosław Szwichtenberg ------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173, 80-298 Gdansk KRS 101882 - NIP 957-07-52-316

2 4

[PATCH 1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks
by Matthew Auld 06 Jul '21

06 Jul '21

The block here can't be NULL, especially since we already dereferenced it earlier, so remove the redundant check. igt_check_blocks() warn: variable dereferenced before check 'block' (see line 126) Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> --- drivers/gpu/drm/i915/selftests/i915_buddy.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_buddy.c b/drivers/gpu/drm/i915/selftests/i915_buddy.c index f0f5c4df8dbc..d61ec9c951bf 100644 --- a/drivers/gpu/drm/i915/selftests/i915_buddy.c +++ b/drivers/gpu/drm/i915/selftests/i915_buddy.c @@ -166,10 +166,8 @@ static int igt_check_blocks(struct i915_buddy_mm *mm, igt_dump_block(mm, prev); } - if (block) { - pr_err("bad block, dump:\n"); - igt_dump_block(mm, block); - } + pr_err("bad block, dump:\n"); + igt_dump_block(mm, block); return err; } -- 2.26.3

2 3

[PATCH] drm: vc4: Fix pixel-wrap issue with DVP teardown
by Maxime Ripard 06 Jul '21

06 Jul '21

From: Tim Gover <tim.gover(a)raspberrypi.com> Adjust the DVP enable/disable sequence to avoid a pixel getting stuck in an internal, non resettable FIFO within PixelValve when changing HDMI resolution. The blank pixels features of the DVP can prevent signals back to pixelvalve causing it to not clear the FIFO. Adjust the ordering and timing of operations to ensure the clear signal makes it through to pixelvalve. Signed-off-by: Tim Gover <tim.gover(a)raspberrypi.com> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 4ebe216b10a9..472a9d6b5866 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -605,12 +605,12 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder, HDMI_WRITE(HDMI_RAM_PACKET_CONFIG, 0); - HDMI_WRITE(HDMI_VID_CTL, HDMI_READ(HDMI_VID_CTL) | - VC4_HD_VID_CTL_CLRRGB | VC4_HD_VID_CTL_CLRSYNC); + HDMI_WRITE(HDMI_VID_CTL, HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_CLRRGB); + + mdelay(1); HDMI_WRITE(HDMI_VID_CTL, - HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX); - + HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE); vc4_hdmi_disable_scrambling(encoder); } @@ -620,12 +620,12 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder, struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder); int ret; + HDMI_WRITE(HDMI_VID_CTL, + HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX); + if (vc4_hdmi->variant->phy_disable) vc4_hdmi->variant->phy_disable(vc4_hdmi); - HDMI_WRITE(HDMI_VID_CTL, - HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE); - clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock); clk_disable_unprepare(vc4_hdmi->hsm_clock); clk_disable_unprepare(vc4_hdmi->pixel_clock); @@ -1017,6 +1017,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder, HDMI_WRITE(HDMI_VID_CTL, VC4_HD_VID_CTL_ENABLE | + VC4_HD_VID_CTL_CLRRGB | VC4_HD_VID_CTL_UNDERFLOW_ENABLE | VC4_HD_VID_CTL_FRAME_COUNTER_RESET | (vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) | -- 2.31.1

1 1

[PATCH 1/2] dma-fence: export dma_fence_might_wait
by Matthew Auld 06 Jul '21

06 Jul '21

It might be useful for drivers to annotate a path where hitting the actual wait path might be difficult or unlikely through normal testing. Suggested-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/dma-buf/dma-fence.c | 19 ++++++++++++++++--- include/linux/dma-fence.h | 2 ++ 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index ce0f5eff575d..f2cd036b5243 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -335,6 +335,21 @@ void __dma_fence_might_wait(void) } #endif +/** + * dma_fence_might_wait - entering a section which might wait on DMA fence + * critical section. + * + * This is also potentially useful for drivers to call directly, when annotating + * a path where hitting the actual wait path might be difficult or unlikely + * through normal testing. + */ +void dma_fence_might_wait(void) +{ + might_sleep(); + __dma_fence_might_wait(); +} +EXPORT_SYMBOL(dma_fence_might_wait); + /** * dma_fence_signal_timestamp_locked - signal completion of a fence @@ -495,9 +510,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout) if (WARN_ON(timeout < 0)) return -EINVAL; - might_sleep(); - - __dma_fence_might_wait(); + dma_fence_might_wait(); trace_dma_fence_wait_start(fence); if (fence->ops->wait) diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 6ffb4b2c6371..37bf4beed93f 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -370,6 +370,8 @@ static inline void dma_fence_end_signalling(bool cookie) {} static inline void __dma_fence_might_wait(void) {} #endif +void dma_fence_might_wait(void); + int dma_fence_signal(struct dma_fence *fence); int dma_fence_signal_locked(struct dma_fence *fence); int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp); -- 2.26.3

2 4

[PATCH] drm/vc4: hdmi: Limit noise when deferring snd card registration
by Nicolas Saenz Julienne 06 Jul '21

06 Jul '21

We don't want to print an error message each time devm_snd_soc_register_card() returns -EPROBE_DEFER, the function will most likely succeed some time in the future, once the missing resources are available. So use dev_err_probe(), which will redirect the messages to the debug log level in such case. Signed-off-by: Nicolas Saenz Julienne <nsaenzju(a)redhat.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 04936cd6db8c..32da45821d3a 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1575,7 +1575,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) snd_soc_card_set_drvdata(card, vc4_hdmi); ret = devm_snd_soc_register_card(dev, card); if (ret) - dev_err(dev, "Could not register sound card: %d\n", ret); + dev_err_probe(dev, ret, "Could not register sound card\n"); return ret; -- 2.31.1

2 1

[Bug 207383] New: [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
by bugzilla-daemon＠bugzilla.kernel.org 06 Jul '21

06 Jul '21

https://bugzilla.kernel.org/show_bug.cgi?id=207383 Bug ID: 207383 Summary: [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail Product: Drivers Version: 2.5 Kernel Version: 5.7-rc1, 5.7-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: 1i5t5.duncan(a)cox.net Regression: No Created attachment 288649 --> https://bugzilla.kernel.org/attachment.cgi?id=288649&action=edit kernel config 5.7-rc1 and rc2 regression from kernel 5.6.0 After starting X/plasma on 5.7-rc1 and rc2, system runs for a few seconds to a few hours, then display freezes. The pointer continues to be movable and audio will continue to play for some seconds but they eventually stop as well. The kernel remains alive at least enough to reboot with SRQ-b, not sure if previous SRQs have any effect or not. Sometimes but not always there's a gpf left in the log, appearing to confirm it's amdgpu (the -dirty is simply a patch making mounts noatime by default): Apr 20 03:25:55 h2 kernel: general protection fault, probably for non-canonical address 0xc1316515e40a92f6: 0000 [#1] SMP Apr 20 03:25:55 h2 kernel: CPU: 3 PID: 3921 Comm: kworker/u16:5 Tainted: G T 5.7.0-rc2-dirty #194 Apr 20 03:25:55 h2 kernel: Hardware name: Gigabyte Technology Co., Ltd. GA-990FXA-UD3/GA-990FXA-UD3, BIOS F6 03/30/2012 Apr 20 03:25:55 h2 kernel: Workqueue: events_unbound commit_work Apr 20 03:25:55 h2 kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x102d/0x1fd8 Apr 20 03:25:55 h2 kernel: Code: 48 89 9d a0 fc ff ff 8b 90 e0 02 00 00 85 d2 0f 85 26 f1 ff ff 48 8b 85 e0 fc ff ff 48 89 85 a0 fc ff ff 48 8b b5 e0 fc ff ff <80> be b0 01 00 00 01 0f 86 b4 00 00 00 31 c0 48 b9 00 00 00 00 01 Apr 20 03:25:55 h2 kernel: RSP: 0018:ffffc9000216bad0 EFLAGS: 00010286 Apr 20 03:25:55 h2 kernel: RAX: ffff88842a6e1000 RBX: ffff8883d1d5b800 RCX: ffff8884283db200 Apr 20 03:25:55 h2 kernel: RDX: ffff8884283db2e0 RSI: c1316515e40a92f6 RDI: 0000000000000002 Apr 20 03:25:55 h2 kernel: RBP: ffffc9000216be50 R08: 0000000000000001 R09: 0000000000000001 Apr 20 03:25:55 h2 kernel: R10: 0000000000030000 R11: 0000000000000000 R12: 0000000000000000 Apr 20 03:25:55 h2 kernel: R13: 0000000000000005 R14: ffff88842bb76000 R15: ffff88841c08cc00 Apr 20 03:25:55 h2 kernel: FS: 0000000000000000(0000) GS:ffff88842ecc0000(0000) knlGS:0000000000000000 Apr 20 03:25:55 h2 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 20 03:25:55 h2 kernel: CR2: 000078617de4fffc CR3: 000000040ca0e000 CR4: 00000000000406e0 Apr 20 03:25:55 h2 kernel: Call Trace: Apr 20 03:25:55 h2 kernel: ? 0xffffffff81000000 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x34/0x70 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x40/0x70 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x34/0x70 Apr 20 03:25:55 h2 kernel: ? __switch_to_asm+0x40/0x70 Apr 20 03:25:55 h2 kernel: ? commit_tail+0x8e/0x120 Apr 20 03:25:55 h2 kernel: ? process_one_work+0x1a9/0x300 Apr 20 03:25:55 h2 kernel: ? worker_thread+0x45/0x3b8 Apr 20 03:25:55 h2 kernel: ? kthread+0xf3/0x130 Apr 20 03:25:55 h2 kernel: ? process_one_work+0x300/0x300 Apr 20 03:25:55 h2 kernel: ? __kthread_create_on_node+0x180/0x180 Apr 20 03:25:55 h2 kernel: ? ret_from_fork+0x22/0x40 Apr 20 03:25:55 h2 kernel: ---[ end trace 33869116def8e8ad ]--- Apr 20 03:25:55 h2 kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x102d/0x1fd8 Apr 20 03:25:55 h2 kernel: Code: 48 89 9d a0 fc ff ff 8b 90 e0 02 00 00 85 d2 0f 85 26 f1 ff ff 48 8b 85 e0 fc ff ff 48 89 85 a0 fc ff ff 48 89 85 a0 fc ff ff 48 8b b5 e0 fc ff ff <80> be b0 01 00 00 01 0f 86 b4 00 00 00 31 c0 48 b9 00 00 00 00 01 Apr 20 03:25:55 h2 kernel: RSP: 0018:ffffc9000216bad0 EFLAGS: 00010286 Apr 20 03:25:55 h2 kernel: RAX: ffff88842a6e1000 RBX: ffff8883d1d5b800 RCX: ffff8884283db200 Apr 20 03:25:55 h2 kernel: RDX: ffff8884283db2e0 RSI: c1316515e40a92f6 RDI: 0000000000000002 Apr 20 03:25:55 h2 kernel: RBP: ffffc9000216be50 R08: 0000000000000001 R09: 0000000000000001 Apr 20 03:25:55 h2 kernel: R10: 0000000000030000 R11: 0000000000000000 R12: 0000000000000000 Apr 20 03:25:55 h2 kernel: R13: 0000000000000005 R14: ffff88842bb76000 R15: ffff88841c08cc00 Apr 20 03:25:55 h2 kernel: FS: 0000000000000000(0000) GS:ffff88842ecc0000(0000) knlGS:0000000000000000 Apr 20 03:25:55 h2 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 20 03:25:55 h2 kernel: CR2: 000078617de4fffc CR3: 000000040ca0e000 CR4: 00000000000406e0 That's it. Nothing in the log since boot before, and the next entry is after reboot. gcc version 9.3.0 on Gentoo. AMD fx6100 on the Gigabyte board in the log above. xorg-server 1.20.8, mesa 20.0.4, xf86-video-amdgpu 19.1.0, linux-firmware 20200413 kernel config attached -- You are receiving this mail because: You are watching the assignee of the bug.

1 121

← Newer
1
...
75
76
77
78
79
80
81
82
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021