Le 02/01/2017 à 06:01, Peter Nabbefeld a écrit : > Am 31.12.2016 um 13:42 schrieb Bruno Pagani: >> Hi, >> >> Le 31 décembre 2016 07:38:05 GMT+01:00, Peter Nabbefeld >> <peter.nabbefeld@xxxxxx> a écrit : >>> >>> Hello, >>> >>> since some time, hibernation does not work, dmesg contains following >>> messages: >>> >>> [ 738.404244] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type >>> >>> mismatch - Found [Buffer], ACPI requires [Package] >>> (20160422/nsarguments-95) >>> [ 738.404353] ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM >>> [ 738.404356] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type >>> >>> mismatch - Found [Buffer], ACPI requires [Package] >>> (20160422/nsarguments-95) >>> >>> Some time ago, when I closed my laptop, Linux automatically hibernated, >>> >>> now it does not. As my laptop becomes really warm and I don't want to >>> stress my display, I'm using this rarely, so I cannot tell, since when >>> hibernation doesn't work :-/ >>> >>> Kind regartds >>> Peter >> >> These messages are related to Optimus system (Nvidia implementation >> of dGPU power management handling is not compliant with ACPI specs). >> So that’s not related to your hibernation issue. >> > Hm, I'm using the Nouveau driver - is this message hardware-related? Yes, it’s hardware related, and that’s nothing to worry about, there is nothing to be done here. >> Regarding this one, I’d like a precision that might be useful: is >> this about hibernation or suspend? >> > Hm, I'm usually not distinguishing those. As System doesn't need much > time to wake-up, I'd assume it just suspends to RAM - but as computers > are getting more power, this is probably not really visible. How can I > detect, which mode it had to switch to? You can see it in dmesg for instance: PM: Preparing system for sleep (mem) PM: Suspending system (mem) I suppose mem is replaced with disk or something like that in case of hibernation. But looking at the wiki[0], if you don’t know it’s unlikely to be hibernation given the steps involved to make this one work. >> Other than that, what DE do you use if applicable? What does handle >> lid close event? I had the issue that the lid close event wasn’t >> handled because KDE PM daemon isn’t inhibiting systemd one correctly, >> and once fixed it worked again. >> > Using XFCE. Don't know, what handles the lid close evenet - how can I > find that out? Not sure how to know for sure, but see the wiki[1]. Apparently, XFCE should properly inhibit systemd action. But this article says KDE does too, however that’s not true for LidSwitch (at least it wasn’t last time I tried). So you should check that, and also what settings you have in XFCE power manager. One thing that might have happened is XFCE now properly inhibiting systemd and not going to sleep on LidSwitch while systemd was. Hope it might help, Bruno [0] https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#Hibernation [1] https://wiki.archlinux.org/index.php/Power_management#ACPI_events
Attachment:
signature.asc
Description: OpenPGP digital signature
