==System Environment== -------------------------- Regression: No. It's first run tests on BSW Non-working platforms: BSW ==kernel== -------------------------- origin/drm-intel-nightly: BOOT_IMAGE=kernels//nightly_parents/2014_10_11/drm-intel-nightly/ea4bec8e96ea8b33b49a7892c1c7f20041a56da6/bzImage_x86_64 root=/dev/sda4 drm.debug=0xe modules_path=kernels//nightly_parents/2014_10_11/drm-intel-nightly/ea4bec8e96ea8b33b49a7892c1c7f20041a56da6/modules_x86_64/lib/modules/3.17.0_drm-intel-nightly_ea4bec_20141011+ acpi_rsdp=0x7b729014 kexec_jump_back_entry=0x5434a8e8 ==Bug detailed description== ----------------------------- 1. With i915 driver loaded and boot system 2. execute command as root "echo mem > /sys/power/state", system will hang up with board debug LED shows"000A" The serial port error log has not been captured, will upload once we got it. Isolation: 1. disable i915 driver and boot system, execute command as root "echo mem > /sys/power/state" 2. System will enter S3 quickly check from dmesg and resume back automatically.
Created attachment 108511 [details] [review] [PATCH] drm/i915: Enable pipe-a power well on chv This patch fixes resume from S3 on my BSW. Note that this depends on my earlier power sequencer series: git://gitorious.org/vsyrjala/linux.git chv_stuff_21
Verified the git://gitorious.org/vsyrjala/linux.git chv_stuff_21 + attached patch, on BSW B1 with RVP FAB1 board, Appear below call trace when wake up S3, details pls refer to attached dmesg-S3.log file. [ 127.767593] Call Trace: [ 127.767603] [<ffffffff81715d26>] ? dump_stack+0x41/0x51 [ 127.767609] [<ffffffff810373c0>] ? warn_slowpath_common+0x6f/0x84 [ 127.767636] [<ffffffffa007970d>] ? intel_gen6_powersave_work+0xf7/0xe9f [i915] [ 127.767663] [<ffffffffa007970d>] ? intel_gen6_powersave_work+0xf7/0xe9f [i915] [ 127.767669] [<ffffffff810469a6>] ? process_one_work+0x19f/0x2a8 [ 127.767672] [<ffffffff810472e2>] ? worker_thread+0x278/0x364 [ 127.767676] [<ffffffff8104706a>] ? rescuer_thread+0x219/0x219 [ 127.767681] [<ffffffff8104a7ef>] ? kthread+0xca/0xd2 [ 127.767685] [<ffffffff8104a725>] ? kthread_create_on_node+0x162/0x162 [ 127.767690] [<ffffffff8171b4ec>] ? ret_from_fork+0x7c/0xb0 [ 127.767694] [<ffffffff8104a725>] ? kthread_create_on_node+0x162/0x162
Created attachment 108552 [details] dmesg-S3 log file
(In reply to wendy.wang from comment #2) > Verified the git://gitorious.org/vsyrjala/linux.git chv_stuff_21 + attached > patch, on BSW B1 with RVP FAB1 board, > Appear below call trace when wake up S3, details pls refer to attached > dmesg-S3.log file. > > [ 127.767593] Call Trace: > [ 127.767603] [<ffffffff81715d26>] ? dump_stack+0x41/0x51 > [ 127.767609] [<ffffffff810373c0>] ? warn_slowpath_common+0x6f/0x84 > [ 127.767636] [<ffffffffa007970d>] ? intel_gen6_powersave_work+0xf7/0xe9f > [i915] > [ 127.767663] [<ffffffffa007970d>] ? intel_gen6_powersave_work+0xf7/0xe9f > [i915] > [ 127.767669] [<ffffffff810469a6>] ? process_one_work+0x19f/0x2a8 > [ 127.767672] [<ffffffff810472e2>] ? worker_thread+0x278/0x364 > [ 127.767676] [<ffffffff8104706a>] ? rescuer_thread+0x219/0x219 > [ 127.767681] [<ffffffff8104a7ef>] ? kthread+0xca/0xd2 > [ 127.767685] [<ffffffff8104a725>] ? kthread_create_on_node+0x162/0x162 > [ 127.767690] [<ffffffff8171b4ec>] ? ret_from_fork+0x7c/0xb0 > [ 127.767694] [<ffffffff8104a725>] ? kthread_create_on_node+0x162/0x162 That looks to to be a BIOS bug to me: "PCBR offset : 0x0" The BIOS is in charge of setting up the power context, so I believe it should also restore the address on resume.
Link related BIOS bug: BIOS did not restore the power context when resume from S3 https://vthsd.intel.com/hsd/clientsw/default.aspx#bug/default.aspx?bug_id=5584254&hsdmsgstr=3
Hello Ville, I tried latest 2014_11_06 drm-intel-nightly branch kernel: [root@x-bsw01 ~]# cat /proc/cmdline BOOT_IMAGE=kernels//nightly_parents/2014_11_06/drm-intel-nightly/0642a51748ff46a 205cf2a3fc45ba18cc92c9bda/bzImage_x86_64 root=/dev/sda4 hostname=x-bsw01 modules _path=kernels//nightly_parents/2014_11_06/drm-intel-nightly/0642a51748ff46a205cf 2a3fc45ba18cc92c9bda/modules_x86_64/lib/modules/3.18.0-rc3_drm-intel-nightly_064 2a5_20141106+ acpi_rsdp=0x7b71d014 kexec_jump_back_entry=0xe84a9118 After S3 resume and call trace appear, there are some error dmesg, and cannot do S3/reboot action again, would you pls help take a look at below dmesg error and attached s3dmesg.log to see if these error still due to BIOS issue? Thanks a lot! [root@x-bsw01 ~]# dmesg -r|egrep "<[1-4]>"|grep drm <3>[ 2.257951] [drm:i915_gem_init_stolen [i915]] *ERROR* conflict detected wi th stolen region: [0x7ce00000 - 0x7ee00000] <4>[ 54.744813] WARNING: CPU: 3 PID: 20 at drivers/gpu/drm/i915/intel_pm.c:512 0 intel_gen6_powersave_work+0xf3/0x1049 [i915]() <4>[ 54.744848] Modules linked in: ipv6 dm_mod snd_hda_codec_hdmi iTCO_wdt iTC O_vendor_support snd_hda_codec_realtek snd_hda_codec_generic serio_raw pcspkr i2 c_i801 snd_hda_intel snd_hda_controller lpc_ich mfd_core snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore battery ac acpi_cpufreq i915 button video drm_k ms_helper drm cfbfillrect cfbimgblt cfbcopyarea option usb_wwan usbserial <4>[ 54.744853] CPU: 3 PID: 20 Comm: kworker/3:0 Not tainted 3.18.0-rc3_drm-in tel-nightly_e6b3eb_20141107+ #1270
Created attachment 109078 [details] S3dmesg.log
Hello Ville, I tested V47 BIOS(HSD # 5584254) which should fixed "BIOS did not restore the power context when resume from S3" Used GFX Kernel is: BSW gfx Alpha release kernel: Tag: drm-intel-testing 2014-11-21 BSW system : B1 CPU + RVP Fab2 Board The S3 test results are: I tried 3 cycles S3 enter and resume, beginning 2 cycles S3 can successfully enter and resume, at the 3rd time to try to put system into S3, it failed with dmesg showS call trace about i915. I attached the dmesg for your analysis. Then add the parameter in kernel :"modprobe.blacklist=i915" , do S3 enter and resume for 5 times, all PASSed.
(In reply to wendy.wang from comment #8) > I tried 3 cycles S3 enter and resume, beginning 2 cycles S3 can successfully > enter and resume, at the 3rd time to try to put system into S3, it failed > with dmesg showS call trace about i915. > I attached the dmesg for your analysis. I don't see a new dmesg. Did you forget to attach it?
Created attachment 110297 [details] V47_s3_dmesg.log Sorry, attached v47-s3-dmesg log file.
(In reply to wendy.wang from comment #10) > Created attachment 110297 [details] > V47_s3_dmesg.log > > Sorry, attached v47-s3-dmesg log file. There's no failure in the log. Just a warning about new_config being out of whack "[ 737.980749] WARN_ON(intel_crtc->new_config && intel_crtc->new_config != &intel_crtc->config)" It's harmless, but if you want to get rid of it you can cherry-pick commit 2d3d111a8f34606469e589d3491c9a64f62310b8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Nov 21 21:00:36 2014 +0200 drm/i915: Don't clobber crtc->new_config when nothing changes Is there an actual failure that affects the user?
(updating title to reflect the latest status)
(In reply to Ville Syrjala from comment #11) > (In reply to wendy.wang from comment #10) > > Created attachment 110297 [details] > > V47_s3_dmesg.log > > > > Sorry, attached v47-s3-dmesg log file. > > There's no failure in the log. Just a warning about new_config being out of > whack > "[ 737.980749] WARN_ON(intel_crtc->new_config && intel_crtc->new_config != > &intel_crtc->config)" > > It's harmless, but if you want to get rid of it you can cherry-pick > commit 2d3d111a8f34606469e589d3491c9a64f62310b8 > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > Date: Fri Nov 21 21:00:36 2014 +0200 > > drm/i915: Don't clobber crtc->new_config when nothing changes > > Is there an actual failure that affects the user? Hello Ville, I tested your patch: "commit 2d3d111a8f34606469e589d3491c9a64f62310b8", With this commit + V47 BIOS+ BSW B1 CPU+ FAB2 board, I can continually execute S3 command more than 5 cycles, feedback i915_pm_resume_early message.-----------attach dmesg log: ww39.2_patch_s3_dmesg.log While double-check with kernel: tag drm-intel-nightly 2014-11-21, I only can do S3 2 or 3 times, then IP address unavailable, S3 command fail to execute with "resource temporary unavailable" message. attach two dmesg log: WW39.2_v47_s3_3rd_Resume_dmesg1.log, WW39.2_v47_s3_2nd_Resume_dmesg2.log
Created attachment 110339 [details] ww39.2_patch_s3_dmesg
Created attachment 110340 [details] WW39.2_v47_s3_3rd_Resume_dmesg1
Created attachment 110341 [details] WW39.2_v47_s3_2nd_Resume_dmesg2
(In reply to wendy.wang from comment #13) > (In reply to Ville Syrjala from comment #11) > > (In reply to wendy.wang from comment #10) > > > Created attachment 110297 [details] > > > V47_s3_dmesg.log > > > > > > Sorry, attached v47-s3-dmesg log file. > > > > There's no failure in the log. Just a warning about new_config being out of > > whack > > "[ 737.980749] WARN_ON(intel_crtc->new_config && intel_crtc->new_config != > > &intel_crtc->config)" > > > > It's harmless, but if you want to get rid of it you can cherry-pick > > commit 2d3d111a8f34606469e589d3491c9a64f62310b8 > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Date: Fri Nov 21 21:00:36 2014 +0200 > > > > drm/i915: Don't clobber crtc->new_config when nothing changes > > > > Is there an actual failure that affects the user? > > Hello Ville, > > I tested your patch: "commit 2d3d111a8f34606469e589d3491c9a64f62310b8", > With this commit + V47 BIOS+ BSW B1 CPU+ FAB2 board, > I can continually execute S3 command more than 5 cycles, feedback > i915_pm_resume_early message.-----------attach dmesg log: > ww39.2_patch_s3_dmesg.log > > While double-check with kernel: tag drm-intel-nightly 2014-11-21, I only can > do S3 2 or 3 times, then IP address unavailable, S3 command fail to execute > with "resource temporary unavailable" message. > attach two dmesg log: WW39.2_v47_s3_3rd_Resume_dmesg1.log, > WW39.2_v47_s3_2nd_Resume_dmesg2.log Are you saying 2d3d111a8f34606469e589d3491c9a64f62310b8 actually fixes something (apart from just silencing the WARN)? Because that would b a bit surprising.
(In reply to Ville Syrjala from comment #17) > (In reply to wendy.wang from comment #13) > > (In reply to Ville Syrjala from comment #11) > > > (In reply to wendy.wang from comment #10) > > > > Created attachment 110297 [details] > > > > V47_s3_dmesg.log > > > > > > > > Sorry, attached v47-s3-dmesg log file. > > > > > > There's no failure in the log. Just a warning about new_config being out of > > > whack > > > "[ 737.980749] WARN_ON(intel_crtc->new_config && intel_crtc->new_config != > > > &intel_crtc->config)" > > > > > > It's harmless, but if you want to get rid of it you can cherry-pick > > > commit 2d3d111a8f34606469e589d3491c9a64f62310b8 > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > Date: Fri Nov 21 21:00:36 2014 +0200 > > > > > > drm/i915: Don't clobber crtc->new_config when nothing changes > > > > > > Is there an actual failure that affects the user? > > > > Hello Ville, > > > > I tested your patch: "commit 2d3d111a8f34606469e589d3491c9a64f62310b8", > > With this commit + V47 BIOS+ BSW B1 CPU+ FAB2 board, > > I can continually execute S3 command more than 5 cycles, feedback > > i915_pm_resume_early message.-----------attach dmesg log: > > ww39.2_patch_s3_dmesg.log > > > > While double-check with kernel: tag drm-intel-nightly 2014-11-21, I only can > > do S3 2 or 3 times, then IP address unavailable, S3 command fail to execute > > with "resource temporary unavailable" message. > > attach two dmesg log: WW39.2_v47_s3_3rd_Resume_dmesg1.log, > > WW39.2_v47_s3_2nd_Resume_dmesg2.log > > Are you saying 2d3d111a8f34606469e589d3491c9a64f62310b8 actually fixes > something (apart from just silencing the WARN)? Because that would b a bit > surprising. At least commit 2d3d111a8f34606469e589d3491c9a64f62310b8 can help us do more cycles S3, and would you pls check does below call trace matter anything which was got from the commit 2d3d111a8f34606469e589d3491c9a64f62310b8 [ 227.642868] ------------[ cut here ]------------ [ 227.642898] WARNING: CPU: 1 PID: 24 at drivers/gpu/drm/i915/i915_drv.c:1185 vlv_force_gfx_clock+0x41/0x1eb [i915]() [ 227.642901] WARN_ON(!!(val & VLV_GFX_CLK_FORCE_ON_BIT) == force_on) [ 227.642932] Modules linked in: dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek iTCO_wdt iTCO_vendor_support snd_hda_codec_generic serio_raw pcspkr snd_hda_intel snd_hda_controller i2c_i801 lpc_ich mfd_core snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore option usb_wwan usbserial battery ac acpi_cpufreq i915 button video drm_kms_helper drm cfbfillrect cfbimgblt cfbcopyarea [ 227.642937] CPU: 1 PID: 24 Comm: kworker/u8:1 Tainted: G W 3.18.0-rc5_kcloud_2d3d11_20141202+ #40 [ 227.642947] Workqueue: events_unbound async_run_entry_fn [ 227.642954] 0000000000000000 0000000000000009 ffffffff817788a0 ffff88017a467c98 [ 227.642958] ffffffff81036742 ffff88017a467c90 ffffffffa007ea40 ffff88017a464000 [ 227.642962] ffff880175540000 0000000000000000 ffff88017a45a000 00000000ffffff92 [ 227.642964] Call Trace: [ 227.642975] [<ffffffff817788a0>] ? dump_stack+0x41/0x51 [ 227.642981] [<ffffffff81036742>] ? warn_slowpath_common+0x78/0x90 [ 227.643008] [<ffffffffa007ea40>] ? vlv_force_gfx_clock+0x41/0x1eb [i915] [ 227.643013] [<ffffffff8103679f>] ? warn_slowpath_fmt+0x45/0x4a [ 227.643040] [<ffffffffa007ea40>] ? vlv_force_gfx_clock+0x41/0x1eb [i915] [ 227.643067] [<ffffffffa007f9ea>] ? vlv_resume_prepare+0x511/0x546 [i915] [ 227.643095] [<ffffffffa007fad8>] ? i915_resume_legacy+0x23/0x23 [i915] [ 227.643121] [<ffffffffa007fa59>] ? i915_drm_resume_early+0x3a/0x96 [i915] [ 227.643128] [<ffffffff813dd359>] ? dpm_run_callback+0x3a/0xc5 [ 227.643132] [<ffffffff813dd6b5>] ? device_resume_early+0x130/0x171 [ 227.643135] [<ffffffff813dd70a>] ? async_resume_early+0x14/0x38 [ 227.643140] [<ffffffff8104cfd7>] ? async_run_entry_fn+0x2d/0xbf [ 227.643146] [<ffffffff810473f9>] ? process_one_work+0x1b3/0x316 [ 227.643149] [<ffffffff81047da1>] ? worker_thread+0x27d/0x369 [ 227.643153] [<ffffffff81047b24>] ? rescuer_thread+0x219/0x219 [ 227.643158] [<ffffffff8104b375>] ? kthread+0xce/0xd6 [ 227.643162] [<ffffffff8104b2a7>] ? kthread_create_on_node+0x162/0x162 [ 227.643167] [<ffffffff8177de2c>] ? ret_from_fork+0x7c/0xb0 [ 227.643171] [<ffffffff8104b2a7>] ? kthread_create_on_node+0x162/0x162 [ 227.643175] ---[ end trace cdf87c7c71c9a1bc ]--- Then test with kernel tag: drm-intel-testing 2014-11-21 we got this call trace: any wrong here with i915? Would you give some comments, thanks a lot. [ 417.963721] ------------[ cut here ]------------ [ 417.963782] WARNING: CPU: 1 PID: 4708 at drivers/gpu/drm/i915/intel_display.c:10336 __intel_set_mode+0x95a/0x99a [i915]() [ 417.963961] WARN_ON(intel_crtc->new_config && intel_crtc->new_config != &intel_crtc->config) [ 417.964024] Modules linked in: dm_mod iTCO_wdt iTCO_vendor_support snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic serio_raw snd_hda_intel snd_hda_controller option pcspkr usb_wwan snd_hda_codec snd_hwdep usbserial snd_pcm snd_timer lpc_ich i2c_i801 snd mfd_core soundcore battery ac acpi_cpufreq i915 button video drm_kms_helper drm cfbfillrect cfbimgblt cfbcopyarea [ 417.964032] CPU: 1 PID: 4708 Comm: kworker/u8:38 Tainted: G W 3.18.0-rc5_drm-intel-testing_167896_20141122_+ #117 [ 417.964054] Workqueue: events_unbound async_run_entry_fn [ 417.964064] 0000000000000009 ffff880175f879b8 ffffffff8183b528 ffffffff81070ea5 [ 417.964073] ffff880175f87a08 ffff880175f879f8 ffffffff8103bba8 0000000000000000 [ 417.964081] ffffffffa00ea69f ffff880179ece000 ffff880179ece6f0 ffff88017a460000 [ 417.964084] Call Trace: [ 417.964095] [<ffffffff8183b528>] dump_stack+0x46/0x58 [ 417.964102] [<ffffffff81070ea5>] ? up+0x39/0x40 [ 417.964110] [<ffffffff8103bba8>] warn_slowpath_common+0x81/0x9b [ 417.964169] [<ffffffffa00ea69f>] ? __intel_set_mode+0x95a/0x99a [i915] [ 417.964178] [<ffffffff8103bc65>] warn_slowpath_fmt+0x46/0x48 [ 417.964237] [<ffffffffa00ea69f>] __intel_set_mode+0x95a/0x99a [i915] [ 417.964291] [<ffffffffa00eefe7>] intel_set_mode+0xa4/0xc5 [i915] [ 417.964354] [<ffffffffa00f0cfe>] intel_modeset_setup_hw_state+0x991/0xa68 [i915] [ 417.964402] [<ffffffffa00d5aaa>] ? chv_write64+0x26a/0x26a [i915] [ 417.964436] [<ffffffffa0094206>] i915_drm_resume+0x108/0x176 [i915] [ 417.964469] [<ffffffffa0094294>] i915_pm_resume+0x20/0x22 [i915] [ 417.964478] [<ffffffff813bd719>] pci_pm_resume+0x70/0x85 [ 417.964483] [<ffffffff813bd6a9>] ? pci_pm_restore+0x9e/0x9e [ 417.964491] [<ffffffff81456ae9>] dpm_run_callback+0x6c/0xf3 [ 417.964497] [<ffffffff81456eef>] device_resume+0x189/0x1cb [ 417.964502] [<ffffffff81456f4f>] async_resume+0x1e/0x45 [ 417.964509] [<ffffffff81056923>] async_run_entry_fn+0x39/0xc6 [ 417.964518] [<ffffffff8104ff3c>] process_one_work+0x22b/0x409 [ 417.964524] [<ffffffff8104fea4>] ? process_one_work+0x193/0x409 [ 417.964532] [<ffffffff810503ad>] worker_thread+0x264/0x363 [ 417.964538] [<ffffffff81050149>] ? process_scheduled_works+0x2f/0x2f [ 417.964545] [<ffffffff810545be>] kthread+0xed/0xf5 [ 417.964552] [<ffffffff810544d1>] ? __init_kthread_worker+0x5a/0x5a [ 417.964560] [<ffffffff81842b6c>] ret_from_fork+0x7c/0xb0 [ 417.964566] [<ffffffff810544d1>] ? __init_kthread_worker+0x5a/0x5a [ 417.964571] ---[ end trace 949003bc96008731 ]---
Base on drm-intel-nightly branch below commit, S3 can do 10 cycles successfully but with call trace in dmesg. commit 2d3d111a8f34606469e589d3491c9a64f62310b8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Nov 21 21:00:36 2014 +0200 drm/i915: Don't clobber crtc->new_config when nothing changes and latest drm-intel-nightly branch commit: commit 63df8858af984ee11e32579a5d3cf2db17baf942 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 2 16:43:51 2014 +0100 drm-intel-nightly: 2014y-12m-02d-15h-43m-26s UTC integration manifest Close this bug as fix, and file a new bug for the new call trace bug.
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.