search for: rpm_resume

...I think we do in fact resume PCI devices before shutdown. Here's the path I'm looking at: device_shutdown pm_runtime_get_noresume pm_runtime_barrier dev->bus->shutdown pci_device_shutdown pm_runtime_resume __pm_runtime_resume(dev, 0) rpm_resume(dev, 0) __update_runtime_status(dev, RPM_RESUMING) callback = RPM_GET_CALLBACK(dev, runtime_resume) rpm_callback(callback, dev) __rpm_callback pci_pm_runtime_resume drv->pm->runtime_resume...

...ff917c0de3d360 [ 246.899587] 0000000000000086 000000000de3d360 ffff917c165da058 0000000000000000 [ 246.899593] Call Trace: [ 246.899601] [<ffffffff8c920fab>] ? __schedule+0x2fb/0xb30 [ 246.899605] [<ffffffff8c921820>] schedule+0x40/0x90 [ 246.899608] [<ffffffff8c5ff8da>] rpm_resume+0x14a/0x740 [ 246.899614] [<ffffffff8c0e1c10>] ? wake_atomic_t_function+0x60/0x60 [ 246.899617] [<ffffffff8c6012e3>] pm_runtime_forbid+0x43/0x50 [ 246.899678] [<ffffffffc08f67c5>] nouveau_pmops_runtime_suspend+0xc5/0xd0 [nouveau] [ 246.899684] [<ffffffff8c4ced8d>] p...

..._pmops_runtime_resume+0x72/0x150 [nouveau] [ 56.593381] pci_pm_runtime_resume+0x7b/0xa0 [ 56.593382] __rpm_callback+0xc6/0x210 [ 56.593383] ? pci_restore_standard_config+0x40/0x40 [ 56.593384] rpm_callback+0x24/0x80 [ 56.593385] ? pci_restore_standard_config+0x40/0x40 [ 56.593385] rpm_resume+0x47d/0x680 [ 56.593400] ? i915_gem_timeline_init+0xe/0x10 [i915] [ 56.593401] __pm_runtime_resume+0x4f/0x80 [ 56.593415] nouveau_drm_open+0x3b/0x1b0 [nouveau] [ 56.593417] ? security_capable+0x48/0x60 [ 56.593423] drm_open+0x205/0x3f0 [drm] [ 56.593428] drm_stub_open+0xb6/0x110 [...

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. -

...ack bothers with using this special pm_runtime_put_autosuspend() thing, which really means "do a runtime_put(), but skip my .runtime_idle() callback". > > > > > > > > Moreover, it's similar for pm_runtime_mark_last_busy(), it's called > > > during rpm_resume() too, for example. So why bother about having > > > "mark_last_busy" in the new name too. > > > > > > That said, my suggestion is simply "pm_runtime_put_suspend". > > > > Can we do even better, and make pm_runtime_put() to handle autosuspe...

...disables this message. > [ 861.486332] kworker/0:2 D 0 61 2 0x80000000 > [ 861.487044] Workqueue: events nouveau_display_hpd_work [nouveau] > [ 861.487737] Call Trace: > [ 861.488394] __schedule+0x322/0xaf0 > [ 861.489070] schedule+0x33/0x90 > [ 861.489744] rpm_resume+0x19c/0x850 > [ 861.490392] ? finish_wait+0x90/0x90 > [ 861.491068] __pm_runtime_resume+0x4e/0x90 > [ 861.491753] nouveau_display_hpd_work+0x22/0x60 [nouveau] > [ 861.492416] process_one_work+0x231/0x620 > [ 861.493068] worker_thread+0x44/0x3a0 > [ 861.493722] kthread+...

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Cc: Karol Herbst <karolherbst at gmail.com> Cc: stable

...utdown. Here's the > path I'm looking at: > > device_shutdown > pm_runtime_get_noresume > pm_runtime_barrier > dev->bus->shutdown > pci_device_shutdown > pm_runtime_resume > __pm_runtime_resume(dev, 0) > rpm_resume(dev, 0) > __update_runtime_status(dev, RPM_RESUMING) > callback = RPM_GET_CALLBACK(dev, runtime_resume) > rpm_callback(callback, dev) > __rpm_callback > pci_pm_runtime_resume > drv->...

...[nouveau] [ 201.039215] nouveau_do_resume+0x19f/0x570 [nouveau] [ 201.039256] nouveau_pmops_runtime_resume+0xd8/0x2a0 [nouveau] [ 201.039264] pci_pm_runtime_resume+0x130/0x250 [ 201.039269] ? pci_restore_standard_config+0x70/0x70 [ 201.039275] __rpm_callback+0x1f2/0x5d0 [ 201.039279] ? rpm_resume+0x560/0x18a0 [ 201.039283] ? pci_restore_standard_config+0x70/0x70 [ 201.039287] ? pci_restore_standard_config+0x70/0x70 [ 201.039291] ? pci_restore_standard_config+0x70/0x70 [ 201.039296] rpm_callback+0x175/0x210 [ 201.039300] ? pci_restore_standard_config+0x70/0x70 [ 201.039305] rpm_r...

...succeeds to idle the device. In that case, it tags on the RPM_AUTO flag in the call to rpm_suspend(). Quite similar to what is happening when calling pm_runtime_put_autosuspend(). > > > > > Moreover, it's similar for pm_runtime_mark_last_busy(), it's called > > during rpm_resume() too, for example. So why bother about having > > "mark_last_busy" in the new name too. > > > > That said, my suggestion is simply "pm_runtime_put_suspend". > > Can we do even better, and make pm_runtime_put() to handle autosuspend > automatically whe...

...ion of refs further up in the call stack. 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() conflict...

.../hung_task_timeout_secs" disables this message. [ 861.486332] kworker/0:2 D 0 61 2 0x80000000 [ 861.487044] Workqueue: events nouveau_display_hpd_work [nouveau] [ 861.487737] Call Trace: [ 861.488394] __schedule+0x322/0xaf0 [ 861.489070] schedule+0x33/0x90 [ 861.489744] rpm_resume+0x19c/0x850 [ 861.490392] ? finish_wait+0x90/0x90 [ 861.491068] __pm_runtime_resume+0x4e/0x90 [ 861.491753] nouveau_display_hpd_work+0x22/0x60 [nouveau] [ 861.492416] process_one_work+0x231/0x620 [ 861.493068] worker_thread+0x44/0x3a0 [ 861.493722] kthread+0x12b/0x150 [ 861.494342] ?...

...ning X which is very stable, can run for days. Also terminating the X server looks uneventful. *** *** Starting the second X-server hangs... *** [root at optiplex ~]# ps axf | grep X 4173 pts/1 D+ 0:00 | \_ /usr/bin/Xorg.wrap [root at optiplex ~]# cat /proc/4173/wchan rpm_resume [root at optiplex ~]# cat /proc/4173/syscall 2 0x7fffc7a788c0 0x2 0x7fffc7a788ce 0x690 0x7f0c3e0ed140 0x0 0x7fffc7a77fb0 0x7f0c3e06a330 [root at optiplex ~]# cat /proc/4173/stack [<ffffffff8146b222>] rpm_resume+0x220/0x4b7 [<ffffffff8146b4fb>] __pm_runtime_resume+0x42/0x5e [<ffff...

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.

...king 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 notice that drm_dp_mst_link_probe_work() is the ->work element in drm_dp_mst_topology_mgr() and is queued on...

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Next version of

...) 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 worke...

