Bug 72779

Summary:	[HSW mobile GT3e]System will hangs after executed "echo mem > /sys/power/state" on x86_64 OS
Product:	DRI	Reporter:	Guo Jinxian <jinxianx.guo>
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:	normal
Priority:	medium	CC:	intel-gfx-bugs, mengdong.lin, mengmeng.meng
Version:	XOrg git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Guo Jinxian 2013-12-17 08:43:44 UTC

system Environment:
--------------------------
platform: haswell 
CPU:  Intel(R) Core(TM) i7-4950HQ CPU @ 2.40GHz
Libdrm:	(master)libdrm-2.4.50
Mesa:	(master)7435d9f77c84a57ad9bbed2e6558c0f06cac5cd6
Xf86_video_intel:(master)2.99.906-79-gbd22abee8f33b20ff6bc7297b0a9ae8708d18727
Cairo:	(master)8e11a42e3e9b679dce97ac45cd8b47322536a253
Libva:	(staging)1264cd81fd8728f18bd2feedf6e9c1a232663890
Libva_intel_driver:(staging)2a61b0d17072bdc5b58608e3dfa2c4f9f80dcec4
Kernel:	(drm-intel-nightly) 2a9f2367690435ba1d3132c92a71300d2dbe90ba

Bug detailed description:
-------------------------
On haswell mobile GT3e(with 64bit kernel), System will hangs after executed "echo mem > /sys/power/state". It works well with 32bit kernel. 

Unable to got dmesg because the system will hangs after executed "echo mem > /sys/power/state"

This bug unable to reproduce on other HSW(CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz or Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz)

Reproduce steps:
--------------------
1. echo mem > /sys/power/state

Comment 1 Daniel Vetter 2013-12-17 09:21:12 UTC

Is this a regression? If so, can you please try to bisect it?

Comment 2 Guo Jinxian 2013-12-18 05:50:11 UTC

(In reply to comment #1)
> Is this a regression? If so, can you please try to bisect it?

Sorry, the system environment is wrong.

The correct system environment as below:
platform: haswell 
CPU:  Intel(R) Core(TM) i7-4950HQ CPU @ 2.40GHz
Kernel: 3.12.2

We found this bug on 2013Q4 release kernel, and we can reproduce it on 2013Q3 and 2013Q2RC2 too. 

We didn't found good point.

This bug unable to reproduce on latest -nightly (f0404eaa3ab8607058a3581e0d691d35ca4b79bd)

Comment 3 Chris Wilson 2013-12-18 08:53:50 UTC

Step 1: Have you verified that the issue occurs only with i915.ko loaded? Or active?

Comment 4 Guo Jinxian 2013-12-19 01:26:39 UTC

(In reply to comment #3)
> Step 1: Have you verified that the issue occurs only with i915.ko loaded? Or
> active?

Boot OS with parameter "i915.modeset=0", this bug still can be reproduce.

Comment 5 Gordon Jin 2013-12-19 02:08:02 UTC

(In reply to comment #2)
> 
> We found this bug on 2013Q4 release kernel, and we can reproduce it on
> 2013Q3 and 2013Q2RC2 too. 
> 
> We didn't found good point.
> 
> This bug unable to reproduce on latest -nightly
> (f0404eaa3ab8607058a3581e0d691d35ca4b79bd)

Since it's not a recent regression, and already fixed with the latest code, I guess we can just close it.

Comment 6 Chris Wilson 2013-12-30 13:20:37 UTC

* shrugs.

Comment 7 Mengdong Lin 2013-12-30 13:20:55 UTC

I'm on vacation from Dec 25 to Jan 1. Please expect a delay on email response.

Thanks
Mengdong

Comment 8 Guo Jinxian 2014-01-14 00:54:48 UTC

Verified it due to this bug unable to reproduce on latest -nightly (f0404eaa3ab8607058a3581e0d691d35ca4b79bd)

Comment 9 Elizabeth 2017-10-06 14:41:15 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.