[00:00] <Sarvatt> kklimonda: updated lbm-nouveau uploading now that should fix it
[00:00] <Sarvatt> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=53293422072043e897c2d755d4139b5e4d5532de
[00:00] <RAOF> Sarvatt: Have you made it conflict/replaces nouveau-kernel-source?
[00:01] <Sarvatt> nope, will do that next upload, working on libdrm/ddx now and libdrm is a pain in the butt
[00:02] <RAOF> *Another* update to nouveau_class.h?
[00:02] <RAOF> Bah.
[00:02] <Sarvatt> yeah they do this all the darn time, part of the reason i was so skeptical about nouveau in lucid
[00:03] <RAOF> But they haven't updated the DDX for those changes; does the DDX not use them at all?
[00:05] <Sarvatt> think its just mesa that needs the updated nouveau_class.h for now
[00:06] <Sarvatt> they added texture_from_pixmap to nouveau_vieux to have texture_from_pixmap and stuff a few hours ago
[00:06] <Sarvatt> err, ignore the bad english :)
[00:07] <RAOF> Ah.
[00:08] <Sarvatt> the nv50 stuff just looks like formatting changes and new defines instead of changed values? I dont know
[00:08] <Sarvatt> guess we'll see if it builds
[00:09] <Sarvatt> guess i should hold off just incase it needs updating huh? :D
[00:10] <Sarvatt> libdrm is *such* a pain to update, dont mind holding off :)
[00:10] <RAOF> :)
[00:14] <Sarvatt> maybe the kernel guys should just bring nouveau in from upstream instead of linus since its 2.6.32 based and could go right in the kernel without backporting all of drm, that way nouveau would just be the only sketchy thing :)
[00:24] <RAOF> It's not really 2.6.32-based, though.
[00:24] <RAOF> It's 2.6.32+drm-next
[00:25] <RAOF> IE: It's basically 2.6.33's drm stack (and, soon, is likely to be 2.6.34-rc1's drm stack).
[00:42] <superm1> hmm umm is there any known scenarios that nouveau freezes and next time you try to boot the machine is hung before the BIOS screen...?
[00:44] <superm1> just a flashing volume LED, no POST no nothing...
[00:45] <RAOF> It would be theoretically possible for nouveau to do that, I think.  I've never experienced it, though.
[00:45] <RAOF> You've powered-off, rather than warm-rebooted?
[00:45] <superm1> unplugged, and removed battery
[00:45] <superm1> i was just using the machine all day today with a 9.10 install no problems and was trying out the today's 10.04 daily
[00:46] <RAOF> I don't know; I've never run into anything like that.  I'd give raising this in #nouveau a whirl.
[00:48] <superm1> * #nouveau :Cannot send to channel
[00:48] <superm1> is there something special to do to be allowed to talk there?
[00:48] <RAOF> Are you registered with nickserv?
[00:49] <superm1> i must have lost my registration during a netsplit or something
[00:55] <Sarvatt> wow, that would be insane
[00:56] <Sarvatt> can you blind flash whatever model you're using? alot of people had that happen with the shipping bios on these aspire ones but luckily we can blind flash these to fix it
[00:57] <Sarvatt> maybe try pulling power/battery and holding the power button for a few minutes and trying again?
[00:57] <RAOF> Looks like darktama's on it in #nouveau.
[01:01] <superm1> Sarvatt, flashing unfortunately requires it to be booted on these, and only from DOS binaries
[01:04] <Sarvatt> no hidden key combo to bypass it and flash? i think its function+escape in most insyde bioses
[01:04] <superm1> if it at least POSTed maybe, but it's definitely hung on boot when trying to POST - the backlit keyboard doesn't even turn off
[01:04] <superm1> which is normally BIOS controlled
[01:05] <Sarvatt> function+escape, press power, wait a few seconds and release function+escape and the power light blinks
[01:05] <Sarvatt> when mine crashes i dont get POST or anything and it still has a recovery blind flash you can do at least
[01:06] <superm1> same behaviors when i'm trying that
[01:06] <Sarvatt> does it through the insyde efi internal stuff instead of the bios emulation layer or something
[01:06] <Sarvatt> oh that means it should work
[01:06] <superm1> no i mean same behaviors as what i was seeing before
[01:06] <superm1> flashing volume LEDs, frozen backlit keyboard no POST
[01:07] <Sarvatt> need a usb stick formatted fat, with the bios named whatever.FD on it
[01:07] <Sarvatt> oh ok
[01:07] <superm1> well i'm not sure i want to sacrifice another laptop like this to try'n fetch the X log
[03:46] <Sarvatt> RAOF: forgot to attach the debdiff?
[03:46] <RAOF> To the lbm bug?  No.  Just filing first, so I can close it in the changelog :P
[03:47] <RAOF> Do we currently have somewhere to publish that for ctxprog testing?  I don't have any cards new enough to need it.
[03:47] <Sarvatt> The attached debdiff pulls the nouveau changes from 2.6.33-rc7 to 2.6.33
[03:47] <Sarvatt> :P
[03:47] <Sarvatt> maybe x-updates?
[03:47] <RAOF> It's attached now :P
[03:47] <Sarvatt> or delete all of xorg-edgers/nouveau and just put that in there
[03:48] <Sarvatt> kklimonda had problems with just the ctxprogs generator :(
[03:48] <Sarvatt> there was another fix in upstream git for it
[03:48] <RAOF> Was that with the fix?
[03:48] <RAOF> Right; that's in the debdiff, too.
[03:48] <Sarvatt> i'm  not sure if that fixed it for them though
[03:48] <RAOF> That's what I was thinking, but I think bryceh has disabled xorg-edgers/nouveau?
[03:49] <Sarvatt> ya should be able to reenable it
[03:50] <Sarvatt> only me and tormod are admins so i think anyone can
[03:50] <Sarvatt> done
[03:54] <RAOF> And are you subscribed to lbm in lucid, or something? :)
[03:57] <Sarvatt> nope, I was just looking into joining bug-control and saw the bug rss feed link, yours was the first one on the list :)
[03:57] <RAOF> Hah.
[03:59] <Sarvatt> Posts per week: 1,537.2
[03:59] <Sarvatt> sheeeesh
[03:59] <Sarvatt> i thought ubuntu-x-swat was bad :)
[04:02] <Sarvatt> http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-nouveau/nouveau-bgnr.patch?view=markup
[04:02] <Sarvatt> yoink
[04:03] <RAOF> Ah.  We want that for plymouth, don't we.
[04:04] <Sarvatt> we have 189_xserver_1.5.0_bg_none_root.patch in xserver but none of the ddx specific patches enabling it there
[04:05] <Sarvatt> looks like its being used too /usr/bin/X :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-j5c54J/database -nolisten tcp vt7
[04:07] <Sarvatt> (the -nr option)
[04:08] <Sarvatt> http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-intel/copy-fb.patch?view=markup
[04:08] <Sarvatt> intel version
[04:10] <Sarvatt> well thats for 2.10, 2.9.1 version is http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-intel/copy-fb.patch?revision=1.9&view=markup
[04:17] <Sarvatt> ah we've got the intel one in the lucid package, explains why i lost the smooth transition when i switched to edgers :)
[04:17] <Sarvatt> gotta add that nouveau one though
[04:18] <Sarvatt> imagine theres a radeon one we need to pick up too
[04:18] <RAOF> It looks pretty simple.
[04:22] <Sarvatt> the smooth transition  looks really nice, leaves the logo on the screen while the panel loads and stuff
[04:23] <Sarvatt> not just a jerky 1 second ubuntu splash to  a black screen like it is without it
[04:27] <Sarvatt> uploading a new nouveau snapshot on edgers with that patch
[04:28] <RAOF> Huzzah.
[04:35] <Sarvatt> there's radeon's patch -  http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-ati/radeon-6.9.0-bgnr-enable.patch?view=markup
[04:48] <Sarvatt> ahhh looks MUCH better now
[04:49] <Sarvatt> i didnt understand the point of a 1 second splash screen but its nice with these ddx patches at least
[04:51] <RAOF> I've also applied that to nouveau in pkg-xorg git.
[04:52] <Sarvatt> woot just need to see if radeon has the patch or not now
[04:54] <Sarvatt> btw found a api 0.0.16 patch for 2.6.33, might use that on top of linus' for nouveau http://cvs.fedoraproject.org/viewvc/devel/kernel/drm-nouveau-abi16.patch?view=markup
[04:55] <Sarvatt> all kinds of crack in fedora cvs
[04:57] <tjaalton> bryceh: doesn't bzr hate you just as much when you forget to do 'bzr extmerge --all' or something?-)
[05:20] <Sarvatt> fbdev bgnr patch, that'd help out arm - http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-drv-fbdev/BGNoneRoot.patch?view=markup
[05:37] <Sarvatt> http://sarvatt.com/downloads/patches/xserver-xorg-video-fbdev_0.4.1-1ubuntu1.debdiff
[08:21] <toabctl> hi
[08:54] <bryceh> tjaalton, haven't found bzr hating me so far
[08:58] <tjaalton> bryceh: just because you haven't done any merges like that with it :)
[08:58] <tjaalton> no tool does that automatically
[15:42] <tjaalton> bryceh: bh.org:8080 fails to connect
=== yofel_ is now known as yofel
=== Sinnerman is now known as Cobalt
[17:58] <bryceh> tjaalton: yeah I'm in the middle of a hardy->lucid upgrade and it's an old machine so it's hit a variety of glitches
[18:02] <tjaalton> bryceh: heh, ok. I'm doing karmic->lucid on my home desktop, though it still needs more space on /
[18:02] <tjaalton> it's a 500GB disk and root has 11GB.. how wise was that?
[18:03] <bryceh> /dev/sda4              13G   11G  2.1G  83% /
[18:03] <bryceh> I wasn't much smarter tjaalton
[18:04] <bryceh> but it's just a webserver so I've been able to just uninstall stuff to get it down
[18:16] <bjsnider> there aren't any remaining issues with jockey being able to activate the nvidia driver are there?
[18:19] <bryceh> bjsnider, probably will always be some issues, but at the moment I believe we believe it should work properly
[18:19] <bjsnider> cool
[18:20] <bjsnider> the +1 channel is choked with people complaining about it, but i think it's where they upgraded from that's the problem
[18:20] <bryceh> ah, are they mostly upgrading from self-installed nvidia's?
[18:20] <bjsnider> good question. i'm guess they were using the nvidia installer
[18:21] <bryceh> tseliot has been looking to these kinds of bugs so he might want to look into it
[18:29] <superm1> bryceh, tseliot perhaps a good solution is to have update-manager attempt to detect a situation that the nvidia installer has been manually ran just like the packages do, and block the upgrade until it's removed
[18:33] <bjsnider> superm1, what if the user does not know how to remove it?
[18:38] <Sarvatt> we should probably have nvidia-current packages conflict with -190 and -195 even though they were never in ubuntu since alot of people used PPAs
[18:54] <Sarvatt> how about a preinst script for nvidia that tries to find a nvidia-installer binary, and calls it with nvidia-installer --uninstall before?
[18:56] <Sarvatt> or just wont install if it exists since it's only there if the blob has been manually installed as far as I can see
[19:09] <mvo> superm1: if someone gives me instructions what to look for I'm happy to implement that
[19:09] <apw> RAOF, about?
[19:18] <Sarvatt> jcristau: \o/ \o/ \o/ THANK YOU! :)
[19:18] <Sarvatt> for the patch on dri-devel
[19:20] <Sarvatt> moving libdrm headers to /usr/include/libdrm will be so much better
[19:29] <superm1> tseliot, can you provide mvo that information?
[19:35] <Sarvatt> I think you could check for /usr/bin/nvidia-bugreport.sh
[19:35] <Sarvatt> i see that in the extracted .run but its not installed in the package
[19:36] <tjaalton> instead of nvidia-bug-report.sh, which was installed by the deb?
[19:38] <Sarvatt> ah darn yeah its in /usr/lib/nvidia-current/bin/ in the deb
[19:39] <Sarvatt> tls-test isnt in the deb though
[19:39] <tjaalton> /usr/bin/nvidia-bug-report.sh in karmic
[19:39] <tjaalton> but that's 185
[19:39] <bryceh> tjaalton, btw bh.org back online.  upgrade complete.
[19:40] <Sarvatt> --slave /usr/bin/nvidia-bug-report.sh nvidia_bug_report /usr/lib/nvidia-current/bin/nvidia-bug-report.sh \
[19:41] <tjaalton> bryceh: ah, good
[19:42] <Sarvatt> /usr/bin/tls-test isnt installed in the nvidia-current package though, no clue if its installed manually but its in usr/bin/ in the extracted blob
[19:43] <Sarvatt> /usr/lib/libGL.la?
[20:36] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/nouveau-kernel-source/+bug/528683
[20:36] <ubottu> Launchpad bug 528683 in nouveau-kernel-source "Please remove nouveau-kernel-source from the archive (lucid)" [Undecided,New]
[20:46] <Sarvatt> wish i could set wontfix, closing out a crapload of nouveau-kernel-source lucid bugs
[20:47] <johanbr> superm1, any luck with your half-dead laptop?
[20:58] <superm1> johanbr, yes it's back to life per some comments in #nouveau, but it certainly freezes on any lucid boot now, and is broken again
[21:02] <Sarvatt> the new lbm-nouveau that just got uploaded should help you superm1
[21:02] <superm1> Sarvatt, okay i'll wait until a new daily image to try again
[21:13] <Sarvatt> it still might be iffy, the chipset generation you have is one of the sketchier ones with the ctxprog generator and you might need to boot with lbm-nouveau.noaccel=1 manually from tomorrows livecd
[21:16] <Sarvatt> bryceh: if we're sticking to 2.9.1 shouldnt we stop passing --enable-kms-only for intel? so these 8xx people can boot with UMS
[21:17] <Sarvatt> actually, i'm wondering if these people saying booting with i915.modeset=0 on 8xx are actually using vesa when they say it works that way because of that
[21:17] <Sarvatt> saying that works I mean
[21:18] <Sarvatt> because if thats the case it changes my opinion on the 2.9.1/2.10 debate :)
[21:27] <bryceh> Sarvatt, yep, it's on my todo list to reverse that
[21:28] <bryceh> who is saying that modeset=0 works for them?  I agree it'd be good to look at their xorg.0.log
[21:29] <Sarvatt> that blog you linked the other day for one, i dont have any specific bug #'s handy but i'll keep an eye open when i see another next
[21:31] <Sarvatt> because if it works with modeset=0 and they are using vesa that way because of the intel configure flag just moving them to vesa + modeset=0 or fbdev on top of KMS with intel 2.10 might be better. reverting that configure flag might break things again since they'd be using UMS intel instead
[21:33] <bryceh> mm true
[21:33] <bryceh> still, I think it's a good strategy for us
[21:38] <superm1> bryceh, recently cjwatson removed xforcevesa from the daily's afaik.  if new nvidia hardware is gonna be iffy with nouveau, i think it'll be important to still have that as an option
[21:38] <superm1> although i guess the nouveau kernel module is still gonna load with that isn't it..
[21:39] <superm1> so still potential to break
[21:39] <bryceh> superm1, yeah
[21:39] <superm1> so perhaps xforcevesa should still live on, but blacklist intel/radeon/nouveau?
[21:40] <bryceh> superm1, on the plus side, failsafex now uses fbdev properly with kms (and I even tested it on nouveau), but I think that kicks in only for X breakage.  If something is wrong at the KMS layer, I'm not sure it'll help
[21:40] <bryceh> superm1, sounds like something we need to chat with sconklin and apw about
[21:41] <bryceh> superm1, along with that is the need for enabling users to override the mode detection such as if a KVM is blocking edid (as per discussion on kernel list the other day)
[21:41] <superm1> bryceh, yup
[21:41] <superm1> well once things are declared more "stable", the QA folks should try on newer hardware and see if the need is really still there too
[21:42] <bryceh> superm1, would you mind writing this up as a bug report to the kernel?  I'll +1 it and bump up priorities for it with apw/sconklin
[21:42] <Sarvatt> video=blah doesnt work for whoever had that problem bryceh?
[21:42] <bryceh> Sarvatt, I've heard it didn't; I've not tested that myself so dunno if that is a general solution to this or not
[21:43] <bryceh> you tested it yet?
[21:43] <Sarvatt> yeah it works here but i only played with it with a console boot
[21:46] <Sarvatt> so a kernel command line option that launches a failsafe X would work right? is that all xforcevesa did before?
[21:48] <Sarvatt> oh spiffy, you got the fbdev + kms stuff working in failsafeX bryce? gotta try that out
[21:54] <BUGabundo> boas noites
[21:58] <tjaalton> superm1: xforcevesa hasn't been useful since we stopped using dexconf
[21:58] <tjaalton> ie. it did nothing aiui
[21:58] <superm1> tjaalton, not true, please see casper bzr
[21:58] <tjaalton> not without a link :)
[21:59] <superm1> lp:ubuntu/casper/lucid
[21:59] <superm1> it's in casper-bottom
[21:59] <tjaalton> a browser link
[21:59] <superm1> 20xconfig
[22:00] <tjaalton> bah, don't bother :)
[22:00] <tjaalton> trust your word on it
[22:07] <bryceh> Sarvatt, yeah failsafeX should be good to go with KMS now
[22:07] <bryceh> Sarvatt, I'm not sure that xforcevesa made failsafex launch, or just make the system boot with vesa
[22:08] <bryceh> if the latter, then maybe what's needed is something to force fbdev?
[22:08] <bryceh> s/make/made/
[22:09] <bryceh> (I builk software too much)
[22:09] <bryceh> Sarvatt, it might be nice to have a way to launch into failsafex from grub or from the safeboot option maybe
[22:09] <bryceh> not sure
[22:10] <bryceh> maybe a lucid+1 thing
[22:19] <tseliot> superm1: ?
[22:20] <tseliot> superm1: the installer might break things in different ways and you need to shut down X in order to do --uninstall (if I remember correctly)
[22:24] <superm1> tseliot, well the thought process is tell the user they need to do that to upgrade, so you dont knowingly break
[22:25] <superm1> they had to stop X to do it once, they can do it again
[22:25] <tseliot> superm1: aah, ok
[22:27] <bjsnider> superm1, but do they know about the --uninstall option?
[22:27] <bjsnider> it would be better if nvidia just didn't provide an installer at all
[22:29] <superm1> bjsnider, you tell them in the popup from update-manager
[22:29] <bjsnider> cool
[22:29] <superm1> warning: you installed using the nvidia installer, you must uninstall using blah blah command 
[22:29] <superm1> and give them directions
[22:31] <bjsnider> confusing
[22:31] <bjsnider> if i didn't already know what it is i might ask what the nvidia installer is
[22:44] <tjaalton> heh, could reproduce the "package foo in installed and configured already" 'bug' while upgrading to lucid
[22:45] <tjaalton> happened because root got full, despite u-m thinking it had enough space before it started the upgrade
[22:46] <tjaalton> s/in/is/
[23:10] <superm1> bjsnider, well hopefully they'll remember that they manually ran said command to install the nvidia driver the first time
[23:24] <Sarvatt> bryceh: hmm, failsafe no workie here at all - http://pastebin.com/j9tCXSsR
[23:24] <Sarvatt> at least with the old echo foobar > /etc/X11/xorg.conf method
[23:24] <bryceh> Sarvatt, got an Xorg.failsafe.log ?
[23:25] <Sarvatt> its from feb 11th, it didnt even try to use failsafe
[23:25] <bryceh> got any xorg.conf.failsafe ?
[23:25] <Sarvatt> yeah the old vesa one
[23:25] <bryceh> hmm
[23:26] <Sarvatt> from feb 11th too
[23:26] <bryceh> doublecheck that you're using the latest version of xorg - verify that /etc/gdm/failsafeXServer has a timestamp of yesterday or newer
[23:26] <bryceh> if that's good, then check the udev rule that is supposed to trigger failsafeX
[23:26] <Sarvatt> -rwxr-xr-x 1 root root 4484 2010-02-23 01:37 /etc/gdm/failsafeXServer
[23:27] <bryceh> pastebinit /etc/gdm/failsafeXServer
[23:27] <bryceh> I think it should have a newer timestamp, it might be missing the fbdev bits.
[23:28] <Sarvatt> http://pastebin.com/Uzg5YFBC
[23:28] <bryceh> but that should have at least touched Xorg.failsafe.log
[23:28] <bryceh> yep that's the right version of failsafeXServer
[23:28] <Sarvatt> yeah it didnt even try, it just used a normal session and failed
[23:28] <bryceh> check the udev rule
[23:29] <Sarvatt> trying to find it
[23:29] <bryceh> that's one bit I did not test
[23:29] <Sarvatt> nothing in /lib/udev/rules.d/ that matches for grep -R failsafe .
[23:30] <bryceh> hmm
[23:30] <Sarvatt> its a udev rule that triggered it before? didnt know that
[23:31] <bryceh> originally it was gdm that triggered it
[23:31] <bryceh> but they dropped the functionality from gdm that we needed 
[23:31] <bryceh> (I guess redhat didn't need it for anything *grin*)
[23:32] <bryceh> so slangasek did a udev rule for it in karmic
[23:32] <bryceh> x11-common.failsafe-x.upstart
[23:32] <Sarvatt> no x11-common.failsafe* anywhere on my system
[23:33] <bryceh>         dh_installinit -px11-common --no-start --upstart-only --name failsafe-x
[23:33] <Sarvatt> ah init script
[23:33] <Sarvatt> theres a /etc/init.d/failsafe-x
[23:34] <bryceh> that's probably it
[23:34] <BUGabundo> guys how can I find out the EDID of my external LCDTV plugged via vga?
[23:34] <bryceh> BUGabundo, xrandr --verbose or get-edid
[23:34] <Sarvatt> dont be surprised when your tv doesnt expose all the resolutions i t works at over vga
[23:34] <BUGabundo> I know
[23:35] <BUGabundo> vga has limits
[23:35] <BUGabundo> *lower
[23:35] <Sarvatt> most 720p hdtv's i've messed with just do 800x600 :(
[23:35] <BUGabundo> mine goes higher
[23:35] <BUGabundo> but its cutting of part of the screen
[23:35] <BUGabundo> or off center
[23:35] <BUGabundo> depending on res
[23:35] <BUGabundo> $ xrandr --verbose | pastebinit 
[23:35] <BUGabundo> http://paste.ubuntu.com/384746/
[23:36] <Sarvatt> so i guess you could just do sudo /etc/init.d/failsafe-x start to start failsafe instead of the xorg.conf trick
[23:36] <BUGabundo> http://paste.ubuntu.com/384748/
[23:39] <Sarvatt> /etc/init.d/failsafe-x just looks like a skeleton
[23:40] <bryceh> it's a symlink
[23:40] <Sarvatt> cant wrap my head around how failsafe is started
[23:41] <bryceh> there must be a config file installed somewhere
[23:41] <BUGabundo> wow
[23:41] <BUGabundo> at 800x600 the pic is really nice
[23:42] <bryceh> ah /etc/init/failsafe-x.conf
[23:43] <Sarvatt> you have that?
[23:43] <Sarvatt> thats a leftover from superm1's dkms thing i think?
[23:43] <Sarvatt> its .unused here
[23:43] <Sarvatt> failsafe-x.conf.unused
[23:44] <Sarvatt> it got marked .unused during an upgrade a few months ago
[23:44] <bryceh> hrm
[23:44] <bryceh> I'm fairly sure this machine is a fresh install within the last month or two
[23:45] <Sarvatt> you have an /etc/init/failsafe-x.conf bryceh? maybe I screwed something up
[23:45] <bryceh> yeah I used the alpha-2 cd to install from
[23:45] <Sarvatt> will check my other machines when i get home
[23:46] <tjaalton> I have that after the upgrade
[23:46] <Sarvatt> i wouldnt put it past me to have renamed it screwing around with something
[23:46] <Sarvatt> .unused or .conf?
[23:47] <tjaalton> .conf
[23:47] <Sarvatt> ahh i screwed with it then, sorry about that
[23:47] <bryceh> $ dpkg --contents /var/cache/apt/archives/x11-common_1%3a7.5+1ubuntu6_all.deb | grep failsafe
[23:47] <bryceh> -rw-r--r-- root/root       132 2010-02-18 16:02 ./etc/gdm/failsafeBlacklist
[23:47] <bryceh> -rwxr-xr-x root/root      8610 2010-02-18 16:02 ./etc/gdm/failsafeXinit
[23:47] <bryceh> -rwxr-xr-x root/root      4595 2010-02-18 16:02 ./etc/gdm/failsafeXServer
[23:47] <bryceh> -rw-r--r-- root/root       291 2010-02-18 16:02 ./etc/init/failsafe-x.conf
[23:47] <bryceh> lrwxrwxrwx root/root         0 2010-02-18 22:06 ./etc/init.d/failsafe-x -> /lib/init/upstart-job
[23:47] <bryceh> Sarvatt, try reinstalling x11-common
[23:47] <Sarvatt> i bet it was when i was getting failsafe every time a fsck was run and it was annoying me :D