[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

Fix a deadlock on hybrid graphics laptops that's been present since 2013:

DRM drivers poll connectors in 10 sec intervals.  The poll worker is
stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
the poll worker invokes the DRM drivers' ->detect callbacks, which call
pm_runtime_get_sync().  If the poll worker starts after runtime suspend
has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
with the intention of runtime resuming the device afterwards.  The result
is a circular wait between poll worker and autosuspend worker.

I'm seeing this deadlock so often it's not funny anymore. I've also found
3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
[4/5].)

One theoretical solution would be to add a flag to the ->detect callback
to tell it that it's running in the poll worker's context.  In that case
it doesn't need to call pm_runtime_get_sync() because the poll worker is
only enabled while runtime active and we know that ->runtime_suspend
waits for it to finish.  But this approach would require touching every
single DRM driver's ->detect hook.  Moreover the ->detect hook is called
from numerous other places, both in the DRM library as well as in each
driver, making it necessary to trace every possible call chain and check
if it's coming from the poll worker or not.  I've tried to do that for
nouveau (see the call sites listed in the commit message of patch [3/5])
and concluded that this approach is a nightmare to implement.

Another reason for the infeasibility of this approach is that ->detect
is called from within the DRM library without driver involvement, e.g.
via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
have to be called by the DRM library, but the DRM library is supposed to
stay generic, wheras runtime PM is driver-specific.

So instead, I've come up with this much simpler solution which gleans
from the current task's flags if it's a workqueue worker, retrieves the
work_struct and checks if it's the poll worker.  All that's needed is
one small helper in the workqueue code and another small helper in the
DRM library.  This solution lends itself nicely to stable-backporting.

The patches for radeon and amdgpu are compile-tested only, I only have a
MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
"msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
This ensures that the poll worker runs after ->runtime_suspend has begun.
Wait 12 sec after the GPU has begun runtime suspend, then check
/sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
series, the status will be stuck at "suspending" and you'll get hung task
errors in dmesg after a few minutes.

i915, malidp and msm "solved" this issue by not stopping the poll worker
on runtime suspend.  But this results in the GPU bouncing back and forth
between D0 and D3 continuously.  That's a total no-go for GPUs which
runtime suspend to D3cold since every suspend/resume cycle costs a
significant amount of time and energy.  (i915 and malidp do not seem
to acquire a runtime PM ref in the ->detect callbacks, which seems
questionable.  msm however does and would also deadlock if it disabled
the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

Please review.  Thanks,

Lukas

Lukas Wunner (5):
  workqueue: Allow retrieval of current task's work struct
  drm: Allow determining if current task is output poll worker
  drm/nouveau: Fix deadlock on runtime suspend
  drm/radeon: Fix deadlock on runtime suspend
  drm/amdgpu: Fix deadlock on runtime suspend

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
 drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
 drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
 drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
 include/drm/drm_crtc_helper.h                  |  1 +
 include/linux/workqueue.h                      |  1 +
 kernel/workqueue.c                             | 16 ++++++
 7 files changed, 132 insertions(+), 50 deletions(-)

-- 
2.15.1

[PATCH 1/5] workqueue: Allow retrieval of current task's work struct

[Lukas Wunner]

Introduce a helper to retrieve the current task's work struct if it is
a workqueue worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for a specific worker to
finish and that worker in turn calls a function which waits for runtime
suspend to finish.  That function is invoked from multiple call sites
and waiting for runtime suspend to finish is the correct thing to do
except if it's executing in the context of the worker.

Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 include/linux/workqueue.h |  1 +
 kernel/workqueue.c        | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 4a54ef96aff5..bc0cda180c8b 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -465,6 +465,7 @@ extern bool cancel_delayed_work_sync(struct delayed_work *dwork);
 
 extern void workqueue_set_max_active(struct workqueue_struct *wq,
 				     int max_active);
+extern struct work_struct *current_work(void);
 extern bool current_is_workqueue_rescuer(void);
 extern bool workqueue_congested(int cpu, struct workqueue_struct *wq);
 extern unsigned int work_busy(struct work_struct *work);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 017044c26233..bb9a519cbf50 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4179,6 +4179,22 @@ void workqueue_set_max_active(struct workqueue_struct *wq, int max_active)
 }
 EXPORT_SYMBOL_GPL(workqueue_set_max_active);
 
+/**
+ * current_work - retrieve %current task's work struct
+ *
+ * Determine if %current task is a workqueue worker and what it's working on.
+ * Useful to find out the context that the %current task is running in.
+ *
+ * Return: work struct if %current task is a workqueue worker, %NULL otherwise.
+ */
+struct work_struct *current_work(void)
+{
+	struct worker *worker = current_wq_worker();
+
+	return worker ? worker->current_work : NULL;
+}
+EXPORT_SYMBOL(current_work);
+
 /**
  * current_is_workqueue_rescuer - is %current workqueue rescuer?
  *
-- 
2.15.1

[PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish.  The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/gpu/drm/drm_probe_helper.c | 14 ++++++++++++++
 include/drm/drm_crtc_helper.h      |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe54d6e2..019881d15ce1 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct *work)
 		schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
+/**
+ * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
+ *
+ * Determine if %current task is an output poll worker.  This can be used
+ * to select distinct code paths for output polling versus other contexts.
+ */
+bool drm_kms_helper_is_poll_worker(void)
+{
+	struct work_struct *work = current_work();
+
+	return work && work->func == output_poll_execute;
+}
+EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
+
 /**
  * drm_kms_helper_poll_disable - disable output polling
  * @dev: drm_device
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 76e237bd989b..6914633037a5 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
+bool drm_kms_helper_is_poll_worker(void);
 
 #endif
-- 
2.15.1

[PATCH 3/5] drm/nouveau: Fix deadlock on runtime suspend

[Lukas Wunner]

nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.

The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.

Fix by not acquiring a runtime PM ref if nouveau_connector_detect() is
called in the output poll worker's context.  This is safe because
the poll worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.

Other contexts calling nouveau_connector_detect() do require a runtime
PM ref, these comprise:

  status_store() drm sysfs interface
  ->fill_modes drm callback
  drm_fb_helper_probe_connector_modes()
  drm_mode_getconnector()
  nouveau_connector_hotplug()
  nouveau_display_hpd_work()
  nv17_tv_set_property()

Stack trace for posterity:

  INFO: task kworker/0:1:58 blocked for more than 120 seconds.
  Workqueue: events output_poll_execute [drm_kms_helper]
  Call Trace:
   schedule+0x28/0x80
   rpm_resume+0x107/0x6e0
   __pm_runtime_resume+0x47/0x70
   nouveau_connector_detect+0x7e/0x4a0 [nouveau]
   nouveau_connector_detect_lvds+0x132/0x180 [nouveau]
   drm_helper_probe_detect_ctx+0x85/0xd0 [drm_kms_helper]
   output_poll_execute+0x11e/0x1c0 [drm_kms_helper]
   process_one_work+0x184/0x380
   worker_thread+0x2e/0x390

  INFO: task kworker/0:2:252 blocked for more than 120 seconds.
  Workqueue: pm pm_runtime_work
  Call Trace:
   schedule+0x28/0x80
   schedule_timeout+0x1e3/0x370
   wait_for_completion+0x123/0x190
   flush_work+0x142/0x1c0
   nouveau_pmops_runtime_suspend+0x7e/0xd0 [nouveau]
   pci_pm_runtime_suspend+0x5c/0x180
   vga_switcheroo_runtime_suspend+0x1e/0xa0
   __rpm_callback+0xc1/0x200
   rpm_callback+0x1f/0x70
   rpm_suspend+0x13c/0x640
   pm_runtime_work+0x6e/0x90
   process_one_work+0x184/0x380
   worker_thread+0x2e/0x390

Bugzilla: https://bugs.archlinux.org/task/53497
Bugzilla: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870523
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388#c33
Fixes: 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)")
Cc: stable@vger.kernel.org # v3.12+: 1234567890ab: workqueue: Allow retrieval of current task's work struct
Cc: stable@vger.kernel.org # v3.12+: 1234567890ab: drm: Allow determining if current task is output poll worker
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 69d6e61a01ec..6ed9cb053dfa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -570,9 +570,15 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
 		nv_connector->edid = NULL;
 	}
 
-	ret = pm_runtime_get_sync(connector->dev->dev);
-	if (ret < 0 && ret != -EACCES)
-		return conn_status;
+	/* Outputs are only polled while runtime active, so acquiring a
+	 * runtime PM ref here is unnecessary (and would deadlock upon
+	 * runtime suspend because it waits for polling to finish).
+	 */
+	if (!drm_kms_helper_is_poll_worker()) {
+		ret = pm_runtime_get_sync(connector->dev->dev);
+		if (ret < 0 && ret != -EACCES)
+			return conn_status;
+	}
 
 	nv_encoder = nouveau_connector_ddc_detect(connector);
 	if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
@@ -647,8 +653,10 @@ nouveau_connector_detect(struct drm_connector *connector, bool force)
 
  out:
 
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return conn_status;
 }
-- 
2.15.1

[PATCH 4/5] drm/radeon: Fix deadlock on runtime suspend

[Lukas Wunner]

radeon's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.

The output poll worker meanwhile calls pm_runtime_get_sync() in
radeon's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.

Fix by not acquiring a runtime PM ref if the ->detect hooks are called
in the output poll worker's context.  This is safe because the poll
worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.

Stack trace for posterity:

  INFO: task kworker/0:3:31847 blocked for more than 120 seconds
  Workqueue: events output_poll_execute [drm_kms_helper]
  Call Trace:
   schedule+0x3c/0x90
   rpm_resume+0x1e2/0x690
   __pm_runtime_resume+0x3f/0x60
   radeon_lvds_detect+0x39/0xf0 [radeon]
   output_poll_execute+0xda/0x1e0 [drm_kms_helper]
   process_one_work+0x14b/0x440
   worker_thread+0x48/0x4a0

  INFO: task kworker/2:0:10493 blocked for more than 120 seconds.
  Workqueue: pm pm_runtime_work
  Call Trace:
   schedule+0x3c/0x90
   schedule_timeout+0x1b3/0x240
   wait_for_common+0xc2/0x180
   wait_for_completion+0x1d/0x20
   flush_work+0xfc/0x1a0
   __cancel_work_timer+0xa5/0x1d0
   cancel_delayed_work_sync+0x13/0x20
   drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper]
   radeon_pmops_runtime_suspend+0x3d/0xa0 [radeon]
   pci_pm_runtime_suspend+0x61/0x1a0
   vga_switcheroo_runtime_suspend+0x21/0x70
   __rpm_callback+0x32/0x70
   rpm_callback+0x24/0x80
   rpm_suspend+0x12b/0x640
   pm_runtime_work+0x6f/0xb0
   process_one_work+0x14b/0x440
   worker_thread+0x48/0x4a0

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94147
Fixes: 10ebc0bc0934 ("drm/radeon: add runtime PM support (v2)")
Cc: stable@vger.kernel.org # v3.13+: 1234567890ab: workqueue: Allow retrieval of current task's work struct
Cc: stable@vger.kernel.org # v3.13+: 1234567890ab: drm: Allow determining if current task is output poll worker
Cc: Ismo Toijala <ismo.toijala@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 74 ++++++++++++++++++++----------
 1 file changed, 49 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5012f5e47a1e..2e2ca3c6b47d 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -899,9 +899,11 @@ radeon_lvds_detect(struct drm_connector *connector, bool force)
 	enum drm_connector_status ret = connector_status_disconnected;
 	int r;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	if (encoder) {
 		struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
@@ -924,8 +926,12 @@ radeon_lvds_detect(struct drm_connector *connector, bool force)
 	/* check acpi lid status ??? */
 
 	radeon_connector_update_scratch_regs(connector, ret);
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
+
 	return ret;
 }
 
@@ -1039,9 +1045,11 @@ radeon_vga_detect(struct drm_connector *connector, bool force)
 	enum drm_connector_status ret = connector_status_disconnected;
 	int r;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	encoder = radeon_best_single_encoder(connector);
 	if (!encoder)
@@ -1108,8 +1116,10 @@ radeon_vga_detect(struct drm_connector *connector, bool force)
 	radeon_connector_update_scratch_regs(connector, ret);
 
 out:
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return ret;
 }
@@ -1173,9 +1183,11 @@ radeon_tv_detect(struct drm_connector *connector, bool force)
 	if (!radeon_connector->dac_load_detect)
 		return ret;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	encoder = radeon_best_single_encoder(connector);
 	if (!encoder)
@@ -1187,8 +1199,12 @@ radeon_tv_detect(struct drm_connector *connector, bool force)
 	if (ret == connector_status_connected)
 		ret = radeon_connector_analog_encoder_conflict_solve(connector, encoder, ret, false);
 	radeon_connector_update_scratch_regs(connector, ret);
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
+
 	return ret;
 }
 
@@ -1251,9 +1267,11 @@ radeon_dvi_detect(struct drm_connector *connector, bool force)
 	enum drm_connector_status ret = connector_status_disconnected;
 	bool dret = false, broken_edid = false;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	if (radeon_connector->detected_hpd_without_ddc) {
 		force = true;
@@ -1436,8 +1454,10 @@ radeon_dvi_detect(struct drm_connector *connector, bool force)
 	}
 
 exit:
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return ret;
 }
@@ -1688,9 +1708,11 @@ radeon_dp_detect(struct drm_connector *connector, bool force)
 	if (radeon_dig_connector->is_mst)
 		return connector_status_disconnected;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	if (!force && radeon_check_hpd_status_unchanged(connector)) {
 		ret = connector->status;
@@ -1777,8 +1799,10 @@ radeon_dp_detect(struct drm_connector *connector, bool force)
 	}
 
 out:
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return ret;
 }
-- 
2.15.1

[PATCH 5/5] drm/amdgpu: Fix deadlock on runtime suspend

[Lukas Wunner]

amdgpu's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.

The output poll worker meanwhile calls pm_runtime_get_sync() in
amdgpu's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.

Fix by not acquiring a runtime PM ref if the ->detect hooks are called
in the output poll worker's context.  This is safe because the poll
worker is only enabled while runtime active and we know that
->runtime_suspend waits for it to finish.

Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Cc: stable@vger.kernel.org # v4.2+: 1234567890ab: workqueue: Allow retrieval of current task's work struct
Cc: stable@vger.kernel.org # v4.2+: 1234567890ab: drm: Allow determining if current task is output poll worker
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++++++---------
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8ca3783f2deb..74d2efaec52f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -736,9 +736,11 @@ amdgpu_connector_lvds_detect(struct drm_connector *connector, bool force)
 	enum drm_connector_status ret = connector_status_disconnected;
 	int r;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	if (encoder) {
 		struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
@@ -757,8 +759,12 @@ amdgpu_connector_lvds_detect(struct drm_connector *connector, bool force)
 	/* check acpi lid status ??? */
 
 	amdgpu_connector_update_scratch_regs(connector, ret);
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
+
 	return ret;
 }
 
@@ -868,9 +874,11 @@ amdgpu_connector_vga_detect(struct drm_connector *connector, bool force)
 	enum drm_connector_status ret = connector_status_disconnected;
 	int r;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	encoder = amdgpu_connector_best_single_encoder(connector);
 	if (!encoder)
@@ -924,8 +932,10 @@ amdgpu_connector_vga_detect(struct drm_connector *connector, bool force)
 	amdgpu_connector_update_scratch_regs(connector, ret);
 
 out:
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return ret;
 }
@@ -988,9 +998,11 @@ amdgpu_connector_dvi_detect(struct drm_connector *connector, bool force)
 	enum drm_connector_status ret = connector_status_disconnected;
 	bool dret = false, broken_edid = false;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	if (!force && amdgpu_connector_check_hpd_status_unchanged(connector)) {
 		ret = connector->status;
@@ -1115,8 +1127,10 @@ amdgpu_connector_dvi_detect(struct drm_connector *connector, bool force)
 	amdgpu_connector_update_scratch_regs(connector, ret);
 
 exit:
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return ret;
 }
@@ -1359,9 +1373,11 @@ amdgpu_connector_dp_detect(struct drm_connector *connector, bool force)
 	struct drm_encoder *encoder = amdgpu_connector_best_single_encoder(connector);
 	int r;
 
-	r = pm_runtime_get_sync(connector->dev->dev);
-	if (r < 0)
-		return connector_status_disconnected;
+	if (!drm_kms_helper_is_poll_worker()) {
+		r = pm_runtime_get_sync(connector->dev->dev);
+		if (r < 0)
+			return connector_status_disconnected;
+	}
 
 	if (!force && amdgpu_connector_check_hpd_status_unchanged(connector)) {
 		ret = connector->status;
@@ -1429,8 +1445,10 @@ amdgpu_connector_dp_detect(struct drm_connector *connector, bool force)
 
 	amdgpu_connector_update_scratch_regs(connector, ret);
 out:
-	pm_runtime_mark_last_busy(connector->dev->dev);
-	pm_runtime_put_autosuspend(connector->dev->dev);
+	if (!drm_kms_helper_is_poll_worker()) {
+		pm_runtime_mark_last_busy(connector->dev->dev);
+		pm_runtime_put_autosuspend(connector->dev->dev);
+	}
 
 	return ret;
 }
-- 
2.15.1

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

On 11 February 2018 at 09:38, Lukas Wunner <lukas@wunner.de> wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
>
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
>
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
>
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
>
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
>
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
>
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
>
> Please review.  Thanks,
>
> Lukas
>
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
>
> --
> 2.15.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


I wasn't quite sure where to add that msleep. I've tested the patches
as is on top of agd5f's wip branch without ill effects

I've had a radeon and now a amdgpu PRIME setup and don't believe I've
ever seen this issue

If you could pop a patch together for the msleep I'll give it a test on amdgpu

Cheers

Mike

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

On 11 February 2018 at 09:38, Lukas Wunner <lukas@wunner.de> wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
>
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
>
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
>
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
>
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
>
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
>
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
>
> Please review.  Thanks,
>
> Lukas
>
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
>
> --
> 2.15.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


I wasn't quite sure where to add that msleep. I've tested the patches
as is on top of agd5f's wip branch without ill effects

I've had a radeon and now a amdgpu PRIME setup and don't believe I've
ever seen this issue

If you could pop a patch together for the msleep I'll give it a test on amdgpu

Cheers

Mike
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 06:58:11PM +0000, Mike Lothian wrote:
> On 11 February 2018 at 09:38, Lukas Wunner <lukas@wunner.de> wrote:
> > The patches for radeon and amdgpu are compile-tested only, I only have a
> > MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> > "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> > This ensures that the poll worker runs after ->runtime_suspend has begun.
> > Wait 12 sec after the GPU has begun runtime suspend, then check
> > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> > series, the status will be stuck at "suspending" and you'll get hung task
> > errors in dmesg after a few minutes.
> 
> I wasn't quite sure where to add that msleep. I've tested the patches
> as is on top of agd5f's wip branch without ill effects
> 
> I've had a radeon and now a amdgpu PRIME setup and don't believe I've
> ever seen this issue
> 
> If you could pop a patch together for the msleep I'll give it a test on
> amdgpu

Here you go, this is for all 3 drivers.
Should deadlock without the series.
Thanks!


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 50afcf6..eefa0d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -718,6 +718,9 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev)
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe5..ee7cf0d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -586,6 +586,7 @@ static void output_poll_execute(struct work_struct *work)
 		repoll = true;
 		goto out;
 	}
+	dev_info(&dev->pdev->dev, "begin poll\n");
 
 	drm_connector_list_iter_begin(dev, &conn_iter);
 	drm_for_each_connector_iter(connector, &conn_iter) {
@@ -651,6 +652,7 @@ static void output_poll_execute(struct work_struct *work)
 
 	if (repoll)
 		schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
+	dev_info(&dev->pdev->dev, "end poll\n");
 }
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3e29302..f9da5bc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -855,6 +855,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
 	nouveau_switcheroo_optimus_dsm();
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index 31dd04f..707b8aa 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -413,6 +413,9 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 08:23:14PM +0100, Lukas Wunner wrote:
> On Sun, Feb 11, 2018 at 06:58:11PM +0000, Mike Lothian wrote:
> > On 11 February 2018 at 09:38, Lukas Wunner <lukas@wunner.de> wrote:
> > > The patches for radeon and amdgpu are compile-tested only, I only have a
> > > MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> > > "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> > > This ensures that the poll worker runs after ->runtime_suspend has begun.
> > > Wait 12 sec after the GPU has begun runtime suspend, then check
> > > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> > > series, the status will be stuck at "suspending" and you'll get hung task
> > > errors in dmesg after a few minutes.
> > 
> > I wasn't quite sure where to add that msleep. I've tested the patches
> > as is on top of agd5f's wip branch without ill effects
> > 
> > I've had a radeon and now a amdgpu PRIME setup and don't believe I've
> > ever seen this issue
> > 
> > If you could pop a patch together for the msleep I'll give it a test on
> > amdgpu
> 
> Here you go, this is for all 3 drivers.
> Should deadlock without the series.
> Thanks!

Sorry, I missed that amdgpu_drv.c and radeon_drv.c don't include delay.h,
rectified testing patch below:


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 50afcf6..beaaf2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -36,6 +36,7 @@
 
 #include <drm/drm_pciids.h>
 #include <linux/console.h>
+#include <linux/delay.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/vga_switcheroo.h>
@@ -718,6 +719,9 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev)
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe5..ee7cf0d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -586,6 +586,7 @@ static void output_poll_execute(struct work_struct *work)
 		repoll = true;
 		goto out;
 	}
+	dev_info(&dev->pdev->dev, "begin poll\n");
 
 	drm_connector_list_iter_begin(dev, &conn_iter);
 	drm_for_each_connector_iter(connector, &conn_iter) {
@@ -651,6 +652,7 @@ static void output_poll_execute(struct work_struct *work)
 
 	if (repoll)
 		schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
+	dev_info(&dev->pdev->dev, "end poll\n");
 }
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3e29302..f9da5bc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -855,6 +855,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
 	nouveau_switcheroo_optimus_dsm();
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index 31dd04f..2b4e7e0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -35,6 +35,7 @@
 
 #include <drm/drm_pciids.h>
 #include <linux/console.h>
+#include <linux/delay.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/vga_switcheroo.h>
@@ -413,6 +414,9 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 08:23:14PM +0100, Lukas Wunner wrote:
> On Sun, Feb 11, 2018 at 06:58:11PM +0000, Mike Lothian wrote:
> > On 11 February 2018 at 09:38, Lukas Wunner <lukas@wunner.de> wrote:
> > > The patches for radeon and amdgpu are compile-tested only, I only have a
> > > MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> > > "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> > > This ensures that the poll worker runs after ->runtime_suspend has begun.
> > > Wait 12 sec after the GPU has begun runtime suspend, then check
> > > /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> > > series, the status will be stuck at "suspending" and you'll get hung task
> > > errors in dmesg after a few minutes.
> > 
> > I wasn't quite sure where to add that msleep. I've tested the patches
> > as is on top of agd5f's wip branch without ill effects
> > 
> > I've had a radeon and now a amdgpu PRIME setup and don't believe I've
> > ever seen this issue
> > 
> > If you could pop a patch together for the msleep I'll give it a test on
> > amdgpu
> 
> Here you go, this is for all 3 drivers.
> Should deadlock without the series.
> Thanks!

Sorry, I missed that amdgpu_drv.c and radeon_drv.c don't include delay.h,
rectified testing patch below:


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 50afcf6..beaaf2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -36,6 +36,7 @@
 
 #include <drm/drm_pciids.h>
 #include <linux/console.h>
+#include <linux/delay.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/vga_switcheroo.h>
@@ -718,6 +719,9 @@ static int amdgpu_pmops_runtime_suspend(struct device *dev)
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe5..ee7cf0d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -586,6 +586,7 @@ static void output_poll_execute(struct work_struct *work)
 		repoll = true;
 		goto out;
 	}
+	dev_info(&dev->pdev->dev, "begin poll\n");
 
 	drm_connector_list_iter_begin(dev, &conn_iter);
 	drm_for_each_connector_iter(connector, &conn_iter) {
@@ -651,6 +652,7 @@ static void output_poll_execute(struct work_struct *work)
 
 	if (repoll)
 		schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
+	dev_info(&dev->pdev->dev, "end poll\n");
 }
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3e29302..f9da5bc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -855,6 +855,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
 	nouveau_switcheroo_optimus_dsm();
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index 31dd04f..2b4e7e0 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -35,6 +35,7 @@
 
 #include <drm/drm_pciids.h>
 #include <linux/console.h>
+#include <linux/delay.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/vga_switcheroo.h>
@@ -413,6 +414,9 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
 		return -EBUSY;
 	}
 
+	printk("waiting 12 sec\n");
+	msleep(12*1000);
+	printk("done waiting 12 sec\n");
 	drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 	drm_kms_helper_poll_disable(drm_dev);
 	vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF);
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

Hi

I've not been able to reproduce the original problem you're trying to
solve on amdgpu thats with or without your patch set and the above
"trigger" too

Is anything else required to trigger it, I started multiple DRI_PRIME
glxgears, in parallel, serial waiting the 12 seconds and serial within
the 12 seconds and I couldn't reproduce it

Regards

Mike

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

Hi

I've not been able to reproduce the original problem you're trying to
solve on amdgpu thats with or without your patch set and the above
"trigger" too

Is anything else required to trigger it, I started multiple DRI_PRIME
glxgears, in parallel, serial waiting the 12 seconds and serial within
the 12 seconds and I couldn't reproduce it

Regards

Mike
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
> I've not been able to reproduce the original problem you're trying to
> solve on amdgpu thats with or without your patch set and the above
> "trigger" too
> 
> Is anything else required to trigger it, I started multiple DRI_PRIME
> glxgears, in parallel, serial waiting the 12 seconds and serial within
> the 12 seconds and I couldn't reproduce it

The discrete GPU needs to runtime suspend, that's the trigger,
so no DRI_PRIME executables should be running.  Just let it
autosuspend after boot.  Do you see "waiting 12 sec" messages
in dmesg?  If not it's not autosuspending.

Thanks,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
> I've not been able to reproduce the original problem you're trying to
> solve on amdgpu thats with or without your patch set and the above
> "trigger" too
> 
> Is anything else required to trigger it, I started multiple DRI_PRIME
> glxgears, in parallel, serial waiting the 12 seconds and serial within
> the 12 seconds and I couldn't reproduce it

The discrete GPU needs to runtime suspend, that's the trigger,
so no DRI_PRIME executables should be running.  Just let it
autosuspend after boot.  Do you see "waiting 12 sec" messages
in dmesg?  If not it's not autosuspending.

Thanks,

Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
>> I've not been able to reproduce the original problem you're trying to
>> solve on amdgpu thats with or without your patch set and the above
>> "trigger" too
>>
>> Is anything else required to trigger it, I started multiple DRI_PRIME
>> glxgears, in parallel, serial waiting the 12 seconds and serial within
>> the 12 seconds and I couldn't reproduce it
>
> The discrete GPU needs to runtime suspend, that's the trigger,
> so no DRI_PRIME executables should be running.  Just let it
> autosuspend after boot.  Do you see "waiting 12 sec" messages
> in dmesg?  If not it's not autosuspending.
>
> Thanks,
>
> Lukas

Hi

Yes I'm seeing those messages, I'm just not seeing the hangs

I've attached the dmesg in case you're interested

Regards

Mike

