Who do I have to Kill...
FedoraForum.org - Fedora Support Forums and Community
Results 1 to 12 of 12
  1. #1
    Join Date
    Sep 2005
    Posts
    466

    Who do I have to Kill...

    In order to recover from a frozen session...

    The keyboard is evidently locked and the Display is frozen and the mouse can move
    but clicking on anything has no effect.

    I don't know if it is coincidence or not but I recently discovered that I could suspend to
    memory in Fedora 11 on my Centrino based HPDV4000 system.

    When I first installed Fedora 11, suspending worked but waking up did *not*. I guess
    some recent patches made the power manager a little smarter. There are still some
    problems:
    The screen saver and suspend work one time after a reboot, subsequently the
    screen saver does not come on, the screen blanks ( but the backlight stays on) and
    the system does not suspend.

    I got around this problem by writing a tcl daemon that watches the interrupts and if
    no activity ( keypress, mouse movement, or touchpad action) occurs in a suitable
    interval it will call /usr/sbin/pm-suspend.

    This seems to work fairly well but I have been getting several interface freezes a day...

    I can ssh into the laptop from another machine but I don't seem to be able to kill and restart
    the gnome session ( other than issuing a reboot command from the ssh session).

    Is it possible to get a new session started without a reboot?

    Thanks

    Jerry

  2. #2
    Join Date
    Sep 2006
    Location
    Connellsville, PA, USA
    Posts
    11,308
    Try restoring the Xorg "zapping" feature to allow ALT-CTL-Backspace to re-start X: edit (or add) the following to xorg.conf (create if required):
    Code:
    Section "ServerFlags"
    	Option	"DontZap" "false"
    EndSection
    Better than a complete re-boot or hard re-set, if it works. See if that helps.

    V

    P.S. Interestingly, a re-start of X is required to apply.
    Can't win 'em all... .
    Last edited by Hlingler; 21st October 2009 at 08:48 PM.

  3. #3
    Join Date
    Sep 2005
    Posts
    466
    Been there, done that.... Don't work...

    Ctl-Alt-BS works if the keyboard works.

    When my session locks up, I cannot even get a virtual console...

    Jerry

  4. #4
    Join Date
    Jan 2005
    Posts
    5,057
    In the ssh session, su -
    top
    note the xorg pid
    q
    kill -s 9 pid#ofxorg


    Your ssh session will close
    but the gdm logon screen should come up (unless the main system is actually hung)

    SJ
    Do the Math

  5. #5
    Join Date
    Sep 2005
    Posts
    466
    Quote Originally Posted by SlowJet
    In the ssh session, su -
    top
    note the xorg pid
    q
    kill -s 9 pid#ofxorg


    Your ssh session will close
    but the gdm logon screen should come up (unless the main system is actually hung)

    SJ
    I tried that...It did not work.

    Jerry

  6. #6
    Join Date
    Jan 2005
    Posts
    5,057
    Quote Originally Posted by GrayFox
    I tried that...It did not work.

    Jerry
    Then try reboot

    SJ.
    Do the Math

  7. #7
    Join Date
    Aug 2006
    Location
    /dev/realm/{Abba,Carpenters,...stage}
    Posts
    3,285
    This used to happen mostly with compiz, but things seem to have been stabilized now, and in the lack of compiz updates the only fixes came from Nvidia and xorg driver.
    Open SSH sessions with remote GUI apps will freeze a desktop making it seem totally unresponsive. However, even if the VTY's are blocked, SJ solution is the remedy for it. Occasionally a runlevel change might be needed (5-3-5) and less frequent a reboot.
    For safer browsing, use OpenDNS nameservers 208.67.222.222 and 208.67.220.220

    SELinux User Guide

    AutoPager

  8. #8
    Join Date
    Oct 2009
    Posts
    6
    I'm seeing the same thing with a Thinkpad T400 running Fedora 11 x86_64. It appears that suspend to RAM seems to 'work', however, resuming the session by either opening the lid or pressing Fn-F4 results in a total system lock-up. I can't even SysRq the laptop to shut it down 'gracefully'.

    I'm using the ATI fglrx drivers and suspend to RAM *was* working until I updated the ATI packages to the 9.10 release:

    Oct 27 21:47:52 Installed: kernel-devel-2.6.30.9-90.fc11.x86_64
    Oct 27 21:47:53 Updated: kernel-firmware-2.6.30.9-90.fc11.noarch
    Oct 27 21:48:20 Updated: kernel-headers-2.6.30.9-90.fc11.x86_64
    Oct 27 21:48:48 Installed: kernel-2.6.30.9-90.fc11.x86_64
    Oct 27 21:49:14 Updated: kmod-catalyst-9.10-1.fc11.x86_64
    Oct 27 21:49:15 Installed: kmod-catalyst-2.6.30.9-90.fc11.x86_64-9.10-1.fc11.x86_64
    Oct 27 21:49:19 Updated: xorg-x11-drv-catalyst-9.10-1.fc11.x86_64
    Oct 27 21:49:21 Updated: xorg-x11-drv-catalyst-libs-9.10-1.fc11.x86_64
    Oct 27 21:49:23 Updated: xorg-x11-drv-catalyst-libs-9.10-1.fc11.i586

    I tried booting to the previous kernel but I get the same results. I noticed (in the package changelog) that the package maintainers have removed the blacklist for the radeon kernel module. The system seems to load both modules on boot:

    fglrx 2256568 27
    radeon 542904 0
    drm 228628 1 radeon
    i2c_algo_bit 6628 1 radeon
    i2c_core 33520 4 i2c_i801,radeon,drm,i2c_algo_bit

    I have also tried to manually remove the radeon module and attempt a suspend/resume - no dice. This used to work fine.

  9. #9
    Join Date
    Oct 2009
    Posts
    6
    I managed to fix my sleep/resume in Fedora 11 x86_64 (64-bit) on a Thinkpad T400 using the latest ATI fglrx drivers (Catalyst 9.10). The sleep/suspend to RAM would seem to work, however, when I would try to resume, the system appeared to thaw but it would lock-up with a blank screen (requiring a hard reset).

    It appears the latest updates from rpmfusion repository removed the module blacklist from the packages so both the radeon and the fglrx module were being loaded on boot. I managed to disable the radeon module again and now my suspend to RAM / resume works as it did before.

    Here is what I did:
    1. echo "blacklist radeon" >> /etc/modprobe.d/blacklist.conf
    2. echo "blacklist radeonhd" >> /etc/modprobe.d/blacklist.conf

    Then, I generated a new initrd image:
    1. mv /boot/initrd-`uname -r`.img /boot/initrd-`uname -r`.img.backup
    2. mkinitrd -v /boot/initrd-`uname -r`.img `uname -r`
    3. reboot

    After the system booted, I confirmed that the radeon module was not loaded:

    lsmod |grep radeon

    tested the suspend to RAM by entering Fn-F4, closed the lid, opened lid, and the system returned to the login screen (no blank screen).

    Nothing special in my xorg.conf - basically using the one generated by aticonfig with one option I found on other posts:

    aticonfig –initial -f
    aticonfig –set-pcs-str=”DDX,EnableRandR12,FALSE”

    Also set grub.conf to include 'nopat' at the end of the kernel line.

    Hope this helps!

  10. #10
    Join Date
    Sep 2009
    Location
    Teetering between the edge of insanity and the border of all that's weird
    Posts
    107
    Quote Originally Posted by GrayFox
    Is it possible to get a new session started without a reboot?
    It should be, just hit CTRL-ALT-F2, log in as root with your root password and user name root (duh, but in case you are a noob) and run killall Xorg This should either restart the session or just kill the session. If it just kills the session, then run gdm and log in again. If this does not work, use suspend instead, hibernate has been a fedora weakness for a while. Hope this helps.

  11. #11
    Join Date
    May 2007
    Location
    U.S.
    Posts
    4,851
    Quote Originally Posted by bendib
    It should be, just hit CTRL-ALT-F2, log in as root with your root password and user name root (duh, but in case you are a noob) and run killall Xorg This should either restart the session or just kill the session. If it just kills the session, then run gdm and log in again. If this does not work, use suspend instead, hibernate has been a fedora weakness for a while. Hope this helps.
    Except if I'm understanding right, the OP stated he can't even get to virtual terminals.

    I was having the same crap with KDE. Hard-rebooted 9 times in one day because ctrl-alt-backspace zapping and flipping to virtual terminals wasn't even possible.
    - Tom
    "What is freedom? To have the will to be responsible for one's self." - Stirner

  12. #12
    Join Date
    Oct 2009
    Posts
    6
    Quote Originally Posted by tjvanwyk
    Except if I'm understanding right, the OP stated he can't even get to virtual terminals.

    I was having the same crap with KDE. Hard-rebooted 9 times in one day because ctrl-alt-backspace zapping and flipping to virtual terminals wasn't even possible.
    Yeah, when my notebook was locking up after a suspend/hibernate, there was nothing I could do to get a terminal back.

    * The obvious <ctrl><alt>-Fx terminal flip didn't work
    * <ctrl><alt><del> didn't work to restart X
    * Fn-F4 (or any other special keys) didn't work
    * SysRq combinations did not work either

    After I rebuilt my kernel initrd.img file (above), both Suspend and Hibernate started to work flawlessly.

Similar Threads

  1. Kill it
    By glennzo in forum Using Fedora
    Replies: 3
    Last Post: 4th March 2007, 03:37 PM
  2. kill doesn't....kill
    By wjstarck in forum Using Fedora
    Replies: 3
    Last Post: 3rd July 2006, 05:14 AM
  3. I think I might kill myself
    By Wrestler08 in forum Using Fedora
    Replies: 4
    Last Post: 12th March 2006, 11:03 AM
  4. kill X
    By o-ren in forum Using Fedora
    Replies: 7
    Last Post: 6th December 2004, 08:34 PM

Tags for this Thread

Posting Permissions

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