search for: rpm_suspend

...39;ve posted could be resolved using > > the technique I used in d61a5c106351 by adding the following to > > include/linux/pm_runtime.h: > > > > static inline bool pm_runtime_status_suspending(struct device *dev) > > { > > return dev->power.runtime_status == RPM_SUSPENDING; > > } > > > > static inline bool is_pm_work(struct device *dev) > > { > > struct work_struct *work = current_work(); > > > > return work && work->func == dev->power.work; > > } > > > > Then adding this to nvkm_i2c_au...

...4ced30>] ? pci_pm_runtime_resume+0xa0/0xa0 [ 246.899690] [<ffffffff8c5ff252>] __rpm_callback+0x32/0x70 [ 246.899693] [<ffffffff8c5ff2b4>] rpm_callback+0x24/0x80 [ 246.899695] [<ffffffff8c4ced30>] ? pci_pm_runtime_resume+0xa0/0xa0 [ 246.899698] [<ffffffff8c5fffee>] rpm_suspend+0x11e/0x6f0 [ 246.899701] [<ffffffff8c60149b>] pm_runtime_work+0x7b/0xc0 [ 246.899707] [<ffffffff8c0afe58>] process_one_work+0x1f8/0x750 [ 246.899710] [<ffffffff8c0afdd9>] ? process_one_work+0x179/0x750 [ 246.899713] [<ffffffff8c0b03fb>] worker_thread+0x4b/0x4f0 [ 2...

After resuming more than once on battery these HP Ivybridge laptops, the XHCI devices stop working. Have anyone seen this before? I wanted to check before diving in deeper. Let me know if you have any ideas. Thanks! Facts - Xen 4.0.3, Linux 3.2.7 PVOPs - Happens on HP Ivybridge. Doesn''t happen on very similar HP Sandybridge Clash system. - Happens on battery, but not on AC. -

...mediately afterwards. The deadlock in the stack trace you've posted could be resolved using the technique I used in d61a5c106351 by adding the following to include/linux/pm_runtime.h: static inline bool pm_runtime_status_suspending(struct device *dev) { return dev->power.runtime_status == RPM_SUSPENDING; } static inline bool is_pm_work(struct device *dev) { struct work_struct *work = current_work(); return work && work->func == dev->power.work; } Then adding this to nvkm_i2c_aux_acquire(): struct device *dev = pad->i2c->subdev.device->dev; if (!(is_pm_work(dev) &...

...otplug interrupts in nouveau_display_fini() 3. hotplug is handled, display is lit up 4. runtime_suspend worker waits for hotplug handler to finish 5. GPU is runtime suspended and the newly plugged in display goes black The call to pm_runtime_mark_last_busy() has no effect in this situation because rpm_suspend() doesn't look at the last_busy variable after the call to rpm_callback(). What's necessary here is that runtime_suspend is aborted and -EBUSY returned. Thanks, Lukas > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: stable at vger.kernel.org > Cc: Lukas Wunne...

...ack. E.g., if the user forces connector probing via sysfs, a runtime PM ref should be acquired in status_store() in drm_sysfs.c before invoking connector->funcs->fill_modes(). That way, if the user forces connector probing while the GPU is powering down, rpm_resume() will correctly wait for rpm_suspend() to finish before resuming the card. So if we architect it like this, we're actually using the functionality provided by the PM core in the way that it's supposed to be used. The problem is that adding pm_runtime_get_sync() to status_store() conflicts with the desire to have a library of...

...uspend+0x5c/0x160 > [ 12.768419] ? __rpm_callback+0xb6/0x1e0 > [ 12.768423] ? kobject_uevent_env+0x111/0x5e0 > [ 12.768425] ? pci_pm_runtime_resume+0xa0/0xa0 > [ 12.768427] ? rpm_callback+0x1f/0x70 > [ 12.768429] ? pci_pm_runtime_resume+0xa0/0xa0 > [ 12.768431] ? rpm_suspend+0x11f/0x640 > [ 12.768441] ? drm_fb_helper_hotplug_event+0x9a/0xe0 [drm_kms_helper] > [ 12.768447] ? output_poll_execute+0x17b/0x1a0 [drm_kms_helper] > [ 12.768449] ? pm_runtime_work+0x64/0xa0 > [ 12.768453] ? process_one_work+0x1db/0x410 > [ 12.768456] ? worker_thread...

...pm_runtime_suspend+0x62/0x190 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab4796>] __rpm_callback+0x36/0x80 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab4804>] rpm_callback+0x24/0x80 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab4981>] rpm_suspend+0x121/0x650 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff94ab5fea>] pm_runtime_work+0x8a/0xc0 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff946baf9f>] process_one_work+0x17f/0x440 Aug 02 14:19:42 localhost.localdomain kernel: [<ffffffff946bc036>] worker_thr...

