Bug 93684 - [BXT-P APL] Suspend to RAM does not work without i915 loaded
Summary: [BXT-P APL] Suspend to RAM does not work without i915 loaded
Status: CLOSED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 93329 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-01-12 19:45 UTC by Humberto Israel Perez Rodriguez
Modified: 2016-01-18 11:24 UTC (History)
2 users (show)

See Also:
i915 platform: BXT
i915 features: power/suspend-resume


Attachments
dmesg.log (150.07 KB, text/plain)
2016-01-12 19:45 UTC, Humberto Israel Perez Rodriguez
no flags Details
dmesg.log 2 (243.75 KB, text/plain)
2016-01-13 20:59 UTC, Humberto Israel Perez Rodriguez
no flags Details
test.log (4.00 KB, text/plain)
2016-01-13 20:59 UTC, Humberto Israel Perez Rodriguez
no flags Details
dmesg2.log (244.44 KB, text/plain)
2016-01-14 18:08 UTC, Humberto Israel Perez Rodriguez
no flags Details

Description Humberto Israel Perez Rodriguez 2016-01-12 19:45:48 UTC
Created attachment 120993 [details]
dmesg.log

Summary :
-------------------------------------
After send BXT-P to suspend state and try to resume the platform instead to resume it reboots
notice that with/without i915 loaded i have the same behavior
Attached dmesg.log

DMC : 1.05

Graphic stack versions  :
-----------------------------------------
cairo version: 1.15.2 / commit :  db8a7f1 
drm version :  libdrm-2.4.66  / commit : b38a4b2 
intel-driver : 1.6.2 / commit: 683edee
libva version : libva-1.6.2 / commit : 304bc13
mesa version : mesa-11.0.8 / commit : 261daab 
xf86-video-intel version : 2.99.917  / commit : baec802 
xserver version :xorg-server-1.18.0 / commit :7921764 

kernel drm-intel-testing:
------------------------------------------
commit 91587c722c28c4116dedbfbf08aa874377bc76f8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Dec 4 17:35:54 2015 +0100

    drm-intel-nightly: 2015y-12m-04d-16h-35m-07s UTC integration manifest

kernel version : 4.4.0-rc3
git url        : git://anongit.freedesktop.org/drm-intel
git branch     : drm-intel-testing
git describe   : drm-intel-next-2015-11-20-rebased-13721-g91587c7


Steps:
------
1. Execute command :
      echo mem > /sys/power/state
2. Wait 30 seconds
3. Resume with keyboard

Actual result:
--------------
Suspend to Ram and resume do not work instead the system reboots

Expected result:
-----------------
Suspend to RAM and resume should work without any issues
Comment 1 yu.c.chen@intel.com 2016-01-13 07:07:30 UTC
As suggest in https://bugs.freedesktop.org/show_bug.cgi?id=93329, could you please help test S3 in a minimal Linux kernel(w/o graphic loaded) by: append ‘init=/bin/bash nomodeset text’ in grub’s command line and 
test the following command respectively:
echo freezer > /sys/power/pm_test (wait for 5 second to see if it returns)

echo devices > /sys/power/pm_test(wait for 5 second to see if it returns)

echo platform > /sys/power/pm_test(wait for 5 second to see if it returns)

echo processors > /sys/power/pm_test(wait for 5 second to see if it returns)

echo core > /sys/power/pm_test(wait for 5 second to see if it returns)

please also provide serial port output and dmesg when you are doing the test.


