Re: X won't start

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux