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 -- Bill