Yu
Comment 2 Humberto Israel Perez Rodriguez 2016-01-13 20:57:40 UTC
(In reply to yu.c.chen@intel.com from comment #1)
> As suggest in https://bugs.freedesktop.org/show_bug.cgi?id=93329, could you
> please help test S3 in a minimal Linux kernel(w/o graphic loaded) by: append
> ‘init=/bin/bash nomodeset text’ in grub’s command line and 
> test the following command respectively:
> echo freezer > /sys/power/pm_test (wait for 5 second to see if it returns)
> 
> echo devices > /sys/power/pm_test(wait for 5 second to see if it returns)
> 
> echo platform > /sys/power/pm_test(wait for 5 second to see if it returns)
> 
> echo processors > /sys/power/pm_test(wait for 5 second to see if it returns)
> 
> echo core > /sys/power/pm_test(wait for 5 second to see if it returns)
> 
> please also provide serial port output and dmesg when you are doing the test.
> 
> 
> Yu


Hi Yu :

I was not able to boot the BXT-P with the option "init=/bin/bash" because simply the DUT does not boot, it always stop in initramfs prompt, on the other hand i was able to boot with "nomodeset and text" options in the grub.
So once there i did one by one command and then i send the DUT to sleep (echo mem > /sys/power/state), and after each command the DUT returns (please see dmesg.log and test.log)

As well i have to comment that i've update the BIOS version and KSC of my BXT-P

Ifwi       : 119.10
Bxt SOC    : A0
KSC        : 1.06
GOP        : 10.0.1022
Board ID   : APL RVP 1A
Comment 3 Humberto Israel Perez Rodriguez 2016-01-13 20:59:33 UTC
Created attachment 121004 [details]
dmesg.log 2
Comment 4 Humberto Israel Perez Rodriguez 2016-01-13 20:59:48 UTC
Created attachment 121005 [details]
test.log
Comment 5 Len Brown 2016-01-14 03:13:54 UTC
So when booted with "nomodeset" and "text" together,
the 5 test suspends worked, yes?

please do the same without echoing anything to pm_test.
Comment 6 Len Brown 2016-01-14 03:16:19 UTC
it would also be good to confirm the results of those same 5
experiments when booting with default cmdline -- ie no "nomodeset" "text".
Comment 7 Humberto Israel Perez Rodriguez 2016-01-14 18:07:32 UTC
(In reply to Len Brown from comment #5)
> So when booted with "nomodeset" and "text" together,
> the 5 test suspends worked, yes?  <<-- that's correct
> 
> please do the same without echoing anything to pm_test.

Hi Len Brown :

The tests needs 'echo' command because without it the next parameters are recognized as a command.

I tried the following with default cmdline (without "text nomodeset")

Command  : echo freezer > /sys/power/pm_test
Behavior : after type the below command and send the DUT to S3 state with the command (echo mem > /sys/powe/state) looks like that the screen is frozen for a couple of seconds and then the screen come back normal, also i have to comment that the postcode remains the same '00AD'

Command  : echo devices > /sys/power/pm_test
Behavior : after type the below command and send the DUT to S3 state with the command (echo mem > /sys/powe/state) the screen goes black and returns after a few seconds and then come back normal, also i have to comment that the postcode remains the same '00AD'. 

Command  : echo platform > /sys/power/pm_test
Behavior : after type the below command and send the DUT to S3 state with the command (echo mem > /sys/powe/state) the DUT change its postcode to "0003" and the screen goes back for a few seconds and then come back normal.

Command  : echo processors > /sys/power/pm_test
Behavior : after type the below command and send the DUT to S3 state with the command (echo mem > /sys/powe/state) the screen goes black and returns after a few seconds and then come back normal, also the postcode remains the same as "0003"

Command  : echo core> /sys/power/pm_test
Behavior : after type the below command and send the DUT to S3 state with the command (echo mem > /sys/powe/state) the screen goes black and returns after a few seconds and then come back normal, also the postcode remains the same as "0003"

Please see the attachements :
dmesg2.log
Comment 8 Humberto Israel Perez Rodriguez 2016-01-14 18:08:17 UTC
Created attachment 121041 [details]
dmesg2.log
Comment 9 Len Brown 2016-01-15 03:39:22 UTC
comment #8 has this:

[  494.629116] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
[  494.629122] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
[  494.629125] iwlwifi 0000:03:00.0: Failed to start INIT ucode: -110
[  494.629126] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
[  494.629261] ------------[ cut here ]------------
[  494.629268] WARNING: CPU: 0 PID: 2336 at /home/shared/kernels/drm-intel-testing/net/mac80211/util.c:1770 ieee80211_reconfig+0x20b/0xdb0 [mac80211]()
[  494.629269] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
...

Which experiment resulted in that error?

Does that error go away if iwlwifi is unloaded/disabled before the suspend?
Comment 10 Rodrigo Vivi 2016-01-15 04:10:43 UTC
*** Bug 93329 has been marked as a duplicate of this bug. ***
Comment 11 Rodrigo Vivi 2016-01-15 04:12:45 UTC
Please refer to Jira LCK-2823. Put all information you can to help on that Jira and get info from there because apparently we have non graphics related issues causing the suspend/resume bugs that are under investigation.
Comment 12 Rodrigo Vivi 2016-01-15 04:16:15 UTC
Humbeberto, could you please check if unloading wifi module you can get the suspend resume working?
(reopening since I couldn't find you at that Jira)
Comment 13 Rodrigo Vivi 2016-01-15 04:29:12 UTC
ops, sorry for the noise. Please keep this closed and refer to LCK-2823. (You Humberto had been added there already)
Comment 14 cprigent 2016-01-18 11:24:36 UTC
So closed. Let's track LCK-2823 instead.


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.