Open raichoo opened 7 years ago
I am seeing a similar issue - if possible would it be possible for you to test this out on 390597ec789? that's the last revision of drm-next that i'm able to wake from S3 on my kabylake. i believe the issue is in the upstream CURRENT code, sometime shortly after the merge that happened in the above commit.
i'm having a terrible time finding the exact commit which caused the problems upstream, or how to fully debug the problem. there is a thread on freebsd-current@ which may be worth bumping though, just so other devs know that this problem is effecting multiple peeps.
Yes, this seems to work. Sadly, I'm not able to control screen brightness anymore which worked with more recent commits.
EDIT: I was wrong, I can control it. I just had Fn-Lock on ^^. I should really go to bed.
Machine just woke up after a good night of sleep. Looks like your assumption is correct.
I tried this commit (390597e) as well, and while the machine does resume from suspend, the screen looks like this:
I can log in remotely and kill X, at which point the screen does some kind of mode switching (goes black, then back to the coloured stripe pattern but without the little window in the bottom-left). Starting X again via SSH causes the little window to appear again, and the console emits:
X.Org X Server 1.18.4
Release Date: 2016-07-19
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 12.0-CURRENT amd64
Current Operating System: FreeBSD marley 12.0-CURRENT FreeBSD 12.0-CURRENT #50 390597ec789(HEAD): Fri May 12 13:38:48 EDT 2017 jon@marley:/usr/home/jon/freebsd/obj/usr/home/jon/freebsd/graphics/sys/GENERIC amd64
Build Date: 14 March 2017 01:19:07PM
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat May 13 12:43:35 2017
(==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
scfb trace: probe start
scfb trace: probe done
Running kldunload i915kms
causes the machine to hang and restart. Would the crash summary be of any help?
the method i've been trying, unsuccessfully i might add, to troubleshoot this issue is to start at the last working git commit and create a working snapshot via beadmin. then i at least have a base with working suspend/resume.
from there i've been applying upstream patches trying to pinpoint which commit introduced this problem. so far i've been unsuccessful with this approach, and it is really time consuming as well which has prevented me from doing more iterations. if others have the time and bandwidth to try to find the offending commit i think that'd be helpful.
I've made another interesting observation. After waking up the system seems to consume 3000 more Milliwatts (7300mW vs 4000mW) resulting. That pretty much cuts down battery life quite a lot. I've found the following output in dmesg
.
hdac0: Device stuck in reset
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
hdac0: Command timeout on address 0
pci0: failed to set ACPI power state D3 on \134_SB_.PCI0.XHCI: AE_BAD_PARAMETER
I've been having some issues with the XHCI driver producing a massive load of interrupts when loaded so I'm only loading the driver when needed. Maybe this is related, but I'm not sure. I've reported the issue on the bugs mailing list but got no reply concerning the issue.
So it looks like some progress is being made on this upstream on CURRENT as per this thread:
https://lists.freebsd.org/pipermail/freebsd-current/2017-May/065917.html
I'm going to try to build drm-next with this patch today and see if this fixes things on my end.
kib's patch gets me back to the same state as 390597e, i.e., responsive to keyboard input but with weird vertical stripes. If 390597e worked for you, perhaps this patch will too... time for me to go back to my own bug. :)
built drm-next
right now with the ENTRY(resumectx)
patch, my Thinkpad X240 still doesn't resume :(
Currently running da5f90154f123ea316971de3e096f29b528a8c28 and it seems to work fine.
The higher power consumption still seems to be an issue though. I'm still not quite sure where this is coming from. I don't see any excessive amount of interrupts or alike going on.
nah, still nothing on my X240. sound mute LED comes on, but power button LED keeps blinking.
Hi I'm running a recent version of the
drm-next
branch (8563ee90e) on my Thinkpad. When sending it to sleep withacpiconf -s 3
it won't wake up properly. The fan is spinning up but the screen stays black.I'm not quite sure how to report this issue in a helpful way but I'll some information about this machine and maybe that helps.
I hope this helps a bit. If I can provide any more information to make this more robust please let me know.
Kind regards, raichoo
dmesg
output:devinfo -rv
output:pciconf -clv
output: