On Wed, Oct 24, 2018 at 07:39:00PM +0200, Leo Unglaub wrote: > Hello, > the following bug report is for a Lenovo ThinkPad E485. This device is the > one with the AMD Ryzen CPU. > > On this Laptop suspend/hybernate does not work. When I trigger a > suspend/hybernation via zzz or ZZZ or closing the lid the laptop attempts to > do the suspend/hybernation but it's impossible to get the device back when > you open up the lid again or try to press any buttons. > > This device model contains a LED indicator on the back that actually > indicates a successfull hybernate/suspend. But getting the laptop back is > impossible. > > The only way to boot the device again is by doing a hardware reset (pressing > the power button for 6 seconds). Then the laptop boots fine, but i have to > do a fsck on the partitions in order to mount them. > > Here is the disc layout: > > > /dev/sd2a on / type ffs (local, softdep) > > /dev/sd2k on /home type ffs (local, nodev, nosuid, softdep) > > /dev/sd2d on /tmp type ffs (local, nodev, nosuid, softdep) > > /dev/sd2f on /usr type ffs (local, nodev, softdep) > > /dev/sd2g on /usr/X11R6 type ffs (local, nodev, softdep) > > /dev/sd2h on /usr/local type ffs (local, nodev, wxallowed, softdep) > > /dev/sd2j on /usr/obj type ffs (local, nodev, nosuid, softdep) > > /dev/sd2i on /usr/src type ffs (local, nodev, nosuid, softdep) > > /dev/sd2e on /var type ffs (local, nodev, nosuid, softdep) > > > I also tried it without softdep, the same result. > > > Sadly i am unable to get any error messages or error indicators from the > laptop. I have a USB to serial adapter, but i don't get any messages from > that device. This has propobly something todo with sometimes broken USB > support on this ThinkPad. (More on this in a seperate bug report) > > So i am not sure if this bug report is any help, because i don"t have a core > dump or even a stacktrace for you. I am sorry about that. > > Maybe someone in the future has a patch for this, i am able to give them a > try. > > I have tried this on OpenBSD x64 6.3, 6.4 and the latest snapshot. > > Thanks and greetings > Leo
You could try to comment out wsdisplay_suspend in acpi.c (around line 2514) and test using a kernel built that way. That might (or might not) leave the screen on, in case there was some other diagnostic information printed there if the machine crashed somewhere on its suspend path. -ml
