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
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
(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
Created attachment 121004 [details] dmesg.log 2
Created attachment 121005 [details] test.log
So when booted with "nomodeset" and "text" together, the 5 test suspends worked, yes? please do the same without echoing anything to pm_test.
it would also be good to confirm the results of those same 5 experiments when booting with default cmdline -- ie no "nomodeset" "text".
(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
Created attachment 121041 [details] dmesg2.log
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?
*** Bug 93329 has been marked as a duplicate of this bug. ***
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.
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)
ops, sorry for the noise. Please keep this closed and refer to LCK-2823. (You Humberto had been added there already)
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.