[-- Attachment #2: dmesg.nohangs --]
[-- Type: application/octet-stream, Size: 89715 bytes --]

[    0.000000] Linux version 4.15.0-tip+ (root@axion) (gcc version 7.3.0 (Gentoo 7.3.0 p1.0)) #1517 SMP Sun Feb 11 23:47:18 GMT 2018
[    0.000000] Command line: 
[    0.000000] Intel Spectre v2 broken microcode detected; disabling Speculation Control
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[    0.000000] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[    0.000000] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000028693fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000028694000-0x00000000286a5fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000286a6000-0x00000000286c8fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000286c9000-0x00000000286c9fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000286ca000-0x0000000028713fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000028714000-0x000000002876dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000002876e000-0x0000000028e8cfff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000028e8d000-0x000000002e27dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000002e27e000-0x000000002f298fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000002f299000-0x000000002f2d7fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000002f2d8000-0x000000002f882fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000002f883000-0x000000002fffdfff] reserved
[    0.000000] BIOS-e820: [mem 0x000000002fffe000-0x000000002fffefff] usable
[    0.000000] BIOS-e820: [mem 0x0000000030000000-0x0000000037ffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000008c23fffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] e820: update [mem 0x260f7018-0x26106c57] usable ==> usable
[    0.000000] e820: update [mem 0x260f7018-0x26106c57] usable ==> usable
[    0.000000] e820: update [mem 0x260e6018-0x260f6057] usable ==> usable
[    0.000000] e820: update [mem 0x260e6018-0x260f6057] usable ==> usable
[    0.000000] extended physical RAM map:
[    0.000000] reserve setup_data: [mem 0x0000000000000000-0x0000000000057fff] usable
[    0.000000] reserve setup_data: [mem 0x0000000000058000-0x0000000000058fff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000000059000-0x000000000009dfff] usable
[    0.000000] reserve setup_data: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000000100000-0x00000000260e6017] usable
[    0.000000] reserve setup_data: [mem 0x00000000260e6018-0x00000000260f6057] usable
[    0.000000] reserve setup_data: [mem 0x00000000260f6058-0x00000000260f7017] usable
[    0.000000] reserve setup_data: [mem 0x00000000260f7018-0x0000000026106c57] usable
[    0.000000] reserve setup_data: [mem 0x0000000026106c58-0x0000000028693fff] usable
[    0.000000] reserve setup_data: [mem 0x0000000028694000-0x00000000286a5fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000286a6000-0x00000000286c8fff] usable
[    0.000000] reserve setup_data: [mem 0x00000000286c9000-0x00000000286c9fff] ACPI NVS
[    0.000000] reserve setup_data: [mem 0x00000000286ca000-0x0000000028713fff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000028714000-0x000000002876dfff] usable
[    0.000000] reserve setup_data: [mem 0x000000002876e000-0x0000000028e8cfff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000028e8d000-0x000000002e27dfff] usable
[    0.000000] reserve setup_data: [mem 0x000000002e27e000-0x000000002f298fff] reserved
[    0.000000] reserve setup_data: [mem 0x000000002f299000-0x000000002f2d7fff] ACPI data
[    0.000000] reserve setup_data: [mem 0x000000002f2d8000-0x000000002f882fff] ACPI NVS
[    0.000000] reserve setup_data: [mem 0x000000002f883000-0x000000002fffdfff] reserved
[    0.000000] reserve setup_data: [mem 0x000000002fffe000-0x000000002fffefff] usable
[    0.000000] reserve setup_data: [mem 0x0000000030000000-0x0000000037ffffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000100000000-0x00000008c23fffff] usable
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi:  ESRT=0x2ff7f018  ACPI=0x2f2a5000  ACPI 2.0=0x2f2a5000  SMBIOS=0x2feb9000  TPMEventLog=0x28ea1018 
[    0.000000] random: fast init done
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI: Alienware Alienware 15 R2/0H6J09, BIOS 1.4.4 01/08/2018
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x8c2400 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0080000000 mask 7F80000000 uncachable
[    0.000000]   1 base 0040000000 mask 7FC0000000 uncachable
[    0.000000]   2 base 003C000000 mask 7FFC000000 uncachable
[    0.000000]   3 base 003A000000 mask 7FFE000000 uncachable
[    0.000000]   4 base 0039000000 mask 7FFF000000 uncachable
[    0.000000]   5 base 0038800000 mask 7FFF800000 uncachable
[    0.000000]   6 base 0038400000 mask 7FFFC00000 uncachable
[    0.000000]   7 disabled
[    0.000000]   8 disabled
[    0.000000]   9 disabled
[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.000000] e820: last_pfn = 0x2ffff max_arch_pfn = 0x400000000
[    0.000000] esrt: Reserving ESRT space from 0x000000002ff7f018 to 0x000000002ff7f050.
[    0.000000] Base memory trampoline at [        (ptrval)] 97000 size 28672
[    0.000000] Using GB pages for direct mapping
[    0.000000] BRK [0x2eef06000, 0x2eef06fff] PGTABLE
[    0.000000] BRK [0x2eef07000, 0x2eef07fff] PGTABLE
[    0.000000] BRK [0x2eef08000, 0x2eef08fff] PGTABLE
[    0.000000] BRK [0x2eef09000, 0x2eef09fff] PGTABLE
[    0.000000] BRK [0x2eef0a000, 0x2eef0afff] PGTABLE
[    0.000000] BRK [0x2eef0b000, 0x2eef0bfff] PGTABLE
[    0.000000] BRK [0x2eef0c000, 0x2eef0cfff] PGTABLE
[    0.000000] BRK [0x2eef0d000, 0x2eef0dfff] PGTABLE
[    0.000000] BRK [0x2eef0e000, 0x2eef0efff] PGTABLE
[    0.000000] Secure boot disabled
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x000000002F2A5000 000024 (v02 ALWARE)
[    0.000000] ACPI: XSDT 0x000000002F2A50A8 0000CC (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x000000002F2C8F70 00010C (v05 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x000000002F2A5200 023D6B (v02 ALWARE ALIENWRE 01072009 INTL 20120913)
[    0.000000] ACPI: FACS 0x000000002F881F80 000040
[    0.000000] ACPI: APIC 0x000000002F2C9080 0000BC (v03 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: FPDT 0x000000002F2C9140 000044 (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: FIDT 0x000000002F2C9188 00009C (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: MCFG 0x000000002F2C9228 00003C (v01 ALWARE ALIENWRE 01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 0x000000002F2C9268 000038 (v01 ALWARE ALIENWRE 01072009 AMI. 0005000B)
[    0.000000] ACPI: SSDT 0x000000002F2C92A0 0004B9 (v01 SataRe SataTabl 00001000 INTL 20120913)
[    0.000000] ACPI: LPIT 0x000000002F2C9760 000094 (v01 INTEL  SKL      00000000 MSFT 0000005F)
[    0.000000] ACPI: SSDT 0x000000002F2C97F8 000248 (v02 INTEL  sensrhub 00000000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2C9A40 002BAE (v02 INTEL  PtidDevc 00001000 INTL 20120913)
[    0.000000] ACPI: DBGP 0x000000002F2CC5F0 000034 (v01 INTEL           00000000 MSFT 0000005F)
[    0.000000] ACPI: DBG2 0x000000002F2CC628 000054 (v00 INTEL           00000000 MSFT 0000005F)
[    0.000000] ACPI: SSDT 0x000000002F2CC680 00069D (v02 INTEL  xh_rvp10 00000000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2CCD20 002DB7 (v02 DptfTa DptfTabl 00001000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2CFAD8 00559B (v02 SaSsdt SaSsdt   00003000 INTL 20120913)
[    0.000000] ACPI: UEFI 0x000000002F2D5078 000042 (v01                 00000000      00000000)
[    0.000000] ACPI: SSDT 0x000000002F2D50C0 000E58 (v02 CpuRef CpuSsdt  00003000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2D5F18 0000CE (v02 SgRef  SgPeg    00001000 INTL 20120913)
[    0.000000] ACPI: TPM2 0x000000002F2D5FE8 000034 (v03        Tpm2Tabl 00000001 AMI  00000000)
[    0.000000] ACPI: BGRT 0x000000002F2D6020 000038 (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: SSDT 0x000000002F2D6058 001216 (v01 AmdRef AmdTabl  00001000 INTL 20120913)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000008c23fffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000001000-0x0000000000057fff]
[    0.000000]   node   0: [mem 0x0000000000059000-0x000000000009dfff]
[    0.000000]   node   0: [mem 0x0000000000100000-0x0000000028693fff]
[    0.000000]   node   0: [mem 0x00000000286a6000-0x00000000286c8fff]
[    0.000000]   node   0: [mem 0x0000000028714000-0x000000002876dfff]
[    0.000000]   node   0: [mem 0x0000000028e8d000-0x000000002e27dfff]
[    0.000000]   node   0: [mem 0x000000002fffe000-0x000000002fffefff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x00000008c23fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x00000008c23fffff]
[    0.000000] On node 0 totalpages: 8322719
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 22 pages reserved
[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 2861 pages used for memmap
[    0.000000]   DMA32 zone: 183043 pages, LIFO batch:31
[    0.000000]   Normal zone: 127120 pages used for memmap
[    0.000000]   Normal zone: 8135680 pages, LIFO batch:31
[    0.000000] Reserved but unavailable: 99 pages
[    0.000000] Reserving Intel graphics memory at [mem 0x38c00000-0x3cbfffff]
[    0.000000] ACPI: PM-Timer IO Port: 0x1808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] e820: [mem 0x3cc00000-0xdfffffff] available for PCI devices
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] percpu: Embedded 43 pages/cpu @        (ptrval) s136984 r8192 d30952 u262144
[    0.000000] pcpu-alloc: s136984 r8192 d30952 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8192652
[    0.000000] Kernel command line: root=/dev/nvme0n1p2 rootfstype=ext4 libahci.ignore_sss=1 init=/usr/lib/systemd/systemd systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all psmouse.synaptics_intertouch=1 
[    0.000000] log_buf_len individual max cpu contribution: 131072 bytes
[    0.000000] log_buf_len total cpu_extra contributions: 917504 bytes
[    0.000000] log_buf_len min size: 262144 bytes
[    0.000000] log_buf_len: 2097152 bytes
[    0.000000] early log buf free: 247872(94%)
[    0.000000] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    0.000000] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    0.000000] Memory: 32531188K/33290876K available (14348K kernel code, 1149K rwdata, 7020K rodata, 1152K init, 596K bss, 759688K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Kernel/User page tables isolation: enabled
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS: 4352, nr_irqs: 2048, preallocated irqs: 16
[    0.000000] spurious 8259A interrupt: IRQ7.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] ACPI: Core revision 20180105
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
[    0.000000] hpet clockevent registered
[    0.001000] APIC: Switch to symmetric I/O mode setup
[    0.003000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.008000] tsc: Detected 2700.000 MHz processor
[    0.008000] tsc: Detected 2712.000 MHz TSC
[    0.008000] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2717868ea45, max_idle_ns: 440795316085 ns
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5424.00 BogoMIPS (lpj=2712000)
[    0.008000] pid_max: default: 32768 minimum: 301
[    0.008000] Mount-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.008000] Mountpoint-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.008000] Disabling cpuset control group subsystem in v1 mounts
[    0.008000] Disabling cpu control group subsystem in v1 mounts
[    0.008000] Disabling cpuacct control group subsystem in v1 mounts
[    0.008000] Disabling io control group subsystem in v1 mounts
[    0.008000] Disabling memory control group subsystem in v1 mounts
[    0.008000] Disabling devices control group subsystem in v1 mounts
[    0.008000] Disabling freezer control group subsystem in v1 mounts
[    0.008000] Disabling net_cls control group subsystem in v1 mounts
[    0.008000] Disabling net_prio control group subsystem in v1 mounts
[    0.008000] Disabling hugetlb control group subsystem in v1 mounts
[    0.008000] Disabling pids control group subsystem in v1 mounts
[    0.008000] Disabling rdma control group subsystem in v1 mounts
[    0.008000] CPU: Physical Processor ID: 0
[    0.008000] CPU: Processor Core ID: 0
[    0.008000] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    0.008000] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    0.008000] mce: CPU supports 10 MCE banks
[    0.008000] CPU0: Thermal monitoring enabled (TM1)
[    0.008000] process: using mwait in idle threads
[    0.008000] Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
[    0.008000] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
[    0.008000] Spectre V2 : Mitigation: Full generic retpoline
[    0.008000] Spectre V2 : Filling RSB on context switch
[    0.009546] Freeing SMP alternatives memory: 32K
[    0.011429] TSC deadline timer enabled
[    0.011434] smpboot: CPU0: Intel(R) Core(TM) i7-6820HK CPU @ 2.70GHz (family: 0x6, model: 0x5e, stepping: 0x3)
[    0.011469] Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR, full-width counters, Intel PMU driver.
[    0.011497] ... version:                4
[    0.011498] ... bit width:              48
[    0.011499] ... generic registers:      4
[    0.011500] ... value mask:             0000ffffffffffff
[    0.011502] ... max period:             00007fffffffffff
[    0.011503] ... fixed-purpose events:   3
[    0.011504] ... event mask:             000000070000000f
[    0.011530] Hierarchical SRCU implementation.
[    0.011612] smp: Bringing up secondary CPUs ...
[    0.011652] x86: Booting SMP configuration:
[    0.011653] .... node  #0, CPUs:      #1 #2 #3 #4 #5 #6 #7
[    0.015119] smp: Brought up 1 node, 8 CPUs
[    0.015119] smpboot: Max logical packages: 1
[    0.015119] smpboot: Total of 8 processors activated (43392.00 BogoMIPS)
[    0.016426] devtmpfs: initialized
[    0.016426] PM: Registering ACPI NVS region [mem 0x286c9000-0x286c9fff] (4096 bytes)
[    0.016426] PM: Registering ACPI NVS region [mem 0x2f2d8000-0x2f882fff] (5943296 bytes)
[    0.016426] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[    0.016426] futex hash table entries: 2048 (order: 5, 131072 bytes)
[    0.016426] NET: Registered protocol family 16
[    0.016426] audit: initializing netlink subsys (disabled)
[    0.016426] audit: type=2000 audit(1518394540.016:1): state=initialized audit_enabled=0 res=1
[    0.016426] cpuidle: using governor ladder
[    0.016426] cpuidle: using governor menu
[    0.017065] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.017081] ACPI: bus type PCI registered
[    0.017082] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.017111] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.017114] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.017122] PCI: Using configuration type 1 for base access
[    0.019021] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.019021] cryptd: max_cpu_qlen set to 1000
[    0.019035] ACPI: Added _OSI(Module Device)
[    0.019037] ACPI: Added _OSI(Processor Device)
[    0.019038] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.019039] ACPI: Added _OSI(Processor Aggregator Device)
[    0.022349] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022362] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022373] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022384] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022396] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022407] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022418] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022429] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022440] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022451] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022462] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022473] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022484] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022495] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022506] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022518] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022529] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022540] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022551] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022562] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022573] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022584] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022596] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022607] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022618] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022629] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022640] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022652] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022663] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022674] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022685] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022696] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022707] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022718] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022729] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022741] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022752] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022763] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022775] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022786] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022797] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022808] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022884] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022895] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022906] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022917] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022937] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022948] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022959] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022970] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022988] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022999] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.025018] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.025031] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.025042] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.025062] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.025074] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.025085] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.025097] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.049790] ACPI: 10 ACPI AML tables successfully acquired and loaded
[    0.053470] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[    0.057227] ACPI: Dynamic OEM Table Load:
[    0.057233] ACPI: SSDT 0xFFFF88ED5EBA4800 0005FD (v02 PmRef  Cpu0Ist  00003000 INTL 20120913)
[    0.057531] ACPI: \_PR_.CPU0: _OSC native thermal LVT Acked
[    0.058868] ACPI: Dynamic OEM Table Load:
[    0.058873] ACPI: SSDT 0xFFFF88ED5E082800 00037F (v02 PmRef  Cpu0Cst  00003001 INTL 20120913)
[    0.059768] ACPI: Dynamic OEM Table Load:
[    0.059773] ACPI: SSDT 0xFFFF88ED5EBA3800 0005AA (v02 PmRef  ApIst    00003000 INTL 20120913)
[    0.060234] ACPI: Dynamic OEM Table Load:
[    0.060238] ACPI: SSDT 0xFFFF88ED5E07A600 000119 (v02 PmRef  ApCst    00003000 INTL 20120913)
[    0.064561] ACPI: EC: EC started
[    0.064563] ACPI: EC: interrupt blocked
[    0.064909] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as first EC
[    0.064911] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x14, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.064914] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions
[    0.064915] ACPI: Interpreter enabled
[    0.064943] ACPI: (supports S0 S3 S5)
[    0.064944] ACPI: Using IOAPIC for interrupt routing
[    0.064971] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.065690] ACPI: Enabled 9 GPEs in block 00 to 7F
[    0.067590] ACPI: Power Resource [PG00] (on)
[    0.068146] ACPI: Power Resource [PG01] (on)
[    0.068459] ACPI: Power Resource [PG02] (on)
[    0.068970] ACPI: Power Resource [WRST] (off)
[    0.069216] ACPI: Power Resource [WRST] (off)
[    0.069459] ACPI: Power Resource [WRST] (off)
[    0.069704] ACPI: Power Resource [WRST] (off)
[    0.069949] ACPI: Power Resource [WRST] (off)
[    0.070188] ACPI: Power Resource [WRST] (off)
[    0.070432] ACPI: Power Resource [WRST] (off)
[    0.070676] ACPI: Power Resource [WRST] (off)
[    0.070932] ACPI: Power Resource [WRST] (off)
[    0.071178] ACPI: Power Resource [WRST] (off)
[    0.071464] ACPI: Power Resource [WRST] (off)
[    0.071717] ACPI: Power Resource [WRST] (off)
[    0.071961] ACPI: Power Resource [WRST] (off)
[    0.072205] ACPI: Power Resource [WRST] (off)
[    0.072449] ACPI: Power Resource [WRST] (off)
[    0.072691] ACPI: Power Resource [WRST] (off)
[    0.072935] ACPI: Power Resource [WRST] (off)
[    0.073181] ACPI: Power Resource [WRST] (off)
[    0.073423] ACPI: Power Resource [WRST] (off)
[    0.073664] ACPI: Power Resource [WRST] (off)
[    0.085733] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fe])
[    0.085739] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.085766] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[    0.086162] PCI host bridge to bus 0000:00
[    0.086165] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.086167] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.086169] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    0.086171] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000c3fff window]
[    0.086173] pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000c7fff window]
[    0.086175] pci_bus 0000:00: root bus resource [mem 0x000c8000-0x000cbfff window]
[    0.086177] pci_bus 0000:00: root bus resource [mem 0x000cc000-0x000cffff window]
[    0.086179] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff window]
[    0.086181] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff window]
[    0.086183] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff window]
[    0.086185] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff window]
[    0.086187] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff window]
[    0.086189] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff window]
[    0.086191] pci_bus 0000:00: root bus resource [mem 0x000e8000-0x000ebfff window]
[    0.086193] pci_bus 0000:00: root bus resource [mem 0x000ec000-0x000effff window]
[    0.086195] pci_bus 0000:00: root bus resource [mem 0x3cc00000-0xdfffffff window]
[    0.086198] pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfe7fffff window]
[    0.086200] pci_bus 0000:00: root bus resource [bus 00-fe]
[    0.086202] pci_bus 0000:00: scanning bus
[    0.086207] pci 0000:00:00.0: [8086:1910] type 00 class 0x060000
[    0.086214] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0x10
[    0.086463] pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
[    0.086484] pci 0000:00:01.0: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.086498] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    0.086500] pci 0000:00:01.0: PME# disabled
[    0.086628] pci 0000:00:02.0: [8086:191b] type 00 class 0x030000
[    0.086636] pci 0000:00:02.0: reg 0x10: [mem 0xdb000000-0xdbffffff 64bit]
[    0.086640] pci 0000:00:02.0: reg 0x18: [mem 0x70000000-0x7fffffff 64bit pref]
[    0.086644] pci 0000:00:02.0: reg 0x20: [io  0xf000-0xf03f]
[    0.086656] pci 0000:00:02.0: calling efifb_fixup_resources+0x0/0x120
[    0.086658] pci 0000:00:02.0: BAR 2: assigned to efifb
[    0.086744] pci 0000:00:04.0: [8086:1903] type 00 class 0x118000
[    0.086754] pci 0000:00:04.0: reg 0x10: [mem 0xdc620000-0xdc627fff 64bit]
[    0.086911] pci 0000:00:14.0: [8086:a12f] type 00 class 0x0c0330
[    0.086930] pci 0000:00:14.0: reg 0x10: [mem 0xdc610000-0xdc61ffff 64bit]
[    0.086986] pci 0000:00:14.0: PME# supported from D3hot D3cold
[    0.086988] pci 0000:00:14.0: PME# disabled
[    0.087081] pci 0000:00:14.2: [8086:a131] type 00 class 0x118000
[    0.087099] pci 0000:00:14.2: reg 0x10: [mem 0xdc636000-0xdc636fff 64bit]
[    0.087229] pci 0000:00:16.0: [8086:a13a] type 00 class 0x078000
[    0.087252] pci 0000:00:16.0: reg 0x10: [mem 0xdc635000-0xdc635fff 64bit]
[    0.087317] pci 0000:00:16.0: PME# supported from D3hot
[    0.087320] pci 0000:00:16.0: PME# disabled
[    0.087429] pci 0000:00:17.0: [8086:a103] type 00 class 0x010601
[    0.087443] pci 0000:00:17.0: reg 0x10: [mem 0xdc630000-0xdc631fff]
[    0.087449] pci 0000:00:17.0: reg 0x14: [mem 0xdc634000-0xdc6340ff]
[    0.087456] pci 0000:00:17.0: reg 0x18: [io  0xf090-0xf097]
[    0.087462] pci 0000:00:17.0: reg 0x1c: [io  0xf080-0xf083]
[    0.087468] pci 0000:00:17.0: reg 0x20: [io  0xf060-0xf07f]
[    0.087474] pci 0000:00:17.0: reg 0x24: [mem 0xdc633000-0xdc6337ff]
[    0.087507] pci 0000:00:17.0: PME# supported from D3hot
[    0.087509] pci 0000:00:17.0: PME# disabled
[    0.087608] pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400
[    0.087643] pci 0000:00:1c.0: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.087671] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.087673] pci 0000:00:1c.0: PME# disabled
[    0.087795] pci 0000:00:1c.4: [8086:a114] type 01 class 0x060400
[    0.087826] pci 0000:00:1c.4: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.087850] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    0.087852] pci 0000:00:1c.4: PME# disabled
[    0.087958] pci 0000:00:1c.5: [8086:a115] type 01 class 0x060400
[    0.087988] pci 0000:00:1c.5: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.088012] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    0.088014] pci 0000:00:1c.5: PME# disabled
[    0.088122] pci 0000:00:1c.6: [8086:a116] type 01 class 0x060400
[    0.088152] pci 0000:00:1c.6: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.088177] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[    0.088179] pci 0000:00:1c.6: PME# disabled
[    0.088289] pci 0000:00:1d.0: [8086:a118] type 01 class 0x060400
[    0.088325] pci 0000:00:1d.0: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.088355] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[    0.088357] pci 0000:00:1d.0: PME# disabled
[    0.088493] pci 0000:00:1f.0: [8086:a14e] type 00 class 0x060100
[    0.088679] pci 0000:00:1f.2: [8086:a121] type 00 class 0x058000
[    0.088691] pci 0000:00:1f.2: reg 0x10: [mem 0xdc62c000-0xdc62ffff]
[    0.088818] pci 0000:00:1f.3: [8086:a170] type 00 class 0x040300
[    0.088841] pci 0000:00:1f.3: reg 0x10: [mem 0xdc628000-0xdc62bfff 64bit]
[    0.088863] pci 0000:00:1f.3: reg 0x20: [mem 0xdc600000-0xdc60ffff 64bit]
[    0.088905] pci 0000:00:1f.3: PME# supported from D3hot D3cold
[    0.088908] pci 0000:00:1f.3: PME# disabled
[    0.089051] pci 0000:00:1f.4: [8086:a123] type 00 class 0x0c0500
[    0.089110] pci 0000:00:1f.4: reg 0x10: [mem 0xdc632000-0xdc6320ff 64bit]
[    0.089179] pci 0000:00:1f.4: reg 0x20: [io  0xf040-0xf05f]
[    0.089336] pci_bus 0000:00: fixups for bus
[    0.089338] pci 0000:00:01.0: scanning [bus 01-01] behind bridge, pass 0
[    0.089359] pci_bus 0000:01: scanning bus
[    0.089367] pci 0000:01:00.0: [1002:6921] type 00 class 0x038000
[    0.089382] pci 0000:01:00.0: reg 0x10: [mem 0xb0000000-0xbfffffff 64bit pref]
[    0.089388] pci 0000:01:00.0: reg 0x18: [mem 0xc0000000-0xc01fffff 64bit pref]
[    0.089392] pci 0000:01:00.0: reg 0x20: [io  0xe000-0xe0ff]
[    0.089395] pci 0000:01:00.0: reg 0x24: [mem 0xdc500000-0xdc53ffff]
[    0.089399] pci 0000:01:00.0: reg 0x30: [mem 0xdc540000-0xdc55ffff pref]
[    0.089410] pci 0000:01:00.0: calling efifb_fixup_resources+0x0/0x120
[    0.089439] pci 0000:01:00.0: supports D1 D2
[    0.089440] pci 0000:01:00.0: PME# supported from D1 D2 D3hot D3cold
[    0.089442] pci 0000:01:00.0: PME# disabled
[    0.092034] pci_bus 0000:01: fixups for bus
[    0.092035] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.092052] pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
[    0.092053] pci 0000:00:01.0:   bridge window [mem 0xdc500000-0xdc5fffff]
[    0.092056] pci 0000:00:01.0:   bridge window [mem 0xb0000000-0xc01fffff 64bit pref]
[    0.092057] pci_bus 0000:01: bus scan returning with max=01
[    0.092060] pci 0000:00:1c.0: scanning [bus 02-3a] behind bridge, pass 0
[    0.092138] acpiphp_glue: get_slot_status() reading function 0 dvid
[    0.092142] pci_bus 0000:02: got 0x0 dvid 0xffffffff
[    0.092143] acpiphp_glue: get_slot_status() returns: 0x0
[    0.092144] acpiphp_glue: get_slot_status() reading function 0 dvid
[    0.092147] pci_bus 0000:02: got 0x0 dvid 0xffffffff
[    0.092148] acpiphp_glue: get_slot_status() returns: 0x0
[    0.092152] pci_bus 0000:02: dev 00, created physical slot 1
[    0.092155] acpiphp: Slot [1] registered
[    0.092158] pci_bus 0000:02: scanning bus
[    0.092160] pci_bus 0000:02: fixups for bus
[    0.092161] pci 0000:00:1c.0: PCI bridge to [bus 02-3a]
[    0.092165] pci 0000:00:1c.0:   bridge window [mem 0xc4000000-0xda0fffff]
[    0.092169] pci 0000:00:1c.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[    0.092170] pci_bus 0000:02: bus scan returning with max=02
[    0.092173] pci 0000:00:1c.4: scanning [bus 3b-3b] behind bridge, pass 0
[    0.092233] pci_bus 0000:3b: scanning bus
[    0.092247] pci 0000:3b:00.0: [1969:e0a1] type 00 class 0x020000
[    0.092276] pci 0000:3b:00.0: reg 0x10: [mem 0xdc400000-0xdc43ffff 64bit]
[    0.092286] pci 0000:3b:00.0: reg 0x18: [io  0xd000-0xd07f]
[    0.092386] pci 0000:3b:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.092389] pci 0000:3b:00.0: PME# disabled
[    0.095015] pci_bus 0000:3b: fixups for bus
[    0.095016] pci 0000:00:1c.4: PCI bridge to [bus 3b]
[    0.095020] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[    0.095022] pci 0000:00:1c.4:   bridge window [mem 0xdc400000-0xdc4fffff]
[    0.095026] pci_bus 0000:3b: bus scan returning with max=3b
[    0.095029] pci 0000:00:1c.5: scanning [bus 3c-3c] behind bridge, pass 0
[    0.095149] pci_bus 0000:3c: scanning bus
[    0.095213] pci 0000:3c:00.0: [168c:003e] type 00 class 0x028000
[    0.095390] pci 0000:3c:00.0: reg 0x10: [mem 0xdc000000-0xdc1fffff 64bit]
[    0.095877] pci 0000:3c:00.0: PME# supported from D0 D3hot D3cold
[    0.095928] pci 0000:3c:00.0: PME# disabled
[    0.099115] pci_bus 0000:3c: fixups for bus
[    0.099117] pci 0000:00:1c.5: PCI bridge to [bus 3c]
[    0.099122] pci 0000:00:1c.5:   bridge window [mem 0xdc000000-0xdc1fffff]
[    0.099125] pci_bus 0000:3c: bus scan returning with max=3c
[    0.099128] pci 0000:00:1c.6: scanning [bus 3d-3d] behind bridge, pass 0
[    0.099203] pci_bus 0000:3d: scanning bus
[    0.099228] pci 0000:3d:00.0: [10ec:5227] type 00 class 0xff0000
[    0.099255] pci 0000:3d:00.0: reg 0x10: [mem 0xdc300000-0xdc300fff]
[    0.099372] pci 0000:3d:00.0: supports D1 D2
[    0.099374] pci 0000:3d:00.0: PME# supported from D1 D2 D3hot D3cold
[    0.099381] pci 0000:3d:00.0: PME# disabled
[    0.102023] pci_bus 0000:3d: fixups for bus
[    0.102024] pci 0000:00:1c.6: PCI bridge to [bus 3d]
[    0.102029] pci 0000:00:1c.6:   bridge window [mem 0xdc300000-0xdc3fffff]
[    0.102033] pci_bus 0000:3d: bus scan returning with max=3d
[    0.102036] pci 0000:00:1d.0: scanning [bus 3e-3e] behind bridge, pass 0
[    0.102169] pci_bus 0000:3e: scanning bus
[    0.102181] pci 0000:3e:00.0: [144d:a802] type 00 class 0x010802
[    0.102205] pci 0000:3e:00.0: reg 0x10: [mem 0xdc200000-0xdc203fff 64bit]
[    0.102213] pci 0000:3e:00.0: reg 0x18: [io  0xc000-0xc0ff]
[    0.105079] pci_bus 0000:3e: fixups for bus
[    0.105080] pci 0000:00:1d.0: PCI bridge to [bus 3e]
[    0.105084] pci 0000:00:1d.0:   bridge window [io  0xc000-0xcfff]
[    0.105087] pci 0000:00:1d.0:   bridge window [mem 0xdc200000-0xdc2fffff]
[    0.105090] pci_bus 0000:3e: bus scan returning with max=3e
[    0.105093] pci 0000:00:01.0: scanning [bus 01-01] behind bridge, pass 1
[    0.105097] pci 0000:00:1c.0: scanning [bus 02-3a] behind bridge, pass 1
[    0.105102] pci 0000:00:1c.4: scanning [bus 3b-3b] behind bridge, pass 1
[    0.105106] pci 0000:00:1c.5: scanning [bus 3c-3c] behind bridge, pass 1
[    0.105110] pci 0000:00:1c.6: scanning [bus 3d-3d] behind bridge, pass 1
[    0.105115] pci 0000:00:1d.0: scanning [bus 3e-3e] behind bridge, pass 1
[    0.105118] pci_bus 0000:00: bus scan returning with max=3e
[    0.105119] pci_bus 0000:00: on NUMA node 0
[    0.108712] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108752] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14 15)
[    0.108790] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108828] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108865] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108902] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108939] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108976] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.109332] ACPI: EC: interrupt unblocked
[    0.109345] ACPI: EC: event unblocked
[    0.109356] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x14, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.109359] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions and events
[    0.109389] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[    0.109389] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    0.109389] pci 0000:00:02.0: vgaarb: bridge control possible
[    0.109389] vgaarb: loaded
[    0.109389] SCSI subsystem initialized
[    0.109389] libata version 3.00 loaded.
[    0.109389] ACPI: bus type USB registered
[    0.109389] usbcore: registered new interface driver usbfs
[    0.109389] usbcore: registered new interface driver hub
[    0.109389] usbcore: registered new device driver usb
[    0.109389] Linux video capture interface: v2.00
[    0.109389] Registered efivars operations
[    0.116952] Advanced Linux Sound Architecture Driver Initialized.
[    0.116961] PCI: Using ACPI for IRQ routing
[    0.139848] PCI: pci_cache_line_size set to 64 bytes
[    0.139855] pci 0000:00:02.0: BAR 0: reserving [mem 0xdb000000-0xdbffffff flags 0x140204] (d=0, p=0)
[    0.139856] pci 0000:00:02.0: BAR 2: reserving [mem 0x70000000-0x7fffffff flags 0x14220c] (d=0, p=0)
[    0.139858] pci 0000:00:02.0: BAR 4: reserving [io  0xf000-0xf03f flags 0x40101] (d=0, p=0)
[    0.139860] pci 0000:00:14.0: BAR 0: reserving [mem 0xdc610000-0xdc61ffff flags 0x140204] (d=0, p=0)
[    0.139862] pci 0000:00:14.2: BAR 0: reserving [mem 0xdc636000-0xdc636fff flags 0x140204] (d=0, p=0)
[    0.139866] pci 0000:00:17.0: BAR 0: reserving [mem 0xdc630000-0xdc631fff flags 0x40200] (d=0, p=0)
[    0.139867] pci 0000:00:17.0: BAR 1: reserving [mem 0xdc634000-0xdc6340ff flags 0x40200] (d=0, p=0)
[    0.139868] pci 0000:00:17.0: BAR 2: reserving [io  0xf090-0xf097 flags 0x40101] (d=0, p=0)
[    0.139869] pci 0000:00:17.0: BAR 3: reserving [io  0xf080-0xf083 flags 0x40101] (d=0, p=0)
[    0.139870] pci 0000:00:17.0: BAR 4: reserving [io  0xf060-0xf07f flags 0x40101] (d=0, p=0)
[    0.139871] pci 0000:00:17.0: BAR 5: reserving [mem 0xdc633000-0xdc6337ff flags 0x40200] (d=0, p=0)
[    0.139875] pci 0000:3b:00.0: BAR 0: reserving [mem 0xdc400000-0xdc43ffff flags 0x140204] (d=0, p=0)
[    0.139877] pci 0000:3b:00.0: BAR 2: reserving [io  0xd000-0xd07f flags 0x40101] (d=0, p=0)
[    0.139994] pci 0000:3e:00.0: BAR 0: reserving [mem 0xdc200000-0xdc203fff flags 0x140204] (d=0, p=0)
[    0.139995] pci 0000:3e:00.0: BAR 2: reserving [io  0xc000-0xc0ff flags 0x40101] (d=0, p=0)
[    0.140002] pci 0000:00:1f.4: BAR 0: reserving [mem 0xdc632000-0xdc6320ff flags 0x140204] (d=0, p=0)
[    0.140003] pci 0000:00:1f.4: BAR 4: reserving [io  0xf040-0xf05f flags 0x40101] (d=0, p=0)
[    0.140006] pci 0000:01:00.0: BAR 0: reserving [mem 0xb0000000-0xbfffffff flags 0x14220c] (d=1, p=1)
[    0.140007] pci 0000:01:00.0: BAR 2: reserving [mem 0xc0000000-0xc01fffff flags 0x14220c] (d=1, p=1)
[    0.140008] pci 0000:01:00.0: BAR 4: reserving [io  0xe000-0xe0ff flags 0x40101] (d=1, p=1)
[    0.140009] pci 0000:01:00.0: BAR 5: reserving [mem 0xdc500000-0xdc53ffff flags 0x40200] (d=1, p=1)
[    0.140011] pci 0000:00:04.0: BAR 0: reserving [mem 0xdc620000-0xdc627fff flags 0x140204] (d=1, p=1)
[    0.140015] pci 0000:00:16.0: BAR 0: reserving [mem 0xdc635000-0xdc635fff flags 0x140204] (d=1, p=1)
[    0.140067] pci 0000:3c:00.0: BAR 0: reserving [mem 0xdc000000-0xdc1fffff flags 0x140204] (d=1, p=1)
[    0.140075] pci 0000:3d:00.0: BAR 0: reserving [mem 0xdc300000-0xdc300fff flags 0x40200] (d=1, p=1)
[    0.140080] pci 0000:00:1f.2: BAR 0: reserving [mem 0xdc62c000-0xdc62ffff flags 0x40200] (d=1, p=1)
[    0.140082] pci 0000:00:1f.3: BAR 0: reserving [mem 0xdc628000-0xdc62bfff flags 0x140204] (d=1, p=1)
[    0.140084] pci 0000:00:1f.3: BAR 4: reserving [mem 0xdc600000-0xdc60ffff flags 0x140204] (d=1, p=1)
[    0.140089] e820: reserve RAM buffer [mem 0x00058000-0x0005ffff]
[    0.140090] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[    0.140090] e820: reserve RAM buffer [mem 0x260e6018-0x27ffffff]
[    0.140091] e820: reserve RAM buffer [mem 0x260f7018-0x27ffffff]
[    0.140092] e820: reserve RAM buffer [mem 0x28694000-0x2bffffff]
[    0.140093] e820: reserve RAM buffer [mem 0x286c9000-0x2bffffff]
[    0.140093] e820: reserve RAM buffer [mem 0x2876e000-0x2bffffff]
[    0.140094] e820: reserve RAM buffer [mem 0x2e27e000-0x2fffffff]
[    0.140095] e820: reserve RAM buffer [mem 0x2ffff000-0x2fffffff]
[    0.140096] e820: reserve RAM buffer [mem 0x8c2400000-0x8c3ffffff]
[    0.140140] Bluetooth: Core ver 2.22
[    0.140144] NET: Registered protocol family 31
[    0.140145] Bluetooth: HCI device and connection manager initialized
[    0.140147] Bluetooth: HCI socket layer initialized
[    0.140148] Bluetooth: L2CAP socket layer initialized
[    0.140152] Bluetooth: SCO socket layer initialized
[    0.140207] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found
[    0.140321] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[    0.140325] hpet0: 8 comparators, 64-bit 24.000000 MHz counter
[    0.142011] clocksource: Switched to clocksource tsc-early
[    0.147499] FS-Cache: Loaded
[    0.147524] CacheFiles: Loaded
[    0.147531] pnp: PnP ACPI init
[    0.147650] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
[    0.147666] pnp 00:01: Plug and Play ACPI device, IDs DLL0708 PNP0f13 (active)
[    0.147762] system 00:02: [io  0x0680-0x069f] has been reserved
[    0.147764] system 00:02: [io  0xffff] has been reserved
[    0.147766] system 00:02: [io  0xffff] has been reserved
[    0.147768] system 00:02: [io  0xffff] has been reserved
[    0.147770] system 00:02: [io  0x1800-0x18fe] has been reserved
[    0.147772] system 00:02: [io  0x164e-0x164f] has been reserved
[    0.147776] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.147841] system 00:03: [io  0x0800-0x087f] has been reserved
[    0.147844] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.147855] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.147876] system 00:05: [io  0x1854-0x1857] has been reserved
[    0.147880] system 00:05: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active)
[    0.150179] system 00:06: [mem 0xfed10000-0xfed17fff] has been reserved
[    0.150181] system 00:06: [mem 0xfed18000-0xfed18fff] has been reserved
[    0.150183] system 00:06: [mem 0xfed19000-0xfed19fff] has been reserved
[    0.150186] system 00:06: [mem 0xe0000000-0xefffffff] has been reserved
[    0.150188] system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved
[    0.150190] system 00:06: [mem 0xfed90000-0xfed93fff] has been reserved
[    0.150192] system 00:06: [mem 0xfed45000-0xfed8ffff] has been reserved
[    0.150194] system 00:06: [mem 0xff000000-0xffffffff] has been reserved
[    0.150196] system 00:06: [mem 0xfee00000-0xfeefffff] could not be reserved
[    0.150199] system 00:06: [mem 0xdffe0000-0xdfffffff] has been reserved
[    0.150202] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.150228] system 00:07: [mem 0xfd000000-0xfdabffff] has been reserved
[    0.150230] system 00:07: [mem 0xfdad0000-0xfdadffff] has been reserved
[    0.150233] system 00:07: [mem 0xfdb00000-0xfdffffff] has been reserved
[    0.150235] system 00:07: [mem 0xfe000000-0xfe01ffff] could not be reserved
[    0.150237] system 00:07: [mem 0xfe036000-0xfe03bfff] has been reserved
[    0.150239] system 00:07: [mem 0xfe03d000-0xfe3fffff] has been reserved
[    0.150241] system 00:07: [mem 0xfe410000-0xfe7fffff] has been reserved
[    0.150244] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.151093] system 00:08: [mem 0xfdaf0000-0xfdafffff] has been reserved
[    0.151096] system 00:08: [mem 0xfdae0000-0xfdaeffff] has been reserved
[    0.151099] system 00:08: [mem 0xfdac0000-0xfdacffff] has been reserved
[    0.151102] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.151780] pnp: PnP ACPI: found 9 devices
[    0.157104] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.157117] pci 0000:00:1c.0: bridge window [io  0x1000-0x0fff] to [bus 02-3a] add_size 1000
[    0.157136] pci 0000:00:1c.0: BAR 13: assigned [io  0x2000-0x2fff]
[    0.157139] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.157141] pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
[    0.157144] pci 0000:00:01.0:   bridge window [mem 0xdc500000-0xdc5fffff]
[    0.157147] pci 0000:00:01.0:   bridge window [mem 0xb0000000-0xc01fffff 64bit pref]
[    0.157151] pci 0000:00:1c.0: PCI bridge to [bus 02-3a]
[    0.157153] pci 0000:00:1c.0:   bridge window [io  0x2000-0x2fff]
[    0.157157] pci 0000:00:1c.0:   bridge window [mem 0xc4000000-0xda0fffff]
[    0.157160] pci 0000:00:1c.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[    0.157165] pci 0000:00:1c.4: PCI bridge to [bus 3b]
[    0.157168] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[    0.157171] pci 0000:00:1c.4:   bridge window [mem 0xdc400000-0xdc4fffff]
[    0.157177] pci 0000:00:1c.5: PCI bridge to [bus 3c]
[    0.157180] pci 0000:00:1c.5:   bridge window [mem 0xdc000000-0xdc1fffff]
[    0.157186] pci 0000:00:1c.6: PCI bridge to [bus 3d]
[    0.157189] pci 0000:00:1c.6:   bridge window [mem 0xdc300000-0xdc3fffff]
[    0.157195] pci 0000:00:1d.0: PCI bridge to [bus 3e]
[    0.157197] pci 0000:00:1d.0:   bridge window [io  0xc000-0xcfff]
[    0.157201] pci 0000:00:1d.0:   bridge window [mem 0xdc200000-0xdc2fffff]
[    0.157208] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.157209] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.157210] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[    0.157211] pci_bus 0000:00: resource 7 [mem 0x000c0000-0x000c3fff window]
[    0.157212] pci_bus 0000:00: resource 8 [mem 0x000c4000-0x000c7fff window]
[    0.157213] pci_bus 0000:00: resource 9 [mem 0x000c8000-0x000cbfff window]
[    0.157214] pci_bus 0000:00: resource 10 [mem 0x000cc000-0x000cffff window]
[    0.157214] pci_bus 0000:00: resource 11 [mem 0x000d0000-0x000d3fff window]
[    0.157215] pci_bus 0000:00: resource 12 [mem 0x000d4000-0x000d7fff window]
[    0.157216] pci_bus 0000:00: resource 13 [mem 0x000d8000-0x000dbfff window]
[    0.157217] pci_bus 0000:00: resource 14 [mem 0x000dc000-0x000dffff window]
[    0.157218] pci_bus 0000:00: resource 15 [mem 0x000e0000-0x000e3fff window]
[    0.157219] pci_bus 0000:00: resource 16 [mem 0x000e4000-0x000e7fff window]
[    0.157220] pci_bus 0000:00: resource 17 [mem 0x000e8000-0x000ebfff window]
[    0.157221] pci_bus 0000:00: resource 18 [mem 0x000ec000-0x000effff window]
[    0.157222] pci_bus 0000:00: resource 19 [mem 0x3cc00000-0xdfffffff window]
[    0.157223] pci_bus 0000:00: resource 20 [mem 0xfd000000-0xfe7fffff window]
[    0.157224] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
[    0.157225] pci_bus 0000:01: resource 1 [mem 0xdc500000-0xdc5fffff]
[    0.157226] pci_bus 0000:01: resource 2 [mem 0xb0000000-0xc01fffff 64bit pref]
[    0.157227] pci_bus 0000:02: resource 0 [io  0x2000-0x2fff]
[    0.157228] pci_bus 0000:02: resource 1 [mem 0xc4000000-0xda0fffff]
[    0.157229] pci_bus 0000:02: resource 2 [mem 0x80000000-0xa1ffffff 64bit pref]
[    0.157229] pci_bus 0000:3b: resource 0 [io  0xd000-0xdfff]
[    0.157230] pci_bus 0000:3b: resource 1 [mem 0xdc400000-0xdc4fffff]
[    0.157231] pci_bus 0000:3c: resource 1 [mem 0xdc000000-0xdc1fffff]
[    0.157232] pci_bus 0000:3d: resource 1 [mem 0xdc300000-0xdc3fffff]
[    0.157233] pci_bus 0000:3e: resource 0 [io  0xc000-0xcfff]
[    0.157234] pci_bus 0000:3e: resource 1 [mem 0xdc200000-0xdc2fffff]
[    0.157336] NET: Registered protocol family 2
[    0.157398] tcp_listen_portaddr_hash hash table entries: 16384 (order: 6, 262144 bytes)
[    0.157427] TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.157640] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.157726] TCP: Hash tables configured (established 262144 bind 65536)
[    0.157746] UDP hash table entries: 16384 (order: 7, 524288 bytes)
[    0.157791] UDP-Lite hash table entries: 16384 (order: 7, 524288 bytes)
[    0.157865] NET: Registered protocol family 1
[    0.157919] pci 0000:00:02.0: calling pci_fixup_video+0x0/0x110
[    0.157922] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    0.157929] pci 0000:00:14.0: calling quirk_usb_early_handoff+0x0/0x690
[    0.158587] pci 0000:3b:00.0: calling quirk_blacklist_vpd+0x0/0x30
[    0.158700] PCI: CLS 0 bytes, default 64
[    0.158718] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.158721] software IO TLB [mem 0x220e6000-0x260e6000] (64MB) mapped at [000000006e6c8cce-00000000e12cbca7]
[    0.158790] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms ovfl timer
[    0.158792] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[    0.158794] RAPL PMU: hw unit of domain package 2^-14 Joules
[    0.158795] RAPL PMU: hw unit of domain dram 2^-14 Joules
[    0.158796] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[    0.158797] RAPL PMU: hw unit of domain psys 2^-14 Joules
[    0.158810] skl_uncore 0000:00:00.0: runtime IRQ mapping not provided by arch
[    0.158882] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2717868ea45, max_idle_ns: 440795316085 ns
[    0.158890] clocksource: Switched to clocksource tsc
[    0.159833] Initialise system trusted keyrings
[    0.159848] workingset: timestamp_bits=46 max_order=23 bucket_order=0
[    0.160986] FS-Cache: Netfs 'cifs' registered for caching
[    0.161032] Key type cifs.idmap registered
[    0.161045] fuse init (API version 7.26)
[    0.161684] NET: Registered protocol family 38
[    0.161711] Key type asymmetric registered
[    0.161713] Asymmetric key parser 'x509' registered
[    0.161730] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    0.161732] io scheduler noop registered
[    0.161756] io scheduler cfq registered (default)
[    0.161847] pcieport 0000:00:01.0: runtime IRQ mapping not provided by arch
[    0.161964] pcieport 0000:00:1c.0: runtime IRQ mapping not provided by arch
[    0.162061] pcieport 0000:00:1c.4: runtime IRQ mapping not provided by arch
[    0.162145] pcieport 0000:00:1c.5: runtime IRQ mapping not provided by arch
[    0.162232] pcieport 0000:00:1c.6: runtime IRQ mapping not provided by arch
[    0.162321] pcieport 0000:00:1d.0: runtime IRQ mapping not provided by arch
[    0.162434] intel_idle: MWAIT substates: 0x11142120
[    0.162434] intel_idle: v0.4.1 model 0x5E
[    0.162646] intel_idle: lapic_timer_reliable_states 0xffffffff
[    0.162711] ACPI: AC Adapter [ACAD] (on-line)
[    0.162749] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:40/PNP0C0D:00/input/input0
[    0.162755] ACPI: Lid Switch [LID0]
[    0.162777] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[    0.162786] ACPI: Power Button [PWRB]
[    0.162803] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[    0.162813] ACPI: Power Button [PWRF]
[    0.180112] ACPI: Battery Slot [BAT1] (battery present)
[    0.180380] Non-volatile memory driver v1.3
[    0.180532] Linux agpgart interface v0.103
[    0.180559] [drm] amdgpu kernel modesetting enabled.
[    0.180566] vga_switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle
[    0.180634] ATPX version 1, functions 0x00000033
[    0.180731] ATPX Hybrid Graphics
[    0.180740] amdgpu 0000:01:00.0: runtime IRQ mapping not provided by arch
[    0.180754] amdgpu 0000:01:00.0: enabling device (0000 -> 0003)
[    0.180949] [drm] initializing kernel modesetting (TONGA 0x1002:0x6921 0x1028:0x0708 0x00).
[    0.180956] [drm] register mmio base: 0xDC500000
[    0.180957] [drm] register mmio size: 262144
[    0.180966] [drm] probing gen 2 caps for device 8086:1901 = 261ad03/e
[    0.180968] [drm] probing mlw for device 8086:1901 = 261ad03
[    0.180981] [drm] VCE enabled in physical mode
[    0.207246] ATOM BIOS: BR46576.001
[    0.207255] [drm] GPU posting now...
[    0.213089] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
[    0.213097] amdgpu 0000:01:00.0: VRAM: 4096M 0x000000F400000000 - 0x000000F4FFFFFFFF (4096M used)
[    0.213100] amdgpu 0000:01:00.0: GTT: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
[    0.213103] [drm] Detected VRAM RAM=4096M, BAR=256M
[    0.213105] [drm] RAM width 256bits GDDR5
[    0.213331] [TTM] Zone  kernel: Available graphics memory: 16309014 kiB
[    0.213333] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    0.213334] [TTM] Initializing pool allocator
[    0.213337] [TTM] Initializing DMA pool allocator
[    0.213369] [drm] amdgpu: 4096M of VRAM memory ready
[    0.213371] [drm] amdgpu: 4096M of GTT memory ready.
[    0.213395] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    0.213900] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[    0.215680] [drm] Found UVD firmware Version: 1.65 Family ID: 10
[    0.215957] [drm] Found VCE firmware Version: 52.8 Binary ID: 3
[    0.216177] amdgpu 0000:01:00.0: enabling bus mastering
[    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
[    0.265879] [drm] Display Core initialized with v3.1.27!
[    0.265901] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.265902] [drm] Driver supports precise vblank timestamp query.
[    0.315206] [drm] UVD initialized successfully.
[    0.526289] [drm] VCE initialized successfully.
[    0.632410] [drm] Initialized amdgpu 3.23.0 20150101 for 0000:01:00.0 on minor 0
[    0.632434] i915 0000:00:02.0: runtime IRQ mapping not provided by arch
[    0.633145] [drm] Replacing VGA console driver
[    0.634230] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.634232] [drm] Driver supports precise vblank timestamp query.
[    0.634596] vga_switcheroo: enabled
[    0.634626] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    0.635788] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27)
[    0.642100] [drm] Initialized i915 1.6.0 20171222 for 0000:00:02.0 on minor 1
[    0.643782] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[    0.644007] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[    0.645039] loop: module loaded
[    0.645055] mei_me 0000:00:16.0: runtime IRQ mapping not provided by arch
[    0.645062] mei_me 0000:00:16.0: enabling device (0000 -> 0002)
[    0.645156] mei_me 0000:00:16.0: enabling bus mastering
[    0.645169] nvme 0000:3e:00.0: runtime IRQ mapping not provided by arch
[    0.645196] nvme nvme0: pci function 0000:3e:00.0
[    0.648887] ahci 0000:00:17.0: runtime IRQ mapping not provided by arch
[    0.648929] ahci 0000:00:17.0: version 3.0
[    0.659125] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x2 impl SATA mode
[    0.659131] ahci 0000:00:17.0: flags: 64bit ncq sntf pm led clo only pio slum part ems deso sadm sds apst 
[    0.659384] scsi host0: ahci
[    0.659651] scsi host1: ahci
[    0.659731] ata1: DUMMY
[    0.659733] ata2: SATA max UDMA/133 abar m2048@0xdc633000 port 0xdc633180 irq 124
[    0.659782] tun: Universal TUN/TAP device driver, 1.6
[    0.659839] alx 0000:3b:00.0: runtime IRQ mapping not provided by arch
[    0.661920] fbcon: inteldrmfb (fb0) is primary device
[    0.670598] alx 0000:3b:00.0 eth0: Qualcomm Atheros AR816x/AR817x Ethernet [20:47:47:db:e8:9b]
[    0.670614] ath10k_pci 0000:3c:00.0: runtime IRQ mapping not provided by arch
[    0.671046] ath10k_pci 0000:3c:00.0: enabling device (0000 -> 0002)
[    0.671250] ath10k_pci 0000:3c:00.0: enabling bus mastering
[    0.671920] ath10k_pci 0000:3c:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[    0.757546]  nvme0n1: p1 p2 p3
[    0.772579] xhci_hcd 0000:00:14.0: runtime IRQ mapping not provided by arch
[    0.772739] xhci_hcd 0000:00:14.0: enabling bus mastering
[    0.772742] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    0.772747] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[    0.773807] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x00109810
[    0.773811] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[    0.773899] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.773900] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.773901] usb usb1: Product: xHCI Host Controller
[    0.773902] usb usb1: Manufacturer: Linux 4.15.0-tip+ xhci-hcd
[    0.773902] usb usb1: SerialNumber: 0000:00:14.0
[    0.774088] hub 1-0:1.0: USB hub found
[    0.774103] hub 1-0:1.0: 16 ports detected
[    0.774823] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    0.774825] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[    0.774846] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[    0.774848] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.774848] usb usb2: Product: xHCI Host Controller
[    0.774849] usb usb2: Manufacturer: Linux 4.15.0-tip+ xhci-hcd
[    0.774850] usb usb2: SerialNumber: 0000:00:14.0
[    0.774997] hub 2-0:1.0: USB hub found
[    0.775010] hub 2-0:1.0: 8 ports detected
[    0.775332] usb: port power management may be unreliable
[    0.775497] usbcore: registered new interface driver cdc_acm
[    0.775497] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    0.775505] usbcore: registered new interface driver usb-storage
[    0.775533] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    0.802408] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.802410] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.802558] mousedev: PS/2 mouse device common for all mice
[    0.802974] usbcore: registered new interface driver synaptics_usb
[    0.803064] rtc_cmos 00:04: RTC can wake from S4
[    0.803447] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    0.803542] rtc_cmos 00:04: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    0.803547] i2c /dev entries driver
[    0.803766] i801_smbus 0000:00:1f.4: runtime IRQ mapping not provided by arch
[    0.803857] i801_smbus 0000:00:1f.4: SPD Write Disable is set
[    0.803875] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt
[    0.808131] usbcore: registered new interface driver uvcvideo
[    0.808131] USB Video Class driver (1.1.1)
[    0.810048] proc_thermal 0000:00:04.0: runtime IRQ mapping not provided by arch
[    0.810069] proc_thermal 0000:00:04.0: enabling device (0000 -> 0002)
[    0.810751] intel_pch_thermal 0000:00:14.2: runtime IRQ mapping not provided by arch
[    0.810841] usbcore: registered new interface driver btusb
[    0.810843] intel_pstate: Intel P-state driver initializing
[    0.811416] intel_pstate: HWP enabled
[    0.811528] EFI Variables Facility v0.08 2004-May-17
[    0.813725] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[    0.819844] pstore: using lz4 compression
[    0.819845] pstore: Registered efi as persistent store backend
[    0.819928] usbcore: registered new interface driver usbhid
[    0.819928] usbhid: USB HID core driver
[    0.821056] intel_rapl: Found RAPL domain package
[    0.821057] intel_rapl: Found RAPL domain core
[    0.821057] intel_rapl: Found RAPL domain uncore
[    0.821058] intel_rapl: Found RAPL domain dram
[    0.821759] snd_hda_intel 0000:00:1f.3: runtime IRQ mapping not provided by arch
[    0.821773] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    0.822158] Initializing XFRM netlink socket
[    0.822219] NET: Registered protocol family 10
[    0.822440] Segment Routing with IPv6
[    0.822459] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.822515] NET: Registered protocol family 17
[    0.822517] NET: Registered protocol family 15
[    0.822597] Bluetooth: RFCOMM TTY layer initialized
[    0.822615] Bluetooth: RFCOMM socket layer initialized
[    0.822617] Bluetooth: RFCOMM ver 1.11
[    0.822617] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    0.822618] Bluetooth: BNEP filters: protocol multicast
[    0.822619] Bluetooth: BNEP socket layer initialized
[    0.822619] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    0.822620] Bluetooth: HIDP socket layer initialized
[    0.822899] Key type dns_resolver registered
[    0.823294] microcode: sig=0x506e3, pf=0x20, revision=0xc2
[    0.823522] microcode: Microcode Update Driver: v2.2.
[    0.823525] AVX2 version of gcm_enc/dec engaged.
[    0.823525] AES CTR mode by8 optimization enabled
[    0.823697] sched_clock: Marking stable (823695302, 0)->(822474002, 1221300)
[    0.823859] registered taskstats version 1
[    0.823859] Loading compiled-in X.509 certificates
[    0.824682] input: Dell WMI hotkeys as /devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input7
[    0.824797] rtc_cmos 00:04: setting system clock to 2018-02-12 00:15:41 UTC (1518394541)
[    0.824802] ALSA device list:
[    0.824803]   No soundcards found.
[    0.883536] ath10k_pci 0000:3c:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3c:00.0.bin failed with error -2
[    0.883542] ath10k_pci 0000:3c:00.0: Direct firmware load for ath10k/cal-pci-0000:3c:00.0.bin failed with error -2
[    0.883546] ath10k_pci 0000:3c:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
[    0.883548] ath10k_pci 0000:3c:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
[    0.884076] ath10k_pci 0000:3c:00.0: firmware ver RM.4.4.1.c1-00037-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 0845d1b2
[    0.947214] ath10k_pci 0000:3c:00.0: board_file api 2 bmi_id N/A crc32 414716a3
[    0.965155] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    0.965558] ata2.00: ATA-9: M4-CT512M4SSD2, 0309, max UDMA/100
[    0.965559] ata2.00: 1000215216 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    0.966032] ata2.00: configured for UDMA/100
[    1.098045] usb 1-4: new full-speed USB device number 2 using xhci_hcd
[    1.186861] psmouse serio1: synaptics: queried max coordinates: x [..5668], y [..4756]
[    1.216241] psmouse serio1: synaptics: queried min coordinates: x [1274..], y [1098..]
[    1.216242] psmouse serio1: synaptics: Trying to set up SMBus access
[    1.219747] rmi4_smbus 6-002c: registering SMbus-connected sensor
[    1.224816] usb 1-4: config 1 interface 0 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[    1.225630] usb 1-4: New USB device found, idVendor=187c, idProduct=0528
[    1.225649] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    1.225650] usb 1-4: Product: AW1517
[    1.225651] usb 1-4: Manufacturer: Alienware
[    1.225652] usb 1-4: SerialNumber: 16.0
[    1.227083] hid-generic 0003:187C:0528.0001: device has no listeners, quitting
[    1.254819] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2417-001, fw id: 0
[    1.291822] input: Synaptics TM2417-001 as /devices/rmi4-00/input/input8
[    1.341042] usb 1-5: new full-speed USB device number 3 using xhci_hcd
[    1.468489] usb 1-5: New USB device found, idVendor=0cf3, idProduct=e300
[    1.468490] usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.526259] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[    1.529195] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[    1.529959] ath10k_pci 0000:3c:00.0: htt-ver 3.46 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
[    1.588557] ath: EEPROM regdomain: 0x6c
[    1.588558] ath: EEPROM indicates we should expect a direct regpair map
[    1.588559] ath: Country alpha2 being used: 00
[    1.588559] ath: Regpair used: 0x6c
[    1.820745] Console: switching to colour frame buffer device 320x98
[    1.820756] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffff830e6040)
[    1.840491] snd_hda_intel 0000:00:1f.3: enabling bus mastering
[    1.840500] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    1.853172] snd_hda_codec_ca0132 hdaudioC0D0: autoconfig for CA0132: line_outs=1 (0xb/0x0/0x0/0x0/0x0) type:speaker
[    1.931613] snd_hda_codec_ca0132 hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    1.931614] snd_hda_codec_ca0132 hdaudioC0D0:    hp_outs=1 (0xf/0x0/0x0/0x0/0x0)
[    1.931615] snd_hda_codec_ca0132 hdaudioC0D0:    mono: mono_out=0x0
[    1.931616] snd_hda_codec_ca0132 hdaudioC0D0:    inputs:
[    1.931618] snd_hda_codec_ca0132 hdaudioC0D0:      Mic=0x11
[    1.931619] snd_hda_codec_ca0132 hdaudioC0D0:      Internal Mic=0x12
[    1.931759] scsi 1:0:0:0: Direct-Access     ATA      M4-CT512M4SSD2   0309 PQ: 0 ANSI: 5
[    1.952137] sd 1:0:0:0: [sda] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
[    1.954264] sd 1:0:0:0: [sda] Write Protect is off
[    1.956648] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.956652] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.958930] i915 0000:00:02.0: end poll
[    1.960979] i915 0000:00:02.0: begin poll
[    1.962515]  sda: sda1 sda2 sda3 sda4
[    1.965932] sd 1:0:0:0: [sda] Attached SCSI disk
[    1.990430] i915 0000:00:02.0: end poll
[    2.471301] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[    2.662022] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9
[    2.669447] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10
[    2.677400] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input11
[    2.684860] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input12
[    2.690156] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13
[    2.694097] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input14
[    2.697517] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input15
[    2.708802] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.711125] VFS: Mounted root (ext4 filesystem) readonly on device 259:2.
[    2.713948] devtmpfs: mounted
[    2.716992] Freeing unused kernel memory: 1152K
[    2.719298] Write protecting the kernel read-only data: 24576k
[    2.721968] Freeing unused kernel memory: 2020K
[    2.725358] Freeing unused kernel memory: 1172K
[    2.790227] systemd[1]: systemd 237 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[    2.806470] systemd[1]: Detected architecture x86-64.
[    2.823431] systemd[1]: Set hostname to <axion>.
[    2.876425] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    2.881722] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    2.886986] systemd[1]: Created slice System Slice.
[    2.892801] systemd[1]: Listening on Process Core Dump Socket.
[    2.897907] systemd[1]: Listening on Journal Socket.
[    2.902984] systemd[1]: Listening on Network Service Netlink Socket.
[    2.908167] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[    3.018932] EXT4-fs (nvme0n1p2): re-mounted. Opts: (null)
[    3.075779] systemd-journald[232]: Received request to flush runtime journal from PID 1
[    3.090002] random: crng init done
[    3.256577] EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Opts: (null)
[    3.663627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    3.665889] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    3.673853] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    3.812218] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[    4.373386] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[    4.376319] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[    4.419227] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    5.167925] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[    5.170837] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[    5.223120] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    5.276215] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    9.184046] waiting 12 sec
[   10.933989] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[   10.936915] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[   10.990991] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   15.689333] wlan0: authenticate with a0:63:91:a7:3c:9f
[   15.733176] wlan0: send auth to a0:63:91:a7:3c:9f (try 1/3)
[   15.735706] wlan0: authenticated
[   15.740052] wlan0: associate with a0:63:91:a7:3c:9f (try 1/3)
[   15.742191] wlan0: RX AssocResp from a0:63:91:a7:3c:9f (capab=0x11 status=0 aid=1)
[   15.744988] wlan0: associated
[   15.745164] ath: EEPROM regdomain: 0x833a
[   15.745166] ath: EEPROM indicates we should expect a country code
[   15.745168] ath: doing EEPROM country->regdmn map search
[   15.745170] ath: country maps to regdmn code: 0x37
[   15.745172] ath: Country alpha2 being used: GB
[   15.745173] ath: Regpair used: 0x37
[   15.745176] ath: regdomain 0x833a dynamically updated by country IE
[   15.760824] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   21.472096] done waiting 12 sec
[   21.700582] amdgpu 0000:01:00.0: GPU pci config reset
[   21.700586] amdgpu 0000:01:00.0: disabling bus mastering
[   21.700691] amdgpu 0000:01:00.0: enabling bus mastering
[   21.743420] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[   37.086261] pcieport 0000:00:01.0: power state changed by ACPI to D0
[   37.192203] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[   37.192213] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[   37.192220] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[   37.192228] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[   37.192236] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[   37.192246] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[   37.201887] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[   37.399942] [drm] UVD initialized successfully.
[   37.612003] [drm] VCE initialized successfully.
[   56.902565] waiting 12 sec
[   69.269467] done waiting 12 sec
[   69.519581] amdgpu 0000:01:00.0: GPU pci config reset
[   69.519584] amdgpu 0000:01:00.0: disabling bus mastering
[   69.519689] amdgpu 0000:01:00.0: enabling bus mastering
[   69.562150] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[   75.480966] pcieport 0000:00:01.0: power state changed by ACPI to D0
[   75.586668] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[   75.586674] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[   75.586678] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[   75.586683] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[   75.586687] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[   75.586693] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[   75.597132] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[   75.798225] [drm] UVD initialized successfully.
[   76.010230] [drm] VCE initialized successfully.
[  110.942939] waiting 12 sec
[  123.039401] done waiting 12 sec
[  123.288840] amdgpu 0000:01:00.0: GPU pci config reset
[  123.288843] amdgpu 0000:01:00.0: disabling bus mastering
[  123.288948] amdgpu 0000:01:00.0: enabling bus mastering
[  123.331681] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[  123.773713] pcieport 0000:00:01.0: power state changed by ACPI to D0
[  123.879524] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[  123.879537] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[  123.879545] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[  123.879554] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[  123.879563] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[  123.879573] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[  123.888805] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[  124.086898] [drm] UVD initialized successfully.
[  124.298958] [drm] VCE initialized successfully.
[  143.983924] waiting 12 sec
[  156.319685] done waiting 12 sec
[  156.558188] amdgpu 0000:01:00.0: GPU pci config reset
[  156.558192] amdgpu 0000:01:00.0: disabling bus mastering
[  156.558297] amdgpu 0000:01:00.0: enabling bus mastering
[  156.600899] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[  710.067880] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[  867.498109] pcieport 0000:00:01.0: power state changed by ACPI to D0
[  867.604029] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[  867.604034] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[  867.604038] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[  867.604042] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[  867.604046] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[  867.604050] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[  867.612559] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[  867.859670] [drm] UVD initialized successfully.
[  868.071735] [drm] VCE initialized successfully.
[  873.123999] waiting 12 sec
[  885.413116] done waiting 12 sec
[  885.722429] amdgpu 0000:01:00.0: GPU pci config reset
[  885.722435] amdgpu 0000:01:00.0: disabling bus mastering
[  885.722541] amdgpu 0000:01:00.0: enabling bus mastering
[  885.765440] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[  991.201843] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[  991.503736] WARNING! power/level is deprecated; use power/control instead
[  991.979335] pcieport 0000:00:01.0: power state changed by ACPI to D0
[  992.085409] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[  992.085414] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[  992.085417] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[  992.085421] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[  992.085425] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[  992.085430] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[  992.094828] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[  992.293008] [drm] UVD initialized successfully.
[  992.505073] [drm] VCE initialized successfully.
[ 1002.149280] waiting 12 sec
[ 1014.437410] done waiting 12 sec
[ 1014.766156] amdgpu 0000:01:00.0: GPU pci config reset
[ 1014.766161] amdgpu 0000:01:00.0: disabling bus mastering
[ 1014.766267] amdgpu 0000:01:00.0: enabling bus mastering
[ 1014.808734] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[ 3596.751977] CPU0: Core temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751978] CPU4: Core temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751979] CPU5: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751980] CPU6: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751981] CPU7: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751983] CPU1: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751983] CPU3: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751984] CPU2: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751986] CPU4: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751988] CPU0: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.752992] CPU4: Core temperature/speed normal
[ 3596.752992] CPU0: Core temperature/speed normal
[ 3596.752993] CPU2: Package temperature/speed normal
[ 3596.752994] CPU1: Package temperature/speed normal
[ 3596.752995] CPU6: Package temperature/speed normal
[ 3596.752996] CPU3: Package temperature/speed normal
[ 3596.752996] CPU5: Package temperature/speed normal
[ 3596.752997] CPU7: Package temperature/speed normal
[ 3596.752998] CPU0: Package temperature/speed normal
[ 3596.753005] CPU4: Package temperature/speed normal

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Mike Lothian]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
>> I've not been able to reproduce the original problem you're trying to
>> solve on amdgpu thats with or without your patch set and the above
>> "trigger" too
>>
>> Is anything else required to trigger it, I started multiple DRI_PRIME
>> glxgears, in parallel, serial waiting the 12 seconds and serial within
>> the 12 seconds and I couldn't reproduce it
>
> The discrete GPU needs to runtime suspend, that's the trigger,
> so no DRI_PRIME executables should be running.  Just let it
> autosuspend after boot.  Do you see "waiting 12 sec" messages
> in dmesg?  If not it's not autosuspending.
>
> Thanks,
>
> Lukas

Hi

Yes I'm seeing those messages, I'm just not seeing the hangs

I've attached the dmesg in case you're interested

Regards

Mike

[-- Attachment #2: dmesg.nohangs --]
[-- Type: application/octet-stream, Size: 89715 bytes --]

[    0.000000] Linux version 4.15.0-tip+ (root@axion) (gcc version 7.3.0 (Gentoo 7.3.0 p1.0)) #1517 SMP Sun Feb 11 23:47:18 GMT 2018
[    0.000000] Command line: 
[    0.000000] Intel Spectre v2 broken microcode detected; disabling Speculation Control
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[    0.000000] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[    0.000000] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000000058000-0x0000000000058fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000059000-0x000000000009dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000028693fff] usable
[    0.000000] BIOS-e820: [mem 0x0000000028694000-0x00000000286a5fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000286a6000-0x00000000286c8fff] usable
[    0.000000] BIOS-e820: [mem 0x00000000286c9000-0x00000000286c9fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000286ca000-0x0000000028713fff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000028714000-0x000000002876dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000002876e000-0x0000000028e8cfff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000028e8d000-0x000000002e27dfff] usable
[    0.000000] BIOS-e820: [mem 0x000000002e27e000-0x000000002f298fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000002f299000-0x000000002f2d7fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000002f2d8000-0x000000002f882fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000002f883000-0x000000002fffdfff] reserved
[    0.000000] BIOS-e820: [mem 0x000000002fffe000-0x000000002fffefff] usable
[    0.000000] BIOS-e820: [mem 0x0000000030000000-0x0000000037ffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000008c23fffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] e820: update [mem 0x260f7018-0x26106c57] usable ==> usable
[    0.000000] e820: update [mem 0x260f7018-0x26106c57] usable ==> usable
[    0.000000] e820: update [mem 0x260e6018-0x260f6057] usable ==> usable
[    0.000000] e820: update [mem 0x260e6018-0x260f6057] usable ==> usable
[    0.000000] extended physical RAM map:
[    0.000000] reserve setup_data: [mem 0x0000000000000000-0x0000000000057fff] usable
[    0.000000] reserve setup_data: [mem 0x0000000000058000-0x0000000000058fff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000000059000-0x000000000009dfff] usable
[    0.000000] reserve setup_data: [mem 0x000000000009e000-0x000000000009ffff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000000100000-0x00000000260e6017] usable
[    0.000000] reserve setup_data: [mem 0x00000000260e6018-0x00000000260f6057] usable
[    0.000000] reserve setup_data: [mem 0x00000000260f6058-0x00000000260f7017] usable
[    0.000000] reserve setup_data: [mem 0x00000000260f7018-0x0000000026106c57] usable
[    0.000000] reserve setup_data: [mem 0x0000000026106c58-0x0000000028693fff] usable
[    0.000000] reserve setup_data: [mem 0x0000000028694000-0x00000000286a5fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000286a6000-0x00000000286c8fff] usable
[    0.000000] reserve setup_data: [mem 0x00000000286c9000-0x00000000286c9fff] ACPI NVS
[    0.000000] reserve setup_data: [mem 0x00000000286ca000-0x0000000028713fff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000028714000-0x000000002876dfff] usable
[    0.000000] reserve setup_data: [mem 0x000000002876e000-0x0000000028e8cfff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000028e8d000-0x000000002e27dfff] usable
[    0.000000] reserve setup_data: [mem 0x000000002e27e000-0x000000002f298fff] reserved
[    0.000000] reserve setup_data: [mem 0x000000002f299000-0x000000002f2d7fff] ACPI data
[    0.000000] reserve setup_data: [mem 0x000000002f2d8000-0x000000002f882fff] ACPI NVS
[    0.000000] reserve setup_data: [mem 0x000000002f883000-0x000000002fffdfff] reserved
[    0.000000] reserve setup_data: [mem 0x000000002fffe000-0x000000002fffefff] usable
[    0.000000] reserve setup_data: [mem 0x0000000030000000-0x0000000037ffffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fe000000-0x00000000fe010fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] reserve setup_data: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] reserve setup_data: [mem 0x0000000100000000-0x00000008c23fffff] usable
[    0.000000] efi: EFI v2.40 by American Megatrends
[    0.000000] efi:  ESRT=0x2ff7f018  ACPI=0x2f2a5000  ACPI 2.0=0x2f2a5000  SMBIOS=0x2feb9000  TPMEventLog=0x28ea1018 
[    0.000000] random: fast init done
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI: Alienware Alienware 15 R2/0H6J09, BIOS 1.4.4 01/08/2018
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x8c2400 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: write-back
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0080000000 mask 7F80000000 uncachable
[    0.000000]   1 base 0040000000 mask 7FC0000000 uncachable
[    0.000000]   2 base 003C000000 mask 7FFC000000 uncachable
[    0.000000]   3 base 003A000000 mask 7FFE000000 uncachable
[    0.000000]   4 base 0039000000 mask 7FFF000000 uncachable
[    0.000000]   5 base 0038800000 mask 7FFF800000 uncachable
[    0.000000]   6 base 0038400000 mask 7FFFC00000 uncachable
[    0.000000]   7 disabled
[    0.000000]   8 disabled
[    0.000000]   9 disabled
[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.000000] e820: last_pfn = 0x2ffff max_arch_pfn = 0x400000000
[    0.000000] esrt: Reserving ESRT space from 0x000000002ff7f018 to 0x000000002ff7f050.
[    0.000000] Base memory trampoline at [        (ptrval)] 97000 size 28672
[    0.000000] Using GB pages for direct mapping
[    0.000000] BRK [0x2eef06000, 0x2eef06fff] PGTABLE
[    0.000000] BRK [0x2eef07000, 0x2eef07fff] PGTABLE
[    0.000000] BRK [0x2eef08000, 0x2eef08fff] PGTABLE
[    0.000000] BRK [0x2eef09000, 0x2eef09fff] PGTABLE
[    0.000000] BRK [0x2eef0a000, 0x2eef0afff] PGTABLE
[    0.000000] BRK [0x2eef0b000, 0x2eef0bfff] PGTABLE
[    0.000000] BRK [0x2eef0c000, 0x2eef0cfff] PGTABLE
[    0.000000] BRK [0x2eef0d000, 0x2eef0dfff] PGTABLE
[    0.000000] BRK [0x2eef0e000, 0x2eef0efff] PGTABLE
[    0.000000] Secure boot disabled
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x000000002F2A5000 000024 (v02 ALWARE)
[    0.000000] ACPI: XSDT 0x000000002F2A50A8 0000CC (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: FACP 0x000000002F2C8F70 00010C (v05 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: DSDT 0x000000002F2A5200 023D6B (v02 ALWARE ALIENWRE 01072009 INTL 20120913)
[    0.000000] ACPI: FACS 0x000000002F881F80 000040
[    0.000000] ACPI: APIC 0x000000002F2C9080 0000BC (v03 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: FPDT 0x000000002F2C9140 000044 (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: FIDT 0x000000002F2C9188 00009C (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: MCFG 0x000000002F2C9228 00003C (v01 ALWARE ALIENWRE 01072009 MSFT 00000097)
[    0.000000] ACPI: HPET 0x000000002F2C9268 000038 (v01 ALWARE ALIENWRE 01072009 AMI. 0005000B)
[    0.000000] ACPI: SSDT 0x000000002F2C92A0 0004B9 (v01 SataRe SataTabl 00001000 INTL 20120913)
[    0.000000] ACPI: LPIT 0x000000002F2C9760 000094 (v01 INTEL  SKL      00000000 MSFT 0000005F)
[    0.000000] ACPI: SSDT 0x000000002F2C97F8 000248 (v02 INTEL  sensrhub 00000000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2C9A40 002BAE (v02 INTEL  PtidDevc 00001000 INTL 20120913)
[    0.000000] ACPI: DBGP 0x000000002F2CC5F0 000034 (v01 INTEL           00000000 MSFT 0000005F)
[    0.000000] ACPI: DBG2 0x000000002F2CC628 000054 (v00 INTEL           00000000 MSFT 0000005F)
[    0.000000] ACPI: SSDT 0x000000002F2CC680 00069D (v02 INTEL  xh_rvp10 00000000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2CCD20 002DB7 (v02 DptfTa DptfTabl 00001000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2CFAD8 00559B (v02 SaSsdt SaSsdt   00003000 INTL 20120913)
[    0.000000] ACPI: UEFI 0x000000002F2D5078 000042 (v01                 00000000      00000000)
[    0.000000] ACPI: SSDT 0x000000002F2D50C0 000E58 (v02 CpuRef CpuSsdt  00003000 INTL 20120913)
[    0.000000] ACPI: SSDT 0x000000002F2D5F18 0000CE (v02 SgRef  SgPeg    00001000 INTL 20120913)
[    0.000000] ACPI: TPM2 0x000000002F2D5FE8 000034 (v03        Tpm2Tabl 00000001 AMI  00000000)
[    0.000000] ACPI: BGRT 0x000000002F2D6020 000038 (v01 ALWARE ALIENWRE 01072009 AMI  00010013)
[    0.000000] ACPI: SSDT 0x000000002F2D6058 001216 (v01 AmdRef AmdTabl  00001000 INTL 20120913)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000008c23fffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000001000-0x0000000000057fff]
[    0.000000]   node   0: [mem 0x0000000000059000-0x000000000009dfff]
[    0.000000]   node   0: [mem 0x0000000000100000-0x0000000028693fff]
[    0.000000]   node   0: [mem 0x00000000286a6000-0x00000000286c8fff]
[    0.000000]   node   0: [mem 0x0000000028714000-0x000000002876dfff]
[    0.000000]   node   0: [mem 0x0000000028e8d000-0x000000002e27dfff]
[    0.000000]   node   0: [mem 0x000000002fffe000-0x000000002fffefff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x00000008c23fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x00000008c23fffff]
[    0.000000] On node 0 totalpages: 8322719
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 22 pages reserved
[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 2861 pages used for memmap
[    0.000000]   DMA32 zone: 183043 pages, LIFO batch:31
[    0.000000]   Normal zone: 127120 pages used for memmap
[    0.000000]   Normal zone: 8135680 pages, LIFO batch:31
[    0.000000] Reserved but unavailable: 99 pages
[    0.000000] Reserving Intel graphics memory at [mem 0x38c00000-0x3cbfffff]
[    0.000000] ACPI: PM-Timer IO Port: 0x1808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 8 CPUs, 0 hotplug CPUs
[    0.000000] e820: [mem 0x3cc00000-0xdfffffff] available for PCI devices
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[    0.000000] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.000000] percpu: Embedded 43 pages/cpu @        (ptrval) s136984 r8192 d30952 u262144
[    0.000000] pcpu-alloc: s136984 r8192 d30952 u262144 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 8192652
[    0.000000] Kernel command line: root=/dev/nvme0n1p2 rootfstype=ext4 libahci.ignore_sss=1 init=/usr/lib/systemd/systemd systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all psmouse.synaptics_intertouch=1 
[    0.000000] log_buf_len individual max cpu contribution: 131072 bytes
[    0.000000] log_buf_len total cpu_extra contributions: 917504 bytes
[    0.000000] log_buf_len min size: 262144 bytes
[    0.000000] log_buf_len: 2097152 bytes
[    0.000000] early log buf free: 247872(94%)
[    0.000000] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes)
[    0.000000] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes)
[    0.000000] Memory: 32531188K/33290876K available (14348K kernel code, 1149K rwdata, 7020K rodata, 1152K init, 596K bss, 759688K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Kernel/User page tables isolation: enabled
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS: 4352, nr_irqs: 2048, preallocated irqs: 16
[    0.000000] spurious 8259A interrupt: IRQ7.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] ACPI: Core revision 20180105
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
[    0.000000] hpet clockevent registered
[    0.001000] APIC: Switch to symmetric I/O mode setup
[    0.003000] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.008000] tsc: Detected 2700.000 MHz processor
[    0.008000] tsc: Detected 2712.000 MHz TSC
[    0.008000] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2717868ea45, max_idle_ns: 440795316085 ns
[    0.008000] Calibrating delay loop (skipped), value calculated using timer frequency.. 5424.00 BogoMIPS (lpj=2712000)
[    0.008000] pid_max: default: 32768 minimum: 301
[    0.008000] Mount-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.008000] Mountpoint-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.008000] Disabling cpuset control group subsystem in v1 mounts
[    0.008000] Disabling cpu control group subsystem in v1 mounts
[    0.008000] Disabling cpuacct control group subsystem in v1 mounts
[    0.008000] Disabling io control group subsystem in v1 mounts
[    0.008000] Disabling memory control group subsystem in v1 mounts
[    0.008000] Disabling devices control group subsystem in v1 mounts
[    0.008000] Disabling freezer control group subsystem in v1 mounts
[    0.008000] Disabling net_cls control group subsystem in v1 mounts
[    0.008000] Disabling net_prio control group subsystem in v1 mounts
[    0.008000] Disabling hugetlb control group subsystem in v1 mounts
[    0.008000] Disabling pids control group subsystem in v1 mounts
[    0.008000] Disabling rdma control group subsystem in v1 mounts
[    0.008000] CPU: Physical Processor ID: 0
[    0.008000] CPU: Processor Core ID: 0
[    0.008000] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    0.008000] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    0.008000] mce: CPU supports 10 MCE banks
[    0.008000] CPU0: Thermal monitoring enabled (TM1)
[    0.008000] process: using mwait in idle threads
[    0.008000] Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
[    0.008000] Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
[    0.008000] Spectre V2 : Mitigation: Full generic retpoline
[    0.008000] Spectre V2 : Filling RSB on context switch
[    0.009546] Freeing SMP alternatives memory: 32K
[    0.011429] TSC deadline timer enabled
[    0.011434] smpboot: CPU0: Intel(R) Core(TM) i7-6820HK CPU @ 2.70GHz (family: 0x6, model: 0x5e, stepping: 0x3)
[    0.011469] Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR, full-width counters, Intel PMU driver.
[    0.011497] ... version:                4
[    0.011498] ... bit width:              48
[    0.011499] ... generic registers:      4
[    0.011500] ... value mask:             0000ffffffffffff
[    0.011502] ... max period:             00007fffffffffff
[    0.011503] ... fixed-purpose events:   3
[    0.011504] ... event mask:             000000070000000f
[    0.011530] Hierarchical SRCU implementation.
[    0.011612] smp: Bringing up secondary CPUs ...
[    0.011652] x86: Booting SMP configuration:
[    0.011653] .... node  #0, CPUs:      #1 #2 #3 #4 #5 #6 #7
[    0.015119] smp: Brought up 1 node, 8 CPUs
[    0.015119] smpboot: Max logical packages: 1
[    0.015119] smpboot: Total of 8 processors activated (43392.00 BogoMIPS)
[    0.016426] devtmpfs: initialized
[    0.016426] PM: Registering ACPI NVS region [mem 0x286c9000-0x286c9fff] (4096 bytes)
[    0.016426] PM: Registering ACPI NVS region [mem 0x2f2d8000-0x2f882fff] (5943296 bytes)
[    0.016426] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[    0.016426] futex hash table entries: 2048 (order: 5, 131072 bytes)
[    0.016426] NET: Registered protocol family 16
[    0.016426] audit: initializing netlink subsys (disabled)
[    0.016426] audit: type=2000 audit(1518394540.016:1): state=initialized audit_enabled=0 res=1
[    0.016426] cpuidle: using governor ladder
[    0.016426] cpuidle: using governor menu
[    0.017065] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[    0.017081] ACPI: bus type PCI registered
[    0.017082] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.017111] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.017114] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
[    0.017122] PCI: Using configuration type 1 for base access
[    0.019021] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.019021] cryptd: max_cpu_qlen set to 1000
[    0.019035] ACPI: Added _OSI(Module Device)
[    0.019037] ACPI: Added _OSI(Processor Device)
[    0.019038] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.019039] ACPI: Added _OSI(Processor Aggregator Device)
[    0.022349] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022362] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022373] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022384] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022396] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022407] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022418] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022429] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022440] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022451] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022462] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022473] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022484] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022495] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022506] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022518] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022529] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022540] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022551] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022562] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022573] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022584] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022596] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022607] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022618] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022629] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022640] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022652] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022663] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022674] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022685] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022696] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022707] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022718] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022729] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022741] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022752] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022763] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022775] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022786] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022797] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022808] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022884] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022895] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022906] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022917] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022937] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.022948] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022959] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.022970] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.022988] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.022999] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.024002] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.025018] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.025031] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.025042] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.025062] ACPI Error: Could not find/resolve named package element: LNKD (20180105/dspkginit-384)
[    0.025074] ACPI Error: Could not find/resolve named package element: LNKA (20180105/dspkginit-384)
[    0.025085] ACPI Error: Could not find/resolve named package element: LNKB (20180105/dspkginit-384)
[    0.025097] ACPI Error: Could not find/resolve named package element: LNKC (20180105/dspkginit-384)
[    0.049790] ACPI: 10 ACPI AML tables successfully acquired and loaded
[    0.053470] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[    0.057227] ACPI: Dynamic OEM Table Load:
[    0.057233] ACPI: SSDT 0xFFFF88ED5EBA4800 0005FD (v02 PmRef  Cpu0Ist  00003000 INTL 20120913)
[    0.057531] ACPI: \_PR_.CPU0: _OSC native thermal LVT Acked
[    0.058868] ACPI: Dynamic OEM Table Load:
[    0.058873] ACPI: SSDT 0xFFFF88ED5E082800 00037F (v02 PmRef  Cpu0Cst  00003001 INTL 20120913)
[    0.059768] ACPI: Dynamic OEM Table Load:
[    0.059773] ACPI: SSDT 0xFFFF88ED5EBA3800 0005AA (v02 PmRef  ApIst    00003000 INTL 20120913)
[    0.060234] ACPI: Dynamic OEM Table Load:
[    0.060238] ACPI: SSDT 0xFFFF88ED5E07A600 000119 (v02 PmRef  ApCst    00003000 INTL 20120913)
[    0.064561] ACPI: EC: EC started
[    0.064563] ACPI: EC: interrupt blocked
[    0.064909] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as first EC
[    0.064911] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x14, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.064914] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions
[    0.064915] ACPI: Interpreter enabled
[    0.064943] ACPI: (supports S0 S3 S5)
[    0.064944] ACPI: Using IOAPIC for interrupt routing
[    0.064971] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.065690] ACPI: Enabled 9 GPEs in block 00 to 7F
[    0.067590] ACPI: Power Resource [PG00] (on)
[    0.068146] ACPI: Power Resource [PG01] (on)
[    0.068459] ACPI: Power Resource [PG02] (on)
[    0.068970] ACPI: Power Resource [WRST] (off)
[    0.069216] ACPI: Power Resource [WRST] (off)
[    0.069459] ACPI: Power Resource [WRST] (off)
[    0.069704] ACPI: Power Resource [WRST] (off)
[    0.069949] ACPI: Power Resource [WRST] (off)
[    0.070188] ACPI: Power Resource [WRST] (off)
[    0.070432] ACPI: Power Resource [WRST] (off)
[    0.070676] ACPI: Power Resource [WRST] (off)
[    0.070932] ACPI: Power Resource [WRST] (off)
[    0.071178] ACPI: Power Resource [WRST] (off)
[    0.071464] ACPI: Power Resource [WRST] (off)
[    0.071717] ACPI: Power Resource [WRST] (off)
[    0.071961] ACPI: Power Resource [WRST] (off)
[    0.072205] ACPI: Power Resource [WRST] (off)
[    0.072449] ACPI: Power Resource [WRST] (off)
[    0.072691] ACPI: Power Resource [WRST] (off)
[    0.072935] ACPI: Power Resource [WRST] (off)
[    0.073181] ACPI: Power Resource [WRST] (off)
[    0.073423] ACPI: Power Resource [WRST] (off)
[    0.073664] ACPI: Power Resource [WRST] (off)
[    0.085733] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-fe])
[    0.085739] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.085766] acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
[    0.086162] PCI host bridge to bus 0000:00
[    0.086165] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.086167] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.086169] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    0.086171] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000c3fff window]
[    0.086173] pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000c7fff window]
[    0.086175] pci_bus 0000:00: root bus resource [mem 0x000c8000-0x000cbfff window]
[    0.086177] pci_bus 0000:00: root bus resource [mem 0x000cc000-0x000cffff window]
[    0.086179] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff window]
[    0.086181] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff window]
[    0.086183] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff window]
[    0.086185] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff window]
[    0.086187] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff window]
[    0.086189] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff window]
[    0.086191] pci_bus 0000:00: root bus resource [mem 0x000e8000-0x000ebfff window]
[    0.086193] pci_bus 0000:00: root bus resource [mem 0x000ec000-0x000effff window]
[    0.086195] pci_bus 0000:00: root bus resource [mem 0x3cc00000-0xdfffffff window]
[    0.086198] pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfe7fffff window]
[    0.086200] pci_bus 0000:00: root bus resource [bus 00-fe]
[    0.086202] pci_bus 0000:00: scanning bus
[    0.086207] pci 0000:00:00.0: [8086:1910] type 00 class 0x060000
[    0.086214] pci 0000:00:00.0: calling quirk_mmio_always_on+0x0/0x10
[    0.086463] pci 0000:00:01.0: [8086:1901] type 01 class 0x060400
[    0.086484] pci 0000:00:01.0: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.086498] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[    0.086500] pci 0000:00:01.0: PME# disabled
[    0.086628] pci 0000:00:02.0: [8086:191b] type 00 class 0x030000
[    0.086636] pci 0000:00:02.0: reg 0x10: [mem 0xdb000000-0xdbffffff 64bit]
[    0.086640] pci 0000:00:02.0: reg 0x18: [mem 0x70000000-0x7fffffff 64bit pref]
[    0.086644] pci 0000:00:02.0: reg 0x20: [io  0xf000-0xf03f]
[    0.086656] pci 0000:00:02.0: calling efifb_fixup_resources+0x0/0x120
[    0.086658] pci 0000:00:02.0: BAR 2: assigned to efifb
[    0.086744] pci 0000:00:04.0: [8086:1903] type 00 class 0x118000
[    0.086754] pci 0000:00:04.0: reg 0x10: [mem 0xdc620000-0xdc627fff 64bit]
[    0.086911] pci 0000:00:14.0: [8086:a12f] type 00 class 0x0c0330
[    0.086930] pci 0000:00:14.0: reg 0x10: [mem 0xdc610000-0xdc61ffff 64bit]
[    0.086986] pci 0000:00:14.0: PME# supported from D3hot D3cold
[    0.086988] pci 0000:00:14.0: PME# disabled
[    0.087081] pci 0000:00:14.2: [8086:a131] type 00 class 0x118000
[    0.087099] pci 0000:00:14.2: reg 0x10: [mem 0xdc636000-0xdc636fff 64bit]
[    0.087229] pci 0000:00:16.0: [8086:a13a] type 00 class 0x078000
[    0.087252] pci 0000:00:16.0: reg 0x10: [mem 0xdc635000-0xdc635fff 64bit]
[    0.087317] pci 0000:00:16.0: PME# supported from D3hot
[    0.087320] pci 0000:00:16.0: PME# disabled
[    0.087429] pci 0000:00:17.0: [8086:a103] type 00 class 0x010601
[    0.087443] pci 0000:00:17.0: reg 0x10: [mem 0xdc630000-0xdc631fff]
[    0.087449] pci 0000:00:17.0: reg 0x14: [mem 0xdc634000-0xdc6340ff]
[    0.087456] pci 0000:00:17.0: reg 0x18: [io  0xf090-0xf097]
[    0.087462] pci 0000:00:17.0: reg 0x1c: [io  0xf080-0xf083]
[    0.087468] pci 0000:00:17.0: reg 0x20: [io  0xf060-0xf07f]
[    0.087474] pci 0000:00:17.0: reg 0x24: [mem 0xdc633000-0xdc6337ff]
[    0.087507] pci 0000:00:17.0: PME# supported from D3hot
[    0.087509] pci 0000:00:17.0: PME# disabled
[    0.087608] pci 0000:00:1c.0: [8086:a110] type 01 class 0x060400
[    0.087643] pci 0000:00:1c.0: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.087671] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.087673] pci 0000:00:1c.0: PME# disabled
[    0.087795] pci 0000:00:1c.4: [8086:a114] type 01 class 0x060400
[    0.087826] pci 0000:00:1c.4: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.087850] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[    0.087852] pci 0000:00:1c.4: PME# disabled
[    0.087958] pci 0000:00:1c.5: [8086:a115] type 01 class 0x060400
[    0.087988] pci 0000:00:1c.5: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.088012] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[    0.088014] pci 0000:00:1c.5: PME# disabled
[    0.088122] pci 0000:00:1c.6: [8086:a116] type 01 class 0x060400
[    0.088152] pci 0000:00:1c.6: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.088177] pci 0000:00:1c.6: PME# supported from D0 D3hot D3cold
[    0.088179] pci 0000:00:1c.6: PME# disabled
[    0.088289] pci 0000:00:1d.0: [8086:a118] type 01 class 0x060400
[    0.088325] pci 0000:00:1d.0: calling pci_fixup_transparent_bridge+0x0/0x20
[    0.088355] pci 0000:00:1d.0: PME# supported from D0 D3hot D3cold
[    0.088357] pci 0000:00:1d.0: PME# disabled
[    0.088493] pci 0000:00:1f.0: [8086:a14e] type 00 class 0x060100
[    0.088679] pci 0000:00:1f.2: [8086:a121] type 00 class 0x058000
[    0.088691] pci 0000:00:1f.2: reg 0x10: [mem 0xdc62c000-0xdc62ffff]
[    0.088818] pci 0000:00:1f.3: [8086:a170] type 00 class 0x040300
[    0.088841] pci 0000:00:1f.3: reg 0x10: [mem 0xdc628000-0xdc62bfff 64bit]
[    0.088863] pci 0000:00:1f.3: reg 0x20: [mem 0xdc600000-0xdc60ffff 64bit]
[    0.088905] pci 0000:00:1f.3: PME# supported from D3hot D3cold
[    0.088908] pci 0000:00:1f.3: PME# disabled
[    0.089051] pci 0000:00:1f.4: [8086:a123] type 00 class 0x0c0500
[    0.089110] pci 0000:00:1f.4: reg 0x10: [mem 0xdc632000-0xdc6320ff 64bit]
[    0.089179] pci 0000:00:1f.4: reg 0x20: [io  0xf040-0xf05f]
[    0.089336] pci_bus 0000:00: fixups for bus
[    0.089338] pci 0000:00:01.0: scanning [bus 01-01] behind bridge, pass 0
[    0.089359] pci_bus 0000:01: scanning bus
[    0.089367] pci 0000:01:00.0: [1002:6921] type 00 class 0x038000
[    0.089382] pci 0000:01:00.0: reg 0x10: [mem 0xb0000000-0xbfffffff 64bit pref]
[    0.089388] pci 0000:01:00.0: reg 0x18: [mem 0xc0000000-0xc01fffff 64bit pref]
[    0.089392] pci 0000:01:00.0: reg 0x20: [io  0xe000-0xe0ff]
[    0.089395] pci 0000:01:00.0: reg 0x24: [mem 0xdc500000-0xdc53ffff]
[    0.089399] pci 0000:01:00.0: reg 0x30: [mem 0xdc540000-0xdc55ffff pref]
[    0.089410] pci 0000:01:00.0: calling efifb_fixup_resources+0x0/0x120
[    0.089439] pci 0000:01:00.0: supports D1 D2
[    0.089440] pci 0000:01:00.0: PME# supported from D1 D2 D3hot D3cold
[    0.089442] pci 0000:01:00.0: PME# disabled
[    0.092034] pci_bus 0000:01: fixups for bus
[    0.092035] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.092052] pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
[    0.092053] pci 0000:00:01.0:   bridge window [mem 0xdc500000-0xdc5fffff]
[    0.092056] pci 0000:00:01.0:   bridge window [mem 0xb0000000-0xc01fffff 64bit pref]
[    0.092057] pci_bus 0000:01: bus scan returning with max=01
[    0.092060] pci 0000:00:1c.0: scanning [bus 02-3a] behind bridge, pass 0
[    0.092138] acpiphp_glue: get_slot_status() reading function 0 dvid
[    0.092142] pci_bus 0000:02: got 0x0 dvid 0xffffffff
[    0.092143] acpiphp_glue: get_slot_status() returns: 0x0
[    0.092144] acpiphp_glue: get_slot_status() reading function 0 dvid
[    0.092147] pci_bus 0000:02: got 0x0 dvid 0xffffffff
[    0.092148] acpiphp_glue: get_slot_status() returns: 0x0
[    0.092152] pci_bus 0000:02: dev 00, created physical slot 1
[    0.092155] acpiphp: Slot [1] registered
[    0.092158] pci_bus 0000:02: scanning bus
[    0.092160] pci_bus 0000:02: fixups for bus
[    0.092161] pci 0000:00:1c.0: PCI bridge to [bus 02-3a]
[    0.092165] pci 0000:00:1c.0:   bridge window [mem 0xc4000000-0xda0fffff]
[    0.092169] pci 0000:00:1c.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[    0.092170] pci_bus 0000:02: bus scan returning with max=02
[    0.092173] pci 0000:00:1c.4: scanning [bus 3b-3b] behind bridge, pass 0
[    0.092233] pci_bus 0000:3b: scanning bus
[    0.092247] pci 0000:3b:00.0: [1969:e0a1] type 00 class 0x020000
[    0.092276] pci 0000:3b:00.0: reg 0x10: [mem 0xdc400000-0xdc43ffff 64bit]
[    0.092286] pci 0000:3b:00.0: reg 0x18: [io  0xd000-0xd07f]
[    0.092386] pci 0000:3b:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.092389] pci 0000:3b:00.0: PME# disabled
[    0.095015] pci_bus 0000:3b: fixups for bus
[    0.095016] pci 0000:00:1c.4: PCI bridge to [bus 3b]
[    0.095020] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[    0.095022] pci 0000:00:1c.4:   bridge window [mem 0xdc400000-0xdc4fffff]
[    0.095026] pci_bus 0000:3b: bus scan returning with max=3b
[    0.095029] pci 0000:00:1c.5: scanning [bus 3c-3c] behind bridge, pass 0
[    0.095149] pci_bus 0000:3c: scanning bus
[    0.095213] pci 0000:3c:00.0: [168c:003e] type 00 class 0x028000
[    0.095390] pci 0000:3c:00.0: reg 0x10: [mem 0xdc000000-0xdc1fffff 64bit]
[    0.095877] pci 0000:3c:00.0: PME# supported from D0 D3hot D3cold
[    0.095928] pci 0000:3c:00.0: PME# disabled
[    0.099115] pci_bus 0000:3c: fixups for bus
[    0.099117] pci 0000:00:1c.5: PCI bridge to [bus 3c]
[    0.099122] pci 0000:00:1c.5:   bridge window [mem 0xdc000000-0xdc1fffff]
[    0.099125] pci_bus 0000:3c: bus scan returning with max=3c
[    0.099128] pci 0000:00:1c.6: scanning [bus 3d-3d] behind bridge, pass 0
[    0.099203] pci_bus 0000:3d: scanning bus
[    0.099228] pci 0000:3d:00.0: [10ec:5227] type 00 class 0xff0000
[    0.099255] pci 0000:3d:00.0: reg 0x10: [mem 0xdc300000-0xdc300fff]
[    0.099372] pci 0000:3d:00.0: supports D1 D2
[    0.099374] pci 0000:3d:00.0: PME# supported from D1 D2 D3hot D3cold
[    0.099381] pci 0000:3d:00.0: PME# disabled
[    0.102023] pci_bus 0000:3d: fixups for bus
[    0.102024] pci 0000:00:1c.6: PCI bridge to [bus 3d]
[    0.102029] pci 0000:00:1c.6:   bridge window [mem 0xdc300000-0xdc3fffff]
[    0.102033] pci_bus 0000:3d: bus scan returning with max=3d
[    0.102036] pci 0000:00:1d.0: scanning [bus 3e-3e] behind bridge, pass 0
[    0.102169] pci_bus 0000:3e: scanning bus
[    0.102181] pci 0000:3e:00.0: [144d:a802] type 00 class 0x010802
[    0.102205] pci 0000:3e:00.0: reg 0x10: [mem 0xdc200000-0xdc203fff 64bit]
[    0.102213] pci 0000:3e:00.0: reg 0x18: [io  0xc000-0xc0ff]
[    0.105079] pci_bus 0000:3e: fixups for bus
[    0.105080] pci 0000:00:1d.0: PCI bridge to [bus 3e]
[    0.105084] pci 0000:00:1d.0:   bridge window [io  0xc000-0xcfff]
[    0.105087] pci 0000:00:1d.0:   bridge window [mem 0xdc200000-0xdc2fffff]
[    0.105090] pci_bus 0000:3e: bus scan returning with max=3e
[    0.105093] pci 0000:00:01.0: scanning [bus 01-01] behind bridge, pass 1
[    0.105097] pci 0000:00:1c.0: scanning [bus 02-3a] behind bridge, pass 1
[    0.105102] pci 0000:00:1c.4: scanning [bus 3b-3b] behind bridge, pass 1
[    0.105106] pci 0000:00:1c.5: scanning [bus 3c-3c] behind bridge, pass 1
[    0.105110] pci 0000:00:1c.6: scanning [bus 3d-3d] behind bridge, pass 1
[    0.105115] pci 0000:00:1d.0: scanning [bus 3e-3e] behind bridge, pass 1
[    0.105118] pci_bus 0000:00: bus scan returning with max=3e
[    0.105119] pci_bus 0000:00: on NUMA node 0
[    0.108712] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108752] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *10 11 12 14 15)
[    0.108790] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108828] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108865] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108902] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108939] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.108976] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 *11 12 14 15)
[    0.109332] ACPI: EC: interrupt unblocked
[    0.109345] ACPI: EC: event unblocked
[    0.109356] ACPI: \_SB_.PCI0.LPCB.EC0_: GPE=0x14, EC_CMD/EC_SC=0x66, EC_DATA=0x62
[    0.109359] ACPI: \_SB_.PCI0.LPCB.EC0_: Used as boot DSDT EC to handle transactions and events
[    0.109389] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[    0.109389] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    0.109389] pci 0000:00:02.0: vgaarb: bridge control possible
[    0.109389] vgaarb: loaded
[    0.109389] SCSI subsystem initialized
[    0.109389] libata version 3.00 loaded.
[    0.109389] ACPI: bus type USB registered
[    0.109389] usbcore: registered new interface driver usbfs
[    0.109389] usbcore: registered new interface driver hub
[    0.109389] usbcore: registered new device driver usb
[    0.109389] Linux video capture interface: v2.00
[    0.109389] Registered efivars operations
[    0.116952] Advanced Linux Sound Architecture Driver Initialized.
[    0.116961] PCI: Using ACPI for IRQ routing
[    0.139848] PCI: pci_cache_line_size set to 64 bytes
[    0.139855] pci 0000:00:02.0: BAR 0: reserving [mem 0xdb000000-0xdbffffff flags 0x140204] (d=0, p=0)
[    0.139856] pci 0000:00:02.0: BAR 2: reserving [mem 0x70000000-0x7fffffff flags 0x14220c] (d=0, p=0)
[    0.139858] pci 0000:00:02.0: BAR 4: reserving [io  0xf000-0xf03f flags 0x40101] (d=0, p=0)
[    0.139860] pci 0000:00:14.0: BAR 0: reserving [mem 0xdc610000-0xdc61ffff flags 0x140204] (d=0, p=0)
[    0.139862] pci 0000:00:14.2: BAR 0: reserving [mem 0xdc636000-0xdc636fff flags 0x140204] (d=0, p=0)
[    0.139866] pci 0000:00:17.0: BAR 0: reserving [mem 0xdc630000-0xdc631fff flags 0x40200] (d=0, p=0)
[    0.139867] pci 0000:00:17.0: BAR 1: reserving [mem 0xdc634000-0xdc6340ff flags 0x40200] (d=0, p=0)
[    0.139868] pci 0000:00:17.0: BAR 2: reserving [io  0xf090-0xf097 flags 0x40101] (d=0, p=0)
[    0.139869] pci 0000:00:17.0: BAR 3: reserving [io  0xf080-0xf083 flags 0x40101] (d=0, p=0)
[    0.139870] pci 0000:00:17.0: BAR 4: reserving [io  0xf060-0xf07f flags 0x40101] (d=0, p=0)
[    0.139871] pci 0000:00:17.0: BAR 5: reserving [mem 0xdc633000-0xdc6337ff flags 0x40200] (d=0, p=0)
[    0.139875] pci 0000:3b:00.0: BAR 0: reserving [mem 0xdc400000-0xdc43ffff flags 0x140204] (d=0, p=0)
[    0.139877] pci 0000:3b:00.0: BAR 2: reserving [io  0xd000-0xd07f flags 0x40101] (d=0, p=0)
[    0.139994] pci 0000:3e:00.0: BAR 0: reserving [mem 0xdc200000-0xdc203fff flags 0x140204] (d=0, p=0)
[    0.139995] pci 0000:3e:00.0: BAR 2: reserving [io  0xc000-0xc0ff flags 0x40101] (d=0, p=0)
[    0.140002] pci 0000:00:1f.4: BAR 0: reserving [mem 0xdc632000-0xdc6320ff flags 0x140204] (d=0, p=0)
[    0.140003] pci 0000:00:1f.4: BAR 4: reserving [io  0xf040-0xf05f flags 0x40101] (d=0, p=0)
[    0.140006] pci 0000:01:00.0: BAR 0: reserving [mem 0xb0000000-0xbfffffff flags 0x14220c] (d=1, p=1)
[    0.140007] pci 0000:01:00.0: BAR 2: reserving [mem 0xc0000000-0xc01fffff flags 0x14220c] (d=1, p=1)
[    0.140008] pci 0000:01:00.0: BAR 4: reserving [io  0xe000-0xe0ff flags 0x40101] (d=1, p=1)
[    0.140009] pci 0000:01:00.0: BAR 5: reserving [mem 0xdc500000-0xdc53ffff flags 0x40200] (d=1, p=1)
[    0.140011] pci 0000:00:04.0: BAR 0: reserving [mem 0xdc620000-0xdc627fff flags 0x140204] (d=1, p=1)
[    0.140015] pci 0000:00:16.0: BAR 0: reserving [mem 0xdc635000-0xdc635fff flags 0x140204] (d=1, p=1)
[    0.140067] pci 0000:3c:00.0: BAR 0: reserving [mem 0xdc000000-0xdc1fffff flags 0x140204] (d=1, p=1)
[    0.140075] pci 0000:3d:00.0: BAR 0: reserving [mem 0xdc300000-0xdc300fff flags 0x40200] (d=1, p=1)
[    0.140080] pci 0000:00:1f.2: BAR 0: reserving [mem 0xdc62c000-0xdc62ffff flags 0x40200] (d=1, p=1)
[    0.140082] pci 0000:00:1f.3: BAR 0: reserving [mem 0xdc628000-0xdc62bfff flags 0x140204] (d=1, p=1)
[    0.140084] pci 0000:00:1f.3: BAR 4: reserving [mem 0xdc600000-0xdc60ffff flags 0x140204] (d=1, p=1)
[    0.140089] e820: reserve RAM buffer [mem 0x00058000-0x0005ffff]
[    0.140090] e820: reserve RAM buffer [mem 0x0009e000-0x0009ffff]
[    0.140090] e820: reserve RAM buffer [mem 0x260e6018-0x27ffffff]
[    0.140091] e820: reserve RAM buffer [mem 0x260f7018-0x27ffffff]
[    0.140092] e820: reserve RAM buffer [mem 0x28694000-0x2bffffff]
[    0.140093] e820: reserve RAM buffer [mem 0x286c9000-0x2bffffff]
[    0.140093] e820: reserve RAM buffer [mem 0x2876e000-0x2bffffff]
[    0.140094] e820: reserve RAM buffer [mem 0x2e27e000-0x2fffffff]
[    0.140095] e820: reserve RAM buffer [mem 0x2ffff000-0x2fffffff]
[    0.140096] e820: reserve RAM buffer [mem 0x8c2400000-0x8c3ffffff]
[    0.140140] Bluetooth: Core ver 2.22
[    0.140144] NET: Registered protocol family 31
[    0.140145] Bluetooth: HCI device and connection manager initialized
[    0.140147] Bluetooth: HCI socket layer initialized
[    0.140148] Bluetooth: L2CAP socket layer initialized
[    0.140152] Bluetooth: SCO socket layer initialized
[    0.140207] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found
[    0.140321] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[    0.140325] hpet0: 8 comparators, 64-bit 24.000000 MHz counter
[    0.142011] clocksource: Switched to clocksource tsc-early
[    0.147499] FS-Cache: Loaded
[    0.147524] CacheFiles: Loaded
[    0.147531] pnp: PnP ACPI init
[    0.147650] pnp 00:00: Plug and Play ACPI device, IDs PNP0303 (active)
[    0.147666] pnp 00:01: Plug and Play ACPI device, IDs DLL0708 PNP0f13 (active)
[    0.147762] system 00:02: [io  0x0680-0x069f] has been reserved
[    0.147764] system 00:02: [io  0xffff] has been reserved
[    0.147766] system 00:02: [io  0xffff] has been reserved
[    0.147768] system 00:02: [io  0xffff] has been reserved
[    0.147770] system 00:02: [io  0x1800-0x18fe] has been reserved
[    0.147772] system 00:02: [io  0x164e-0x164f] has been reserved
[    0.147776] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.147841] system 00:03: [io  0x0800-0x087f] has been reserved
[    0.147844] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.147855] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.147876] system 00:05: [io  0x1854-0x1857] has been reserved
[    0.147880] system 00:05: Plug and Play ACPI device, IDs INT3f0d PNP0c02 (active)
[    0.150179] system 00:06: [mem 0xfed10000-0xfed17fff] has been reserved
[    0.150181] system 00:06: [mem 0xfed18000-0xfed18fff] has been reserved
[    0.150183] system 00:06: [mem 0xfed19000-0xfed19fff] has been reserved
[    0.150186] system 00:06: [mem 0xe0000000-0xefffffff] has been reserved
[    0.150188] system 00:06: [mem 0xfed20000-0xfed3ffff] has been reserved
[    0.150190] system 00:06: [mem 0xfed90000-0xfed93fff] has been reserved
[    0.150192] system 00:06: [mem 0xfed45000-0xfed8ffff] has been reserved
[    0.150194] system 00:06: [mem 0xff000000-0xffffffff] has been reserved
[    0.150196] system 00:06: [mem 0xfee00000-0xfeefffff] could not be reserved
[    0.150199] system 00:06: [mem 0xdffe0000-0xdfffffff] has been reserved
[    0.150202] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.150228] system 00:07: [mem 0xfd000000-0xfdabffff] has been reserved
[    0.150230] system 00:07: [mem 0xfdad0000-0xfdadffff] has been reserved
[    0.150233] system 00:07: [mem 0xfdb00000-0xfdffffff] has been reserved
[    0.150235] system 00:07: [mem 0xfe000000-0xfe01ffff] could not be reserved
[    0.150237] system 00:07: [mem 0xfe036000-0xfe03bfff] has been reserved
[    0.150239] system 00:07: [mem 0xfe03d000-0xfe3fffff] has been reserved
[    0.150241] system 00:07: [mem 0xfe410000-0xfe7fffff] has been reserved
[    0.150244] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.151093] system 00:08: [mem 0xfdaf0000-0xfdafffff] has been reserved
[    0.151096] system 00:08: [mem 0xfdae0000-0xfdaeffff] has been reserved
[    0.151099] system 00:08: [mem 0xfdac0000-0xfdacffff] has been reserved
[    0.151102] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.151780] pnp: PnP ACPI: found 9 devices
[    0.157104] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.157117] pci 0000:00:1c.0: bridge window [io  0x1000-0x0fff] to [bus 02-3a] add_size 1000
[    0.157136] pci 0000:00:1c.0: BAR 13: assigned [io  0x2000-0x2fff]
[    0.157139] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.157141] pci 0000:00:01.0:   bridge window [io  0xe000-0xefff]
[    0.157144] pci 0000:00:01.0:   bridge window [mem 0xdc500000-0xdc5fffff]
[    0.157147] pci 0000:00:01.0:   bridge window [mem 0xb0000000-0xc01fffff 64bit pref]
[    0.157151] pci 0000:00:1c.0: PCI bridge to [bus 02-3a]
[    0.157153] pci 0000:00:1c.0:   bridge window [io  0x2000-0x2fff]
[    0.157157] pci 0000:00:1c.0:   bridge window [mem 0xc4000000-0xda0fffff]
[    0.157160] pci 0000:00:1c.0:   bridge window [mem 0x80000000-0xa1ffffff 64bit pref]
[    0.157165] pci 0000:00:1c.4: PCI bridge to [bus 3b]
[    0.157168] pci 0000:00:1c.4:   bridge window [io  0xd000-0xdfff]
[    0.157171] pci 0000:00:1c.4:   bridge window [mem 0xdc400000-0xdc4fffff]
[    0.157177] pci 0000:00:1c.5: PCI bridge to [bus 3c]
[    0.157180] pci 0000:00:1c.5:   bridge window [mem 0xdc000000-0xdc1fffff]
[    0.157186] pci 0000:00:1c.6: PCI bridge to [bus 3d]
[    0.157189] pci 0000:00:1c.6:   bridge window [mem 0xdc300000-0xdc3fffff]
[    0.157195] pci 0000:00:1d.0: PCI bridge to [bus 3e]
[    0.157197] pci 0000:00:1d.0:   bridge window [io  0xc000-0xcfff]
[    0.157201] pci 0000:00:1d.0:   bridge window [mem 0xdc200000-0xdc2fffff]
[    0.157208] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.157209] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.157210] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[    0.157211] pci_bus 0000:00: resource 7 [mem 0x000c0000-0x000c3fff window]
[    0.157212] pci_bus 0000:00: resource 8 [mem 0x000c4000-0x000c7fff window]
[    0.157213] pci_bus 0000:00: resource 9 [mem 0x000c8000-0x000cbfff window]
[    0.157214] pci_bus 0000:00: resource 10 [mem 0x000cc000-0x000cffff window]
[    0.157214] pci_bus 0000:00: resource 11 [mem 0x000d0000-0x000d3fff window]
[    0.157215] pci_bus 0000:00: resource 12 [mem 0x000d4000-0x000d7fff window]
[    0.157216] pci_bus 0000:00: resource 13 [mem 0x000d8000-0x000dbfff window]
[    0.157217] pci_bus 0000:00: resource 14 [mem 0x000dc000-0x000dffff window]
[    0.157218] pci_bus 0000:00: resource 15 [mem 0x000e0000-0x000e3fff window]
[    0.157219] pci_bus 0000:00: resource 16 [mem 0x000e4000-0x000e7fff window]
[    0.157220] pci_bus 0000:00: resource 17 [mem 0x000e8000-0x000ebfff window]
[    0.157221] pci_bus 0000:00: resource 18 [mem 0x000ec000-0x000effff window]
[    0.157222] pci_bus 0000:00: resource 19 [mem 0x3cc00000-0xdfffffff window]
[    0.157223] pci_bus 0000:00: resource 20 [mem 0xfd000000-0xfe7fffff window]
[    0.157224] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
[    0.157225] pci_bus 0000:01: resource 1 [mem 0xdc500000-0xdc5fffff]
[    0.157226] pci_bus 0000:01: resource 2 [mem 0xb0000000-0xc01fffff 64bit pref]
[    0.157227] pci_bus 0000:02: resource 0 [io  0x2000-0x2fff]
[    0.157228] pci_bus 0000:02: resource 1 [mem 0xc4000000-0xda0fffff]
[    0.157229] pci_bus 0000:02: resource 2 [mem 0x80000000-0xa1ffffff 64bit pref]
[    0.157229] pci_bus 0000:3b: resource 0 [io  0xd000-0xdfff]
[    0.157230] pci_bus 0000:3b: resource 1 [mem 0xdc400000-0xdc4fffff]
[    0.157231] pci_bus 0000:3c: resource 1 [mem 0xdc000000-0xdc1fffff]
[    0.157232] pci_bus 0000:3d: resource 1 [mem 0xdc300000-0xdc3fffff]
[    0.157233] pci_bus 0000:3e: resource 0 [io  0xc000-0xcfff]
[    0.157234] pci_bus 0000:3e: resource 1 [mem 0xdc200000-0xdc2fffff]
[    0.157336] NET: Registered protocol family 2
[    0.157398] tcp_listen_portaddr_hash hash table entries: 16384 (order: 6, 262144 bytes)
[    0.157427] TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.157640] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.157726] TCP: Hash tables configured (established 262144 bind 65536)
[    0.157746] UDP hash table entries: 16384 (order: 7, 524288 bytes)
[    0.157791] UDP-Lite hash table entries: 16384 (order: 7, 524288 bytes)
[    0.157865] NET: Registered protocol family 1
[    0.157919] pci 0000:00:02.0: calling pci_fixup_video+0x0/0x110
[    0.157922] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    0.157929] pci 0000:00:14.0: calling quirk_usb_early_handoff+0x0/0x690
[    0.158587] pci 0000:3b:00.0: calling quirk_blacklist_vpd+0x0/0x30
[    0.158700] PCI: CLS 0 bytes, default 64
[    0.158718] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.158721] software IO TLB [mem 0x220e6000-0x260e6000] (64MB) mapped at [000000006e6c8cce-00000000e12cbca7]
[    0.158790] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms ovfl timer
[    0.158792] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[    0.158794] RAPL PMU: hw unit of domain package 2^-14 Joules
[    0.158795] RAPL PMU: hw unit of domain dram 2^-14 Joules
[    0.158796] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[    0.158797] RAPL PMU: hw unit of domain psys 2^-14 Joules
[    0.158810] skl_uncore 0000:00:00.0: runtime IRQ mapping not provided by arch
[    0.158882] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2717868ea45, max_idle_ns: 440795316085 ns
[    0.158890] clocksource: Switched to clocksource tsc
[    0.159833] Initialise system trusted keyrings
[    0.159848] workingset: timestamp_bits=46 max_order=23 bucket_order=0
[    0.160986] FS-Cache: Netfs 'cifs' registered for caching
[    0.161032] Key type cifs.idmap registered
[    0.161045] fuse init (API version 7.26)
[    0.161684] NET: Registered protocol family 38
[    0.161711] Key type asymmetric registered
[    0.161713] Asymmetric key parser 'x509' registered
[    0.161730] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    0.161732] io scheduler noop registered
[    0.161756] io scheduler cfq registered (default)
[    0.161847] pcieport 0000:00:01.0: runtime IRQ mapping not provided by arch
[    0.161964] pcieport 0000:00:1c.0: runtime IRQ mapping not provided by arch
[    0.162061] pcieport 0000:00:1c.4: runtime IRQ mapping not provided by arch
[    0.162145] pcieport 0000:00:1c.5: runtime IRQ mapping not provided by arch
[    0.162232] pcieport 0000:00:1c.6: runtime IRQ mapping not provided by arch
[    0.162321] pcieport 0000:00:1d.0: runtime IRQ mapping not provided by arch
[    0.162434] intel_idle: MWAIT substates: 0x11142120
[    0.162434] intel_idle: v0.4.1 model 0x5E
[    0.162646] intel_idle: lapic_timer_reliable_states 0xffffffff
[    0.162711] ACPI: AC Adapter [ACAD] (on-line)
[    0.162749] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:40/PNP0C0D:00/input/input0
[    0.162755] ACPI: Lid Switch [LID0]
[    0.162777] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[    0.162786] ACPI: Power Button [PWRB]
[    0.162803] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[    0.162813] ACPI: Power Button [PWRF]
[    0.180112] ACPI: Battery Slot [BAT1] (battery present)
[    0.180380] Non-volatile memory driver v1.3
[    0.180532] Linux agpgart interface v0.103
[    0.180559] [drm] amdgpu kernel modesetting enabled.
[    0.180566] vga_switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle
[    0.180634] ATPX version 1, functions 0x00000033
[    0.180731] ATPX Hybrid Graphics
[    0.180740] amdgpu 0000:01:00.0: runtime IRQ mapping not provided by arch
[    0.180754] amdgpu 0000:01:00.0: enabling device (0000 -> 0003)
[    0.180949] [drm] initializing kernel modesetting (TONGA 0x1002:0x6921 0x1028:0x0708 0x00).
[    0.180956] [drm] register mmio base: 0xDC500000
[    0.180957] [drm] register mmio size: 262144
[    0.180966] [drm] probing gen 2 caps for device 8086:1901 = 261ad03/e
[    0.180968] [drm] probing mlw for device 8086:1901 = 261ad03
[    0.180981] [drm] VCE enabled in physical mode
[    0.207246] ATOM BIOS: BR46576.001
[    0.207255] [drm] GPU posting now...
[    0.213089] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
[    0.213097] amdgpu 0000:01:00.0: VRAM: 4096M 0x000000F400000000 - 0x000000F4FFFFFFFF (4096M used)
[    0.213100] amdgpu 0000:01:00.0: GTT: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
[    0.213103] [drm] Detected VRAM RAM=4096M, BAR=256M
[    0.213105] [drm] RAM width 256bits GDDR5
[    0.213331] [TTM] Zone  kernel: Available graphics memory: 16309014 kiB
[    0.213333] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[    0.213334] [TTM] Initializing pool allocator
[    0.213337] [TTM] Initializing DMA pool allocator
[    0.213369] [drm] amdgpu: 4096M of VRAM memory ready
[    0.213371] [drm] amdgpu: 4096M of GTT memory ready.
[    0.213395] [drm] GART: num cpu pages 262144, num gpu pages 262144
[    0.213900] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[    0.215680] [drm] Found UVD firmware Version: 1.65 Family ID: 10
[    0.215957] [drm] Found VCE firmware Version: 52.8 Binary ID: 3
[    0.216177] amdgpu 0000:01:00.0: enabling bus mastering
[    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
[    0.265879] [drm] Display Core initialized with v3.1.27!
[    0.265901] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.265902] [drm] Driver supports precise vblank timestamp query.
[    0.315206] [drm] UVD initialized successfully.
[    0.526289] [drm] VCE initialized successfully.
[    0.632410] [drm] Initialized amdgpu 3.23.0 20150101 for 0000:01:00.0 on minor 0
[    0.632434] i915 0000:00:02.0: runtime IRQ mapping not provided by arch
[    0.633145] [drm] Replacing VGA console driver
[    0.634230] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.634232] [drm] Driver supports precise vblank timestamp query.
[    0.634596] vga_switcheroo: enabled
[    0.634626] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    0.635788] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin (v1.27)
[    0.642100] [drm] Initialized i915 1.6.0 20171222 for 0000:00:02.0 on minor 1
[    0.643782] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[    0.644007] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[    0.645039] loop: module loaded
[    0.645055] mei_me 0000:00:16.0: runtime IRQ mapping not provided by arch
[    0.645062] mei_me 0000:00:16.0: enabling device (0000 -> 0002)
[    0.645156] mei_me 0000:00:16.0: enabling bus mastering
[    0.645169] nvme 0000:3e:00.0: runtime IRQ mapping not provided by arch
[    0.645196] nvme nvme0: pci function 0000:3e:00.0
[    0.648887] ahci 0000:00:17.0: runtime IRQ mapping not provided by arch
[    0.648929] ahci 0000:00:17.0: version 3.0
[    0.659125] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x2 impl SATA mode
[    0.659131] ahci 0000:00:17.0: flags: 64bit ncq sntf pm led clo only pio slum part ems deso sadm sds apst 
[    0.659384] scsi host0: ahci
[    0.659651] scsi host1: ahci
[    0.659731] ata1: DUMMY
[    0.659733] ata2: SATA max UDMA/133 abar m2048@0xdc633000 port 0xdc633180 irq 124
[    0.659782] tun: Universal TUN/TAP device driver, 1.6
[    0.659839] alx 0000:3b:00.0: runtime IRQ mapping not provided by arch
[    0.661920] fbcon: inteldrmfb (fb0) is primary device
[    0.670598] alx 0000:3b:00.0 eth0: Qualcomm Atheros AR816x/AR817x Ethernet [20:47:47:db:e8:9b]
[    0.670614] ath10k_pci 0000:3c:00.0: runtime IRQ mapping not provided by arch
[    0.671046] ath10k_pci 0000:3c:00.0: enabling device (0000 -> 0002)
[    0.671250] ath10k_pci 0000:3c:00.0: enabling bus mastering
[    0.671920] ath10k_pci 0000:3c:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[    0.757546]  nvme0n1: p1 p2 p3
[    0.772579] xhci_hcd 0000:00:14.0: runtime IRQ mapping not provided by arch
[    0.772739] xhci_hcd 0000:00:14.0: enabling bus mastering
[    0.772742] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    0.772747] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[    0.773807] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x00109810
[    0.773811] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[    0.773899] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.773900] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.773901] usb usb1: Product: xHCI Host Controller
[    0.773902] usb usb1: Manufacturer: Linux 4.15.0-tip+ xhci-hcd
[    0.773902] usb usb1: SerialNumber: 0000:00:14.0
[    0.774088] hub 1-0:1.0: USB hub found
[    0.774103] hub 1-0:1.0: 16 ports detected
[    0.774823] xhci_hcd 0000:00:14.0: xHCI Host Controller
[    0.774825] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[    0.774846] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[    0.774848] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.774848] usb usb2: Product: xHCI Host Controller
[    0.774849] usb usb2: Manufacturer: Linux 4.15.0-tip+ xhci-hcd
[    0.774850] usb usb2: SerialNumber: 0000:00:14.0
[    0.774997] hub 2-0:1.0: USB hub found
[    0.775010] hub 2-0:1.0: 8 ports detected
[    0.775332] usb: port power management may be unreliable
[    0.775497] usbcore: registered new interface driver cdc_acm
[    0.775497] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    0.775505] usbcore: registered new interface driver usb-storage
[    0.775533] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    0.802408] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.802410] serio: i8042 AUX port at 0x60,0x64 irq 12
[    0.802558] mousedev: PS/2 mouse device common for all mice
[    0.802974] usbcore: registered new interface driver synaptics_usb
[    0.803064] rtc_cmos 00:04: RTC can wake from S4
[    0.803447] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
[    0.803542] rtc_cmos 00:04: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    0.803547] i2c /dev entries driver
[    0.803766] i801_smbus 0000:00:1f.4: runtime IRQ mapping not provided by arch
[    0.803857] i801_smbus 0000:00:1f.4: SPD Write Disable is set
[    0.803875] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt
[    0.808131] usbcore: registered new interface driver uvcvideo
[    0.808131] USB Video Class driver (1.1.1)
[    0.810048] proc_thermal 0000:00:04.0: runtime IRQ mapping not provided by arch
[    0.810069] proc_thermal 0000:00:04.0: enabling device (0000 -> 0002)
[    0.810751] intel_pch_thermal 0000:00:14.2: runtime IRQ mapping not provided by arch
[    0.810841] usbcore: registered new interface driver btusb
[    0.810843] intel_pstate: Intel P-state driver initializing
[    0.811416] intel_pstate: HWP enabled
[    0.811528] EFI Variables Facility v0.08 2004-May-17
[    0.813725] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[    0.819844] pstore: using lz4 compression
[    0.819845] pstore: Registered efi as persistent store backend
[    0.819928] usbcore: registered new interface driver usbhid
[    0.819928] usbhid: USB HID core driver
[    0.821056] intel_rapl: Found RAPL domain package
[    0.821057] intel_rapl: Found RAPL domain core
[    0.821057] intel_rapl: Found RAPL domain uncore
[    0.821058] intel_rapl: Found RAPL domain dram
[    0.821759] snd_hda_intel 0000:00:1f.3: runtime IRQ mapping not provided by arch
[    0.821773] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[    0.822158] Initializing XFRM netlink socket
[    0.822219] NET: Registered protocol family 10
[    0.822440] Segment Routing with IPv6
[    0.822459] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.822515] NET: Registered protocol family 17
[    0.822517] NET: Registered protocol family 15
[    0.822597] Bluetooth: RFCOMM TTY layer initialized
[    0.822615] Bluetooth: RFCOMM socket layer initialized
[    0.822617] Bluetooth: RFCOMM ver 1.11
[    0.822617] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    0.822618] Bluetooth: BNEP filters: protocol multicast
[    0.822619] Bluetooth: BNEP socket layer initialized
[    0.822619] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    0.822620] Bluetooth: HIDP socket layer initialized
[    0.822899] Key type dns_resolver registered
[    0.823294] microcode: sig=0x506e3, pf=0x20, revision=0xc2
[    0.823522] microcode: Microcode Update Driver: v2.2.
[    0.823525] AVX2 version of gcm_enc/dec engaged.
[    0.823525] AES CTR mode by8 optimization enabled
[    0.823697] sched_clock: Marking stable (823695302, 0)->(822474002, 1221300)
[    0.823859] registered taskstats version 1
[    0.823859] Loading compiled-in X.509 certificates
[    0.824682] input: Dell WMI hotkeys as /devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input7
[    0.824797] rtc_cmos 00:04: setting system clock to 2018-02-12 00:15:41 UTC (1518394541)
[    0.824802] ALSA device list:
[    0.824803]   No soundcards found.
[    0.883536] ath10k_pci 0000:3c:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3c:00.0.bin failed with error -2
[    0.883542] ath10k_pci 0000:3c:00.0: Direct firmware load for ath10k/cal-pci-0000:3c:00.0.bin failed with error -2
[    0.883546] ath10k_pci 0000:3c:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
[    0.883548] ath10k_pci 0000:3c:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
[    0.884076] ath10k_pci 0000:3c:00.0: firmware ver RM.4.4.1.c1-00037-QCARMSWP-1 api 6 features wowlan,ignore-otp crc32 0845d1b2
[    0.947214] ath10k_pci 0000:3c:00.0: board_file api 2 bmi_id N/A crc32 414716a3
[    0.965155] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    0.965558] ata2.00: ATA-9: M4-CT512M4SSD2, 0309, max UDMA/100
[    0.965559] ata2.00: 1000215216 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    0.966032] ata2.00: configured for UDMA/100
[    1.098045] usb 1-4: new full-speed USB device number 2 using xhci_hcd
[    1.186861] psmouse serio1: synaptics: queried max coordinates: x [..5668], y [..4756]
[    1.216241] psmouse serio1: synaptics: queried min coordinates: x [1274..], y [1098..]
[    1.216242] psmouse serio1: synaptics: Trying to set up SMBus access
[    1.219747] rmi4_smbus 6-002c: registering SMbus-connected sensor
[    1.224816] usb 1-4: config 1 interface 0 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[    1.225630] usb 1-4: New USB device found, idVendor=187c, idProduct=0528
[    1.225649] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    1.225650] usb 1-4: Product: AW1517
[    1.225651] usb 1-4: Manufacturer: Alienware
[    1.225652] usb 1-4: SerialNumber: 16.0
[    1.227083] hid-generic 0003:187C:0528.0001: device has no listeners, quitting
[    1.254819] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TM2417-001, fw id: 0
[    1.291822] input: Synaptics TM2417-001 as /devices/rmi4-00/input/input8
[    1.341042] usb 1-5: new full-speed USB device number 3 using xhci_hcd
[    1.468489] usb 1-5: New USB device found, idVendor=0cf3, idProduct=e300
[    1.468490] usb 1-5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.526259] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[    1.529195] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[    1.529959] ath10k_pci 0000:3c:00.0: htt-ver 3.46 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
[    1.588557] ath: EEPROM regdomain: 0x6c
[    1.588558] ath: EEPROM indicates we should expect a direct regpair map
[    1.588559] ath: Country alpha2 being used: 00
[    1.588559] ath: Regpair used: 0x6c
[    1.820745] Console: switching to colour frame buffer device 320x98
[    1.820756] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops 0xffffffff830e6040)
[    1.840491] snd_hda_intel 0000:00:1f.3: enabling bus mastering
[    1.840500] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    1.853172] snd_hda_codec_ca0132 hdaudioC0D0: autoconfig for CA0132: line_outs=1 (0xb/0x0/0x0/0x0/0x0) type:speaker
[    1.931613] snd_hda_codec_ca0132 hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    1.931614] snd_hda_codec_ca0132 hdaudioC0D0:    hp_outs=1 (0xf/0x0/0x0/0x0/0x0)
[    1.931615] snd_hda_codec_ca0132 hdaudioC0D0:    mono: mono_out=0x0
[    1.931616] snd_hda_codec_ca0132 hdaudioC0D0:    inputs:
[    1.931618] snd_hda_codec_ca0132 hdaudioC0D0:      Mic=0x11
[    1.931619] snd_hda_codec_ca0132 hdaudioC0D0:      Internal Mic=0x12
[    1.931759] scsi 1:0:0:0: Direct-Access     ATA      M4-CT512M4SSD2   0309 PQ: 0 ANSI: 5
[    1.952137] sd 1:0:0:0: [sda] 1000215216 512-byte logical blocks: (512 GB/477 GiB)
[    1.954264] sd 1:0:0:0: [sda] Write Protect is off
[    1.956648] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.956652] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.958930] i915 0000:00:02.0: end poll
[    1.960979] i915 0000:00:02.0: begin poll
[    1.962515]  sda: sda1 sda2 sda3 sda4
[    1.965932] sd 1:0:0:0: [sda] Attached SCSI disk
[    1.990430] i915 0000:00:02.0: end poll
[    2.471301] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[    2.662022] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9
[    2.669447] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10
[    2.677400] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input11
[    2.684860] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input12
[    2.690156] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13
[    2.694097] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input14
[    2.697517] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input15
[    2.708802] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. Opts: (null)
[    2.711125] VFS: Mounted root (ext4 filesystem) readonly on device 259:2.
[    2.713948] devtmpfs: mounted
[    2.716992] Freeing unused kernel memory: 1152K
[    2.719298] Write protecting the kernel read-only data: 24576k
[    2.721968] Freeing unused kernel memory: 2020K
[    2.725358] Freeing unused kernel memory: 1172K
[    2.790227] systemd[1]: systemd 237 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[    2.806470] systemd[1]: Detected architecture x86-64.
[    2.823431] systemd[1]: Set hostname to <axion>.
[    2.876425] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    2.881722] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    2.886986] systemd[1]: Created slice System Slice.
[    2.892801] systemd[1]: Listening on Process Core Dump Socket.
[    2.897907] systemd[1]: Listening on Journal Socket.
[    2.902984] systemd[1]: Listening on Network Service Netlink Socket.
[    2.908167] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[    3.018932] EXT4-fs (nvme0n1p2): re-mounted. Opts: (null)
[    3.075779] systemd-journald[232]: Received request to flush runtime journal from PID 1
[    3.090002] random: crng init done
[    3.256577] EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Opts: (null)
[    3.663627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    3.665889] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    3.673853] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    3.812218] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[    4.373386] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[    4.376319] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[    4.419227] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    5.167925] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[    5.170837] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[    5.223120] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    5.276215] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[    9.184046] waiting 12 sec
[   10.933989] ath10k_pci 0000:3c:00.0: Unknown eventid: 118809
[   10.936915] ath10k_pci 0000:3c:00.0: Unknown eventid: 90118
[   10.990991] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   15.689333] wlan0: authenticate with a0:63:91:a7:3c:9f
[   15.733176] wlan0: send auth to a0:63:91:a7:3c:9f (try 1/3)
[   15.735706] wlan0: authenticated
[   15.740052] wlan0: associate with a0:63:91:a7:3c:9f (try 1/3)
[   15.742191] wlan0: RX AssocResp from a0:63:91:a7:3c:9f (capab=0x11 status=0 aid=1)
[   15.744988] wlan0: associated
[   15.745164] ath: EEPROM regdomain: 0x833a
[   15.745166] ath: EEPROM indicates we should expect a country code
[   15.745168] ath: doing EEPROM country->regdmn map search
[   15.745170] ath: country maps to regdmn code: 0x37
[   15.745172] ath: Country alpha2 being used: GB
[   15.745173] ath: Regpair used: 0x37
[   15.745176] ath: regdomain 0x833a dynamically updated by country IE
[   15.760824] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   21.472096] done waiting 12 sec
[   21.700582] amdgpu 0000:01:00.0: GPU pci config reset
[   21.700586] amdgpu 0000:01:00.0: disabling bus mastering
[   21.700691] amdgpu 0000:01:00.0: enabling bus mastering
[   21.743420] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[   37.086261] pcieport 0000:00:01.0: power state changed by ACPI to D0
[   37.192203] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[   37.192213] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[   37.192220] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[   37.192228] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[   37.192236] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[   37.192246] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[   37.201887] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[   37.399942] [drm] UVD initialized successfully.
[   37.612003] [drm] VCE initialized successfully.
[   56.902565] waiting 12 sec
[   69.269467] done waiting 12 sec
[   69.519581] amdgpu 0000:01:00.0: GPU pci config reset
[   69.519584] amdgpu 0000:01:00.0: disabling bus mastering
[   69.519689] amdgpu 0000:01:00.0: enabling bus mastering
[   69.562150] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[   75.480966] pcieport 0000:00:01.0: power state changed by ACPI to D0
[   75.586668] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[   75.586674] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[   75.586678] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[   75.586683] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[   75.586687] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[   75.586693] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[   75.597132] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[   75.798225] [drm] UVD initialized successfully.
[   76.010230] [drm] VCE initialized successfully.
[  110.942939] waiting 12 sec
[  123.039401] done waiting 12 sec
[  123.288840] amdgpu 0000:01:00.0: GPU pci config reset
[  123.288843] amdgpu 0000:01:00.0: disabling bus mastering
[  123.288948] amdgpu 0000:01:00.0: enabling bus mastering
[  123.331681] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[  123.773713] pcieport 0000:00:01.0: power state changed by ACPI to D0
[  123.879524] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[  123.879537] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[  123.879545] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[  123.879554] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[  123.879563] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[  123.879573] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[  123.888805] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[  124.086898] [drm] UVD initialized successfully.
[  124.298958] [drm] VCE initialized successfully.
[  143.983924] waiting 12 sec
[  156.319685] done waiting 12 sec
[  156.558188] amdgpu 0000:01:00.0: GPU pci config reset
[  156.558192] amdgpu 0000:01:00.0: disabling bus mastering
[  156.558297] amdgpu 0000:01:00.0: enabling bus mastering
[  156.600899] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[  710.067880] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[  867.498109] pcieport 0000:00:01.0: power state changed by ACPI to D0
[  867.604029] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[  867.604034] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[  867.604038] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[  867.604042] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[  867.604046] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[  867.604050] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[  867.612559] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[  867.859670] [drm] UVD initialized successfully.
[  868.071735] [drm] VCE initialized successfully.
[  873.123999] waiting 12 sec
[  885.413116] done waiting 12 sec
[  885.722429] amdgpu 0000:01:00.0: GPU pci config reset
[  885.722435] amdgpu 0000:01:00.0: disabling bus mastering
[  885.722541] amdgpu 0000:01:00.0: enabling bus mastering
[  885.765440] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[  991.201843] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded and running
[  991.503736] WARNING! power/level is deprecated; use power/control instead
[  991.979335] pcieport 0000:00:01.0: power state changed by ACPI to D0
[  992.085409] amdgpu 0000:01:00.0: restoring config space at offset 0x30 (was 0x0, writing 0xdc540000)
[  992.085414] amdgpu 0000:01:00.0: restoring config space at offset 0x24 (was 0x0, writing 0xdc500000)
[  992.085417] amdgpu 0000:01:00.0: restoring config space at offset 0x20 (was 0x1, writing 0xe001)
[  992.085421] amdgpu 0000:01:00.0: restoring config space at offset 0x18 (was 0xc, writing 0xc000000c)
[  992.085425] amdgpu 0000:01:00.0: restoring config space at offset 0x10 (was 0xc, writing 0xb000000c)
[  992.085430] amdgpu 0000:01:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100407)
[  992.094828] [drm] PCIE GART of 1024M enabled (table at 0x000000F400040000).
[  992.293008] [drm] UVD initialized successfully.
[  992.505073] [drm] VCE initialized successfully.
[ 1002.149280] waiting 12 sec
[ 1014.437410] done waiting 12 sec
[ 1014.766156] amdgpu 0000:01:00.0: GPU pci config reset
[ 1014.766161] amdgpu 0000:01:00.0: disabling bus mastering
[ 1014.766267] amdgpu 0000:01:00.0: enabling bus mastering
[ 1014.808734] pcieport 0000:00:01.0: power state changed by ACPI to D3cold
[ 3596.751977] CPU0: Core temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751978] CPU4: Core temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751979] CPU5: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751980] CPU6: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751981] CPU7: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751983] CPU1: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751983] CPU3: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751984] CPU2: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751986] CPU4: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.751988] CPU0: Package temperature above threshold, cpu clock throttled (total events = 1)
[ 3596.752992] CPU4: Core temperature/speed normal
[ 3596.752992] CPU0: Core temperature/speed normal
[ 3596.752993] CPU2: Package temperature/speed normal
[ 3596.752994] CPU1: Package temperature/speed normal
[ 3596.752995] CPU6: Package temperature/speed normal
[ 3596.752996] CPU3: Package temperature/speed normal
[ 3596.752996] CPU5: Package temperature/speed normal
[ 3596.752997] CPU7: Package temperature/speed normal
[ 3596.752998] CPU0: Package temperature/speed normal
[ 3596.753005] CPU4: Package temperature/speed normal

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
> > > I've not been able to reproduce the original problem you're trying to
> > > solve on amdgpu thats with or without your patch set and the above
> > > "trigger" too
> > >
> > > Is anything else required to trigger it, I started multiple DRI_PRIME
> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
> > > the 12 seconds and I couldn't reproduce it
> >
> > The discrete GPU needs to runtime suspend, that's the trigger,
> > so no DRI_PRIME executables should be running.  Just let it
> > autosuspend after boot.  Do you see "waiting 12 sec" messages
> > in dmesg?  If not it's not autosuspending.
> 
> Yes I'm seeing those messages, I'm just not seeing the hangs
> 
> I've attached the dmesg in case you're interested

Okay the reason you're not seeing deadlocks is because the output poll
worker is not enabled.  And the output poll worker is not enabled
because your discrete GPU doesn't have any outputs:

[    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!

The outputs are only polled if there are connectors which have the
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
And that only ever seems to be the case for VGA and DVI.

We know based on bugzilla reports that hybrid graphics laptops do exist
which poll outputs with radeon and nouveau.  If there are no laptops
supported by amdgpu whose discrete GPU has polled connectors, then
patch [5/5] would be unnecessary.  That is for Alex to decide.

However that is very good to know, so thanks a lot for your testing
efforts, much appreciated!

Kind regards,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
> > > I've not been able to reproduce the original problem you're trying to
> > > solve on amdgpu thats with or without your patch set and the above
> > > "trigger" too
> > >
> > > Is anything else required to trigger it, I started multiple DRI_PRIME
> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
> > > the 12 seconds and I couldn't reproduce it
> >
> > The discrete GPU needs to runtime suspend, that's the trigger,
> > so no DRI_PRIME executables should be running.  Just let it
> > autosuspend after boot.  Do you see "waiting 12 sec" messages
> > in dmesg?  If not it's not autosuspending.
> 
> Yes I'm seeing those messages, I'm just not seeing the hangs
> 
> I've attached the dmesg in case you're interested

Okay the reason you're not seeing deadlocks is because the output poll
worker is not enabled.  And the output poll worker is not enabled
because your discrete GPU doesn't have any outputs:

[    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!

The outputs are only polled if there are connectors which have the
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
And that only ever seems to be the case for VGA and DVI.

We know based on bugzilla reports that hybrid graphics laptops do exist
which poll outputs with radeon and nouveau.  If there are no laptops
supported by amdgpu whose discrete GPU has polled connectors, then
patch [5/5] would be unnecessary.  That is for Alex to decide.

However that is very good to know, so thanks a lot for your testing
efforts, much appreciated!

Kind regards,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Imre Deak]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> [...]
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

In i915 polling is on during runtime suspend only if there are outputs
without hotplug interrupt support. A special case is when an output has
working HPD interrupts when in D0, but no interrupts when runtime
suspended. For these we start polling (from a scheduled work) in the
runtime suspend hook and stop it in the runtime resume hook (again from
a scheduled work).

Imo whether to leave polling on or not for the above purpose is a policy
question (configurable with the drm_kms_helper.poll param).

--Imre

> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Imre Deak]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> [...]
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

