Results 1 to 4 of 4

Thread: Screen Appears Not to Work After Being Suspended

  1. #1

    Default Screen Appears Not to Work After Being Suspended

    I have a Lenovo E535 laptop running the 64 bit openSUSE 12.3 with the Gnome GUI, and every time I close the laptop lid, the computer suspends, and open it again, the screen goes dark and won't start up, and I end up having to hold down on the power button to restart the computer. I'm not sure what's going on here or what I can do to fix it. Before the screen goes dark there are a few words that flash in the upper right corner, but unfortunately it's only for an instant and I can't read what they say, although I'm not sure if that helps any.

    Thanks for any help.

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,806
    Blog Entries
    1

    Default Re: Screen Appears Not to Work After Being Suspended

    Recommend you try doing a manual suspend (from the App Launcher) rather than as an automatic behavior by closing the lid.
    Compare to see if you still have a problem.

    Then, of course, "unsuspend" to see if you still have a problem.

    In either case (if manual suspends fixes the problem or not), you should probably take an inventory what applications are still running when you suspend.

    You should probably inspect your /var/log/messages,
    Look for where your last suspend and restart point is, then look at the last 100 lines or so before and after that point,.

    You can inspect the logfile with something like
    Code:
    tail -n 1000 /var/log/messages
    Am just guessing that specifying the last 1000 lines of your syslog should be enough to capture the suspend and re-start, you may need to modify that.

    Of course, if you don't mind waiting a very long time and if your machine has enough memory resources, with superuser permissions you could open that file in a graphical text editor... But, I highly recommend using "tail" instead.

    TSU

  3. #3

    Default Re: Screen Appears Not to Work After Being Suspended

    Okay, thanks. I tried manually suspending the laptop which worked, but I'm not sure what it is I'm supposed to be looking for in the log file. I see a lot of lines that look like: 2013-09-30T17:14:35.488207-07:00 linux-uhim kernel: [12213.084285] ieee80211 phy1: brcms_ops_bss_info_changed: cqm change: threshold 0, hys 0 (implement). Is there something specific I should be looking for?

  4. #4
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,806
    Blog Entries
    1

    Default Re: Screen Appears Not to Work After Being Suspended

    Quote Originally Posted by fischer77 View Post
    Okay, thanks. I tried manually suspending the laptop which worked, but I'm not sure what it is I'm supposed to be looking for in the log file. I see a lot of lines that look like: 2013-09-30T17:14:35.488207-07:00 linux-uhim kernel: [12213.084285] ieee80211 phy1: brcms_ops_bss_info_changed: cqm change: threshold 0, hys 0 (implement). Is there something specific I should be looking for?
    That's great that you are able to suspend properly when doing it manually as opposed to when closing your lid.

    Now, you can compare what happens in the hundred or so lines before suspension.
    Copy the hundred or so lines before successfully suspending to a separate file.
    Then suspend by closing the lid.
    When you are able to get your system running again, look for that point in your logfile when you suspended using the lid and copy the hundred or so lines before that event and save to a file.

    Then, you can compare the two side by side looking for differences, generally what I do is open them both in a text editor side by side and scroll down for comparing.

    If I were to hazard a wild guess, closing the lid also activated ACPI which powered down your machine at the system level before the Desktop completed stopping running processes and saving necessary settings. If you find that to be the likely case, then I'd report this as a KDE bug and as something that'd not be totally unexpected since KDE tries to be cross-distro which generally tries to conform to SysVinit while openSUSE has moved on to implementing systemd instead, so the "system suspend" command is different (now implemented as a systemd Unit).

    TSU

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •