| Summary: | [BYT] suspend/resume failure on MinnowBoard MAX | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Darren Hart <dvhart> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | major | ||||||||
| Priority: | high | CC: | intel-gfx-bugs | ||||||
| Version: | XOrg git | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 114388 [details]
Linux kernel .config for 3.19.1
I've set the Importance per my perspective to high/major as this has a significant functional impact to the MinnowBoard MAX board. I just tried with current bits and it doesn't even suspend/resume once. that one looks like an internal JIRA we have open, VIZ-5153. This one looks different though... maybe I should update my minnowboard BIOS and see if that changes anything. Please do use the latest firmware. 0.78 is available here, including an EFI flash utility: https://firmware.intel.com/projects/minnowboard-max The SMBIOS strings will report the current version if you want to compare. I believe the following works (sorry, don't have one handy atm): $ dmidecode | grep -A2 BIOS Can you try these two patches: http://lists.freedesktop.org/archives/intel-gfx/2015-April/063729.html http://lists.freedesktop.org/archives/intel-gfx/2015-April/063728.html on top of today's drm-intel-nightly. My minnowboardmax behaves much better with them applied. With these two patches applied on top of drm-intel-nightly, my MinnowBoard MAX passed two sequential suspend/resume cycles. Awesome. Thank you. How far back can we apply these to stable? I know the MinnowMax is unreliable at least as far back as 3.17, possibly earlier. (Darren, please remember to clear "NEEDINFO" status after responding) commit 5df0582bf036bb5f9a8ad8db5884fe13a55347d1 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Apr 1 14:22:58 2015 -0700 drm/i915/vlv: remove wait for previous GFX clk disable request Looks like it was introduced in: And also backported to 3.19.5. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 114387 [details] 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.