In i915 polling is on during runtime suspend only if there are outputs
without hotplug interrupt support. A special case is when an output has
working HPD interrupts when in D0, but no interrupts when runtime
suspended. For these we start polling (from a scheduled work) in the
runtime suspend hook and stop it in the runtime resume hook (again from
a scheduled work).

Imo whether to leave polling on or not for the above purpose is a policy
question (configurable with the drm_kms_helper.poll param).

--Imre

> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

[Tejun Heo]

Hello,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Introduce a helper to retrieve the current task's work struct if it is
> a workqueue worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for a specific worker to
> finish and that worker in turn calls a function which waits for runtime
> suspend to finish.  That function is invoked from multiple call sites
> and waiting for runtime suspend to finish is the correct thing to do
> except if it's executing in the context of the worker.
> 
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>

I wonder whether it's too generic a name but there are other functions
named in a similar fashion and AFAICS current_work isn't used by
anyone in the tree, so it seems okay.

Acked-by: Tejun Heo <tj@kernel.org>

Please feel free to route as you see fit.

Thanks.

-- 
tejun

Re: [PATCH 1/5] workqueue: Allow retrieval of current task's work struct

[Tejun Heo]

Hello,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Introduce a helper to retrieve the current task's work struct if it is
> a workqueue worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for a specific worker to
> finish and that worker in turn calls a function which waits for runtime
> suspend to finish.  That function is invoked from multiple call sites
> and waiting for runtime suspend to finish is the correct thing to do
> except if it's executing in the context of the worker.
> 
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Lai Jiangshan <jiangshanlai@gmail.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>