...__rpm_callback+0xb6/0x1e0 >>> [ 12.768423] ? kobject_uevent_env+0x111/0x5e0 >>> [ 12.768425] ? pci_pm_runtime_resume+0xa0/0xa0 >>> [ 12.768427] ? rpm_callback+0x1f/0x70 >>> [ 12.768429] ? pci_pm_runtime_resume+0xa0/0xa0 >>> [ 12.768431] ? rpm_suspend+0x11f/0x640 >>> [ 12.768441] ? drm_fb_helper_hotplug_event+0x9a/0xe0 [drm_kms_helper] >>> [ 12.768447] ? output_poll_execute+0x17b/0x1a0 [drm_kms_helper] >>> [ 12.768449] ? pm_runtime_work+0x64/0xa0 >>> [ 12.768453] ? process_one_work+0x1db/0x410 >...

We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops. For runtime-resume (which gets called on resume from normal suspend too) we must call drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock. Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI blocks to make it suitable for generic work.

...posted could be resolved using > > the technique I used in d61a5c106351 by adding the following to > > include/linux/pm_runtime.h: > > > > static inline bool pm_runtime_status_suspending(struct device *dev) > > { > > return dev->power.runtime_status == RPM_SUSPENDING; > > } > > > > static inline bool is_pm_work(struct device *dev) > > { > > struct work_struct *work = current_work(); > > > > return work && work->func == dev->power.work; > > } > > > > Then adding this to...

.../0x170 [ 1730.734393] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.734394] __rpm_callback+0xc1/0x1f0 [ 1730.734395] ? set_next_entity+0x162/0x610 [ 1730.734396] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.734397] rpm_callback+0x24/0x80 [ 1730.734398] ? pci_pm_runtime_resume+0xa0/0xa0 [ 1730.734399] rpm_suspend+0x121/0x640 [ 1730.734401] ? finish_task_switch+0x74/0x1f0 [ 1730.734402] pm_runtime_work+0x67/0x90 [ 1730.734403] process_one_work+0x1e3/0x3e0 [ 1730.734404] worker_thread+0x48/0x3f0 [ 1730.734405] kthread+0x109/0x140 [ 1730.734406] ? process_one_work+0x3e0/0x3e0 [ 1730.734407] ? kthread_cr...

On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote: > > OK, so this issue appears to be that we're calling > drm_crtc_vblank_off() on a crtc for which vblank is already disabled. > My guess is that this happens because the crtc is disabled. > > Not sure what the proper check is to see if vblanks are already disabled... Seems so, the below shut up suspend for both 8600 GT

