Re: [DPU PATCH v2 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845
On 2018-03-29 20:22, Sean Paul wrote: On Thu, Mar 29, 2018 at 03:59:24PM +0530, Sravanthi Kollukuduru wrote: Currently, the downstream driver depends on the DT file for the hardware block offsets and other target specific catalog information. To align the driver with the upstream DT design, this information is now removed from the DT file and added in the driver source. Reviewed-by: Sean Paul Change-Id: I63a366d7d7a26939ee1c20c702c7d4d976852067 (btw, please strip these out when you send patches upstream. I will remove it when applying) Thanks Sean for pointing it out. Will take care from next time. Sravanthi Signed-off-by: Sravanthi Kollukuduru --- .../devicetree/bindings/display/msm/dpu.txt| 530 - 1 file changed, 530 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt index 136f0d3..90cd3e0 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt @@ -19,61 +19,6 @@ Required properties - interrupt-controller: Mark the device node as an interrupt controller. - #interrupt-cells: Should be one. The first cell is interrupt number. - iommus: Specifies the SID's used by this context bank. -- qcom,dpu-sspp-type: Array of strings for DPU source surface pipes type information. - A source pipe can be "vig", "rgb", "dma" or "cursor" type. - Number of xin ids defined should match the number of offsets - defined in property: qcom,dpu-sspp-off. -- qcom,dpu-sspp-off: Array of offset for DPU source surface pipes. The offsets - are calculated from register "mdp_phys" defined in -reg property + "dpu-off". The number of offsets defined here should - reflect the amount of pipes that can be active in DPU for - this configuration. -- qcom,dpu-sspp-xin-id: Array of VBIF clients ids (xins) corresponding - to the respective source pipes. Number of xin ids - defined should match the number of offsets - defined in property: qcom,dpu-sspp-off. -- qcom,dpu-ctl-off:Array of offset addresses for the available ctl - hw blocks within DPU, these offsets are - calculated from register "mdp_phys" defined in - reg property. The number of ctl offsets defined - here should reflect the number of control paths - that can be configured concurrently on DPU for - this configuration. -- qcom,dpu-wb-off: Array of offset addresses for the programmable - writeback blocks within DPU. -- qcom,dpu-wb-xin-id: Array of VBIF clients ids (xins) corresponding - to the respective writeback. Number of xin ids - defined should match the number of offsets - defined in property: qcom,dpu-wb-off. -- qcom,dpu-mixer-off: Array of offset addresses for the available - mixer blocks that can drive data to panel - interfaces. These offsets are be calculated from - register "mdp_phys" defined in reg property. - The number of offsets defined should reflect the - amount of mixers that can drive data to a panel - interface. -- qcom,dpu-dspp-top-off: Offset address for the dspp top block. - The offset is calculated from register "mdp_phys" - defined in reg property. -- qcom,dpu-dspp-off: Array of offset addresses for the available dspp - blocks. These offsets are calculated from - register "mdp_phys" defined in reg property. -- qcom,dpu-pp-off: Array of offset addresses for the available - pingpong blocks. These offsets are calculated - from register "mdp_phys" defined in reg property. -- qcom,dpu-pp-slave: Array of flags indicating whether each ping pong - block may be configured as a pp slave. -- qcom,dpu-intf-off: Array of offset addresses for the available DPU - interface blocks that can drive data to a - panel controller. The offsets are calculated - from "mdp_phys" defined in reg property. The number -
Re: [PATCH v2 4/6] drm/msm: Issue queued events when disabling crtc
On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:
Ensure that any queued events are issued when disabling the crtc. This
avoids timeouts when we come back and wait for dependencies (like the
previous frame's flip_done).
Reviewed-by: Archit Taneja
Changes in v2:
- None
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 76b96081916f..10271359789e 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -430,6 +430,7 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct device *dev = &mdp5_kms->pdev->dev;
+ unsigned long flags;
DBG("%s", crtc->name);
@@ -445,6 +446,14 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc *crtc,
mdp_irq_unregister(&mdp5_kms->base, &mdp5_crtc->err);
pm_runtime_put_sync(dev);
+ if (crtc->state->event && !crtc->state->active) {
+ WARN_ON(mdp5_crtc->event);
+ spin_lock_irqsave(&mdp5_kms->dev->event_lock, flags);
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ spin_unlock_irqrestore(&mdp5_kms->dev->event_lock, flags);
+ }
+
mdp5_crtc->enabled = false;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/6] drm/msm: Mark the crtc->state->event consumed
On Thursday 29 March 2018 12:36 AM, Sean Paul wrote: Don't leave the event != NULL once it's consumed, this is used a signal s/used a/used as a ? to the atomic helpers that the event will be handled by the driver. Reviewed-by: Archit Taneja Changes in v2: - None Cc: Jeykumar Sankaran Signed-off-by: Sean Paul --- drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c index 6e5e1aa54ce1..b001699297c4 100644 --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c @@ -351,6 +351,7 @@ static void mdp4_crtc_atomic_flush(struct drm_crtc *crtc, spin_lock_irqsave(&dev->event_lock, flags); mdp4_crtc->event = crtc->state->event; + crtc->state->event = NULL; spin_unlock_irqrestore(&dev->event_lock, flags); blend_setup(crtc); diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c index 9893e43ba6c5..76b96081916f 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c @@ -708,6 +708,7 @@ static void mdp5_crtc_atomic_flush(struct drm_crtc *crtc, spin_lock_irqsave(&dev->event_lock, flags); mdp5_crtc->event = crtc->state->event; + crtc->state->event = NULL; spin_unlock_irqrestore(&dev->event_lock, flags); /* ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/6] drm/msm: Refactor complete_commit() to look more the helpers
On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:
Factor out the commit_tail() portions of complete_commit() into a
separate function to facilitate moving to the atomic helpers in future
patches.
Reviewed-by: Archit Taneja
Changes in v2:
- None
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/msm_atomic.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index e792158676aa..671a18ee977d 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -97,18 +97,12 @@ static void msm_atomic_wait_for_commit_done(struct
drm_device *dev,
}
}
-/* The (potentially) asynchronous part of the commit. At this point
- * nothing can fail short of armageddon.
- */
-static void complete_commit(struct msm_commit *c, bool async)
+static void msm_atomic_commit_tail(struct drm_atomic_state *state)
{
- struct drm_atomic_state *state = c->state;
struct drm_device *dev = state->dev;
struct msm_drm_private *priv = dev->dev_private;
struct msm_kms *kms = priv->kms;
- drm_atomic_helper_wait_for_fences(dev, state, false);
-
kms->funcs->prepare_commit(kms, state);
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -135,6 +129,19 @@ static void complete_commit(struct msm_commit *c, bool
async)
drm_atomic_helper_cleanup_planes(dev, state);
kms->funcs->complete_commit(kms, state);
+}
+
+/* The (potentially) asynchronous part of the commit. At this point
+ * nothing can fail short of armageddon.
+ */
+static void complete_commit(struct msm_commit *c)
+{
+ struct drm_atomic_state *state = c->state;
+ struct drm_device *dev = state->dev;
+
+ drm_atomic_helper_wait_for_fences(dev, state, false);
+
+ msm_atomic_commit_tail(state);
drm_atomic_state_put(state);
@@ -143,7 +150,7 @@ static void complete_commit(struct msm_commit *c, bool async)
static void commit_worker(struct work_struct *work)
{
- complete_commit(container_of(work, struct msm_commit, work), true);
+ complete_commit(container_of(work, struct msm_commit, work));
}
/**
@@ -242,7 +249,7 @@ int msm_atomic_commit(struct drm_device *dev,
return 0;
}
- complete_commit(c, false);
+ complete_commit(c);
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] drm/msm: Use drm_private_obj/state instead of subclassing
On Thursday 29 March 2018 12:36 AM, Sean Paul wrote:
Now that we have private state handled by the core, we can use those
instead of rolling our own swap_state for private data.
Originally posted here: https://patchwork.freedesktop.org/patch/211361/
Changes in v2:
- Use state->state in disp duplicate_state callback (Jeykumar)
Changes in v3:
- Update comment describing msm_kms_state (Jeykumar)
Changes in v4:
- Rebased on msm-next
- Don't always use private state from atomic state (Archit)
- Renamed some of the state accessors
- Tested on mdp5 db410c
Changes in v5:
- None
Cc: Jeykumar Sankaran
Cc: Archit Taneja
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 77 ++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 11 +--
drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 12 ++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c | 28 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 19 +++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.h | 4 +-
drivers/gpu/drm/msm/msm_atomic.c | 37 -
drivers/gpu/drm/msm/msm_drv.c | 87 +-
drivers/gpu/drm/msm/msm_drv.h | 3 -
drivers/gpu/drm/msm/msm_kms.h | 21 --
10 files changed, 183 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..366670043190 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -70,60 +70,62 @@ static int mdp5_hw_init(struct msm_kms *kms)
return 0;
}
-struct mdp5_state *mdp5_get_state(struct drm_atomic_state *s)
+struct mdp5_state *mdp5_state_from_atomic(struct drm_atomic_state *state)
{
- struct msm_drm_private *priv = s->dev->dev_private;
- struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
- struct msm_kms_state *state = to_kms_state(s);
- struct mdp5_state *new_state;
- int ret;
+ struct msm_kms_state *kms_state = msm_kms_state_from_atomic(state);
- if (state->state)
- return state->state;
+ if (IS_ERR_OR_NULL(kms_state))
+ return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
- ret = drm_modeset_lock(&mdp5_kms->state_lock, s->acquire_ctx);
- if (ret)
- return ERR_PTR(ret);
+ return kms_state->state;
+}
- new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
- if (!new_state)
- return ERR_PTR(-ENOMEM);
+struct mdp5_state *mdp5_state_from_dev(struct drm_device *dev)
+{
+ struct msm_kms_state *kms_state = msm_kms_state_from_dev(dev);
- /* Copy state: */
- new_state->hwpipe = mdp5_kms->state->hwpipe;
- new_state->hwmixer = mdp5_kms->state->hwmixer;
- if (mdp5_kms->smp)
- new_state->smp = mdp5_kms->state->smp;
+ if (IS_ERR_OR_NULL(kms_state))
+ return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
- state->state = new_state;
+ return kms_state->state;
+}
+
+static void *mdp5_duplicate_state(void *state)
+{
+ if (!state)
+ return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
- return new_state;
+ return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
}
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state *state)
+static void mdp5_destroy_state(void *state)
{
- struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
- swap(to_kms_state(state)->state, mdp5_kms->state);
+ struct mdp5_state *mdp_state = (struct mdp5_state *)state;
+ kfree(mdp_state);
}
-static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state *state)
+static void mdp5_prepare_commit(struct msm_kms *kms,
+ struct drm_atomic_state *old_state)
{
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+ struct mdp5_state *mdp5_state = mdp5_state_from_dev(mdp5_kms->dev);
struct device *dev = &mdp5_kms->pdev->dev;
pm_runtime_get_sync(dev);
if (mdp5_kms->smp)
- mdp5_smp_prepare_commit(mdp5_kms->smp, &mdp5_kms->state->smp);
+ mdp5_smp_prepare_commit(mdp5_kms->smp, &mdp5_state->smp);
}
-static void mdp5_complete_commit(struct msm_kms *kms, struct drm_atomic_state *state)
+static void mdp5_complete_commit(struct msm_kms *kms,
+struct drm_atomic_state *old_state)
{
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+ struct mdp5_state *mdp5_state = mdp5_state_from_dev(mdp5_kms->dev);
struct device *dev = &mdp5_kms->pdev->dev;
if (mdp5_kms->smp)
- mdp5_smp_complete_commit(mdp5_kms->smp, &mdp5_kms->state->smp);
+ mdp5_smp_complete_commit(mdp5_kms->smp, &mdp5_state->smp);
pm_runtime_put_sync(dev);
}
@@ -229,7 +231,8 @@ static const struct mdp_kms
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #12 from MirceaKitsune --- Created attachment 138483 --> https://bugs.freedesktop.org/attachment.cgi?id=138483&action=edit Output of: watch cat /sys/kernel/debug/dri/0/amdgpu_pm_info I decided to turn my attention to the last logical thing I can imagine: DPM (Dynamic Power Management) and the clocks on my video card. The kernel added support for realtime tuning of the frequencies a while ago, so I was pondering if the default setup may have led to excess overclocking. I left a console to watch the file /sys/kernel/debug/dri/0/amdgpu_pm_info which I understand contains the video card frequencies. The maximum "power level" I seem to reach is 4, at sclk 101500 and mclk 14. I'm attaching the peak output of this file here. My video card is supposed to run at 1015 MHz (core clock) + 5600 MHz (memory clock). I don't fully understand how those numbers translate to frequencies, but from what I heard that represents the MHz * 100. If such is the case, my GPU clock is just right whereas my VRAM is actually under-clocked to a quarter of its default frequency! Can anyone confirm this so at least the hypothesis of bad clocks is out of the way? I may try testing with the kernel parameters "radeon.dpm=0 amdgpu.dpm=0" later: I tried doing so briefly but the performance is too horrible to play a game, so I'll instead leave a bot match running in spectator mode while I'm away. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
Am 01.04.2018 um 20:21 schrieb Takashi Iwai: On Sun, 01 Apr 2018 19:58:11 +0200, Christian K6nig wrote: Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: On Sun, Apr 1, 2018 at 1:39 PM, Christian König wrote: Am 30.03.2018 um 22:45 schrieb Takashi Iwai: amdgpu driver lacks of modeset module option other drm drivers provide for enforcing or disabling the driver load. Interestingly, the amdgpu_mode variable declaration is already found in the header file, but the actual implementation seems to have been forgotten. This patch adds the missing piece. NAK, modesetting is mandatory for amdgpu and we should probably remove the option to disable it from other DRM drivers without UMS support as well (pretty much all of them now). If you want to prevent a driver from loading I think the correct way to do so is to give modprobe.blacklist=amdgpu on the kernel commandline. That would remove the possibility to prevent the driver from loading when it is compiled in, but I don't see much of a problem with that. Having a way to kill the graphics driver is a very useful debugging tool, and also a quick and easy way to get out of an unpleasant situation where graphics are messed up / system hangs / etc. The modprobe blacklist kernel arg only works in certain environments (and only if it's a module). Every other DRM driver has this and this is a well-documented workaround for "graphics are messed up when I install linux", why not allow a uniform experience for the end users who are just trying to get their systems up and running? Because it is not well documented and repeated over and over again in drivers. The problem is that people don't realized that the driver isn't loaded at all without the modeset=0 module option and demand fixing the resulting bad performance without modesetting. Hm, I don't get it. What this options has to do with performance for a KMS-only driver...? Well exactly that's the point, nothing. The problem is that the option name is confusing to the end user because the expectation is that "nomodeset" just means that they only can't change the display mode. Some (unfortunately quite a lot) people don't realize that for KMS drivers this means that the driver isn't even loaded and they also don't get any acceleration. We had to explain that numerous times now. I think it would be best to give the option a more meaningful name. Christian. I can't count how often I had to explain that this approach won't work. We could rename it to something like disable_gfx_accel or something like that to make this clear. Maybe it's a different view from a different perspective. From the distro side, nomodeset and the force reload via modeset option has been the most reliable way to achieve the purpose, so far. It's easier especially when the system has a hybrid graphics. It might be not same for developers, though. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).
https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #4 from Roman Elshin --- patch from 94459 does not help, d3d9 apitrace (witcher.trace.7z - 170M): https://drive.google.com/file/d/11yogHC1q45emz3hOQOkJ70wW_xzhjOP8/view?usp=sharing -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #11 from MirceaKitsune --- I'm still struggling to debug this. The more I see the more my jaw drops. First of all, the rule that disabling anti-aliasing decreases the frequency of the freeze (see the comments above) was just patched out: AA no longer has any effect either, it always freezes between 0 and 30 minutes now. I ran the following new tests in Xonotic, none of which had any influence: - Running with the following environment variable set: R600_DEBUG=checkir,precompile,nooptvariant,nodpbb,nodfsm,nodma,nowc,nooutoforder,nohyperz,norbplus,no2d,notiling,nodcc,nodccclear,nodccfb,nodccmsaa - Disabling all shaders, even turning off OpenGL 2.0 support entirely. - Resetting the entire BIOS to its failsafe defaults, making sure that neither overclocking nor any other settings are involved. - Running under both an X11 and Wayland session (Plasma). In Wayland it crashes instantly so it's even worse. - Verified that this occurs on both the "radeon" and "amdgpu" modules, meaning the video driver makes no difference either. It's clear to me at this point that this is the work of a professional: The code causing the crash is carefully maintained and injected into my system. If this was just a bug, at least one of the countless things I tried would have affected it somehow, it's impossible for a randomly occurring bug to survive so many different settings and environments... the issue instead is adaptive, so that the moment I find and disable one implementation another is activated within minutes to keep the crashes going. I imagine the objective is to block the user from finding a solution and ultimately censor them from using specific programs. I find it unbelievable that someone out there is actively doing this. Please help me get to the bottom of this: The crash clearly acts by simulating some sort of bug, so there must be a vulnerability deep in the system which hidden code is exploiting. I offered a lot of test data on this report: If the developers read this, please let me know what to try next! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8
https://bugs.freedesktop.org/show_bug.cgi?id=105218 Matias N. Goldberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8
https://bugs.freedesktop.org/show_bug.cgi?id=105218 --- Comment #7 from Matias N. Goldberg --- I just tested with Mesa latest from git (2f175bfe5d8ca59a8a68b6d6d072cd7bf2f8baa9) and LLVM 7.0 revision 328838 (anything newer and Mesa won't compile due to a known issue) and the problem is gone. Either a later Mesa commit already fixed it, or my LLVM version was too old. This ticket can be closed as the problem can no longer be reproduced. Thanks and Cheers -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
On Sun, 01 Apr 2018 19:58:11 +0200, Christian K6nig wrote: > > Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: > > On Sun, Apr 1, 2018 at 1:39 PM, Christian König > > wrote: > >> Am 30.03.2018 um 22:45 schrieb Takashi Iwai: > >>> amdgpu driver lacks of modeset module option other drm drivers provide > >>> for enforcing or disabling the driver load. Interestingly, the > >>> amdgpu_mode variable declaration is already found in the header file, > >>> but the actual implementation seems to have been forgotten. > >>> > >>> This patch adds the missing piece. > >> > >> NAK, modesetting is mandatory for amdgpu and we should probably remove the > >> option to disable it from other DRM drivers without UMS support as well > >> (pretty much all of them now). > >> > >> If you want to prevent a driver from loading I think the correct way to do > >> so is to give modprobe.blacklist=amdgpu on the kernel commandline. > >> > >> That would remove the possibility to prevent the driver from loading when > >> it > >> is compiled in, but I don't see much of a problem with that. > > Having a way to kill the graphics driver is a very useful debugging > > tool, and also a quick and easy way to get out of an unpleasant > > situation where graphics are messed up / system hangs / etc. The > > modprobe blacklist kernel arg only works in certain environments (and > > only if it's a module). > > > > Every other DRM driver has this and this is a well-documented > > workaround for "graphics are messed up when I install linux", why not > > allow a uniform experience for the end users who are just trying to > > get their systems up and running? > > Because it is not well documented and repeated over and over again in > drivers. > > The problem is that people don't realized that the driver isn't loaded > at all without the modeset=0 module option and demand fixing the > resulting bad performance without modesetting. Hm, I don't get it. What this options has to do with performance for a KMS-only driver...? > I can't count how often I had to explain that this approach won't > work. We could rename it to something like disable_gfx_accel or > something like that to make this clear. Maybe it's a different view from a different perspective. From the distro side, nomodeset and the force reload via modeset option has been the most reliable way to achieve the purpose, so far. It's easier especially when the system has a hybrid graphics. It might be not same for developers, though. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #19 from mercuriete --- Created attachment 138480 --> https://bugs.freedesktop.org/attachment.cgi?id=138480&action=edit lspci balanced -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #18 from mercuriete --- Created attachment 138479 --> https://bugs.freedesktop.org/attachment.cgi?id=138479&action=edit lspci battery -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
Am 01.04.2018 um 19:45 schrieb Ilia Mirkin: On Sun, Apr 1, 2018 at 1:39 PM, Christian König wrote: Am 30.03.2018 um 22:45 schrieb Takashi Iwai: amdgpu driver lacks of modeset module option other drm drivers provide for enforcing or disabling the driver load. Interestingly, the amdgpu_mode variable declaration is already found in the header file, but the actual implementation seems to have been forgotten. This patch adds the missing piece. NAK, modesetting is mandatory for amdgpu and we should probably remove the option to disable it from other DRM drivers without UMS support as well (pretty much all of them now). If you want to prevent a driver from loading I think the correct way to do so is to give modprobe.blacklist=amdgpu on the kernel commandline. That would remove the possibility to prevent the driver from loading when it is compiled in, but I don't see much of a problem with that. Having a way to kill the graphics driver is a very useful debugging tool, and also a quick and easy way to get out of an unpleasant situation where graphics are messed up / system hangs / etc. The modprobe blacklist kernel arg only works in certain environments (and only if it's a module). Every other DRM driver has this and this is a well-documented workaround for "graphics are messed up when I install linux", why not allow a uniform experience for the end users who are just trying to get their systems up and running? Because it is not well documented and repeated over and over again in drivers. The problem is that people don't realized that the driver isn't loaded at all without the modeset=0 module option and demand fixing the resulting bad performance without modesetting. I can't count how often I had to explain that this approach won't work. We could rename it to something like disable_gfx_accel or something like that to make this clear. Christian. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #17 from mercuriete --- With the patch from comment 4 ported to amdgpu... https://patchwork.kernel.org/patch/8731311/ the warning is silenced but i have the same behaviour as Stefano Cipriani I will attach lspci of battery and balanced but i have the same output: partial output of lspci: LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Anyway, thank you very much Alex and Stefano. You make my day. PS: From my point of view the issue of dereference is fixed and this issue can be closed when pushed to git. PS2: Alex, this patch can be merged with linux LTS 4.14? Your patch was tested on: uname -a Linux localhost.localdomain 4.14.27-gentoo #2 SMP PREEMPT Sun Apr 1 19:43:12 CEST 2018 x86_64 Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz GenuineIntel GNU/Linux Thanks you very much guys!!! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
On Sun, Apr 1, 2018 at 1:39 PM, Christian König wrote: > Am 30.03.2018 um 22:45 schrieb Takashi Iwai: >> >> amdgpu driver lacks of modeset module option other drm drivers provide >> for enforcing or disabling the driver load. Interestingly, the >> amdgpu_mode variable declaration is already found in the header file, >> but the actual implementation seems to have been forgotten. >> >> This patch adds the missing piece. > > > NAK, modesetting is mandatory for amdgpu and we should probably remove the > option to disable it from other DRM drivers without UMS support as well > (pretty much all of them now). > > If you want to prevent a driver from loading I think the correct way to do > so is to give modprobe.blacklist=amdgpu on the kernel commandline. > > That would remove the possibility to prevent the driver from loading when it > is compiled in, but I don't see much of a problem with that. Having a way to kill the graphics driver is a very useful debugging tool, and also a quick and easy way to get out of an unpleasant situation where graphics are messed up / system hangs / etc. The modprobe blacklist kernel arg only works in certain environments (and only if it's a module). Every other DRM driver has this and this is a well-documented workaround for "graphics are messed up when I install linux", why not allow a uniform experience for the end users who are just trying to get their systems up and running? -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: Add modeset module option
Am 30.03.2018 um 22:45 schrieb Takashi Iwai:
amdgpu driver lacks of modeset module option other drm drivers provide
for enforcing or disabling the driver load. Interestingly, the
amdgpu_mode variable declaration is already found in the header file,
but the actual implementation seems to have been forgotten.
This patch adds the missing piece.
NAK, modesetting is mandatory for amdgpu and we should probably remove
the option to disable it from other DRM drivers without UMS support as
well (pretty much all of them now).
If you want to prevent a driver from loading I think the correct way to
do so is to give modprobe.blacklist=amdgpu on the kernel commandline.
That would remove the possibility to prevent the driver from loading
when it is compiled in, but I don't see much of a problem with that.
Christian.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index e55792d3cd12..029d95ecd26b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -78,6 +78,7 @@
#define KMS_DRIVER_MINOR 23
#define KMS_DRIVER_PATCHLEVEL 0
+int amdgpu_modeset = -1;
int amdgpu_vram_limit = 0;
int amdgpu_vis_vram_limit = 0;
int amdgpu_gart_size = -1; /* auto */
@@ -130,6 +131,9 @@ int amdgpu_lbpw = -1;
int amdgpu_compute_multipipe = -1;
int amdgpu_gpu_recovery = -1; /* auto */
+MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
+module_param_named(modeset, amdgpu_modeset, int, 0400);
+
MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in megabytes");
module_param_named(vramlimit, amdgpu_vram_limit, int, 0600);
@@ -905,10 +909,12 @@ static int __init amdgpu_init(void)
{
int r;
- if (vgacon_text_force()) {
+ if (vgacon_text_force() && amdgpu_modeset == -1) {
DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
return -EINVAL;
}
+ if (amdgpu_modeset == 0)
+ return -EINVAL;
r = amdgpu_sync_init();
if (r)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103736] Sudden system freezes, GPU fault detected
https://bugs.freedesktop.org/show_bug.cgi?id=103736 --- Comment #14 from aceman --- I'm using Mesa git, but LLVM 6.0 release. Is that fine wrt. this mismatch? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference
https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #16 from mercuriete --- (In reply to Alex Deucher from comment #13) > Created attachment 138450 [details] [review] > possible fix > > Thanks for looking into this. Good start! The attached patch should fix it. Hi Alex, I tested your patch from comment 13 It indeed fix the null dereference but you ported a bug from radeonsi partial output from dmesg [ 40.620248] [drm:si_dpm_set_power_state] *ERROR* invalid pcie lane request: 7 [ 45.921237] [drm:si_dpm_set_power_state] *ERROR* invalid pcie lane request: 15 Apart from that this patch is: Tested-by: Abel Garcia Dorta -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #6 from Allan --- TL;DR : I don't have any idea of what is happening. The errors aren't clear and I didn't find a discrete way of reproducing it and I'm in need of help. That's exactly the problem... I'm getting crazy about this problem. I've been trying to understand what is happening for weeks... So... I'll give you a brief(long) description : I've been running an RX 580. And then sometimes the system used to freeze like this and I was starting to think about the card being problematic. Then I got an RX 480, and I was planning to sell the RX580. I compiled a kernel with the polaris binaries and etc... It was going very well until a system upgrade. Then "here we go again" ... same problems... and now it seems like RX 480 fails twice as fast as the RX580 fails. If you are asking yourself "what kind of failures ?" I'll resume it : code 147, code 146, chrome_dthread libxul.so (for both firefox and chromium), a big call trace telling about amdgpu blocked for more than 120 seconds. Everything after the screen being frozen, ignoring the keyboard and mouse clicks, the only thing that really works is the mouse cursor moving. When it happens? After a few minutes running youtube or unigine valley or some random time (from minutes to several hours) using an opencl task for example. Then I started to think about the other components... - RAM ? Checked and running if the screen hangs, some ssh tests run fine. - CPU ? Never had a problem about it as far as I remember. Ssh tests run fine. - MOBO ? I really don't know. That's why : I had been having some sound cracklings, indicating that some power management could be tainted. I noticed that disabling IOMMU decreased the amount of crashes significantly... but unfortunately after updating the BIOS/EFI the option of enabling/disabling it simply was removed... I'll be contacting the manufacturer. So I can't affirm that it was the cause. I started to think that something nasty was going on with the power supply. - POWER SUPPLY ? I bet that it is not I have an 5 yeras old Aerocool 80 plus silver 800W power supply. It always had been a very good PSU... holding a HD7970GHz (290W TDP) most part of the time without a single problem. But okay... maybe the capacitors were faulty (as the mobo manufacturer said when I asked about the sound). Then I bought an AX860i. And if there is any better PSU than this for the 800W range... I'd like to know. 80 plus platinum certified... and even that the certification system does not get verified for years (almost like irrelevant to be honest). I already had an Corsair HX600 before and it was outstanding... an AX is better than a HX so... only a titanium that costs more than my mobo and cpu togheter would be better then. Guess what? The same problems. Actually, now, it shuts down sometimes. - KERNEL ? I was thinking that the problem was 4.15 because it has like 5x more chance of failling. But it also occurs with the very stable 4.13. Maybe I'll try other kernels... but as further we go behind with kernel versions, less features we have with amdgpu AFAIK. Also. With the RX480 it started to fail the video output when I configure the Display Port output to be 144Hz. My screen can handle 160Hz with adaptive sync, but it never worked with amdgpu. The DisplayPort/HDMI sound with DC/DAL support in 4.15 is a myth and NEVER works. If I configure amdgpu.dc=1 with RX580 it simply does not sound anything and with the RX480 it hangs the system when starting the pavucontrol. When forcing the output to the HDMI/DP it simply does not sound anything in both ways (but pavucontrol shows that something was supposed to be happening). While running a tty the chances of crashing is very low. But it happens when trying an opencl application after some random time as said before. When using RX580+1070 or RX480+1070 for vfio I noticed that unbinding the nvidia card extended the amount of working time before crashing. (was also one reason for me to think that the PSU was faulty) Now the "best" part : running a single GPU leads to the same problems... :/ I'm not sure about anything right now. I'll try only the 1070 for sometime to guarantee that amdgpu is the only problem here. I never touched the amdgpu code but it seems to me that either I sell the cards or I fix it by hand. Because I'm not finding anything related. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).
https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #3 from Roman Elshin --- I am not sure about compiling 32 bit mesa on 64 bit system, but will try. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199085] Multiple [drm] Got external EDID base block and 0 extensions messages
https://bugzilla.kernel.org/show_bug.cgi?id=199085 --- Comment #5 from Stuart Foster (smf.li...@ntlworld.com) --- If I remove drm_kms_helper.edid_firmware=edid/hp_lp2065.bin from the kernel boot line the messages go away and as far as I can seen no edid data is loaded by the kernel is this the correct behaviour ? thanks -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).
https://bugs.freedesktop.org/show_bug.cgi?id=99403 --- Comment #2 from i...@yahoo.com --- Could you try the patch from this bugreport : https://bugs.freedesktop.org/show_bug.cgi?id=94459 If the bug is still present, please make an d3d9 apitrace of the game that shows the bug. The smaller the file the better. Upload it on the Ixit Nine ftp or some filesharing service (like google drive). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=105729 --- Comment #3 from Jan Vlug --- I reported this issue also on the AMD support forum here: https://community.amd.com/message/2855328 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104825] [amdgpu] [drm:gfx_v8_0_hw_fini] *ERROR* KCQ disabled failed (scratch(0xC040)=0x00000000) when unbinding
https://bugs.freedesktop.org/show_bug.cgi?id=104825 --- Comment #17 from mlen --- No issues on drm-next-4.17-wip, unbinding works without any lockdep issues. Do you plan to backport these changes to 4.16 or maybe even 4.15? For the record, suspend fails on drm-next-4.17-wip. This could be possibly related, but I don't know how to debug this and most likely this is out of scope of this bug. [ 96.222095] PM: suspend entry (deep) [ 96.222099] PM: Syncing filesystems ... done. [ 96.230020] INFO: trying to register non-static key. [ 96.230024] the code is fine but needs lockdep annotation. [ 96.230026] turning off the locking correctness validator. [ 96.230029] CPU: 39 PID: 4506 Comm: pm-suspend Not tainted 4.16.0-rc7+ #2 [ 96.230031] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D16 WS/Z10PE-D16 WS, BIOS 3407 03/10/2017 [ 96.230033] Call Trace: [ 96.230040] dump_stack+0x46/0x59 [ 96.230046] register_lock_class+0x192/0x361 [ 96.230050] ? cycles_2_ns+0x55/0x75 [ 96.230054] __lock_acquire.isra.30+0x97/0x595 [ 96.230057] lock_acquire+0x105/0x12e [ 96.230060] ? devres_for_each_res+0x41/0xc4 [ 96.230064] ? __fw_entry_found+0x3b/0x3b [ 96.230068] _raw_spin_lock_irqsave+0x3d/0x74 [ 96.230071] ? devres_for_each_res+0x41/0xc4 [ 96.230073] ? kref_get+0xa/0xa [ 96.230075] ? alloc_fw_cache_entry+0x4e/0x4e [ 96.230077] devres_for_each_res+0x41/0xc4 [ 96.230096] dev_cache_fw_image+0x59/0x11d [ 96.230098] ? fw_pm_notify+0xd1/0xd1 [ 96.230102] dpm_for_each_dev+0x41/0x58 [ 96.230104] fw_pm_notify+0xac/0xd1 [ 96.230108] notifier_call_chain+0x39/0x5a [ 96.230127] __blocking_notifier_call_chain+0x4e/0x65 [ 96.230130] __pm_notifier_call_chain+0x1b/0x2f [ 96.230133] pm_suspend+0x15b/0x2c1 [ 96.230135] state_store+0x4b/0x7e [ 96.230140] kernfs_fop_write+0x114/0x15c [ 96.230145] __vfs_write+0x33/0xd7 [ 96.230148] ? __sb_start_write+0x94/0x180 [ 96.230150] ? __sb_start_write+0xc0/0x180 [ 96.230153] vfs_write+0xa5/0xe2 [ 96.230156] SyS_write+0x5f/0xa3 [ 96.230160] do_syscall_64+0x79/0x88 [ 96.230164] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 96.230166] RIP: 0033:0x7fac7a914468 [ 96.230168] RSP: 002b:7ffea25554e0 EFLAGS: 0246 ORIG_RAX: 0001 [ 96.230171] RAX: ffda RBX: 0004 RCX: 7fac7a914468 [ 96.230172] RDX: 0004 RSI: 558679eb4500 RDI: 0001 [ 96.230174] RBP: 558679eb4500 R08: 000a R09: 558679eeb6b0 [ 96.230175] R10: 7fac7a9a5b20 R11: 0246 R12: 0004 [ 96.230177] R13: 0001 R14: 7fac7abe1740 R15: 0004 [ 96.230183] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 96.230189] IP: devres_for_each_res+0x59/0xc4 [ 96.230191] PGD 0 P4D 0 [ 96.230196] Oops: [#1] PREEMPT SMP PTI [ 96.230199] Modules linked in: [ 96.230203] CPU: 39 PID: 4506 Comm: pm-suspend Not tainted 4.16.0-rc7+ #2 [ 96.230205] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D16 WS/Z10PE-D16 WS, BIOS 3407 03/10/2017 [ 96.230208] RIP: 0010:devres_for_each_res+0x59/0xc4 [ 96.230210] RSP: 0018:a63689fabc70 EFLAGS: 00010086 [ 96.230214] RAX: RBX: 9fd574d4ad98 RCX: 9fd574d4b1f0 [ 96.230216] RDX: 9fd576ea0918 RSI: 9fd574d4b1c0 RDI: 9fd576ea0918 [ 96.230218] RBP: a8951b3a R08: R09: [ 96.230221] R10: 9fd576ea R11: ab22aa07 R12: a8951f44 [ 96.230223] R13: dead0100 R14: a8951c08 R15: 9fd574d4b1a8 [ 96.230226] FS: 7fac7b021740() GS:9fe57f40() knlGS: [ 96.230229] CS: 0010 DS: ES: CR0: 80050033 [ 96.230231] CR2: 0008 CR3: 00202a4a8002 CR4: 003606e0 [ 96.230233] DR0: DR1: DR2: [ 96.230236] DR3: DR6: fffe0ff0 DR7: 0400 [ 96.230238] Call Trace: [ 96.230243] dev_cache_fw_image+0x59/0x11d [ 96.230247] ? fw_pm_notify+0xd1/0xd1 [ 96.230250] dpm_for_each_dev+0x41/0x58 [ 96.230253] fw_pm_notify+0xac/0xd1 [ 96.230256] notifier_call_chain+0x39/0x5a [ 96.230261] __blocking_notifier_call_chain+0x4e/0x65 [ 96.230264] __pm_notifier_call_chain+0x1b/0x2f [ 96.230267] pm_suspend+0x15b/0x2c1 [ 96.230271] state_store+0x4b/0x7e [ 96.230275] kernfs_fop_write+0x114/0x15c [ 96.230279] __vfs_write+0x33/0xd7 [ 96.230284] ? __sb_start_write+0x94/0x180 [ 96.230286] ? __sb_start_write+0xc0/0x180 [ 96.230290] vfs_write+0xa5/0xe2 [ 96.230295] SyS_write+0x5f/0xa3 [ 96.230299] do_syscall_64+0x79/0x88 [ 96.230303] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 96.230305] RIP: 0033:0x7fac7a914468 [ 96.230308] RSP: 002b:7ffea25554e0 EFLAGS: 0246 ORIG_RAX: 0001 [ 96.230311] RAX: ffda RBX: 0004 RCX: 7fac7a91
[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=105729 Jan Vlug changed: What|Removed |Added Summary|AMD Radeon flickering on|AMD Radeon flickering on |Gnome Wayland after wake|HiDPI display with Gnome |from suspend|Wayland after wake from ||suspend -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103736] Sudden system freezes, GPU fault detected
https://bugs.freedesktop.org/show_bug.cgi?id=103736 --- Comment #13 from Ernst Sjöstrand --- aceman: the problem was mismatching development snapshots, couldn't happen if you have any real releases in the mix. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
