[00:00] <RAOF> bryceh: It wasn't obvious to me how to make it work with a “DRI "on"” override; it would be easy enough to add a new parameter, though.
[00:01] <bryceh> RAOF, that sounds fine
[00:01] <RAOF> I'm not sure that disabling DRI bought us much, though.
[00:01] <bryceh> want to just drop the patch entirely?
[00:02] <RAOF> Yeah.
[00:02] <bryceh> if the patch is dropped, then users can opt to turn off DRI the usual way
[00:02] <RAOF> I think drop the patch, and drop to vesa.
[00:02] <bryceh> hmm, I think I tend favoring documenting the workarounds, rather than forcing to vesa
[00:03] <bryceh> (of course, I say this not owning any 8xx...)
[00:03] <RAOF> Well, it wouldn't be forcing vesa.  And the nice thing about defaulting to vesa is that the user will have a working X to check for workarounds.
[00:03] <jcristau> bryceh: you can just drop those pci ids from the server autoconfig for intel.  then by default it'll choose vesa+fbdev, and if people want to force it they can set intel in xorg.conf?
[00:04] <RAOF> jcristau: Exactly.
[00:04] <RAOF> If the user happens to have a system where -intel freezes X almost immediately after starting X, it's much more difficult for them to find & apply workarounds.
[00:05] <bryceh> hmm
[00:09] <jcristau> every new comment from danvet on that bug 27187 makes the story even more sad..
[00:09] <ubottu> Launchpad bug 27187 in initramfs-tools "failure with 2.6.15 on vmware 5.5 (scsi disk)" [Medium,Fix released] https://launchpad.net/bugs/27187
[00:09] <jcristau> bad ubottu 
[00:10] <Sarvatt> well thats new - http://paste.ubuntu.com/418914/
[00:14] <bryceh> if we go with vesa for this for release, I think that will make it quite hard to get it re-enabled for .1
[00:14] <bryceh> RAOF, with that said though, since I won't be involved in the .1 stuff, I'll defer to your preference here
[00:15] <RAOF> bryceh: Because it will be difficult to get testing?
[00:15] <bryceh> dropping to vesa seems to be rather extreme, but then it does not look like we can expect any simple fix any time soon from upstream
[00:15] <bryceh> RAOF, that, but also because generally it's expected any change be provably free of causing regression
[00:16] <RAOF> Which will be difficult, moving from vesa.  Yeah.
[00:16] <bryceh> someone with a working 8.04 that finds it broken on going to 8.04.1 risks getting really bad press, so archive admins will be very hesistant to accept such changes
[00:17] <bryceh> otoh it seems silly to argue that we should release with known breakage now, just so it's easier to justify updating in .1
[00:18] <RAOF> So, our story for people who have broken i855 is going to be either “We've turned off all the features of your video card to stop it from crashing” or “If your graphics keep crashing, try $LIST_OF_WORKAROUNDS”.
[00:19] <bryceh> pretty much
[00:21] <RAOF> Can we get them to a known-stable X just from the kernel command line?
[00:23] <jcristau> does blacklist=i915 work?
[00:23] <Sarvatt> well todays kernel doesn't work well, dmesg is flooded with [  172.258651] [drm:i915_gem_do_execbuffer] *ERROR* Object f437eea0 appears more than once in object list
[00:24] <Sarvatt> jcristau: thats getting ignored later on in the boot process for me at least
[00:24] <jcristau> or does that just blacklist it from the initramfs, not the actual system?
[00:24] <jcristau> Sarvatt: damn, ok
[00:25] <RAOF> “i915.disable=yes” would prevent the kernel module from loading; I'm not sure if that's sufficient to force a working configuration, though.
[00:25] <jcristau> istr some xforcevesa cmdline option in ubuntu a while back, does that still exist?
[00:26] <Sarvatt> jcristau: nope :( I tried adding it back but ran into problems where those blacklists were getting ignored later in the boot
[00:26] <Sarvatt> its there for livecd's, all it does is make a xorg.conf with vesa in it which will break people using KMS horribly :)
[00:27] <Sarvatt> and installs that xorg.conf too if you install booting with it
[00:27] <jcristau> it would probably be easy to hack up some /proc/cmdline parsing in xf86AutoConfig.c, but eww.
[00:28] <jcristau> like 'if /proc/cmdline contains failsafe, don't bother with the native driver, go with the fallbacks'.  still, eww.
[00:28] <Sarvatt> jcristau: do you know if pci_device_has_kernel_driver from libpciaccess checks for KMS or just if there is a kernel module loaded for it?
[00:29] <Sarvatt> yeah I added it to grub's upstart script actually, can just exit 1 and it'll start failsafe automatically and our failsafe checks if KMS is in use to use fbdev or vesa
[00:30] <Sarvatt> err sorry GDM
[00:30] <jcristau> Sarvatt: if (stat(/sys/bus/pci/xxxxx/driver) == 0) return true; else return false;
[00:31] <jcristau> not sure if that exists in the non-kms case
[00:34] <bryceh> yeah, xforcevesa is gone
[01:17] <wgrant> Bug #565981 is a bit scary.
[01:17] <ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981
[01:38] <bryceh> Re: Bug #565981 -- could this be the memory bug discussed earlier?
[01:38] <ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Undecided,New] https://launchpad.net/bugs/565981
[01:39] <bryceh> oh reported by Tormod... so yeah sounds like it
[01:40] <wgrant> bryceh: Thanks.
[01:43] <bryceh> wgrant, when did you first notice this problem?
[01:43] <bryceh> wgrant, or are you able to reproduce it?
[01:44] <Sarvatt> i want to say it was around the -19 kernel here
[01:44] <bryceh> it would be helpful if we could pinpoint it specifically to the kernel or to xorg-server
[01:45] <wgrant> bryceh: I've been suspicious of it for a few weeks, but it has only been causing real thrashing for a couple of weeks now.
[01:45] <bryceh> hmm, alright
[01:45] <bryceh> well then probably not the xserver
[01:45] <wgrant> And since it is easily reproducible, I might grab an older kernel and see what happens.
[01:46] <wgrant> Hm, actually, maybe not. My bootloader is fragile enough as it is.
[01:47] <bryceh> is it easy enough to reproduce that the testing could be done with LiveCD's?
[01:47] <jcristau> i'd blame libdrm or xf86-video-intel rather than the server tbh.
[01:47] <jcristau> that or kernel.
[01:48] <bryceh> jcristau, we've had people claiming same behavior with -ati
[01:48] <jcristau> hmm. or mesa.  so many pieces..
[01:49] <bryceh> I hate releases
[01:49] <Sarvatt> libdrm wasnt updated, intel and mesa were though and whatever it is I get it with the latest git too
[01:50] <Sarvatt> looks like it was around the beginning of april, after 3-30 sometime judging by how often i started updating edgers again when I switched back :D
[01:50] <wgrant> Oh, oops, I thought the repro instructions weren't working well any more, since it appeared to only increase from 192MiB to 198MiB. Then I closed firefox and it went negative, so I was reading it an order of magnitude too low.
[01:50] <wgrant> So yes, it's still easily reproducible.
[01:50] <bryceh> well, xorg-server did get an update around 3-30
[01:50] <Sarvatt> i switched because i wanted to see if it was a problem there too
[01:51] <Sarvatt> oh yeah 1.98GB you had there :D
[01:51] <bryceh> the updates to -intel have been mostly cherrypicks
[01:51] <bryceh> aside from the Xv backport stuff we got from Debian it's been pretty pedestrian
[01:51] <Sarvatt> trying to narrow it down some more to start looking
[01:51] <bryceh> mesa got a version bump, but that was more recently
[01:51] <wgrant> I might downgrade to xorg-server 2:1.7.6-1ubuntu1 and see what happens.
[01:51] <bryceh> and I don't think it changed at all in late march
[01:51] <wgrant> (25/03/2010, that was)
[01:51] <bryceh> wgrant, that would help
[01:52] <Sarvatt> wgrant: your input devices would stop working is what'd happen :)
[01:52] <wgrant> Sarvatt: I was hoping there wasn't an ABI bump :(
[01:52] <Sarvatt> oh nevermind we dont have the dropped udev rules
[01:52] <wgrant> Oh, right.
[01:53] <Sarvatt> darn dont have the -18 kernel anymore
[01:53] <wgrant> Sarvatt: That's easy to fix, fortunately...
[01:53] <wgrant> It's not like we're Debian.
[01:54] <jcristau> hmm? :)
[01:55] <wgrant> Well, I guess you have snapshot.d.o.
[01:55] <jcristau> yep.
[01:56] <jcristau> and you'd have lp instead?
[01:56] <wgrant> Right.
[01:57] <Sarvatt> hmm why do we have "add some fallback placements for VRAM only objects", that was reverted upstream because it caused problems?
[01:58] <jcristau> isn't that radeon?
[01:59] <Sarvatt> yeah
[01:59] <Sarvatt> that r100 compiz fix
[02:09]  * Sarvatt tries reverting that dri2 fix
[02:13] <wgrant> Downgrading the server to -1ubuntu1 might have fixed it, although I'm running with a rather manual config, so it's not a wonderful test.
[02:18]  * bryceh eyeballs patches
[02:20] <bryceh> hmm
[02:20] <bryceh> from our changelog, none of the patches sound likely to cause memory leaks, I think we'd need to test patch by patch
[02:21] <bryceh> at least if -1ubuntu1 is proven to not have the issue at least we know it's not an upstream bug but one of the distro patches
[02:22] <Sarvatt> bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/553647 - http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=94ccaae1ff45c11453141469f5659b6d2a16c4bf
[02:22] <ubottu> Launchpad bug 553647 in xorg-server "xserver crash (repeatable, triggered by mouse-click)" [High,Incomplete]
[02:22] <Sarvatt> 1ubuntu1 didn't have that dri2 fix that ended up being done differently upstream in the end
[02:24] <wgrant> Yeah, -2ubuntu1 is good, -2ubuntu2 is bad.
[02:24] <bryceh> ah, so it would be 114_dri2_make_sure_x_drawable_exists.patch
[02:24] <wgrant> I looked at that patch before, but didn't feel too suspicious.
[02:25]  * wgrant upgrades again, and is pleased to have a working keyboard.
[02:26] <bryceh> Sarvatt, 114_dri2_make_sure_x_drawable_exists.patch is one you'd suggested - know if there's a better patch available, or should we just drop it for now?
[02:26] <Sarvatt> still waiting on xserver without that patch to build to see if it fixes the issue here too
[02:26] <Sarvatt> there are better patches available, they went through a ton of revisions but i have no idea if they apply to 1.7 branch
[02:27] <Sarvatt> digging up the bug
[02:27] <bryceh> well, at this stage we'd need something reasonably simple
[02:27] <bryceh> https://bugs.edge.launchpad.net/ubuntu/+bug/550218
[02:27] <ubottu> Launchpad bug 550218 in xorg-server "xserver crashes when closing application using clutter" [High,Fix released]
[02:28] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=26394
[02:28] <ubottu> Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,Assigned]
[02:29] <Sarvatt>  -- Bryce Harrington <bryce@ubuntu.com>  Wed, 31 Mar 2010 16:37:45 -0700
[02:29] <Sarvatt> wow I got the time exactly right
[02:33] <Sarvatt> yeah thats not going to apply cleanly, I see hunks in DRI2WaitMSC thats not on 1.7
[02:46] <Sarvatt> yeeep thats for sure the problem, 3 runs of tormods eog background loop and its hovering around 60MB
[02:47] <Sarvatt> will try to backport those patches tomorrow, looks doable but I have to pass out
[02:48] <Sarvatt> 188 objects
[02:48] <Sarvatt> 55336960 object bytes
[02:48] <Sarvatt> (with at least 20 chrome tabs open including flash ones)
[02:49] <Sarvatt> actually fedora probably already backported them since it affects F-12 too!
[02:50] <Sarvatt> nope
[02:50] <Sarvatt> The patches are now on xserver master, please give that a try and close the bug
[02:50] <Sarvatt> if it fixes the problem for you.
[02:51] <Sarvatt> that's going to be so lovely once we have 8 xserver release branches in lucid's lifespan
[02:51] <Sarvatt> with the 3 month release cycles
[02:53] <Sarvatt> oops I meant 12, 8 until the next LTS release :)
[03:32] <Sarvatt> this is rougher than it looked
[06:16] <stefanlsd> Im getting random gdm restarts on Lucid. Happened about 6 times this morning, any ideas where I can look? Ive checked normal log files and dont find anything conclusive...
[06:24] <RAOF> stefanlsd: What graphics card, log files pastebinned, etc?
[06:25] <RAOF> Too slow :/
[06:33] <stefanlsd> RAOF: sorry, having issues here :)  its a nVidia Corporation GT200 [GeForce GTX 260M] (running propietry drivers).  cant find anything relating to a crash in the logs under /var/log
[06:35] <RAOF> What, specifically are “random gdm restarts”?  Crash from a working session back to gdm?
[06:42] <stefanlsd> RAOF: yeah. just working, and screen goes black and im at GDM login again
[06:43] <stefanlsd> (happened twice since last post)
[06:45] <RAOF> There *should* be something either in dmesg or in /var/log/Xorg.0.log.old about that.
[06:49] <tjaalton> it's a blob, so not much we can do about
[06:50] <stefanlsd> http://pastebin.ubuntu.com/419026/ is my Xorg.0.log.old
[06:51] <stefanlsd> dont really see anything
[06:51] <stefanlsd> Just switched to opensource nv driver to see if i can reproduce it
[06:56] <RAOF> ddxSigGiveUp is “X has been asked nicely to shutdown”, right?
[06:59] <stefanlsd> mm. Would the backtrace stuff help? not sure since its not really a crash...
[07:01] <RAOF> Yeah.  To *me* it looks like something is telling X nicely to shut down, and it's complying.
[07:04] <stefanlsd> RAOF: hehe. thats nice of X :)
[07:04] <stefanlsd> nv drivers looks better so far, will run it today
[07:05] <RAOF> stefanlsd: dmesg doesn't have any complaints in it?
[07:45] <stefanlsd> RAOF: yeah, nothing in dmesg. no crash on nv driver yet though
[11:06] <vish> hmm , in this comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565981/comments/5  wgrant is referring to xserver-xorg  or xserver-xorg-core ?
[11:06] <ubottu> Launchpad bug 565981 in linux "[KMS] gem objects not deallocated" [Critical,New]
[11:07] <vish> not sure which package to downgrade and test 
[11:07] <wgrant> vish: xserver-xorg-core and xserver-common. xserver-xorg is the source.
[11:07] <wgrant> Er, xorg-server is the source.
[11:08] <vish> wgrant: ah, thanks.. so only those 2 i need to downgrade?
[11:08] <wgrant> vish: Potentially xvfb too, unless you want apt to be angry.
[11:09] <vish> we dont want that ;)  k.. thanks downgrading those 3..
=== skimj1 is now known as skimj
[15:50] <Sarvatt> just uploaded an xserver with the 2 commits backported, can anyone try it out? i'm about to  head out to work
[15:50] <Sarvatt> 1.7.6-2ubuntu7
[15:50] <Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/bugs
[15:54] <Sarvatt> vish, wgrant ^ :)
[15:58] <vish> Sarvatt: sure.. i had downgraded as per what wgrant mentioned and it seems to be working fine too..
[15:58]  * vish adds ppa
[15:58] <Sarvatt> removing that patch isnt really an option
[15:59] <Sarvatt> open quadrapassel and close it to see why :)
[16:00] <Sarvatt> lol
[16:00] <Sarvatt> dangit, I didn't think he'd really do it :(
[16:01] <vish> Sarvatt: damn you! ;p
[16:01]  * vish should stop blindly trying things mentioned on irc :s
[16:02] <vish> wow , that was a weird crash ..
[16:02] <Sarvatt> vish: sorry about that, that happens closing any clutter based app though
[16:03] <vish> Sarvatt: hehe , np.. ;) luckily i had no unsaved docs :)
[16:12] <Sarvatt> yeah xserver failed to build, ahh well will have to mess with it later
=== seb128_ is now known as seb128
[16:37] <Sarvatt> oh hmm, looks like silly mistakes, here goes try 2
[16:40] <Sarvatt> here's what i've got so far - http://sarvatt.com/downloads/patches/119_dri2_drawables.patch
[16:41] <Sarvatt> plus http://sarvatt.com/downloads/patches/120_glx_drop_destroywindow.patch which applied cleanly
[16:44] <Sarvatt> ah damn I forgot to account for http://cgit.freedesktop.org/xorg/xserver/diff/hw/xfree86/dri2/dri2ext.c?id=895f40792a14d8b88923bf3b428d31ae3bb31e46 
[17:07] <Sarvatt> darn, i'm not sure what to do here
[17:09] <Sarvatt> they added dri2DrawableRes = CreateNewResourceType(DRI2DrawableGone, "DRI2Drawable"); to DRI2Setup in dri2.c, we have an older dix abi and have to register it seperately, I split it out to this 
[17:09] <Sarvatt> +    dri2DrawableRes = CreateNewResourceType(DRI2DrawableGone);
[17:09] <Sarvatt> +    RegisterResourceName(dri2DrawableRes, "DRI2Drawable");
[17:10] <Sarvatt> guess I have to #include "registry.h" in dri2.c too to do that? this is a bit over my head, need someone else to look at it :)
[17:29] <ricotz> Sarvatt, seen this? https://bugs.freedesktop.org/show_bug.cgi?id=26394
[17:29] <ubottu> Freedesktop bug 26394 in Extensions/DRI "Server sometimes crashes when closing OpenGL programs" [Critical,Assigned]
[18:00] <bryceh> heya
[18:08] <NinoScript> Is this the appropiate place to ask about an xmodmap issue?
[18:10] <Sarvatt> ok try 4! hopefully this one works, found another dri2 commit that was changing things slightly in the way - http://sarvatt.com/downloads/patches/119_dri2_drawables.patch
[18:10] <Sarvatt> heyo bryceh!
[18:12] <bryceh> heya Sarvatt, how goes?
[18:15] <apw> bryceh, whats the gen on this DVI detect issue 
[18:15] <Sarvatt> just fighting this dri2 fix backport :)
[18:16] <bryceh> apw, gen which?
[18:17] <bryceh> apw, good morning :-)
[18:17] <apw> whats the story on that twin dvi issue
[18:17] <apw> is there any work around for it?
[18:17] <apw> morning :)
[18:17] <Sarvatt> nomodeset :)
[18:18] <bryceh> apw, was there a patch on the upstream bug report?  I forget
[18:19] <apw> yeah i was wondering how bad things are, if there was a workaround, seems nomodeset at least
[18:19] <apw> so it can likely wait for an SRU kernel
[18:19] <bryceh> apw, yeah
[18:19] <Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/bugs/+build/1700415 -- if that fails i'm at a brick wall pretty much, it depends on too many big changes 
[18:21] <bryceh> apw, the bugs I've assigned your way recently were ones that looked like they had a reasonable fix that could be considered for SRU
[18:21] <bryceh> apw, at this point I'm assuming it's basically too late for Lucid
[18:21] <apw> bryceh, yeah i don't think we'll get a new kernel in a hurry before release
[18:22] <apw> after release we may be able to do something more, as this is an LTS and we can SRU h/w support etc
[18:22]  * bryceh nods
[18:23] <bryceh> so yeah, don't stress over the ones I sent your way, I just wanted to be sure they didn't get lost in the shuffle since they looked sru-worthy
[18:24] <Sarvatt> making RS600 use modeset=0 is pretty important too since its entirely broken, but luckily thats one of the rarest ATI's out there
[18:25] <Sarvatt> except dell used it in latitude XT's :(
[18:25] <bryceh> Sarvatt, do we have a bug # on that one?
[18:26] <Sarvatt> dont have one handy but i'll look in a bit, there are 2 bugs, one register wasn't getting set up right making KMS not work at all, then there was a agp bug with it thats pretty serious even after that
[18:27] <Sarvatt> both went to stable but stable hasn't updated in weeks and theres probably 50+ ati patches queued by now :)
[18:27] <bryceh> heh
[18:27] <bryceh> *sigh*
[18:27]  * bryceh --> more coffee
[18:27] <Sarvatt> but dell latitude XT's are completely unbootable without nomodeset at the moment
[18:28] <NinoScript> Is this the appropiate place to ask about an xmodmap issue?
[18:28] <Sarvatt> Keybuk and raffi had the problems with those latitude XT's
[18:29] <Sarvatt> dang thats a lot of mail in my inbox
[18:30] <Sarvatt> darn apport-collect spam
[18:31] <Sarvatt> darnit.. http://launchpadlibrarian.net/44910586/buildlog_ubuntu-lucid-i386.xorg-server_2:1.7.6-2ubuntu7.4_FAILEDTOBUILD.txt.gz
[18:33] <bryceh> Sarvatt, ok let me know when you locate a bug # for it.  If nothing else we can add it to ReleaseNotes
[18:33] <Sarvatt> digging..
[18:34] <Sarvatt> bryceh: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/544590
[18:34] <ubottu> Launchpad bug 544590 in linux "[RS600] video freeze with KMS (X and plymouth)" [High,Confirmed]
[18:34] <bryceh> thanks
[18:35] <Sarvatt> but theres another bug even after that - http://lists.freedesktop.org/archives/dri-devel/2010-April/000094.html
[18:35] <Sarvatt> (which sounds serious)
[18:40] <Sarvatt> ohh i'm missing hunks from dri2ext.c
[18:40] <Sarvatt> must have been removed in another patch
[18:41] <Sarvatt> DRI2ExtensionInit still has     dri2DrawableRes = CreateNewResourceType(DRI2DrawableGone);
[18:47] <Sarvatt> yeah I'm stuck, hopefully someone else tries to backport it :)
[18:47] <bryceh> Sarvatt, ok just spoke with JFo
[18:48] <bryceh> Sarvatt, so the process for now is if we see bugs that need a kernel patch, just give him a ping
[18:48] <bryceh> he'll then get it in front of andy or stefan or whomever
[18:49] <bryceh> I think this'll be better than overwhelming apw with them
[18:50] <apw> bryce sounds good
[18:58] <vish> Sarvatt: is the ppa fine to use for the gems bug?  i notice you^ mentioning some problem above.. is it related or different?
[18:59] <vish> or for a different bug*
[18:59] <Sarvatt> its the same, i'm trying to backport the fixes that dont have the problem that they only applied to xserver master but i'm not having any luck because of the significant changes done between
[19:00] <Sarvatt> vish: just disable the 2 glx 1.4 enablement patches and 114 from the xserver patch series, thats the only real option unless someone can backport it
[19:01] <Sarvatt> 03_fedora_glx_versioning.diff and 04_fedora_glx14-swrast.diff
[19:01] <vish> Sarvatt: hmm , well , let me know when it is safe to use the ppa :)
[19:01] <Sarvatt> its not really an upstream problem in the first place since those backports weren't done to 1.7 branch
[19:01] <vish> for testing
[19:02] <Sarvatt> vish: its safe because it isnt building and it doesn't look like i'll be able to fix it i'm saying
[19:03] <vish> :s
[19:03] <Sarvatt> going to keep trying using that ppa, not going to upload one with those patches dropped there if that's what you mean
[19:04] <Sarvatt> got too many darn PPA's, trying to find somewhere to put something usable for now
[19:09] <vish> nah , dropping is not really an option as you pointed out ;)  i can just use the 2ubuntu1 version.. but was just asking to test your fix
[19:10] <Sarvatt> it is an option if we drop the 2 glx 1.4 enablement patches, the only reason we need the 114 patch is because of those
[19:11] <Sarvatt> i'll put it in x-updates
[19:11] <Sarvatt> uploading now
[19:11] <Sarvatt> https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
[19:12] <Sarvatt> going to take awhile though at this rate, crappy cell connection :)
[19:13] <Sarvatt> oh helps if i dont put my phone under a coat
[19:16] <Sarvatt> whoa wait, xserver built with my backports
[19:16] <Sarvatt> 2ubuntu7.5 in the bugs ppa
[19:17] <Sarvatt> now does it work? :D vish: can ya try https://edge.launchpad.net/~sarvatt/+archive/bugs/+packages ?
[19:17] <Sarvatt> the patches need some serious review
[19:18] <Sarvatt> http://sarvatt.com/downloads/patches/119_dri2_drawables.patch
[19:19] <Sarvatt> and http://sarvatt.com/downloads/patches/120_glx_drop_destroywindow.patch
[19:29] <vish> Sarvatt: installing , will report back
[19:31] <Sarvatt> vish: thanks! i wont be able to downgrade and test it until I get home in a few hours since theres a crapload of packages
[19:39] <Sarvatt> updates https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/565981 with what I can see
[19:39] <ubottu> Launchpad bug 565981 in xorg-server "[KMS] gem objects not deallocated" [Critical,Confirmed]
[19:39] <Sarvatt> err updated rather
[19:42] <sbeattie> is fglrx failing on an upgrade from karmic a known issue? I'm getting a different dpkg-diversion error than in (fixed) bug 552782... dpkg is complaining about overwriting libdri.so with libdri.so.xlibmesa rather than the mismatch on removing the diversion.
[19:42] <ubottu> Launchpad bug 552782 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: mismatch on package" [High,Fix released] https://launchpad.net/bugs/552782
[19:44] <Sarvatt> not a good sign he's not back yet :)
[19:45] <Sarvatt> should have told him to install ppa-purge and sudo ppa-purge -p bugs sarvatt if its broken
[19:48] <Sarvatt> horribly broken? :)
[19:50] <Sarvatt> looks like it needs the 4 commits not just the two, ajax just sent a pull request for 1.8 branch for tem, maybe fedora will backport it to fedora 12
[19:51] <Sarvatt> http://cgit.freedesktop.org/~ajax/xserver/log/?h=glx-fixes-for-1.8
[19:57] <vish> Sarvatt: doesnt seem good.. i had three freezes in 3 boots could do nothing couldnt enter VT or couldnt even do an SAK
[19:58] <vish> looks like the freezes/lockups occur with compiz cube desktop switches
[19:59] <vish> and boot is also delayed , , let me pastebin  the messages
[20:04] <sbeattie> fglrx failure on karmic to lucid upgrade filed as bug 567425
[20:04] <ubottu> Launchpad bug 567425 in fglrx-installer "package fglrx (not installed) failed to install/upgrade: dpkg-divert: rename involves overwriting" [Undecided,New] https://launchpad.net/bugs/567425
[20:13] <vish> Sarvatt: not the desktop switching , but the windows preview plugin seems to be the problem , if i disable it i'm able to switch desktops , previously when i just hover over the app icon on cairo-dock to switch the desktop , everything just locked
[20:26] <vish> thats 5 lockups in 5 boots?  or is it 6.. :(  
[20:26]  * vish downgrades
[20:28] <BUGabundo> 6 lookups in 5 boots! 
[20:28] <BUGabundo> yep, stable
[20:28] <BUGabundo> oh he is gone :)
[20:31] <bryceh> Sarvatt, it occurs to me that it would be nice to have a way to easily view all linux bugs we've forwarded from the X side... might help in re-locating issues, or to spot dupes or whatever
[20:31]  * bryceh hmms
[20:33] <vish> Sarvatt: btw , from the syslogs:  http://paste.ubuntu.com/419425/ http://paste.ubuntu.com/419432/
[20:35] <vish> from ^   /var/log/messages , rather
[20:56] <Sarvatt> vish: yeah looks like 2ubuntu7~xup is what you want to fix it then
[21:03]  * vish tries x-updates
[21:40] <\vish> Sarvatt: thats bad as well :(  same problem
[21:41]  * \vish downgrades again
[21:51] <Sarvatt> vish: sheesh, I didn't even disable the patches
[21:52] <Sarvatt> oh yeah I did.. hmm
[21:54] <Sarvatt> ok i disabled them but i had manually edited the 114 patch in, sorry, that was a case of doing too many things at the same time :)
[21:57]  * vish sleeps... enough reboots for one day ...  ;)
[21:58] <Sarvatt> fixed one uploading now, I know that'll work because I tested the heck out of it last month with these clutter problems :)
[21:59] <Sarvatt> looks like i extracted the source package on top of one i had modified already, doh
[22:40] <Sarvatt> bryceh: that identification string in the xorg log is normal now :)
[22:52] <Sarvatt> nvidia released a 96.43.17 driver to fix a major problem in lucid making nvidia-96 unusable, seems pretty important we pick that up ASAP
[22:53] <Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?p=2236176
[22:53] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-96/+bug/553200
[22:53] <ubottu> Launchpad bug 553200 in nvidia-graphics-drivers-96 "Mouse and keyboard stop working after selecting user" [High,Fix committed]
[22:54] <Sarvatt> ah alberto is on the ball with a ppa package :)
[23:08] <Sarvatt> i wonder if aplattner knows installing the blob from nvidia.com will screw up the system in lucid, he's telling people to in that bug and its getting screwed up :P
[23:26] <Sarvatt> tormod: sorry, missed your email but no I haven't been building kernels lately because of the kernel-package changes