I wonder whether it's too generic a name but there are other functions
named in a similar fashion and AFAICS current_work isn't used by
anyone in the tree, so it seems okay.

Acked-by: Tejun Heo <tj@kernel.org>

Please feel free to route as you see fit.

Thanks.

-- 
tejun
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lyude Paul]

This patchset is a no-brainer for me. I'm ashamed to say I think I might have
seen this issue before, but polling gets used so rarely nowadays it slipped
under the rug by accident.

Anyway, for the whole series  (except patch #2, which I will respond to with a
short comment in just a moment):

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
> 
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++----
> -----
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
-- 
Cheers,
	Lyude Paul

Re: [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lyude Paul]

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish and the worker in turn calls a ->detect callback which waits
> for runtime suspend to finish.  The ->detect callback is invoked from
> multiple call sites and waiting for runtime suspend to finish is the
> correct thing to do except if it's executing in the context of the
> worker.
> 
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 14 ++++++++++++++
>  include/drm/drm_crtc_helper.h      |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 555fbe54d6e2..019881d15ce1 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> *work)
>  		schedule_delayed_work(delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
>  }
>  
> +/**
> + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> + *
> + * Determine if %current task is an output poll worker.  This can be used
> + * to select distinct code paths for output polling versus other contexts.
> + */
For this, it would be worth explicitly noting in the comments herethat this
should be called by DRM drivers in order to prevent racing with hotplug
polling workers, so that new drivers in the future can avoid implementing this
race condition in their driver.

> +bool drm_kms_helper_is_poll_worker(void)
> +{
> +	struct work_struct *work = current_work();
> +
> +	return work && work->func == output_poll_execute;
> +}
> +EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> +
>  /**
>   * drm_kms_helper_poll_disable - disable output polling
>   * @dev: drm_device
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>  
>  void drm_kms_helper_poll_disable(struct drm_device *dev);
>  void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
>  
>  #endif
-- 
Cheers,
	Lyude Paul

Re: [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lyude Paul]

On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish and the worker in turn calls a ->detect callback which waits
> for runtime suspend to finish.  The ->detect callback is invoked from
> multiple call sites and waiting for runtime suspend to finish is the
> correct thing to do except if it's executing in the context of the
> worker.
> 
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 14 ++++++++++++++
>  include/drm/drm_crtc_helper.h      |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 555fbe54d6e2..019881d15ce1 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> *work)
>  		schedule_delayed_work(delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
>  }
>  
> +/**
> + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> + *
> + * Determine if %current task is an output poll worker.  This can be used
> + * to select distinct code paths for output polling versus other contexts.
> + */
For this, it would be worth explicitly noting in the comments herethat this
should be called by DRM drivers in order to prevent racing with hotplug
polling workers, so that new drivers in the future can avoid implementing this
race condition in their driver.

