This machine is running CentOS 5.3, fully updated Linux mavis.localdomain 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 athlon i386 GNU/Linux. Video is an ATI Radeon 9000. X froze overnight and attempts to restart it fail. I tried an old kernel (2.6.18-92.1.22.el5) before realizing that root can start X and a virgin user can start X. I still can't use my original user name. I'm sure the last line of this is telling me something that I'm missing.
(**) RADEON(0): RADEONDRIStop (**) RADEON(0): EngineRestore (16/16) (**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x9d2831c) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00030065 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3 (**) RADEON(0): Disposing accel... (**) RADEON(0): Disposing cusor info (**) RADEON(0): Disposing DGA (**) RADEON(0): Unmapping memory (**) RADEON(0): RADEONDRICloseScreen FreeFontPath: FPE "unix/:7100" refcount is 2, should be 1; fixing.
If it matters I normally boot into run level 3, log in and issue "startx" from the BASH prompt.
Any ideas welcome.
On Sun, 2009-04-19 at 12:25 -0500, Robert wrote:
This machine is running CentOS 5.3, fully updated Linux mavis.localdomain 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 athlon i386 GNU/Linux. Video is an ATI Radeon 9000. X froze overnight and attempts to restart it fail. I tried an old kernel (2.6.18-92.1.22.el5) before realizing that root can start X and a virgin user can start X. I still can't use my original user name. I'm sure the last line of this is telling me something that I'm missing.
(**) RADEON(0): RADEONDRIStop (**) RADEON(0): EngineRestore (16/16) (**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x9d2831c) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00030065 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3 (**) RADEON(0): Disposing accel... (**) RADEON(0): Disposing cusor info (**) RADEON(0): Disposing DGA (**) RADEON(0): Unmapping memory (**) RADEON(0): RADEONDRICloseScreen FreeFontPath: FPE "unix/:7100" refcount is 2, should be 1; fixing.If it matters I normally boot into run level 3, log in and issue "startx" from the BASH prompt.
Any ideas welcome.
--- IDEA ONLY! Caution! Perhaps the ATIRadeon Kernel Module is not loaded into the kernel? So maybe a modprobe <radeon_module_name>? then startx ATI seems to have a slew of these problems. Alternative: Try another card..
JohnStanley
On Sun, 2009-04-19 at 12:25 -0500, Robert wrote:
This machine is running CentOS 5.3, fully updated Linux mavis.localdomain 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 athlon i386 GNU/Linux. Video is an ATI Radeon 9000. X froze overnight and attempts to restart it fail. I tried an old kernel (2.6.18-92.1.22.el5) before realizing that root can start X and a virgin user can start X. I still can't use my original user name. I'm sure the last line of this is telling me something that I'm missing.
(**) RADEON(0): RADEONDRIStop (**) RADEON(0): EngineRestore (16/16) (**) RADEON(0): RADEONDisplayPowerManagementSet(0,0x0) (**) RADEON(0): RADEONRestore (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMode(0x9d2831c) (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0x1fff0000 (**) RADEON(0): MC_AGP_LOCATION : 0x27ff2000 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000000c 0x00030065 0x00000000 (0x0000a400) (**) RADEON(0): Wrote: rd=12, fd=101, pd=3 (**) RADEON(0): Disposing accel... (**) RADEON(0): Disposing cusor info (**) RADEON(0): Disposing DGA (**) RADEON(0): Unmapping memory (**) RADEON(0): RADEONDRICloseScreen FreeFontPath: FPE "unix/:7100" refcount is 2, should be 1; fixing.If it matters I normally boot into run level 3, log in and issue "startx" from the BASH prompt.
Any ideas welcome.
I'm now expert, but have done some programming in the past. I suspect that the X font server is either running already or scrogged the cleanup.
Try
# ps -eaf|grep xfs xfs 2927 1 0 07:12 ? 00:00:00 xfs -droppriv -daemon
and see if it is still running. If so, maybe a simple telinit 3 and then telinit 5 will clean it up and let you get going. Regardless, if it is running, something like this might give you enough to continue.
# lsof -p 2927 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME xfs 2927 xfs cwd DIR 253,0 4096 2 / <snip>
xfs 2927 xfs 3u unix 0xf5ded580 10315 /tmp/.font-unix/fs7100 xfs 2927 xfs 4u unix 0xf5c74700 13635 /tmp/.font-unix/fs7100
These lst two lines seem to be the socket setup the xfs uses. After making sure the xfs daemon is not running, you may be able to remove them. However, I believe they should disappear if you get the xfs shutdown cleanly. If there is an old socket left in the fs from some kind of previous error, this may not clean up properly.
I do think a telinit 3/5 combo might do it. If not, a reboot should remove the /tmp file system and recreate it new. Then you should be OK.
# ls -l /tmp/.font-unix/*7100* srwxrwxrwx 1 xfs xfs 0 Apr 19 07:12 /tmp/.font-unix/fs7100
<snip sig stuff>
Again, I'm not really knowledgeable about this stuff.
HTH
William L. Maltby wrote:
On Sun, 2009-04-19 at 12:25 -0500, Robert wrote:
<snip>
<snip sig stuff>
Again, I'm not really knowledgeable about this stuff.
HTH
First, thanks to both you and John Stanley and anyone else whose reply I lost.
Finally, after beating up on myself, I found an <empty> ~/.Xclients-default file. Not missing, but empty! Copying the file from the newly created user fixed the problem.
This is after the repair: [rj@mavis ~]$ ls -l ~/.X* -rw------- 1 rj rj 222 Mar 19 11:52 /home/rj/.Xauthority -rwxr-xr-x 1 rj rj 189 Jun 20 2007 /home/rj/.Xclients -rwxr-xr-x 1 rj rj 189 Apr 19 13:09 /home/rj/.Xclients-default
I don't understand why .Xclients and .Xclients-default are the same length (or even why both are needed).
[rj@mavis ~]$ cat .Xclients #! /bin/bash
# Created by Red Hat Desktop Switcher
if [ -e "$HOME/.Xclients-$HOSTNAME$DISPLAY" ]; then exec $HOME/.Xclients-$HOSTNAME$DISPLAY else exec $HOME/.Xclients-default fi [rj@mavis ~]$
and
[rj@mavis ~]$ cat .Xclients-default #! /bin/bash # Created by Red Hat Desktop Switcher
WM="startkde" WMPATH="/usr/bin /opt/bin /usr/local/bin /usr/X11R6/bin"
for p in $WMPATH ; do [ -x $p/$WM ] && exec $p/$WM done
exit 1 [rj@mavis ~]$
But startx sure grows disappointed in a hurry if the latter is empty.
On Sun, 2009-04-19 at 13:54 -0500, Robert wrote:
William L. Maltby wrote:
On Sun, 2009-04-19 at 12:25 -0500, Robert wrote:
<snip>
<snip sig stuff>
Again, I'm not really knowledgeable about this stuff.
HTH
First, thanks to both you and John Stanley and anyone else whose reply I lost.
Finally, after beating up on myself, I found an <empty> ~/.Xclients-default file. Not missing, but empty! Copying the file from the newly created user fixed the problem.
This is after the repair: [rj@mavis ~]$ ls -l ~/.X* -rw------- 1 rj rj 222 Mar 19 11:52 /home/rj/.Xauthority -rwxr-xr-x 1 rj rj 189 Jun 20 2007 /home/rj/.Xclients -rwxr-xr-x 1 rj rj 189 Apr 19 13:09 /home/rj/.Xclients-defaultI don't understand why .Xclients and .Xclients-default are the same length (or even why both are needed).
[rj@mavis ~]$ cat .Xclients #! /bin/bash # Created by Red Hat Desktop Switcher if [ -e "$HOME/.Xclients-$HOSTNAME$DISPLAY" ]; then exec $HOME/.Xclients-$HOSTNAME$DISPLAY else exec $HOME/.Xclients-default fi [rj@mavis ~]$and
[rj@mavis ~]$ cat .Xclients-default #! /bin/bash # Created by Red Hat Desktop Switcher WM="startkde" WMPATH="/usr/bin /opt/bin /usr/local/bin /usr/X11R6/bin" for p in $WMPATH ; do [ -x $p/$WM ] && exec $p/$WM done exit 1 [rj@mavis ~]$But startx sure grows disappointed in a hurry if the latter is empty.
--- Interesting.. Upstream mentions in bugzilla that the kernel module is not loaded. Maybe if that specific file is not present that is what happens also?>
-
JohnS -
Robert -
William L. Maltby