...[nouveau] [410260.351678] pci_pm_runtime_suspend+0x58/0x140 [410260.351678] ? __switch_to_asm+0x40/0x70 [410260.351678] ? pci_pm_thaw_noirq+0xa0/0xa0 [410260.351678] __rpm_callback+0xc1/0x140 [410260.351678] ? pci_pm_thaw_noirq+0xa0/0xa0 [410260.351678] rpm_callback+0x1f/0x70 [410260.351678] rpm_suspend+0x10a/0x5a0 [410260.351678] ? __switch_to_asm+0x34/0x70 [410260.351678] pm_runtime_work+0x86/0x90 [410260.351678] process_one_work+0x19d/0x340 [410260.351678] worker_thread+0x50/0x3b0 [410260.351678] kthread+0xfb/0x130 [410260.351678] ? process_one_work+0x340/0x340 [410260.351678] ? kthread_...

...all to pm_runtime_get_sync() is not happening in output_poll_execute() but in drm_dp_mst_link_probe_work(). Looking once more at the three stack traces you've provided, we've got: - output_poll_execute() stuck waiting for fb_helper->lock which is held by drm_dp_mst_link_probe_work() - rpm_suspend() stuck waiting for output_poll_execute() to finish - drm_dp_mst_link_probe_work() stuck waiting in rpm_resume() For the moment we can ignore the first task, i.e. output_poll_execute(), and focus on the latter two. As said I'm unfamiliar with MST but browsing through drm_dp_mst_topology.c I n...

...? pci_pm_runtime_resume+0xa0/0xa0 [ 49.196384] ? intel_runtime_suspend+0x142/0x250 [i915] [ 49.196386] ? pci_pm_runtime_suspend+0x50/0x140 [ 49.196387] ? __rpm_callback+0xb1/0x1f0 [ 49.196389] ? rpm_callback+0x1a/0x70 [ 49.196390] ? pci_pm_runtime_resume+0xa0/0xa0 [ 49.196392] ? rpm_suspend+0x11d/0x670 [ 49.196396] ? _raw_write_unlock_irq+0xe/0x20 [ 49.196400] ? finish_task_switch+0xa7/0x260 [ 49.196403] ? __update_idle_core+0x1b/0xb0 [ 49.196405] ? pm_runtime_work+0x62/0xa0 [ 49.196407] ? process_one_work+0x133/0x480 [ 49.196408] ? worker_thread+0x42/0x4c0 [ 49.19...

...spend+0x238/0x2b0 [nouveau] [<ffffffffa0314b5c>] nouveau_pmops_runtime_suspend+0x5c/0xe0 [nouveau] [<ffffffff81395451>] pci_pm_runtime_suspend+0x61/0x140 [<ffffffff81470f11>] __rpm_callback+0x31/0x80 [<ffffffff81470f84>] rpm_callback+0x24/0x80 [<ffffffff81471116>] rpm_suspend+0x136/0x6d0 [<ffffffff8147279a>] pm_runtime_work+0x7a/0xb0 [<ffffffff810a68b6>] process_one_work+0x176/0x430 [<ffffffff810a754b>] worker_thread+0x11b/0x3a0 [<ffffffff810a7430>] ? rescuer_thread+0x3b0/0x3b0 [<ffffffff810ae2a1>] kthread+0xe1/0x100 [<ffffffff810a...

...using > > > the technique I used in d61a5c106351 by adding the following to > > > include/linux/pm_runtime.h: > > > > > > static inline bool pm_runtime_status_suspending(struct device *dev) > > > { > > > return dev->power.runtime_status == RPM_SUSPENDING; > > > } > > > > > > static inline bool is_pm_work(struct device *dev) > > > { > > > struct work_struct *work = current_work(); > > > > > > return work && work->func == dev->power.work; > > > } > > &g...

...dule+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: 5addcf0a5f...

...ser forces connector probing via sysfs, a runtime PM ref > should be acquired in status_store() in drm_sysfs.c before invoking > connector->funcs->fill_modes(). That way, if the user forces connector > probing while the GPU is powering down, rpm_resume() will correctly wait > for rpm_suspend() to finish before resuming the card. So if we architect > it like this, we're actually using the functionality provided by the > PM core in the way that it's supposed to be used. > > The problem is that adding pm_runtime_get_sync() to status_store() > conflicts with the de...