Bug 90232 - [BSW]S3 sporadically cause Call Trace
Summary: [BSW]S3 sporadically cause Call Trace
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-29 12:00 UTC by liulei
Modified: 2017-10-06 14:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (99.20 KB, text/plain)
2015-04-29 12:00 UTC, liulei
no flags Details
dmesg log with call trace and black screen (2.02 MB, text/plain)
2015-05-11 07:33 UTC, Jeff Zheng
no flags Details
dmesg after upgrade BIOS to V69 (447.29 KB, text/plain)
2015-05-15 01:41 UTC, Jeff Zheng
no flags Details

Description liulei 2015-04-29 12:00:05 UTC
Created attachment 115435 [details]
dmesg

==System Environment==
--------------------------
Regression: Not sure.

==kernel==
--------------------------
-testing: git tag:drm-intel-testing-2015-04-23 drm-intel-nightly: 2015y-04m-23d-19h-58m-37s UTC integration manifest (fails)

==Bug detailed description==
-----------------------------
Call Trace:
[11337.102092] ------------[ cut here ]------------
[11337.102139] WARNING: CPU: 0 PID: 13131 at drivers/gpu/drm/i915/i915_gem.c:4648 i915_gem_suspend+0xbb/0xd3 [i915]()
[11337.102149] call usb2+ returned 0 after 2463 usecs
[11337.102182] calling  0000:00:14.0+ @ 20599, parent: pci0000:00
[11337.102185] WARN_ON(dev_priv->mm.busy)
[11337.102351] Modules linked in: dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic iTCO_wdt iTCO_vendor_support pcspkr serio_raw snd_hda_intel snd_hda_controller i2c_i801 snd_hda_codec snd_hda_core lpc_ich snd_hwdep mfd_core snd_pcm snd_timer snd soundcore battery ac acpi_cpufreq i915 option
[11337.102352] call 0000:00:14.0+ returned 0 after 152 usecs
[11337.102401]  usb_wwan usbserial button video drm_kms_helper drm
[11337.102406] CPU: 0 PID: 13131 Comm: kworker/u8:41 Tainted: G        W       4.0.0_drm-intel-testing-2015-04-23+ #412
[11337.102454] Workqueue: events_unbound async_run_entry_fn
[11337.102460]  0000000000000000 0000000000000009 ffffffff81795847 ffff88017626fc78
[11337.102463]  ffffffff8103bd5a 0000000000000086 ffffffffa00e8d31 00000000000000bc
[11337.102505]  0000000000000000 ffff88007bbb0000 ffff880175ba9060 ffff88007bbb0000
[11337.102506] Call Trace:
[11337.102516]  [<ffffffff81795847>] ? dump_stack+0x40/0x50
[11337.102562]  [<ffffffff8103bd5a>] ? warn_slowpath_common+0x98/0xb0
[11337.102594]  [<ffffffffa00e8d31>] ? i915_gem_suspend+0xbb/0xd3 [i915]
[11337.102637]  [<ffffffff8103bdb7>] ? warn_slowpath_fmt+0x45/0x4a
[11337.102669]  [<ffffffffa00e8d31>] ? i915_gem_suspend+0xbb/0xd3 [i915]
[11337.102755]  [<ffffffffa00c5789>] ? i915_drm_suspend+0x59/0x1a1 [i915]
[11337.102802]  [<ffffffff8135fa1e>] ? pci_pm_suspend+0x79/0xf6
[11337.102806]  [<ffffffff8135f9a5>] ? pci_pm_freeze+0xa4/0xa4
[11337.102850]  [<ffffffff813f21a9>] ? dpm_run_callback+0x3a/0xc5
[11337.102854]  [<ffffffff813f2b17>] ? __device_suspend+0x1d1/0x25d
[11337.102894]  [<ffffffff813f2bb9>] ? async_suspend+0x16/0x7d
[11337.102898]  [<ffffffff81052783>] ? async_run_entry_fn+0x2d/0xbf
[11337.102905]  [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d
[11337.102948]  [<ffffffff8104d278>] ? worker_thread+0x24d/0x339
[11337.102953]  [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa
[11337.102958]  [<ffffffff81050b25>] ? kthread+0xce/0xd6
[11337.103000]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[11337.103005]  [<ffffffff8179b048>] ? ret_from_fork+0x58/0x90
[11337.103008]  [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162
[11337.103049] ---[ end trace a727ae3112bed330 ]---

==Reproduce steps==
---------------------------- 
1. do s3
2. check dmesg.
Comment 1 Ville Syrjala 2015-04-29 12:06:11 UTC
Does it happen with enable_execlists=0 ?
Comment 2 liulei 2015-04-29 12:10:41 UTC
The dmesg isn't complete. Because I have to run s3 so many times that i can get this Call Trace. Even though, it still can offer some slues for this issue. I will update a more complete dmesg, later.
Comment 3 Jeff Zheng 2015-05-11 07:33:18 UTC
Created attachment 115688 [details]
dmesg log with call trace and black screen

I saw this issue on drm-intel-testing-2015-05-08. When this issue appears after I suspend/resume several times, the eDP screen is black.
Comment 4 Ander Conselvan de Oliveira 2015-05-12 09:15:16 UTC
Changing to NEEDINFO, see comment 1.
Comment 5 Jeff Zheng 2015-05-15 01:41:07 UTC
Created attachment 115789 [details]
dmesg after upgrade BIOS to V69

After upgrade BIOS to V69, I still saw this issue. The eDP screen shows texts though.
Comment 6 Jeff Zheng 2015-05-15 01:50:09 UTC
And I didn't see this WARNING with enable_execlists=0
Comment 7 Ville Syrjala 2015-05-29 16:21:46 UTC
Looks like I fixed this one (now that I finally have a BIOS with working S3 on my BSW):

commit b45aa85338865bf479cda4586989fef28d580051
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu May 28 18:32:36 2015 +0300

    drm/i915: Don't skip request retirement if the active list is empty
Comment 8 ye.tian 2015-06-02 06:42:19 UTC
Test it on the latest nightly kernel, this problem does not exists.
So verified.
Comment 9 Elizabeth 2017-10-06 14:30:12 UTC
Closing old verified.


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.