X fails to start

[Da Rock]

> Date: Thu, 2 Jul 2009 13:54:22 +0200
> Subject: Re: X fails to start
> From: onemda at gmail.com
> To: rock_on_the_web at hotmail.com
> CC: freebsd-questions at freebsd.org
> 
> On 7/2/09, Da Rock <rock_on_the_web at hotmail.com> wrote:
> >> Date: Thu, 2 Jul 2009 12:16:49 +0200
> >> Subject: Re: X fails to start
> >> From: onemda at gmail.com
> >> To: rock_on_the_web at hotmail.com
> >> CC: freebsd-questions at freebsd.org
> >>
> >> On 7/2/09, Da Rock <rock_on_the_web at hotmail.com> wrote:
> >> >
> >> > I'm still having intermittent troubles with getting the freebsd servers
> >> > seeing my mail servers for my normal maillist subscription, so if I
> >> > could be
> >> > cc'd...
> >> >
> >> > I'm struggling to get my head around a reasonably severe problem with
> >> > Xorg -
> >> > I'm wondering if anyone else is having the same. I've installed Xorg,
> >> > got it
> >> > working, started to refine some settings with the wm and other apps for
> >> > it,
> >> > and then Xorg refuses to work.
> >> >
> >> > My xorg log has only a couple of errors, for reference I'm using the
> >> > i915 ko
> >> > with drm:
> >> >
> >> > startx:
> >> > X.Org X Server 1.6.1
> >> > Release Date: 2009-4-14
> >> > X Protocol Version 11, Revision 0
> >> > Build Operating System: FreeBSD 7.2-RELEASE-p1 i386
> >> > ...
> >> > (EE) [drm] Could not set DRM device bus ID.
> >> > (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI.
> >> > Setting master
> >> > MIT-SHM extension disabled due to lack of kernel support
> >> >
> >> > Xorg.0.log:
> >> > ...
> >> > drmGetBusid returned ''
> >> > (II) [drm] DRM interface version 1.0
> >> > (EE) [drm] Could not set DRM device bus ID.
> >> > (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI
> >> > ...
> >> > (WW) intel(0): drmDropMaster failed: Unknown error: -1
> >> > ...
> >> > (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
> >> > (WW) intel(0): Existing errors found in hardware state.
> >> > ...
> >> > MIT-SHM extension disabled due to lack of kernel support
> >> > ...
> >> > (WW) intel(0): drmDropMaster failed: Unknown error: -1
> >> >
> >> > Because of my communications issues I've been trying to resolve this
> >> > myself-
> >> > with no luck. I've been trying to get some more info on this, and it
> >> > seems
> >> > to be a huge bug on a lot of linux distros, but noone has a clear
> >> > response-
> >> > it all seems to be a secondary issue to whatever their problem is. SO, I
> >> > then tried to find out how to debug, and ran into ANOTHER issue. I've
> >> > rebuilt xorg-server with debug (ccflags='-O0 -g3' as per xorg wiki) with
> >> > no
> >> > real success, so then I moved to dri and hit this wall:
> >> >
> >> > ../../../src/mesa/main/dispatch.o(.text+0xbb90):../../../src/mesa/glapi/glapitemp.h:4951:
> >> > first defined here
> >> > ../../../src/mesa/x86/glapi_x86.o(.text+0x4130): In function
> >> > `glPointParameteri':
> >> > ../../../src/mesa/x86/glapi_x86.S:1270: multiple definition of
> >> > `glPointParameteri'
> >> > ../../../src/mesa/main/dispatch.o(.text+0xc8e0):../../../src/mesa/glapi/glapitemp.h:5256:
> >> > first defined here
> >> > ../../../src/mesa/x86/glapi_x86.o(.text+0x4140): In function
> >> > `glPointParameteriv':
> >> > ../../../src/mesa/x86/glapi_x86.S:1271: multiple definition of
> >> > `glPointParameteriv'
> >> > ../../../src/mesa/main/dispatch.o(.text+0xc940):../../../src/mesa/glapi/glapitemp.h:5266:
> >> > first defined here
> >> > mklib: Installing libGL.so.1 libGL.so in ../../../lib
> >> > mv: rename libGL.so.1 to ../../../lib/libGL.so.1: No such file or
> >> > directory
> >> > gmake[2]: *** [../../../lib/libGL.so] Error 1
> >> > gmake[2]: Leaving directory
> >> > `/usr/ports/graphics/dri/work/Mesa-7.4.4/src/glx/x11'
> >> > gmake[1]: *** [subdirs] Error 1
> >> > gmake[1]: Leaving directory
> >> > `/usr/ports/graphics/dri/work/Mesa-7.4.4/src'
> >> > gmake: *** [default] Error 1
> >> > *** Error code 1
> >> >
> >> > Stop in /usr/ports/graphics/dri.
> >> >
> >> > The various warnings are in the gallon, but my main problem lay with the
> >> > mklib error. So I tried to simply copy or rename libGL.so(.1) to make it
> >> > happy (I couldn't find references in the Makefile(s) after half an hour
> >> > of
> >> > examination, so I took a little shortcut). It did, but then the gallon
> >> > of
> >> > warnings came back to hit me again- but harder, and so I get another
> >> > stop in
> >> > the build.
> >> >
> >> > So now I can't get dri back, I can't get X working and I'm losing my
> >> > patience fast! :)
> >> >
> >> > What I can't figure out is what started all this in the first place,
> >> > because
> >> > it was working. Unfortunately I was in the midst of several things
> >> > happening
> >> > at once, so I can't remember if I rebuilt the kernel, upgraded xorg or
> >> > both
> >> > before X failed. As far as I can tell that is only secondary at any
> >> > rate, as
> >> > I need to prevent this happening again during upgrades/updates whatever.
> >> >
> >> > My main questions here are:
> >> >
> >> > 1. How do debug Xorg? The debug flags haven't provided much at all so
> >> > far
> >> > (maybe I've done it wrong?)
> >>
> >> You can still use xf86-video-vesa even without dri.
> >> Debug flags are useful only if Xorg crashed and dropped core.
> >>
> >
> > Nuts! :(
> >
> >> > 2. Why can I get the busid failure and Xorg keep going? How do I force
> >> > it?
> >> > Where is this problem lying (kmod, driver, server)? Is it critical?
> >>
> >> What kernel modules are loaded? What version of server, Mesa, drivers
> >> are installed
> >> and how are they installed?
> >>
> >
> > KMods:
> > i915.ko
> > drm.ko
> >
> > Xorg Server: 1.6.1 (in the Xorg log)
> > Mesa (not entirely sure now, was current I believe though- I'll have to wait
> > and see once I can build again...)
> > Drivers: (installed or used?) used intel- xorg ports. Incidentally vesa is
> > available, and is failover in the conf, but it doesn't get there. Its also
> > installed via ports.
> 
> You can use vesa if you specify alternative or modify default server layout.
> But anyway without xorg.conf I can't comment on this.
> 
> >> > 3. Is the MIT-SHM error the cause of my problems? (Or a contributor)
> >>
> >> You are using custom kernel without sysv* modules. Not a good idea for X.
> >>
> >
> > Interesting. Isn't this standard in GENERIC? I have built a kernel, but only
> > GENERIC, which I would have thought had the standard kit in it that comes
> > with a distro on disk.
> 
> Than it is not problem, probably some Xorg way to report errors.
> 
> >> > 4. What do I need to do about the Mesa library? Is this related to the
> >> > core
> >> > issue? Is this a known bug in the port build?
> >>
> >> Your environment is highly polluted.
> >>
> >
> > eh? I could use some explanation on this, especially considering my last
> > remedy used in this communication. As per my last comment in the OP, I've
> > run portsclean -C and then removed all ports (something I have the luxury of
> > doing being a new system install), and started again- with the same result.
> > What exactly do I have to clean up to remove the pollution? (This is no
> > reflection on your comment, I'm merely at a loss to know what could be
> > getting in the way here given my situation)
> 
> Perhaps you forgot to run "make clean"?
> Just remove whole /usr/local,/usr/ports,/var/db/pkg and update ports tree.
> Yes, this is very radical approach but I don't know any better way.
> 

And I thought I was radical! I didn't want to sound ruthless, but I ran pkg_delete -f \* which I believe achieves the same result (and from what I understand so does portsclean -C - only available if you have installed portupgrade as I found out once) and thats how I cleaned my system to start again. For anyone else watching, be very careful if and when you do this- don't reboot or something until you have a grasp of what you have done! :)

In my circumstances its impossible to actually blow away the ports system, but I can kill the pkg db - I'm just not entirely sure why. Ports is up to date - ran portsnap twice jic. My only other alternative is to blow away usr/local- in case that may be getting in the way (I don't know exactly how, but I AM getting desperate!).

Before I do that I might run make clean in the ports (jic portsclean isn't doing its job properly), and blow away the ports db (hence the options saved). I still don't hold much hope.

As for the pollution factor, I'm not sure. This has to be one of the cleanest systems I've setup yet- I'm starting small and building up from there, but I haven't even reached the first landing yet!

I've had a lot worse- in fact the system itself is a complete rebuild from the major f***kup I committed before- don't ask what I was thinking, but I did blow away the db dir for pkg AND ports, so updates were impossible, and I didn't even know (or the system) what was actually installed (thank god it was only a desktop!). Definitely a blonde moment... and I'm not even blonde (or female)! Must have been a long day or a late night... :)

> >> > I've considered manually debugging the drmGetBusID failure, but I don't
> >> > exactly relish the idea of going through that much code. I could easily
> >> > follow the procedures in the wiki, but I'd rather go through ports.
> >> >
> >> > I've also just completely removed xorg and started again with the
> >> > cflags,
> >> > but it has failed again at the dri port.
> >> >
> >> > I hope someone can help here... :/
> 
> -- 
> Paul

_________________________________________________________________
Looking for a place to rent, share or buy this winter? Find your next place with Ninemsn property
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT