<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - MinnowBoard MAX fails to suspend twice in a row with i915 module loaded"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89611">89611</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>MinnowBoard MAX fails to suspend twice in a row with i915 module loaded
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>XOrg git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dvhart@linux.intel.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=114387" name="attach_114387" title="dmesg following the first resume">attachment 114387</a> <a href="attachment.cgi?id=114387&action=edit" title="dmesg following the first resume">[details]</a></span>
dmesg following the first resume
I've observed that from at least 3.17.1 through 3.19.1 (I don't know if
this worked previously), the MinnowBoard MAX (Firmware 0.77 or 0.78) will
suspend and resume successfully once, but fail to suspend after the
initial resume.
$ echo mem > /sys/power/state
<suspends successfully>
<press and release power button>
<system resumes>
The following Intel DRM PM warning appears on the console:
[ 67.772124] ------------[ cut here ]------------
[ 67.784552] WARNING: CPU: 0 PID: 570 at
drivers/gpu/drm/i915/intel_pm.c:5043
intel_gen6_powersave_work+0xf6a/0x11d0()
[ 67.803814] WARN_ON(pctx_addr != dev_priv->mm.stolen_base +
dev_priv->vlv_pctx->stolen->start)
[ 67.813591] Modules linked in: iptable_nat nf_nat_ipv4 nf_nat i2c_i801
dw_dmac dw_dmac_core i2c_designware_platform i2c_designware_core
spi_pxa2xx_platform
[ 67.844750] CPU: 0 PID: 570 Comm: kworker/0:1 Tainted: G W
3.19.1 #2
[ 67.860960] Hardware name: Circuitco MinnowBoard MAX B3
PLATFORM/MinnowBoard MAX, BIOS MNW2MAX1.X64.0078.R01.1503091142 03/09/2015
[ 67.882352] Workqueue: events intel_gen6_powersave_work
[ 67.896476] ffffffff81c0b548 ffff88003a933cf8 ffffffff818b52b3
ffff88003940ea30
[ 67.913321] ffff88003a933d48 ffff88003a933d38 ffffffff8104ef85
ffff88003a933d28
[ 67.928496] ffff88003abf0000 ffff880038c00000 ffff88003abf8828
ffff88003abf88c0
[ 67.942521] Call Trace:
[ 67.950068] [<ffffffff818b52b3>] dump_stack+0x45/0x57
[ 67.960676] [<ffffffff8104ef85>] warn_slowpath_common+0x85/0xc0
[ 67.971700] [<ffffffff8104f001>] warn_slowpath_fmt+0x41/0x50
[ 67.981949] [<ffffffff81427d4a>] intel_gen6_powersave_work+0xf6a/0x11d0
[ 67.992920] [<ffffffff8112c953>] ? vmstat_shepherd+0x123/0x140
[ 68.002707] [<ffffffff81065cb0>] process_one_work+0x150/0x400
[ 68.012393] [<ffffffff810662bb>] worker_thread+0x6b/0x480
[ 68.021690] [<ffffffff81066250>] ? rescuer_thread+0x2f0/0x2f0
[ 68.031389] [<ffffffff8106ac06>] kthread+0xd6/0xf0
[ 68.040002] [<ffffffff8106ab30>] ? kthread_create_on_node+0x180/0x180
[ 68.050507] [<ffffffff818bd56c>] ret_from_fork+0x7c/0xb0
[ 68.059745] [<ffffffff8106ab30>] ? kthread_create_on_node+0x180/0x180
[ 68.070263] ---[ end trace be1bc8f8605e963c ]---
$ echo mem > /sys/power/state
[ 98.340941] PM: Syncing filesystems ... done.
[ 98.357282] PM: Preparing system for mem sleep
[ 98.376033] Freezing user space processes ... (elapsed 0.001 seconds)
done.
[ 98.395983] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[ 98.416075] PM: Entering mem sleep
[ 98.430013] Suspending console(s) (use no_console_suspend to debug)
The system does not suspend (display does not enter standby), and is
non-responsive to USB keyboard and serial console input.
If I blacklist the i915 module, the system will suspend and resume successfully
repeatedly (I tried four in a row).
I have attached a dmesg log following the first successful resume with
drm.debug=14. I saw no drm output after issuing the second suspend command.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>