> +bool drm_kms_helper_is_poll_worker(void)
> +{
> +	struct work_struct *work = current_work();
> +
> +	return work && work->func == output_poll_execute;
> +}
> +EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> +
>  /**
>   * drm_kms_helper_poll_disable - disable output polling
>   * @dev: drm_device
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>  
>  void drm_kms_helper_poll_disable(struct drm_device *dev);
>  void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
>  
>  #endif
-- 
Cheers,
	Lyude Paul
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Chris Wilson]

Quoting Lyude Paul (2018-02-12 17:46:11)
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
> > 
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > ---
> >  drivers/gpu/drm/drm_probe_helper.c | 14 ++++++++++++++
> >  include/drm/drm_crtc_helper.h      |  1 +
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 555fbe54d6e2..019881d15ce1 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > *work)
> >               schedule_delayed_work(delayed_work,
> > DRM_OUTPUT_POLL_PERIOD);
> >  }
> >  
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.
> 
> > +bool drm_kms_helper_is_poll_worker(void)
> > +{
> > +     struct work_struct *work = current_work();
> > +
> > +     return work && work->func == output_poll_execute;

What ensures that work is accessible? Does this need rcu_read_lock
protection or more?
-Chris

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Chris Wilson]

Quoting Lyude Paul (2018-02-12 17:46:11)
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
> > 
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > ---
> >  drivers/gpu/drm/drm_probe_helper.c | 14 ++++++++++++++
> >  include/drm/drm_crtc_helper.h      |  1 +
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 555fbe54d6e2..019881d15ce1 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > *work)
> >               schedule_delayed_work(delayed_work,
> > DRM_OUTPUT_POLL_PERIOD);
> >  }
> >  
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.
> 
> > +bool drm_kms_helper_is_poll_worker(void)
> > +{
> > +     struct work_struct *work = current_work();
> > +
> > +     return work && work->func == output_poll_execute;

What ensures that work is accessible? Does this need rcu_read_lock
protection or more?
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

On Mon, Feb 12, 2018 at 05:50:12PM +0000, Chris Wilson wrote:
> Quoting Lyude Paul (2018-02-12 17:46:11)
> > On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > > Introduce a helper to determine if the current task is an output poll
> > > worker.
> > > 
> > > This allows us to fix a long-standing deadlock in several DRM drivers
> > > wherein the ->runtime_suspend callback waits for the output poll worker
> > > to finish and the worker in turn calls a ->detect callback which waits
> > > for runtime suspend to finish.  The ->detect callback is invoked from
> > > multiple call sites and waiting for runtime suspend to finish is the
> > > correct thing to do except if it's executing in the context of the
> > > worker.
> > > 
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Cc: Ben Skeggs <bskeggs@redhat.com>
> > > Cc: Alex Deucher <alexander.deucher@amd.com>
> > > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > > ---
> > >  drivers/gpu/drm/drm_probe_helper.c | 14 ++++++++++++++
> > >  include/drm/drm_crtc_helper.h      |  1 +
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 555fbe54d6e2..019881d15ce1 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -653,6 +653,20 @@ static void output_poll_execute(struct work_struct
> > > *work)
> > >               schedule_delayed_work(delayed_work,
> > > DRM_OUTPUT_POLL_PERIOD);
> > >  }
> > >  
> > > +/**
> > > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > > + *
> > > + * Determine if %current task is an output poll worker.  This can be used
> > > + * to select distinct code paths for output polling versus other contexts.
> > > + */
> > > +bool drm_kms_helper_is_poll_worker(void)
> > > +{
> > > +     struct work_struct *work = current_work();
> > > +
> > > +     return work && work->func == output_poll_execute;
> 
> What ensures that work is accessible? Does this need rcu_read_lock
> protection or more?

The work_struct exists as long this kthread is working on it.
Since this is called by the kthread itself, it is guaranteed to exist.
So there's no protection needed.

Thanks,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
>> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
>> > > I've not been able to reproduce the original problem you're trying to
>> > > solve on amdgpu thats with or without your patch set and the above
>> > > "trigger" too
>> > >
>> > > Is anything else required to trigger it, I started multiple DRI_PRIME
>> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
>> > > the 12 seconds and I couldn't reproduce it
>> >
>> > The discrete GPU needs to runtime suspend, that's the trigger,
>> > so no DRI_PRIME executables should be running.  Just let it
>> > autosuspend after boot.  Do you see "waiting 12 sec" messages
>> > in dmesg?  If not it's not autosuspending.
>>
>> Yes I'm seeing those messages, I'm just not seeing the hangs
>>
>> I've attached the dmesg in case you're interested
>
> Okay the reason you're not seeing deadlocks is because the output poll
> worker is not enabled.  And the output poll worker is not enabled
> because your discrete GPU doesn't have any outputs:
>
> [    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>
> The outputs are only polled if there are connectors which have the
> DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> And that only ever seems to be the case for VGA and DVI.
>
> We know based on bugzilla reports that hybrid graphics laptops do exist
> which poll outputs with radeon and nouveau.  If there are no laptops
> supported by amdgpu whose discrete GPU has polled connectors, then
> patch [5/5] would be unnecessary.  That is for Alex to decide.

Most hybrid laptops don't have display connectors on the dGPU and we
only use polling on analog connectors, so you are not likely to run
into this on recent laptops.  That said, I don't know if there is some
OEM system out there with a VGA port on the dGPU in a hybrid laptop.
I guess another option is to just disable polling on hybrid laptops.

Alex

>
> However that is very good to know, so thanks a lot for your testing
> efforts, much appreciated!
>
> Kind regards,
>
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
>> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
>> > > I've not been able to reproduce the original problem you're trying to
>> > > solve on amdgpu thats with or without your patch set and the above
>> > > "trigger" too
>> > >
>> > > Is anything else required to trigger it, I started multiple DRI_PRIME
>> > > glxgears, in parallel, serial waiting the 12 seconds and serial within
>> > > the 12 seconds and I couldn't reproduce it
>> >
>> > The discrete GPU needs to runtime suspend, that's the trigger,
>> > so no DRI_PRIME executables should be running.  Just let it
>> > autosuspend after boot.  Do you see "waiting 12 sec" messages
>> > in dmesg?  If not it's not autosuspending.
>>
>> Yes I'm seeing those messages, I'm just not seeing the hangs
>>
>> I've attached the dmesg in case you're interested
>
> Okay the reason you're not seeing deadlocks is because the output poll
> worker is not enabled.  And the output poll worker is not enabled
> because your discrete GPU doesn't have any outputs:
>
> [    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>
> The outputs are only polled if there are connectors which have the
> DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> And that only ever seems to be the case for VGA and DVI.
>
> We know based on bugzilla reports that hybrid graphics laptops do exist
> which poll outputs with radeon and nouveau.  If there are no laptops
> supported by amdgpu whose discrete GPU has polled connectors, then
> patch [5/5] would be unnecessary.  That is for Alex to decide.

Most hybrid laptops don't have display connectors on the dGPU and we
only use polling on analog connectors, so you are not likely to run
into this on recent laptops.  That said, I don't know if there is some
OEM system out there with a VGA port on the dGPU in a hybrid laptop.
I guess another option is to just disable polling on hybrid laptops.

Alex

>
> However that is very good to know, so thanks a lot for your testing
> efforts, much appreciated!
>
> Kind regards,
>
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 01:58:32PM -0500, Alex Deucher wrote:
> On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lukas@wunner.de> wrote:
> > On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
> >> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
> >> > > I've not been able to reproduce the original problem you're trying to
> >> > > solve on amdgpu thats with or without your patch set and the above
> >> > > "trigger" too
> >
> > Okay the reason you're not seeing deadlocks is because the output poll
> > worker is not enabled.  And the output poll worker is not enabled
> > because your discrete GPU doesn't have any outputs:
> >
> > [    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
> >
> > The outputs are only polled if there are connectors which have the
> > DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> > And that only ever seems to be the case for VGA and DVI.
> >
> > We know based on bugzilla reports that hybrid graphics laptops do exist
> > which poll outputs with radeon and nouveau.  If there are no laptops
> > supported by amdgpu whose discrete GPU has polled connectors, then
> > patch [5/5] would be unnecessary.  That is for Alex to decide.
> 
> Most hybrid laptops don't have display connectors on the dGPU and we
> only use polling on analog connectors, so you are not likely to run
> into this on recent laptops.  That said, I don't know if there is some
> OEM system out there with a VGA port on the dGPU in a hybrid laptop.
> I guess another option is to just disable polling on hybrid laptops.

If we don't know for sure, applying patch [5/5] would seem to be the
safest approach.  (Assuming it doesn't break anything else.)

Right now runtime PM is only used on hybrid graphics dGPUs by nouveau,
radeon and amdgpu.  Would it be conceivable that its use is expanded
beyond that in the future?  E.g. on a desktop machine, if DPMS is off
on all screens, why keep the GPU in D0?  If that is conceivable, chances
that analog connectors are present are higher, and then the patch would
be necessary again.  (Of course this would mean that analog screens
wouldn't light up automatically if they're attached while the GPU is
in D3hot, but the user may forbid runtime PM via sysfs if that is
unwanted.)

Thanks,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 12, 2018 at 01:58:32PM -0500, Alex Deucher wrote:
> On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lukas@wunner.de> wrote:
> > On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
> >> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
> >> > > I've not been able to reproduce the original problem you're trying to
> >> > > solve on amdgpu thats with or without your patch set and the above
> >> > > "trigger" too
> >
> > Okay the reason you're not seeing deadlocks is because the output poll
> > worker is not enabled.  And the output poll worker is not enabled
> > because your discrete GPU doesn't have any outputs:
> >
> > [    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
> >
> > The outputs are only polled if there are connectors which have the
> > DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
> > And that only ever seems to be the case for VGA and DVI.
> >
> > We know based on bugzilla reports that hybrid graphics laptops do exist
> > which poll outputs with radeon and nouveau.  If there are no laptops
> > supported by amdgpu whose discrete GPU has polled connectors, then
> > patch [5/5] would be unnecessary.  That is for Alex to decide.
> 
> Most hybrid laptops don't have display connectors on the dGPU and we
> only use polling on analog connectors, so you are not likely to run
> into this on recent laptops.  That said, I don't know if there is some
> OEM system out there with a VGA port on the dGPU in a hybrid laptop.
> I guess another option is to just disable polling on hybrid laptops.

If we don't know for sure, applying patch [5/5] would seem to be the
safest approach.  (Assuming it doesn't break anything else.)

Right now runtime PM is only used on hybrid graphics dGPUs by nouveau,
radeon and amdgpu.  Would it be conceivable that its use is expanded
beyond that in the future?  E.g. on a desktop machine, if DPMS is off
on all screens, why keep the GPU in D0?  If that is conceivable, chances
that analog connectors are present are higher, and then the patch would
be necessary again.  (Of course this would mean that analog screens
wouldn't light up automatically if they're attached while the GPU is
in D3hot, but the user may forbid runtime PM via sysfs if that is
unwanted.)

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Liviu Dudau]

Hi Lukas,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
> 
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

I think I understand the problem you are trying to solve, but I'm
struggling to understand where malidp makes any specific mistakes. First
of all, malidp is only a display engine, so there is no GPU attached to
it, but that is only a small clarification. Second, malidp doesn't use
directly any of the callbacks that you are referring to, it uses the
drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
issues there (as they might well be) I think they would apply to a lot
more drivers and the fix will involve more than just malidp, i915 and
msm.

Would love to get any clarifications on what I might have misunderstood.

Best regards,
Liviu


> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Liviu Dudau]

Hi Lukas,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.
> 
> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

I think I understand the problem you are trying to solve, but I'm
struggling to understand where malidp makes any specific mistakes. First
of all, malidp is only a display engine, so there is no GPU attached to
it, but that is only a small clarification. Second, malidp doesn't use
directly any of the callbacks that you are referring to, it uses the
drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
issues there (as they might well be) I think they would apply to a lot
more drivers and the fix will involve more than just malidp, i915 and
msm.

Would love to get any clarifications on what I might have misunderstood.

Best regards,
Liviu


> 
> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Tue, Feb 13, 2018 at 10:55:06AM +0000, Liviu Dudau wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > with the intention of runtime resuming the device afterwards.  The result
> > is a circular wait between poll worker and autosuspend worker.
> 
> I think I understand the problem you are trying to solve, but I'm
> struggling to understand where malidp makes any specific mistakes. First
> of all, malidp is only a display engine, so there is no GPU attached to
> it, but that is only a small clarification. Second, malidp doesn't use
> directly any of the callbacks that you are referring to, it uses the
> drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
> issues there (as they might well be) I think they would apply to a lot
> more drivers and the fix will involve more than just malidp, i915 and
> msm.

I don't know if malidp makes any specific mistakes and didn't mean to
cast it in a negative light, sorry.

So a lot of DRM drivers acquire a runtime PM ref in the connector ->detect
hook because they can't probe connectors while runtime suspended.
E.g. for a PCI device, probing might require mmio access, which isn't
possible outside of power state D0.  There are no ->detect hooks declared
in drivers/gpu/drm/arm/, so it's unclear to me whether you're able to probe
during runtime suspend.

hdlcd_drv.c and malidp_drv.c both enable output polling.  Output polling
is only necessary if you don't get HPD interrupts.

You're not disabling polling upon runtime suspend.  Thus, if a runtime PM
ref is acquired during polling (such as in a ->detect hook), the GPU will
be runtime resumed every 10 secs.  You may want to verify that's not the
case.  If you decide that you do want to stop polling during runtime
suspend because it runtime resumes the GPU continuously, you'll need the
helper introduced in this series.  So by cc'ing you I just wanted to keep
you in the loop about an issue that may potentially affect your driver.

Let me know if there are any questions.

Thanks,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Tue, Feb 13, 2018 at 3:17 AM, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Feb 12, 2018 at 01:58:32PM -0500, Alex Deucher wrote:
>> On Mon, Feb 12, 2018 at 4:45 AM, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Mon, Feb 12, 2018 at 09:03:26AM +0000, Mike Lothian wrote:
>> >> On 12 February 2018 at 03:39, Lukas Wunner <lukas@wunner.de> wrote:
>> >> > On Mon, Feb 12, 2018 at 12:35:51AM +0000, Mike Lothian wrote:
>> >> > > I've not been able to reproduce the original problem you're trying to
>> >> > > solve on amdgpu thats with or without your patch set and the above
>> >> > > "trigger" too
>> >
>> > Okay the reason you're not seeing deadlocks is because the output poll
>> > worker is not enabled.  And the output poll worker is not enabled
>> > because your discrete GPU doesn't have any outputs:
>> >
>> > [    0.265568] [drm:dc_create] *ERROR* DC: Number of connectors is zero!
>> >
>> > The outputs are only polled if there are connectors which have the
>> > DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT flag set.
>> > And that only ever seems to be the case for VGA and DVI.
>> >
>> > We know based on bugzilla reports that hybrid graphics laptops do exist
>> > which poll outputs with radeon and nouveau.  If there are no laptops
>> > supported by amdgpu whose discrete GPU has polled connectors, then
>> > patch [5/5] would be unnecessary.  That is for Alex to decide.
>>
>> Most hybrid laptops don't have display connectors on the dGPU and we
>> only use polling on analog connectors, so you are not likely to run
>> into this on recent laptops.  That said, I don't know if there is some
>> OEM system out there with a VGA port on the dGPU in a hybrid laptop.
>> I guess another option is to just disable polling on hybrid laptops.
>
> If we don't know for sure, applying patch [5/5] would seem to be the
> safest approach.  (Assuming it doesn't break anything else.)


I don't have any objections.  I see no reason to leave out the amdgpu changes.

Alex

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Liviu Dudau]

On Tue, Feb 13, 2018 at 12:52:06PM +0100, Lukas Wunner wrote:
> On Tue, Feb 13, 2018 at 10:55:06AM +0000, Liviu Dudau wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > > with the intention of runtime resuming the device afterwards.  The result
> > > is a circular wait between poll worker and autosuspend worker.
> > 
> > I think I understand the problem you are trying to solve, but I'm
> > struggling to understand where malidp makes any specific mistakes. First
> > of all, malidp is only a display engine, so there is no GPU attached to
> > it, but that is only a small clarification. Second, malidp doesn't use
> > directly any of the callbacks that you are referring to, it uses the
> > drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
> > issues there (as they might well be) I think they would apply to a lot
> > more drivers and the fix will involve more than just malidp, i915 and
> > msm.
> 
> I don't know if malidp makes any specific mistakes and didn't mean to
> cast it in a negative light, sorry.

I did not take what you've said as a negative thing, only wanted to
understand how you came to your conclusions.

> 
> So a lot of DRM drivers acquire a runtime PM ref in the connector ->detect
> hook because they can't probe connectors while runtime suspended.
> E.g. for a PCI device, probing might require mmio access, which isn't
> possible outside of power state D0.  There are no ->detect hooks declared
> in drivers/gpu/drm/arm/, so it's unclear to me whether you're able to probe
> during runtime suspend.

That's because the drivers in drivers/gpu/drm/arm do not have
connectors, they are only the CRTC part of the driver. Both hdlcd and
mali-dp use the component framework to locate an encoder in device tree
that will then provide the connectors.

> 
> hdlcd_drv.c and malidp_drv.c both enable output polling.  Output polling
> is only necessary if you don't get HPD interrupts.

That's right, hdlcd and mali-dp don't receive HPD interrupts because
they don't have any. And because we don't know ahead of time which
encoder/connector will be paired with the driver, we enable polling as a
safe fallback.

> 
> You're not disabling polling upon runtime suspend.  Thus, if a runtime PM
> ref is acquired during polling (such as in a ->detect hook), the GPU will
> be runtime resumed every 10 secs.  You may want to verify that's not the
> case.  If you decide that you do want to stop polling during runtime
> suspend because it runtime resumes the GPU continuously, you'll need the
> helper introduced in this series.  So by cc'ing you I just wanted to keep
> you in the loop about an issue that may potentially affect your driver.

Again, we have no GPU linked to us and the polling during runtime
suspend should be handled by the driver for the paired encoder, not by
us. I understand the potential issue but I'm struggling to understand if
it really applies to the drivers/gpu/drm/arm drivers other than in an
abstract way.

Best regards,
Liviu

> 
> Let me know if there are any questions.
> 
> Thanks,
> 
> Lukas

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Liviu Dudau]

On Tue, Feb 13, 2018 at 12:52:06PM +0100, Lukas Wunner wrote:
> On Tue, Feb 13, 2018 at 10:55:06AM +0000, Liviu Dudau wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > > with the intention of runtime resuming the device afterwards.  The result
> > > is a circular wait between poll worker and autosuspend worker.
> > 
> > I think I understand the problem you are trying to solve, but I'm
> > struggling to understand where malidp makes any specific mistakes. First
> > of all, malidp is only a display engine, so there is no GPU attached to
> > it, but that is only a small clarification. Second, malidp doesn't use
> > directly any of the callbacks that you are referring to, it uses the
> > drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
> > issues there (as they might well be) I think they would apply to a lot
> > more drivers and the fix will involve more than just malidp, i915 and
> > msm.
> 
> I don't know if malidp makes any specific mistakes and didn't mean to
> cast it in a negative light, sorry.

I did not take what you've said as a negative thing, only wanted to
understand how you came to your conclusions.

> 
> So a lot of DRM drivers acquire a runtime PM ref in the connector ->detect
> hook because they can't probe connectors while runtime suspended.
> E.g. for a PCI device, probing might require mmio access, which isn't
> possible outside of power state D0.  There are no ->detect hooks declared
> in drivers/gpu/drm/arm/, so it's unclear to me whether you're able to probe
> during runtime suspend.

That's because the drivers in drivers/gpu/drm/arm do not have
connectors, they are only the CRTC part of the driver. Both hdlcd and
mali-dp use the component framework to locate an encoder in device tree
that will then provide the connectors.

> 
> hdlcd_drv.c and malidp_drv.c both enable output polling.  Output polling
> is only necessary if you don't get HPD interrupts.

That's right, hdlcd and mali-dp don't receive HPD interrupts because
they don't have any. And because we don't know ahead of time which
encoder/connector will be paired with the driver, we enable polling as a
safe fallback.

> 
> You're not disabling polling upon runtime suspend.  Thus, if a runtime PM
> ref is acquired during polling (such as in a ->detect hook), the GPU will
> be runtime resumed every 10 secs.  You may want to verify that's not the
> case.  If you decide that you do want to stop polling during runtime
> suspend because it runtime resumes the GPU continuously, you'll need the
> helper introduced in this series.  So by cc'ing you I just wanted to keep
> you in the loop about an issue that may potentially affect your driver.

Again, we have no GPU linked to us and the polling during runtime
suspend should be handled by the driver for the paired encoder, not by
us. I understand the potential issue but I'm struggling to understand if
it really applies to the drivers/gpu/drm/arm drivers other than in an
abstract way.

Best regards,
Liviu

> 
> Let me know if there are any questions.
> 
> Thanks,
> 
> Lukas

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

Introduce a helper to determine if the current task is an output poll
worker.

This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for runtime suspend to finish.  The ->detect callback is invoked from
multiple call sites and waiting for runtime suspend to finish is the
correct thing to do except if it's executing in the context of the
worker.

v2: Expand kerneldoc to specifically mention deadlock between
    output poll worker and autosuspend worker as use case. (Lyude)

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
---
 drivers/gpu/drm/drm_probe_helper.c | 20 ++++++++++++++++++++
 include/drm/drm_crtc_helper.h      |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 6dc2dde5b672..7a6b2dc08913 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -654,6 +654,26 @@ static void output_poll_execute(struct work_struct *work)
 		schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
 }
 
+/**
+ * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
+ *
+ * Determine if %current task is an output poll worker.  This can be used
+ * to select distinct code paths for output polling versus other contexts.
+ *
+ * One use case is to avoid a deadlock between the output poll worker and
+ * the autosuspend worker wherein the latter waits for polling to finish
+ * upon calling drm_kms_helper_poll_disable(), while the former waits for
+ * runtime suspend to finish upon calling pm_runtime_get_sync() in a
+ * connector ->detect hook.
+ */
+bool drm_kms_helper_is_poll_worker(void)
+{
+	struct work_struct *work = current_work();
+
+	return work && work->func == output_poll_execute;
+}
+EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
+
 /**
  * drm_kms_helper_poll_disable - disable output polling
  * @dev: drm_device
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 76e237bd989b..6914633037a5 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
 
 void drm_kms_helper_poll_disable(struct drm_device *dev);
 void drm_kms_helper_poll_enable(struct drm_device *dev);
+bool drm_kms_helper_is_poll_worker(void);
 
 #endif
-- 
2.15.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm: Allow determining if current task is output poll worker

[Lukas Wunner]

On Mon, Feb 12, 2018 at 12:46:11PM -0500, Lyude Paul wrote:
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
[snip]
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
>
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.

Good point, I've just sent out a v2 to address your comment.  Let me know
if this isn't what you had in mind.  It may also be worth to expand the
DOC section at the top of drm_probe_helper.c to explain the interaction
between polling and runtime suspend in more detail, but I think this is
better done in a separate patch to keep the present patch small and thus
easily backportable to stable.

Thanks a lot for the review,

Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

Dear drm-misc maintainers,

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:

This series has been reviewed, consent has been expressed by the most
interested parties, patch [1/5] which touches files outside drivers/gpu
has been acked and I've just out a v2 addressing the only objection
raised.  My plan is thus to wait another two days for comments and,
barring further objections, push to drm-misc this weekend.

However I'm struggling with the decision whether to push to next or
fixes.  The series is marked for stable, however the number of
affected machines is limited and for an issue that's been present
for 5 years it probably doesn't matter if it soaks another two months
in linux-next befor it gets backported.  Hence I tend to err on the
side of caution and push to next, however a case could be made that
fixes is more appropriate.

I'm lacking experience making such decisions and would be interested
to learn how you'd handle this.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Maarten Lankhorst]

Op 14-02-18 om 09:46 schreef Lukas Wunner:
> Dear drm-misc maintainers,
>
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> This series has been reviewed, consent has been expressed by the most
> interested parties, patch [1/5] which touches files outside drivers/gpu
> has been acked and I've just out a v2 addressing the only objection
> raised.  My plan is thus to wait another two days for comments and,
> barring further objections, push to drm-misc this weekend.
>
> However I'm struggling with the decision whether to push to next or
> fixes.  The series is marked for stable, however the number of
> affected machines is limited and for an issue that's been present
> for 5 years it probably doesn't matter if it soaks another two months
> in linux-next befor it gets backported.  Hence I tend to err on the
> side of caution and push to next, however a case could be made that
> fixes is more appropriate.
>
> I'm lacking experience making such decisions and would be interested
> to learn how you'd handle this.
>
> Thanks,
>
> Lukas

I would say fixes, it doesn't look particularly scary. :)

~Maarten

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Tue, Feb 13, 2018 at 03:46:08PM +0000, Liviu Dudau wrote:
> On Tue, Feb 13, 2018 at 12:52:06PM +0100, Lukas Wunner wrote:
> > On Tue, Feb 13, 2018 at 10:55:06AM +0000, Liviu Dudau wrote:
> > > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > > > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > > > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > > > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > > > with the intention of runtime resuming the device afterwards.  The result
> > > > is a circular wait between poll worker and autosuspend worker.
> > > 
> > > I think I understand the problem you are trying to solve, but I'm
> > > struggling to understand where malidp makes any specific mistakes. First
> > > of all, malidp is only a display engine, so there is no GPU attached to
> > > it, but that is only a small clarification. Second, malidp doesn't use
> > > directly any of the callbacks that you are referring to, it uses the
> > > drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
> > > issues there (as they might well be) I think they would apply to a lot
> > > more drivers and the fix will involve more than just malidp, i915 and
> > > msm.
[snip]
> > There are no ->detect hooks declared
> > in drivers/gpu/drm/arm/, so it's unclear to me whether you're able to probe
> > during runtime suspend.
> 
> That's because the drivers in drivers/gpu/drm/arm do not have
> connectors, they are only the CRTC part of the driver. Both hdlcd and
> mali-dp use the component framework to locate an encoder in device tree
> that will then provide the connectors.
> 
> > 
> > hdlcd_drv.c and malidp_drv.c both enable output polling.  Output polling
> > is only necessary if you don't get HPD interrupts.
> 
> That's right, hdlcd and mali-dp don't receive HPD interrupts because
> they don't have any. And because we don't know ahead of time which
> encoder/connector will be paired with the driver, we enable polling as a
> safe fallback.
> 

Looking e.g. at inno_hdmi.c (used by rk3036.dtsi), this calls
drm_helper_hpd_irq_event() on receiving an HPD interrupt, and that
function returns immediately if polling is not enabled.  So you *have*
to enable polling to receive HPD events.

You seem to keep the crtc runtime active as long as it's bound to an
encoder.  If you do not ever intend to runtime suspend the crtc while
an encoder is attached, you don't need to keep polling enabled during
runtime suspend (because there's nothing to poll), but it shouldn't
hurt either.

If you would runtime suspend while an encoder is attached, then you
would only runtime resume every 10 sec (upon polling) if the encoder
was a child of the crtc and would support runtime suspend as well.
That's because the PM core wakes the parent by default when a child
runtime resumes.  However in the DT's I've looked at, the encoder
is never a child of the crtc and at least inno_hdmi.c doesn't use
runtime suspend.

So I think you're all green, I can't spot any grave issues here.
Just be aware of the above-mentioned constraints.

Thanks,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Tue, Feb 13, 2018 at 03:46:08PM +0000, Liviu Dudau wrote:
> On Tue, Feb 13, 2018 at 12:52:06PM +0100, Lukas Wunner wrote:
> > On Tue, Feb 13, 2018 at 10:55:06AM +0000, Liviu Dudau wrote:
> > > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > > > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > > > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > > > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > > > with the intention of runtime resuming the device afterwards.  The result
> > > > is a circular wait between poll worker and autosuspend worker.
> > > 
> > > I think I understand the problem you are trying to solve, but I'm
> > > struggling to understand where malidp makes any specific mistakes. First
> > > of all, malidp is only a display engine, so there is no GPU attached to
> > > it, but that is only a small clarification. Second, malidp doesn't use
> > > directly any of the callbacks that you are referring to, it uses the
> > > drm_cma_xxxx() API plus the generic drm_xxxx() call. So if there are any
> > > issues there (as they might well be) I think they would apply to a lot
> > > more drivers and the fix will involve more than just malidp, i915 and
> > > msm.
[snip]
> > There are no ->detect hooks declared
> > in drivers/gpu/drm/arm/, so it's unclear to me whether you're able to probe
> > during runtime suspend.
> 
> That's because the drivers in drivers/gpu/drm/arm do not have
> connectors, they are only the CRTC part of the driver. Both hdlcd and
> mali-dp use the component framework to locate an encoder in device tree
> that will then provide the connectors.
> 
> > 
> > hdlcd_drv.c and malidp_drv.c both enable output polling.  Output polling
> > is only necessary if you don't get HPD interrupts.
> 
> That's right, hdlcd and mali-dp don't receive HPD interrupts because
> they don't have any. And because we don't know ahead of time which
> encoder/connector will be paired with the driver, we enable polling as a
> safe fallback.
> 

Looking e.g. at inno_hdmi.c (used by rk3036.dtsi), this calls
drm_helper_hpd_irq_event() on receiving an HPD interrupt, and that
function returns immediately if polling is not enabled.  So you *have*
to enable polling to receive HPD events.

You seem to keep the crtc runtime active as long as it's bound to an
encoder.  If you do not ever intend to runtime suspend the crtc while
an encoder is attached, you don't need to keep polling enabled during
runtime suspend (because there's nothing to poll), but it shouldn't
hurt either.

If you would runtime suspend while an encoder is attached, then you
would only runtime resume every 10 sec (upon polling) if the encoder
was a child of the crtc and would support runtime suspend as well.
That's because the PM core wakes the parent by default when a child
runtime resumes.  However in the DT's I've looked at, the encoder
is never a child of the crtc and at least inno_hdmi.c doesn't use
runtime suspend.

So I think you're all green, I can't spot any grave issues here.
Just be aware of the above-mentioned constraints.

Thanks,

Lukas
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Sean Paul]

On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> > Dear drm-misc maintainers,
> >
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> >> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > This series has been reviewed, consent has been expressed by the most
> > interested parties, patch [1/5] which touches files outside drivers/gpu
> > has been acked and I've just out a v2 addressing the only objection
> > raised.  My plan is thus to wait another two days for comments and,
> > barring further objections, push to drm-misc this weekend.
> >
> > However I'm struggling with the decision whether to push to next or
> > fixes.  The series is marked for stable, however the number of
> > affected machines is limited and for an issue that's been present
> > for 5 years it probably doesn't matter if it soaks another two months
> > in linux-next befor it gets backported.  Hence I tend to err on the
> > side of caution and push to next, however a case could be made that
> > fixes is more appropriate.
> >
> > I'm lacking experience making such decisions and would be interested
> > to learn how you'd handle this.
> >
> > Thanks,
> >
> > Lukas
> 
> I would say fixes, it doesn't look particularly scary. :)

Agreed. If it's good enough for stable, it's good enough for -fixes!

Sean

> 
> ~Maarten
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Michel Dänzer]

On 2018-02-14 03:08 PM, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
>> Op 14-02-18 om 09:46 schreef Lukas Wunner:
>>> Dear drm-misc maintainers,
>>>
>>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>>> This series has been reviewed, consent has been expressed by the most
>>> interested parties, patch [1/5] which touches files outside drivers/gpu
>>> has been acked and I've just out a v2 addressing the only objection
>>> raised.  My plan is thus to wait another two days for comments and,
>>> barring further objections, push to drm-misc this weekend.
>>>
>>> However I'm struggling with the decision whether to push to next or
>>> fixes.  The series is marked for stable, however the number of
>>> affected machines is limited and for an issue that's been present
>>> for 5 years it probably doesn't matter if it soaks another two months
>>> in linux-next befor it gets backported.  Hence I tend to err on the
>>> side of caution and push to next, however a case could be made that
>>> fixes is more appropriate.
>>>
>>> I'm lacking experience making such decisions and would be interested
>>> to learn how you'd handle this.
>>>
>>> Thanks,
>>>
>>> Lukas
>>
>> I would say fixes, it doesn't look particularly scary. :)
> 
> Agreed. If it's good enough for stable, it's good enough for -fixes!

It's not that simple, is it? Fast-tracking patches (some of which appear
to be untested) to stable without an immediate cause for urgency seems
risky to me.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Sean Paul]

On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> On 2018-02-14 03:08 PM, Sean Paul wrote:
> > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> >>> Dear drm-misc maintainers,
> >>>
> >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> >>> This series has been reviewed, consent has been expressed by the most
> >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> >>> has been acked and I've just out a v2 addressing the only objection
> >>> raised.  My plan is thus to wait another two days for comments and,
> >>> barring further objections, push to drm-misc this weekend.
> >>>
> >>> However I'm struggling with the decision whether to push to next or
> >>> fixes.  The series is marked for stable, however the number of
> >>> affected machines is limited and for an issue that's been present
> >>> for 5 years it probably doesn't matter if it soaks another two months
> >>> in linux-next befor it gets backported.  Hence I tend to err on the
> >>> side of caution and push to next, however a case could be made that
> >>> fixes is more appropriate.
> >>>
> >>> I'm lacking experience making such decisions and would be interested
> >>> to learn how you'd handle this.
> >>>
> >>> Thanks,
> >>>
> >>> Lukas
> >>
> >> I would say fixes, it doesn't look particularly scary. :)
> > 
> > Agreed. If it's good enough for stable, it's good enough for -fixes!
> 
> It's not that simple, is it? Fast-tracking patches (some of which appear
> to be untested) to stable without an immediate cause for urgency seems
> risky to me.
> 

/me should be more careful what he says

Given where we are in the release cycle, it's barely a fast track. If these go
in -fixes, they'll get in -rc2 and will have plenty of time to bake. If we were
at rc5, it might be a different story.

Sean

> 
> -- 
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer

-- 
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm: Allow determining if current task is output poll worker

[Lyude Paul]

I think your idea of having the extra kerneldoc as a seperate patch to make
this easier to backport should work fine :). Thanks for the good work!

Reviewed-by: Lyude Paul <lyude@redhat.com>

On Wed, 2018-02-14 at 08:41 +0100, Lukas Wunner wrote:
> Introduce a helper to determine if the current task is an output poll
> worker.
> 
> This allows us to fix a long-standing deadlock in several DRM drivers
> wherein the ->runtime_suspend callback waits for the output poll worker
> to finish and the worker in turn calls a ->detect callback which waits
> for runtime suspend to finish.  The ->detect callback is invoked from
> multiple call sites and waiting for runtime suspend to finish is the
> correct thing to do except if it's executing in the context of the
> worker.
> 
> v2: Expand kerneldoc to specifically mention deadlock between
>     output poll worker and autosuspend worker as use case. (Lyude)
> 
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Reviewed-by: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 20 ++++++++++++++++++++
>  include/drm/drm_crtc_helper.h      |  1 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 6dc2dde5b672..7a6b2dc08913 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -654,6 +654,26 @@ static void output_poll_execute(struct work_struct
> *work)
>  		schedule_delayed_work(delayed_work,
> DRM_OUTPUT_POLL_PERIOD);
>  }
>  
> +/**
> + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> + *
> + * Determine if %current task is an output poll worker.  This can be used
> + * to select distinct code paths for output polling versus other contexts.
> + *
> + * One use case is to avoid a deadlock between the output poll worker and
> + * the autosuspend worker wherein the latter waits for polling to finish
> + * upon calling drm_kms_helper_poll_disable(), while the former waits for
> + * runtime suspend to finish upon calling pm_runtime_get_sync() in a
> + * connector ->detect hook.
> + */
> +bool drm_kms_helper_is_poll_worker(void)
> +{
> +	struct work_struct *work = current_work();
> +
> +	return work && work->func == output_poll_execute;
> +}
> +EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> +
>  /**
>   * drm_kms_helper_poll_disable - disable output polling
>   * @dev: drm_device
> diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
> index 76e237bd989b..6914633037a5 100644
> --- a/include/drm/drm_crtc_helper.h
> +++ b/include/drm/drm_crtc_helper.h
> @@ -77,5 +77,6 @@ void drm_kms_helper_hotplug_event(struct drm_device *dev);
>  
>  void drm_kms_helper_poll_disable(struct drm_device *dev);
>  void drm_kms_helper_poll_enable(struct drm_device *dev);
> +bool drm_kms_helper_is_poll_worker(void);
>  
>  #endif
-- 
Cheers,
	Lyude Paul
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > On 2018-02-14 03:08 PM, Sean Paul wrote:
> > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> > >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> > >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > >>> This series has been reviewed, consent has been expressed by the most
> > >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> > >>> has been acked and I've just out a v2 addressing the only objection
> > >>> raised.  My plan is thus to wait another two days for comments and,
> > >>> barring further objections, push to drm-misc this weekend.
> > >>>
> > >>> However I'm struggling with the decision whether to push to next or
> > >>> fixes.  The series is marked for stable, however the number of
> > >>> affected machines is limited and for an issue that's been present
> > >>> for 5 years it probably doesn't matter if it soaks another two months
> > >>> in linux-next befor it gets backported.  Hence I tend to err on the
> > >>> side of caution and push to next, however a case could be made that
> > >>> fixes is more appropriate.
> > >>>
> > >>> I'm lacking experience making such decisions and would be interested
> > >>> to learn how you'd handle this.
> > >>
> > >> I would say fixes, it doesn't look particularly scary. :)
> > > 
> > > Agreed. If it's good enough for stable, it's good enough for -fixes!
> > 
> > It's not that simple, is it? Fast-tracking patches (some of which appear
> > to be untested) to stable without an immediate cause for urgency seems
> > risky to me.
> 
> /me should be more careful what he says
> 
> Given where we are in the release cycle, it's barely a fast track.
> If these go in -fixes, they'll get in -rc2 and will have plenty of
> time to bake. If we were at rc5, it might be a different story.

The patches are marked for stable though, so if they go in through
drm-misc-fixes, they may appear in stable kernels before 4.16-final
is out.  Greg picks up patches once they're in Linus' tree, though
often with a delay of a few days or weeks.  If they go in through
drm-misc-next, they're guaranteed not to appear in *any* release
before 4.16-final is out.

This allows for differentiation between no-brainer stable fixes that
can be sent immediately and scarier, but similarly important stable
fixes that should soak for a while.  I'm not sure which category
this series belongs to, though it's true what Maarten says, it's
not *that* grave a change.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers)

[Lukas Wunner]

[trimming cc: a little to avoid spamming folks not directly involved with i915]

On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > on runtime suspend.  But this results in the GPU bouncing back and forth
> > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > runtime suspend to D3cold since every suspend/resume cycle costs a
> > significant amount of time and energy.  (i915 and malidp do not seem
> > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > questionable.  msm however does and would also deadlock if it disabled
> > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> 
> In i915 polling is on during runtime suspend only if there are outputs
> without hotplug interrupt support. A special case is when an output has
> working HPD interrupts when in D0, but no interrupts when runtime
> suspended. For these we start polling (from a scheduled work) in the
> runtime suspend hook and stop it in the runtime resume hook (again from
> a scheduled work).

I'm assuming to poll outputs you need to access mmio, is that correct?
Since mmio is inaccessible in D3hot, you seem to leave the PCI device
in D0 during runtime suspend, right?  Aren't you leaving power saving
potential on the table that way?  Or are you able to achieve the same
low power consumption in D0 as in D3hot by turning off power wells etc?

When powering off the GPU via vga_switcheroo manual power control
(a legacy feature we'll hopefully drop once we have runtime PM
support on muxed laptops and in i915) the PCI device *is* put into
D3hot by i915_suspend_switcheroo().  If leaving the device in D0
in the runtime suspend code path results in less power reduction,
runtime PM wouldn't be a full replacement for vga_switcheroo manual
power control, which would be kind of a bummer. :-/

Another question, you're not calling pm_runtime_allow() when binding
the driver to the device, so users have to either manually allow it
via sysfs or use "powertop --auto-tune" or whatever.  What's the
rationale for that?  nouveau, radeon and amdgpu all allow it by
default.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers)

[Imre Deak]

On Fri, Feb 16, 2018 at 09:49:28AM +0100, Lukas Wunner wrote:
> [trimming cc: a little to avoid spamming folks not directly involved with i915]
> 
> On Mon, Feb 12, 2018 at 03:04:06PM +0200, Imre Deak wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > > on runtime suspend.  But this results in the GPU bouncing back and forth
> > > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > > runtime suspend to D3cold since every suspend/resume cycle costs a
> > > significant amount of time and energy.  (i915 and malidp do not seem
> > > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > > questionable.  msm however does and would also deadlock if it disabled
> > > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> > 
> > In i915 polling is on during runtime suspend only if there are outputs
> > without hotplug interrupt support. A special case is when an output has
> > working HPD interrupts when in D0, but no interrupts when runtime
> > suspended. For these we start polling (from a scheduled work) in the
> > runtime suspend hook and stop it in the runtime resume hook (again from
> > a scheduled work).
> 
> I'm assuming to poll outputs you need to access mmio, is that correct?

Correct.

> Since mmio is inaccessible in D3hot, you seem to leave the PCI device
> in D0 during runtime suspend, right?

No, it's put into D3 (by the runtime PM core).

> Aren't you leaving power saving
> potential on the table that way?  Or are you able to achieve the same
> low power consumption in D0 as in D3hot by turning off power wells etc?
> When powering off the GPU via vga_switcheroo manual power control
> (a legacy feature we'll hopefully drop once we have runtime PM
> support on muxed laptops and in i915) the PCI device *is* put into
> D3hot by i915_suspend_switcheroo().  If leaving the device in D0
> in the runtime suspend code path results in less power reduction,
> runtime PM wouldn't be a full replacement for vga_switcheroo manual
> power control, which would be kind of a bummer. :-/

It's possible that in the future the device won't be put into D3, given
that HPD interrupts are gone in that state, but this will be done only
if D3 doesn't provide any power saving over turning off display/GPU
power wells (still need to figure out the details of this).

> Another question, you're not calling pm_runtime_allow() when binding
> the driver to the device, so users have to either manually allow it
> via sysfs or use "powertop --auto-tune" or whatever.  What's the
> rationale for that?

We decided to have more testing/fixing known issues before enabling it
by default.

--Imre

> nouveau, radeon and amdgpu all allow it by default.
> 
> Thanks,
> 
> Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend

Pushed to drm-misc-fixes, thanks a lot everyone for the acks,
reviews, testing and comments.

drm-misc maintainers, heads-up:

drm-misc-fixes is still based on 4.15-rc8.  The present series
applies cleanly to both 4.15 and 4.16, so I had no need to have
4.16-rc1 backmerged, but that may be necessary sooner or later.
I did a local test pull into drm-fixes, the shortlog looked sane
and it merged and compiled cleanly.

Please note two other commits are still pending in drm-misc-fixes:

    commit 745fd50f3b044db6a3922e1718306555613164b0
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Jan 31 12:04:50 2018 +0100

    drm/cirrus: Load lut in crtc_commit

Gustavo sent a pull request for this one on Jan 31 but erroneously
based it on the wrong commit and it ended up not being pulled by Dave.

    commit 54f809cfbd6b4a43959039f5d33596ed3297ce16
    Author: Leo (Sunpeng) Li <sunpeng.li@amd.com>
    Date:   Wed Jan 17 12:51:08 2018 +0100

    drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

This one has already been pulled by Dave into drm-next for 4.17
as commit 1c6ceeee6ebb but Maarten subsequently cherry-picked
it onto drm-misc-fixes.

Let me know if I've made any mistakes.

Thanks,

Lukas

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend

Pushed to drm-misc-fixes, thanks a lot everyone for the acks,
reviews, testing and comments.

drm-misc maintainers, heads-up:

drm-misc-fixes is still based on 4.15-rc8.  The present series
applies cleanly to both 4.15 and 4.16, so I had no need to have
4.16-rc1 backmerged, but that may be necessary sooner or later.
I did a local test pull into drm-fixes, the shortlog looked sane
and it merged and compiled cleanly.

Please note two other commits are still pending in drm-misc-fixes:

    commit 745fd50f3b044db6a3922e1718306555613164b0
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Wed Jan 31 12:04:50 2018 +0100

    drm/cirrus: Load lut in crtc_commit

Gustavo sent a pull request for this one on Jan 31 but erroneously
based it on the wrong commit and it ended up not being pulled by Dave.

    commit 54f809cfbd6b4a43959039f5d33596ed3297ce16
    Author: Leo (Sunpeng) Li <sunpeng.li@amd.com>
    Date:   Wed Jan 17 12:51:08 2018 +0100

    drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

This one has already been pulled by Dave into drm-next for 4.17
as commit 1c6ceeee6ebb but Maarten subsequently cherry-picked
it onto drm-misc-fixes.

Let me know if I've made any mistakes.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.

Don't shut down the poll worker when runtime suspending, that' doesn't
work. If you need the poll work, then that means waking up the gpu every
few seconds. If you don't need it, then make sure the DRM_CONNECTOR_POLL
flags are set correctly (you can update them at runtime, the poll worker
will pick that up).

That should fix the deadlock, and it's how we do it in i915 (where igt in
CI totally hammers the runtime pm support, and it seems to hold up).

And I guess we need to improve the poll worker docs about this.

> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

Well, userspace expects hotplug events, even when we runtime suspend
stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
pretty serious policy decision which is ok in the context of
vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
up if you plug something in, even with all the runtime pm stuff enabled.
Same for sata and everything else.
-Daniel

> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> 
> DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> the poll worker invokes the DRM drivers' ->detect callbacks, which call
> pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> with the intention of runtime resuming the device afterwards.  The result
> is a circular wait between poll worker and autosuspend worker.

Don't shut down the poll worker when runtime suspending, that' doesn't
work. If you need the poll work, then that means waking up the gpu every
few seconds. If you don't need it, then make sure the DRM_CONNECTOR_POLL
flags are set correctly (you can update them at runtime, the poll worker
will pick that up).

That should fix the deadlock, and it's how we do it in i915 (where igt in
CI totally hammers the runtime pm support, and it seems to hold up).

And I guess we need to improve the poll worker docs about this.

> I'm seeing this deadlock so often it's not funny anymore. I've also found
> 3 nouveau bugzillas about it and 1 radeon bugzilla. (See patch [3/5] and
> [4/5].)
> 
> One theoretical solution would be to add a flag to the ->detect callback
> to tell it that it's running in the poll worker's context.  In that case
> it doesn't need to call pm_runtime_get_sync() because the poll worker is
> only enabled while runtime active and we know that ->runtime_suspend
> waits for it to finish.  But this approach would require touching every
> single DRM driver's ->detect hook.  Moreover the ->detect hook is called
> from numerous other places, both in the DRM library as well as in each
> driver, making it necessary to trace every possible call chain and check
> if it's coming from the poll worker or not.  I've tried to do that for
> nouveau (see the call sites listed in the commit message of patch [3/5])
> and concluded that this approach is a nightmare to implement.
> 
> Another reason for the infeasibility of this approach is that ->detect
> is called from within the DRM library without driver involvement, e.g.
> via DRM's sysfs interface.  In those cases, pm_runtime_get_sync() would
> have to be called by the DRM library, but the DRM library is supposed to
> stay generic, wheras runtime PM is driver-specific.
> 
> So instead, I've come up with this much simpler solution which gleans
> from the current task's flags if it's a workqueue worker, retrieves the
> work_struct and checks if it's the poll worker.  All that's needed is
> one small helper in the workqueue code and another small helper in the
> DRM library.  This solution lends itself nicely to stable-backporting.
> 
> The patches for radeon and amdgpu are compile-tested only, I only have a
> MacBook Pro with an Nvidia GK107 to test.  To test the patches, add an
> "msleep(12*1000);" at the top of the driver's ->runtime_suspend hook.
> This ensures that the poll worker runs after ->runtime_suspend has begun.
> Wait 12 sec after the GPU has begun runtime suspend, then check
> /sys/bus/pci/devices/0000:01:00.0/power/runtime_status.  Without this
> series, the status will be stuck at "suspending" and you'll get hung task
> errors in dmesg after a few minutes.
> 
> i915, malidp and msm "solved" this issue by not stopping the poll worker
> on runtime suspend.  But this results in the GPU bouncing back and forth
> between D0 and D3 continuously.  That's a total no-go for GPUs which
> runtime suspend to D3cold since every suspend/resume cycle costs a
> significant amount of time and energy.  (i915 and malidp do not seem
> to acquire a runtime PM ref in the ->detect callbacks, which seems
> questionable.  msm however does and would also deadlock if it disabled
> the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)

Well, userspace expects hotplug events, even when we runtime suspend
stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
pretty serious policy decision which is ok in the context of
vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
up if you plug something in, even with all the runtime pm stuff enabled.
Same for sata and everything else.
-Daniel

> Please review.  Thanks,
> 
> Lukas
> 
> Lukas Wunner (5):
>   workqueue: Allow retrieval of current task's work struct
>   drm: Allow determining if current task is output poll worker
>   drm/nouveau: Fix deadlock on runtime suspend
>   drm/radeon: Fix deadlock on runtime suspend
>   drm/amdgpu: Fix deadlock on runtime suspend
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 58 +++++++++++++-------
>  drivers/gpu/drm/drm_probe_helper.c             | 14 +++++
>  drivers/gpu/drm/nouveau/nouveau_connector.c    | 18 +++++--
>  drivers/gpu/drm/radeon/radeon_connectors.c     | 74 +++++++++++++++++---------
>  include/drm/drm_crtc_helper.h                  |  1 +
>  include/linux/workqueue.h                      |  1 +
>  kernel/workqueue.c                             | 16 ++++++
>  7 files changed, 132 insertions(+), 50 deletions(-)
> 
> -- 
> 2.15.1
> 
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Thu, Feb 15, 2018 at 06:38:44AM +0100, Lukas Wunner wrote:
> On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> > On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > > On 2018-02-14 03:08 PM, Sean Paul wrote:
> > > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> > > >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> > > >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > > >>> This series has been reviewed, consent has been expressed by the most
> > > >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> > > >>> has been acked and I've just out a v2 addressing the only objection
> > > >>> raised.  My plan is thus to wait another two days for comments and,
> > > >>> barring further objections, push to drm-misc this weekend.
> > > >>>
> > > >>> However I'm struggling with the decision whether to push to next or
> > > >>> fixes.  The series is marked for stable, however the number of
> > > >>> affected machines is limited and for an issue that's been present
> > > >>> for 5 years it probably doesn't matter if it soaks another two months
> > > >>> in linux-next befor it gets backported.  Hence I tend to err on the
> > > >>> side of caution and push to next, however a case could be made that
> > > >>> fixes is more appropriate.
> > > >>>
> > > >>> I'm lacking experience making such decisions and would be interested
> > > >>> to learn how you'd handle this.
> > > >>
> > > >> I would say fixes, it doesn't look particularly scary. :)
> > > > 
> > > > Agreed. If it's good enough for stable, it's good enough for -fixes!
> > > 
> > > It's not that simple, is it? Fast-tracking patches (some of which appear
> > > to be untested) to stable without an immediate cause for urgency seems
> > > risky to me.
> > 
> > /me should be more careful what he says
> > 
> > Given where we are in the release cycle, it's barely a fast track.
> > If these go in -fixes, they'll get in -rc2 and will have plenty of
> > time to bake. If we were at rc5, it might be a different story.
> 
> The patches are marked for stable though, so if they go in through
> drm-misc-fixes, they may appear in stable kernels before 4.16-final
> is out.  Greg picks up patches once they're in Linus' tree, though
> often with a delay of a few days or weeks.  If they go in through
> drm-misc-next, they're guaranteed not to appear in *any* release
> before 4.16-final is out.
> 
> This allows for differentiation between no-brainer stable fixes that
> can be sent immediately and scarier, but similarly important stable
> fixes that should soak for a while.  I'm not sure which category
> this series belongs to, though it's true what Maarten says, it's
> not *that* grave a change.

If you're this concerned about them, then pls do _not_ put cc: stable on
the patches. Instead get them merged through -fixes (or maybe even -next),
and once they're sufficiently tested, send a mail to stable@ asking for
ane explicit backport.

Stuff that's marked for stable must be obviuos and tested enough for
backporting right away (which doesn't seem to be the case here).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > 
> > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > with the intention of runtime resuming the device afterwards.  The result
> > is a circular wait between poll worker and autosuspend worker.
> 
> Don't shut down the poll worker when runtime suspending, that' doesn't
> work. If you need the poll work, then that means waking up the gpu every
> few seconds. If you don't need it, then make sure the DRM_CONNECTOR_POLL
> flags are set correctly (you can update them at runtime, the poll worker
> will pick that up).
> 
> That should fix the deadlock, and it's how we do it in i915 (where igt in
> CI totally hammers the runtime pm support, and it seems to hold up).

It would fix the deadlock but it's not an option on dual GPU laptops.
Power consumption of the discrete GPU is massive (9 W on my machine).


> > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > on runtime suspend.  But this results in the GPU bouncing back and forth
> > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > runtime suspend to D3cold since every suspend/resume cycle costs a
> > significant amount of time and energy.  (i915 and malidp do not seem
> > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > questionable.  msm however does and would also deadlock if it disabled
> > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> 
> Well, userspace expects hotplug events, even when we runtime suspend
> stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> pretty serious policy decision which is ok in the context of
> vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> up if you plug something in, even with all the runtime pm stuff enabled.
> Same for sata and everything else.

On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
the gmux controller, which sends an interrupt on hotplug even if the GPU
is powered down.

Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.

For the rare cases where an external VGA or DVI-A port is present, I guess
it's reasonable to have the user wake up the machine manually.

I'm not sure why nouveau polls ports on my laptop, the GK107 only has an
LVDS and three DP ports, need to investigate.

Thanks,

Lukas

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > 
> > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > with the intention of runtime resuming the device afterwards.  The result
> > is a circular wait between poll worker and autosuspend worker.
> 
> Don't shut down the poll worker when runtime suspending, that' doesn't
> work. If you need the poll work, then that means waking up the gpu every
> few seconds. If you don't need it, then make sure the DRM_CONNECTOR_POLL
> flags are set correctly (you can update them at runtime, the poll worker
> will pick that up).
> 
> That should fix the deadlock, and it's how we do it in i915 (where igt in
> CI totally hammers the runtime pm support, and it seems to hold up).

It would fix the deadlock but it's not an option on dual GPU laptops.
Power consumption of the discrete GPU is massive (9 W on my machine).


> > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > on runtime suspend.  But this results in the GPU bouncing back and forth
> > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > runtime suspend to D3cold since every suspend/resume cycle costs a
> > significant amount of time and energy.  (i915 and malidp do not seem
> > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > questionable.  msm however does and would also deadlock if it disabled
> > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> 
> Well, userspace expects hotplug events, even when we runtime suspend
> stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> pretty serious policy decision which is ok in the context of
> vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> up if you plug something in, even with all the runtime pm stuff enabled.
> Same for sata and everything else.

On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
the gmux controller, which sends an interrupt on hotplug even if the GPU
is powered down.

Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.

For the rare cases where an external VGA or DVI-A port is present, I guess
it's reasonable to have the user wake up the machine manually.

I'm not sure why nouveau polls ports on my laptop, the GK107 only has an
LVDS and three DP ports, need to investigate.

Thanks,

Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 19, 2018 at 12:48:04PM +0100, Daniel Vetter wrote:
> On Thu, Feb 15, 2018 at 06:38:44AM +0100, Lukas Wunner wrote:
> > On Wed, Feb 14, 2018 at 09:58:43AM -0500, Sean Paul wrote:
> > > On Wed, Feb 14, 2018 at 03:43:56PM +0100, Michel Dänzer wrote:
> > > > On 2018-02-14 03:08 PM, Sean Paul wrote:
> > > > > On Wed, Feb 14, 2018 at 10:26:35AM +0100, Maarten Lankhorst wrote:
> > > > >> Op 14-02-18 om 09:46 schreef Lukas Wunner:
> > > > >>> On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > > >>>> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > > > >>> This series has been reviewed, consent has been expressed by the most
> > > > >>> interested parties, patch [1/5] which touches files outside drivers/gpu
> > > > >>> has been acked and I've just out a v2 addressing the only objection
> > > > >>> raised.  My plan is thus to wait another two days for comments and,
> > > > >>> barring further objections, push to drm-misc this weekend.
> > > > >>>
> > > > >>> However I'm struggling with the decision whether to push to next or
> > > > >>> fixes.  The series is marked for stable, however the number of
> > > > >>> affected machines is limited and for an issue that's been present
> > > > >>> for 5 years it probably doesn't matter if it soaks another two months
> > > > >>> in linux-next befor it gets backported.  Hence I tend to err on the
> > > > >>> side of caution and push to next, however a case could be made that
> > > > >>> fixes is more appropriate.
> > > > >>>
> > > > >>> I'm lacking experience making such decisions and would be interested
> > > > >>> to learn how you'd handle this.
> > > > >>
> > > > >> I would say fixes, it doesn't look particularly scary. :)
> > > > > 
> > > > > Agreed. If it's good enough for stable, it's good enough for -fixes!
> > > > 
> > > > It's not that simple, is it? Fast-tracking patches (some of which appear
> > > > to be untested) to stable without an immediate cause for urgency seems
> > > > risky to me.
> > > 
> > > /me should be more careful what he says
> > > 
> > > Given where we are in the release cycle, it's barely a fast track.
> > > If these go in -fixes, they'll get in -rc2 and will have plenty of
> > > time to bake. If we were at rc5, it might be a different story.
> > 
> > The patches are marked for stable though, so if they go in through
> > drm-misc-fixes, they may appear in stable kernels before 4.16-final
> > is out.  Greg picks up patches once they're in Linus' tree, though
> > often with a delay of a few days or weeks.  If they go in through
> > drm-misc-next, they're guaranteed not to appear in *any* release
> > before 4.16-final is out.
> > 
> > This allows for differentiation between no-brainer stable fixes that
> > can be sent immediately and scarier, but similarly important stable
> > fixes that should soak for a while.  I'm not sure which category
> > this series belongs to, though it's true what Maarten says, it's
> > not *that* grave a change.
> 
> If you're this concerned about them, then pls do _not_ put cc: stable on
> the patches. Instead get them merged through -fixes (or maybe even -next),
> and once they're sufficiently tested, send a mail to stable@ asking for
> ane explicit backport.

I'm not concerned about them, but would have erred on the side of caution.
However consensus seems to have been that they're sufficiently unscary to
push to -fixes.  Do you disagree with that decision, if so, why?  Can we
amend the dim docs to codify guidelines whether to push to -fixes or -next?
I allowed 1 week for comments, now you're returning from vacation and seem
to be unhappy, was 1 week too short?

Thanks,

Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > > 
> > > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > > with the intention of runtime resuming the device afterwards.  The result
> > > is a circular wait between poll worker and autosuspend worker.
> > 
> > Don't shut down the poll worker when runtime suspending, that' doesn't
> > work. If you need the poll work, then that means waking up the gpu every
> > few seconds. If you don't need it, then make sure the DRM_CONNECTOR_POLL
> > flags are set correctly (you can update them at runtime, the poll worker
> > will pick that up).
> > 
> > That should fix the deadlock, and it's how we do it in i915 (where igt in
> > CI totally hammers the runtime pm support, and it seems to hold up).
> 
> It would fix the deadlock but it's not an option on dual GPU laptops.
> Power consumption of the discrete GPU is massive (9 W on my machine).
> 
> 
> > > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > > on runtime suspend.  But this results in the GPU bouncing back and forth
> > > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > > runtime suspend to D3cold since every suspend/resume cycle costs a
> > > significant amount of time and energy.  (i915 and malidp do not seem
> > > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > > questionable.  msm however does and would also deadlock if it disabled
> > > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> > 
> > Well, userspace expects hotplug events, even when we runtime suspend
> > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > pretty serious policy decision which is ok in the context of
> > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > up if you plug something in, even with all the runtime pm stuff enabled.
> > Same for sata and everything else.
> 
> On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> the gmux controller, which sends an interrupt on hotplug even if the GPU
> is powered down.
> 
> Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.

Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
makes sense. I think ideally we'd stop polling in the gmux handler somehow
(maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
stopping it all). But not when runtime suspending the entire gpu (e.g.
idle system that shuts down the screen and everything, before it decides
a few minutes later to do a full system suspend).

I also think that this approach would lead to cleaner code, having
explicit checks for the (locking) execution context all over the place
tends to result in regrets eventually ime.

> For the rare cases where an external VGA or DVI-A port is present, I guess
> it's reasonable to have the user wake up the machine manually.
> 
> I'm not sure why nouveau polls ports on my laptop, the GK107 only has an
> LVDS and three DP ports, need to investigate.

Yeah, that'd be good to figure out. The probe helpers should shut down the
worker if there's no connector that needs probing. We use that to
enable/disable the poll worker when there's a hotplug storm on the irq
line.

Once that's fixed we can perhaps also untangle the poll-vs-gmux story.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > On Sun, Feb 11, 2018 at 10:38:28AM +0100, Lukas Wunner wrote:
> > > Fix a deadlock on hybrid graphics laptops that's been present since 2013:
> > > 
> > > DRM drivers poll connectors in 10 sec intervals.  The poll worker is
> > > stopped on ->runtime_suspend with cancel_delayed_work_sync().  However
> > > the poll worker invokes the DRM drivers' ->detect callbacks, which call
> > > pm_runtime_get_sync().  If the poll worker starts after runtime suspend
> > > has begun, pm_runtime_get_sync() will wait for runtime suspend to finish
> > > with the intention of runtime resuming the device afterwards.  The result
> > > is a circular wait between poll worker and autosuspend worker.
> > 
> > Don't shut down the poll worker when runtime suspending, that' doesn't
> > work. If you need the poll work, then that means waking up the gpu every
> > few seconds. If you don't need it, then make sure the DRM_CONNECTOR_POLL
> > flags are set correctly (you can update them at runtime, the poll worker
> > will pick that up).
> > 
> > That should fix the deadlock, and it's how we do it in i915 (where igt in
> > CI totally hammers the runtime pm support, and it seems to hold up).
> 
> It would fix the deadlock but it's not an option on dual GPU laptops.
> Power consumption of the discrete GPU is massive (9 W on my machine).
> 
> 
> > > i915, malidp and msm "solved" this issue by not stopping the poll worker
> > > on runtime suspend.  But this results in the GPU bouncing back and forth
> > > between D0 and D3 continuously.  That's a total no-go for GPUs which
> > > runtime suspend to D3cold since every suspend/resume cycle costs a
> > > significant amount of time and energy.  (i915 and malidp do not seem
> > > to acquire a runtime PM ref in the ->detect callbacks, which seems
> > > questionable.  msm however does and would also deadlock if it disabled
> > > the poll worker on runtime suspend.  cc += Archit, Liviu, intel-gfx)
> > 
> > Well, userspace expects hotplug events, even when we runtime suspend
> > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > pretty serious policy decision which is ok in the context of
> > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > up if you plug something in, even with all the runtime pm stuff enabled.
> > Same for sata and everything else.
> 
> On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> the gmux controller, which sends an interrupt on hotplug even if the GPU
> is powered down.
> 
> Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.

Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
makes sense. I think ideally we'd stop polling in the gmux handler somehow
(maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
stopping it all). But not when runtime suspending the entire gpu (e.g.
idle system that shuts down the screen and everything, before it decides
a few minutes later to do a full system suspend).

I also think that this approach would lead to cleaner code, having
explicit checks for the (locking) execution context all over the place
tends to result in regrets eventually ime.

> For the rare cases where an external VGA or DVI-A port is present, I guess
> it's reasonable to have the user wake up the machine manually.
> 
> I'm not sure why nouveau polls ports on my laptop, the GK107 only has an
> LVDS and three DP ports, need to investigate.

Yeah, that'd be good to figure out. The probe helpers should shut down the
worker if there's no connector that needs probing. We use that to
enable/disable the poll worker when there's a hotplug storm on the irq
line.

Once that's fixed we can perhaps also untangle the poll-vs-gmux story.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > > Well, userspace expects hotplug events, even when we runtime suspend
> > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > > pretty serious policy decision which is ok in the context of
> > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > > up if you plug something in, even with all the runtime pm stuff enabled.
> > > Same for sata and everything else.
> > 
> > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> > the gmux controller, which sends an interrupt on hotplug even if the GPU
> > is powered down.
> > 
> > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
> 
> Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
> makes sense. I think ideally we'd stop polling in the gmux handler somehow
> (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
> stopping it all). But not when runtime suspending the entire gpu (e.g.
> idle system that shuts down the screen and everything, before it decides
> a few minutes later to do a full system suspend).

nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
graphics laptops.

Should the drivers later be extended to also use runtime PM in other
scenarios (desktop machines, eGPUs), they can easily detect whether
to disable polling on runtime suspend by calling apple_gmux_present()
on Macs or the equivalent for Optimus/ATPX.

Thanks,

Lukas

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Lukas Wunner]

On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > > Well, userspace expects hotplug events, even when we runtime suspend
> > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > > pretty serious policy decision which is ok in the context of
> > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > > up if you plug something in, even with all the runtime pm stuff enabled.
> > > Same for sata and everything else.
> > 
> > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> > the gmux controller, which sends an interrupt on hotplug even if the GPU
> > is powered down.
> > 
> > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
> 
> Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
> makes sense. I think ideally we'd stop polling in the gmux handler somehow
> (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
> stopping it all). But not when runtime suspending the entire gpu (e.g.
> idle system that shuts down the screen and everything, before it decides
> a few minutes later to do a full system suspend).

nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
graphics laptops.

Should the drivers later be extended to also use runtime PM in other
scenarios (desktop machines, eGPUs), they can easily detect whether
to disable polling on runtime suspend by calling apple_gmux_present()
on Macs or the equivalent for Optimus/ATPX.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Mon, Feb 19, 2018 at 03:47:42PM +0100, Lukas Wunner wrote:
> On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > > > Well, userspace expects hotplug events, even when we runtime suspend
> > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > > > pretty serious policy decision which is ok in the context of
> > > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > > > up if you plug something in, even with all the runtime pm stuff enabled.
> > > > Same for sata and everything else.
> > > 
> > > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> > > the gmux controller, which sends an interrupt on hotplug even if the GPU
> > > is powered down.
> > > 
> > > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
> > 
> > Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
> > makes sense. I think ideally we'd stop polling in the gmux handler somehow
> > (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
> > stopping it all). But not when runtime suspending the entire gpu (e.g.
> > idle system that shuts down the screen and everything, before it decides
> > a few minutes later to do a full system suspend).
> 
> nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
> graphics laptops.
> 
> Should the drivers later be extended to also use runtime PM in other
> scenarios (desktop machines, eGPUs), they can easily detect whether
> to disable polling on runtime suspend by calling apple_gmux_present()
> on Macs or the equivalent for Optimus/ATPX.

Ah, then I think the current solution is ok (if not entirely clean imo,
but that can be fixed up whenever it hurts). Implementing runtime pm for
other cases is up to the driver authors really (probably more pressing
when the gpu is on the same SoC).
-Daniel

> 
> Thanks,
> 
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Daniel Vetter]

On Mon, Feb 19, 2018 at 03:47:42PM +0100, Lukas Wunner wrote:
> On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
> > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
> > > > Well, userspace expects hotplug events, even when we runtime suspend
> > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
> > > > pretty serious policy decision which is ok in the context of
> > > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
> > > > up if you plug something in, even with all the runtime pm stuff enabled.
> > > > Same for sata and everything else.
> > > 
> > > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
> > > the gmux controller, which sends an interrupt on hotplug even if the GPU
> > > is powered down.
> > > 
> > > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
> > 
> > Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
> > makes sense. I think ideally we'd stop polling in the gmux handler somehow
> > (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
> > stopping it all). But not when runtime suspending the entire gpu (e.g.
> > idle system that shuts down the screen and everything, before it decides
> > a few minutes later to do a full system suspend).
> 
> nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
> graphics laptops.
> 
> Should the drivers later be extended to also use runtime PM in other
> scenarios (desktop machines, eGPUs), they can easily detect whether
> to disable polling on runtime suspend by calling apple_gmux_present()
> on Macs or the equivalent for Optimus/ATPX.

Ah, then I think the current solution is ok (if not entirely clean imo,
but that can be fixed up whenever it hurts). Implementing runtime pm for
other cases is up to the driver authors really (probably more pressing
when the gpu is on the same SoC).
-Daniel

> 
> Thanks,
> 
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 19, 2018 at 9:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Feb 19, 2018 at 03:47:42PM +0100, Lukas Wunner wrote:
>> On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
>> > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
>> > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
>> > > > Well, userspace expects hotplug events, even when we runtime suspend
>> > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
>> > > > pretty serious policy decision which is ok in the context of
>> > > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
>> > > > up if you plug something in, even with all the runtime pm stuff enabled.
>> > > > Same for sata and everything else.
>> > >
>> > > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
>> > > the gmux controller, which sends an interrupt on hotplug even if the GPU
>> > > is powered down.
>> > >
>> > > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
>> >
>> > Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
>> > makes sense. I think ideally we'd stop polling in the gmux handler somehow
>> > (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
>> > stopping it all). But not when runtime suspending the entire gpu (e.g.
>> > idle system that shuts down the screen and everything, before it decides
>> > a few minutes later to do a full system suspend).
>>
>> nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
>> graphics laptops.
>>
>> Should the drivers later be extended to also use runtime PM in other
>> scenarios (desktop machines, eGPUs), they can easily detect whether
>> to disable polling on runtime suspend by calling apple_gmux_present()
>> on Macs or the equivalent for Optimus/ATPX.
>
> Ah, then I think the current solution is ok (if not entirely clean imo,
> but that can be fixed up whenever it hurts). Implementing runtime pm for
> other cases is up to the driver authors really (probably more pressing
> when the gpu is on the same SoC).

On our APUs, we support fairly fine grained powergating so this mostly
happens auto-magically in hw; no need for runtimepm.  We haven't
supported native analog encoders in last 3 or 4 generations of display
hw, so polling is not much of an issue going forward.  On most
integrated platforms (e.g., laptops and all-in-ones), digital hotplug
is handled by the platform (we get an ACPI ATIF notification) so we
can wake the dGPU.

Alex

> -Daniel
>
>>
>> Thanks,
>>
>> Lukas
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [Nouveau] [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers

[Alex Deucher]

On Mon, Feb 19, 2018 at 9:54 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Feb 19, 2018 at 03:47:42PM +0100, Lukas Wunner wrote:
>> On Mon, Feb 19, 2018 at 03:05:53PM +0100, Daniel Vetter wrote:
>> > On Mon, Feb 19, 2018 at 12:58:17PM +0100, Lukas Wunner wrote:
>> > > On Mon, Feb 19, 2018 at 12:34:43PM +0100, Daniel Vetter wrote:
>> > > > Well, userspace expects hotplug events, even when we runtime suspend
>> > > > stuff. Hence waking shit up with polling. Imo ignoring hotplug events is a
>> > > > pretty serious policy decision which is ok in the context of
>> > > > vga_switcheroo, but not really as an automatic thing. E.g. usb also wakes
>> > > > up if you plug something in, even with all the runtime pm stuff enabled.
>> > > > Same for sata and everything else.
>> > >
>> > > On the MacBook Pro, the HPD pin of external DP and HDMI ports goes into
>> > > the gmux controller, which sends an interrupt on hotplug even if the GPU
>> > > is powered down.
>> > >
>> > > Apparently Optimus has a similar functionality, cf. 3a6536c51d5d.
>> >
>> > Yeah, for vga_switcheroo and gmux setups shutting down polling explicitly
>> > makes sense. I think ideally we'd stop polling in the gmux handler somehow
>> > (maybe by dropping the relevant DRM_CONNECTOR_POLL flags, or outright
>> > stopping it all). But not when runtime suspending the entire gpu (e.g.
>> > idle system that shuts down the screen and everything, before it decides
>> > a few minutes later to do a full system suspend).
>>
>> nouveau, radeon and amdgpu currently use runtime PM *only* on hybrid
>> graphics laptops.
>>
>> Should the drivers later be extended to also use runtime PM in other
>> scenarios (desktop machines, eGPUs), they can easily detect whether
>> to disable polling on runtime suspend by calling apple_gmux_present()
>> on Macs or the equivalent for Optimus/ATPX.
>
> Ah, then I think the current solution is ok (if not entirely clean imo,
> but that can be fixed up whenever it hurts). Implementing runtime pm for
> other cases is up to the driver authors really (probably more pressing
> when the gpu is on the same SoC).

On our APUs, we support fairly fine grained powergating so this mostly
happens auto-magically in hw; no need for runtimepm.  We haven't
supported native analog encoders in last 3 or 4 generations of display
hw, so polling is not much of an issue going forward.  On most
integrated platforms (e.g., laptops and all-in-ones), digital hotplug
is handled by the platform (we get an ACPI ATIF notification) so we
can wake the dGPU.

Alex

> -Daniel
>
>>
>> Thanks,
>>
>> Lukas
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel