nouveau_debugfs(drm) will never be NULL, because we're taking the value
of the potentially null device pointer and adding to it so it isn't 0x0.
So, check if drm is NULL instead.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
Forgot to hit :w before committing, whoops!
nouveau_debugfs(drm) will never be NULL, because we're taking the value
of the potentially null device pointer and adding to it so it isn't 0x0.
So, check if drm is NULL instead.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 5 +++--
1 file changed,
On the Lenovo P50 I've been working on, ACPI notifications for hotplugs
always seem happen even while the GPU has it's hotplugs enabled. This
means that we're uselessly scheduling two connector probes every time we
get a hotplug.
Since we can't unregister the acpi handler without causing
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index ec7861457b84..b2a93e3fa67b 100644
---
We can't and don't need to try resuming the device from our hotplug
handlers, but hotplug events are generally something we'd like to keep
the device awake for whenever possible. So, grab a PM ref safely in our
hotplug handlers using pm_runtime_get_noresume() and mark the device as
busy once we're
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector
I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
There isn't actually any reason we need to call drm_hpd_irq_event() from
our hotplug handler, as we already know which connector the hotplug
event was fired for. We're also going to need to avoid probing all
connectors needlessly from hotplug handlers anyway so that we can track
when
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
This is the next version of
https://patchwork.freedesktop.org/series/46815/
With a lot more thought put into it so as to avoid the potential
deadlock scenarios I missed. This also required fixing some bogus DRM
helper usage.
Try and deadlock me now, nouveau. I dare you!!!
Lyude Paul (8):
This removes the potential of deadlocking with fb_helper entirely by
preventing it from handling hotplugs during the runtime suspend process
as early as possible in the suspend process. If it turns out this is not
possible, due to some fb_helper action having been queued up before we
got a time to
Having runtime PM makes no difference on whether or not we want polling,
and it's now safe to just enable polling unconditionally in drm_load()
thanks to d61a5c106351 ("drm/nouveau: Fix deadlock on runtime suspend")
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Peter Ujfalusi
Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=107431
John <17150...@opayq.com> changed:
What|Removed |Added
Priority|medium |highest
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=107431
Bug ID: 107431
Summary: Crash system
Product: Mesa
Version: 18.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: critical
https://bugs.freedesktop.org/show_bug.cgi?id=100567
--- Comment #15 from Zéfling ---
I also have this problem with a 770 GTX since I switched to KDE 5 about 5
months ago. Freeze without reason learns exept the mouse cursor.
Kubuntu 17.10, Kubuntu 18.4, Debian 9 KDE and KDE Neon, same problem.
On Friday, 27 July 2018 20:16:53 MSK Dmitry Osipenko wrote:
> On Friday, 27 July 2018 20:03:26 MSK Jordan Crouse wrote:
> > On Fri, Jul 27, 2018 at 05:02:37PM +0100, Robin Murphy wrote:
> > > On 27/07/18 15:10, Dmitry Osipenko wrote:
> > > >On Friday, 27 July 2018 12:03:28 MSK Will Deacon wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=100177
Rhys Perry changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
18 matches
Mail list logo
