[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: testing upgrade with some sid: Unwanted Suspend to Ram [Fixed]



On Friday, September 9, 2016 5:55:30 AM CEST you wrote:
> On Friday, September 9, 2016 3:38:44 AM CEST you wrote:
> > On Thursday, September 8, 2016 9:55:40 PM CEST you wrote:
> > > On Thursday, September 8, 2016 7:00:42 PM CEST you wrote:
> > > > I just did a "Aptitude GUI" testing upgrade (aptitude -R -t stretch);
> > > > Then I used command line:
> > > > aptitude search -F"%p; %v; %V; %d" -t sid
> > > > '?installed(?maintainer(debian-qt- kde))'|egrep 5.7|egrep
> > > > '5.6|5.7.0'|less -i (goal here is empty output) to see what packages I
> > > > should also upgrade from sid
> > > > (Which I did after recommendations I've seen on this list);
> > > > which I've upgraded using the same GUI way (aptitude -R -t sid).
> > > > I had one glitch with "qml-module-qtmultimedia (5.6.1-2 and others)".
> > > > 
> > > > After reboot I can't see anything unusual.
> > > 
> > > Then After a While the screen got locked: it didn't seem unusual at the
> > > time even though the duration after which it occurred was unusually
> > > short... Then when I came back to my computer it was in a suspend to ram
> > > condition. The computer is a closed lid laptop with external monitor and
> > > of course keyboard...
> > > It is always on AC power.
> > > I join a screenshot of the relevant settings screen that shows, I
> > > believe,
> > > that everything is as it should be. And that therefore the computer
> > > shouldn't have behaved as it did.
> > > Maybe it won't happen again.
> > 
> > It did happen again. So what I did is tick then untick the "on AC power"
> > suspend session thing in settings/power management before clicking to
> > apply.
> > 
> > I'll see what comes from it.
> > 
> > (I've got lock screen automatically after 60 min set in Desktop Behavior -
> > Screen locking timeout...
> > There is some redundancy in settings there.
> > Also I wonder if the right thing to do wouldn't be to tick the suspend
> > session thing in power management and specifying that the thing to do
> > would
> > then be to just lock the screen; maybe if it's just not ticked there is a
> > default behavior consisting in suspend to ram...
> > All that pure speculations I'm afraid.)
> 
> I've found more precisely what causes the suspend to ram thing: it is when I
> use the power button of the external monitor to turn it off.
> However my settings say: "button event handling > when laptop lid closed >
> do nothing", and "even when an external monitor is connected", that last
> one is unticked.
> 
> I tried to tick the "even when external monitor is connected" thing, so that
> the semantic would be: do nothing, even in that specific case; but the
> outcome was just the same.
> 
> So finally I've got so far not solution at all but allowing the laptop to
> suspend to ram, and reach it to open the lid temporarily, when I want to use
> it again. Which is definitely not a solution.
> 
> It might be important in order to reproduce the bug, the external monitor is
> connected to the laptop (Lenovo x230) through "mini displayport".
> 
> There are 2 upstream bugs:
> https://bugs.kde.org/show_bug.cgi?id=361022
> https://bugs.kde.org/show_bug.cgi?id=359142
> But none seem directly related, because mine is specifically "When I power
> off the external monitor".
> 
> It seems very very bad.

Here is the workaround:

Get rid of Powerdevil altogether.
Get rid of acpid just in case.
Get rid of anything else if it's relevant.
No need to remove Upower or acpi.

Then I got help from #debian-next:
Edit /etc/systemd/logind.conf and make HandelLidSwitch=ignore
(remove the comment)
Then 'systemctl restart systemd-logind'
Ta-da!

I rebooted to see if it was resilient...

>From this point it might be that it'd still work if reinstalling Powerdevil...
But for the present it fits my needs.


> 
> > > > Chris



Reply to: