This appears to be a bug specific to KDE 4.9.1; it didn't occur on KDE 4.9.0. Also, waking from suspend to RAM works perfectly with other window managers, such as XFCE. Reproducible: Sometimes Steps to Reproduce: 1. Suspend to RAM. 2. Wake from suspend. Actual Results: Dialog to enter my password to unlock screen DOES NOT appear. Instead, a white underscore ("_") on a black screen appears. Expected Results: Dialog to enter my password to unlock screen should appear.
This problem seems to always occur when Ethernet is plugged in. Also, now that I upgraded to 4.9.2, I still encounter this bug. Are there any logs I should post here? Thanks
> Instead, a white underscore ("_") on a black screen appears. This means the resume process did not switch back to graphical mode. Does using Ctrl+Alt+F7 manually restore the mode?
(In reply to comment #2) > > Instead, a white underscore ("_") on a black screen appears. > > This means the resume process did not switch back to graphical mode. Does > using Ctrl+Alt+F7 manually restore the mode? No, I can't access any of the TTY terminals, neither. The underscore sometimes blinks initially, but then it stops blinking. Perhaps this is an X issue, not KDE?
This appears to be the last thing in my system log before re-waking: org.kde.powerdevil.backlighthelper QDBusConnection: system D-Bus connection created before QCoreApplication. Application may misbehave. Also, occasionally, and for no apparent reason, my screen turns black and all I see is my cursor, frozen.
(In reply to comment #4) > This appears to be the last thing in my system log before re-waking: > > org.kde.powerdevil.backlighthelper QDBusConnection: system D-Bus connection > created before QCoreApplication. Application may misbehave. > > Also, occasionally, and for no apparent reason, my screen turns black and > all I see is my cursor, frozen. Could this be a graphics card driver issue? Thanks
The problem seems to occur whenever my ethernet tries to access my machine. At work, plugging it into their ethernet before waking from sleep always triggers this bug.
Also, this bug occurs for about 50% of my awakes from suspend.
Can you reboot you computer using magic sysrq ? http://en.wikipedia.org/wiki/Magic_SysRq_key
(In reply to comment #8) > Can you reboot you computer using magic sysrq ? > > http://en.wikipedia.org/wiki/Magic_SysRq_key Which command should I issue? Thanks
First you need to enable magic sysrq: echo 1 | sudo tee /proc/sys/kernel/sysrq > /dev/null After it, when you get a white underscore ("_") on a black screen, you must press and don't release "Alt + SysRq" and after it press next "E I S U B" For more info see http://en.wikipedia.org/wiki/Magic_SysRq_key On Sun, Nov 11, 2012 at 9:58 PM, Alan Aversa <aversa@email.arizona.edu> wrote: > https://bugs.kde.org/show_bug.cgi?id=307642 > > --- Comment #9 from Alan Aversa <aversa@email.arizona.edu> --- > (In reply to comment #8) >> Can you reboot you computer using magic sysrq ? >> >> http://en.wikipedia.org/wiki/Magic_SysRq_key > > Which command should I issue? Thanks > > -- > You are receiving this mail because: > You are on the CC list for the bug.
I don't know what KDE does for suspend (I don't have enough time right now to investigate) But if you are using pm-suspend to suspend, and dbus for lock session right from acpi actions, than it is okay. If somebody interesting I can paste here my /etc/acpi/actions/lm_lid.sh /etc/acpi/powerbtn-acpi-support.sh
I thought about this bug, and I don't believe that KDE does much except for performing pm-suspend. In my opinion, the only thing that can cause troubles is the division at On Ac Power / On Battery / On Low Battery.
(In reply to comment #8) > Can you reboot you computer using magic sysrq ? > > http://en.wikipedia.org/wiki/Magic_SysRq_key No, I cannot. However, enabling SysRq displayed some output instead of just the blinking underscore, upon awaking from suspend. Then the computer just shut off. Another time, upon awaking from suspend, just the underscore appeared. The SysRq key combination did nothing, and I had to hold down the power button to force it to shutdown. Also, plugging in USB devices before awaking oftentimes triggers this bug. Is there key combination to make SysRq dump errors to a file? I think the commands on the Wiki page you cited just dump to screen. Thanks for the help
(In reply to comment #11) > But if you are using pm-suspend to suspend, and dbus for lock session right > from acpi actions, than it is okay. I've suspended multiple ways (from the KDE launch menu, issuing pm-suspend, pm-suspend-hybrid, etc.); this bug doesn't seem to depend on how I suspended.
On Mon, Nov 12, 2012 at 11:38 AM, Alan Aversa <aversa@email.arizona.edu> wrote: > https://bugs.kde.org/show_bug.cgi?id=307642 > > However, enabling SysRq displayed some output instead of just the blinking > underscore, upon awaking from suspend. Then the computer just shut off. What information id you see instead of just the blinking? > > Another time, upon awaking from suspend, just the underscore appeared. The > SysRq key combination did nothing, and I had to hold down the power button to > force it to shutdown. > > Also, plugging in USB devices before awaking oftentimes triggers this bug. Could you be more verbose? > > Is there key combination to make SysRq dump errors to a file? I think the > commands on the Wiki page you cited just dump to screen. What errors you need to dump? I don't think that there is such combination. You can just turn on all debug level at boot, passing to kernel specific options, I do it next way: In "/etc/default/grub" Add or replace or join with yours GRUB_CMDLINE_LINUX_DEFAULT="noapic ignore_loglevel debug debug_locks_verbose=1 sched_debug initcall_debug mminit_loglevel=4 udev.log_priority=8 loglevel=8 earlyprintk=vga,keep log_buf_len=10M print_fatal_signals=1 apm.debug=Y scsi_logging_level=1 usbserial.debug=Y option.debug=Y pl2303.debug=Y firewire_ohci.debug=1 hid.debug=1 pci_hotplug.debug=Y pci_hotplug.debug_acpi=Y shpchp.shpchp_debug=Y show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10" > > Thanks for the help > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- Azat Khuzhin
About pm-suspend runs from terminal. Could you be more verbose? For example when I trying to do this, I must disable KDE handling close/open lid, and powerbtn, otherwise it just not resume after pm-suspend. > https://bugs.kde.org/show_bug.cgi?id=307642 > > (In reply to comment #11) >> But if you are using pm-suspend to suspend, and dbus for lock session right >> from acpi actions, than it is okay. > > I've suspended multiple ways (from the KDE launch menu, issuing pm-suspend, > pm-suspend-hybrid, etc.); this bug doesn't seem to depend on how I suspended. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- Azat Khuzhin
I don't have this bug anymore when not connected to ethernet before and after suspending, so I think this bug possibly isn't KDE but something regarding my ethernet…
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
The bug reporter says it's not happening anymore.