...est" problem, so you should consider opening a new bug > report for it. As previously, no (real) badness by just modprobing nouveau. Starting Xorg on top of it (though while having other Xorg running on radeon, but from local linux console) gets my a stuck Xorg: [<ffffffff815704ac>] rpm_resume+0x18c/0x5c0 [<ffffffff81570928>] __pm_runtime_resume+0x48/0x70 [<ffffffffa00914af>] nouveau_drm_open+0x3f/0x230 [nouveau] [<ffffffff8144123d>] drm_open+0x1ad/0x4b0 [<ffffffff81447711>] drm_stub_open+0xb1/0x130 [<ffffffff811c6371>] chrdev_open+0xb1/0x190 [<ffffffff81...

...uveau] > [<ffffffff812ac745>] ? pci_pm_runtime_resume+0x85/0xc0 > [<ffffffff812ac6c0>] ? pci_restore_standard_config+0x30/0x30 > [<ffffffff8137b6f6>] ? __rpm_callback+0x36/0x80 > [<ffffffff8137b768>] ? rpm_callback+0x28/0x90 > [<ffffffff8137c48d>] ? rpm_resume+0x39d/0x570 > [<ffffffff81071483>] ? __wake_up+0x43/0x70 > [<ffffffff8137c8f8>] ? __pm_runtime_resume+0x48/0x70 > [<ffffffffa020e5a2>] ? nouveau_drm_open+0x42/0x1d0 [nouveau] > [<ffffffff811bb858>] ? ext4_da_write_end+0xa8/0x2b0 > [<ffffffff811ef559&gt...

...the call stack. > > 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() t...