[00:01] <Sarvatt> talking in traffic so not really here yet, sorry :P
[00:03] <RAOF> I hope you're not IRCing while driving :)
[00:03] <bryceh> heya RAOF
[00:03] <RAOF> bryceh: Good morning.
[00:04] <bryceh> RAOF, phoronix and slashdot are full of opinion about our little memory bug this morning
[00:04] <bryceh> RAOF, some light reading while you enjoy your coffee/tea ;-)
[00:04] <RAOF> I'd prefer to read the X sources :)
[00:05] <bryceh> smart man!
[00:05] <RAOF> I've got a theory that the leak is because GLX resources allocated with glXCreateWindow (a GLX 1.3 call) have a different XID to their associated X window and thus fall through the cleanup-cracks.
[00:07] <RAOF> Without the guard in the 114 patch, that means that crash.  With the guard, that means that we don't clean them up.
[00:10] <bryceh> mm
[00:14] <bryceh> so, it looks like drawable->pDraw is defined but not always a valid pointer
[00:14] <bryceh> so without 114, that leads to a crash when it's destroyed
[00:15] <bryceh> with patch 114, it doesn't depend on drawable->pDraw being defined, and does a dixLookupDrawable to retrieve it
[00:15] <bryceh> and then only frees drawable->pDraw when it can get a successful lookup
[00:15] <bryceh> however, this means that for the case where drawable->pDraw is valid but not look-uppable, those aren't getting freed, and leak memory
[00:17] <RAOF> Right.
[00:19] <bryceh> so what I'm wondering is if this particular case can be detected and accounted for in some other way
[00:25] <RAOF> It should be possible to do that.
[00:26] <bryceh> (catching up on the upstream bug report)
[00:28] <bryceh> lesson learned here, don't consider a bug fixed if the upstream report is still open with ongoing discussion......
[00:30] <RAOF> :)
[00:32] <bryceh> boy this is kind of hard to follow
[00:33] <bryceh> RAOF, this appears to jibe with your theory:  https://bugs.freedesktop.org/attachment.cgi?id=34730
[00:49] <bryceh> ok
[00:50] <bryceh> RAOF, Sarvatt, here's my take
[00:50] <bryceh> if we want to keep patch 114, we should test reverting 120286aef59dabdb7c9fa762e08457e5cc8ec3a6
[00:51] <bryceh> it sounds like patch 114 obviates the need for 120286ae, from the bug discussion
[00:51] <bryceh> that's option 1
[00:51] <bryceh> option 2 is to drop patch 114, and instead pull/backport the patches that went upstream
[00:52] <bryceh> that is, patches https://bugs.freedesktop.org/attachment.cgi?id=35005 and https://bugs.freedesktop.org/attachment.cgi?id=35006
[00:52] <bryceh> hmm, actually the latter may be the same as reverting 120286ae actually
[00:52] <bryceh> aha yes
[00:53] <bryceh> RAOF, Sarvatt, have either of you tested with patch 114 and https://bugs.freedesktop.org/attachment.cgi?id=35006 ?
[00:54] <bryceh> that might be the least invasive approach
[00:54] <bryceh> (if it works!)
[00:54] <RAOF> bryceh: I see no way in which that could resolve the memory leak?
[00:56] <bryceh> as I understand it, that glxDestroyWindow() call is what generates the dangling pointer
[00:56] <bryceh> iow, if that stops doing what it's doing, then patch 114 should be able to successfully clear the objects without causing leaks
[00:56] <bryceh> however my grokkage of this is really low
[00:58] <bryceh> anyway, that's my take on it, I could easily be wrong
[01:05] <bryceh> alright, back to -ati bugs for an hour then EOD for me, but let me know if you guys reach a decision on what we should do, and I can push patches or set up sru's accordingly.
[01:06] <bryceh> crap, I promised to do some MT stuff today, too.  Hmm, -ati then MT, then EOD.
[02:08] <Sarvatt> bryceh: did you see that dropping the glx 1.4 patches also fixes all clutter apps failing to start with swrast? https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/561734
[02:08] <ubottu> Launchpad bug 561734 in gnome-games "quadrapassel doesn't start: Failed to initialise clutter: Unable to select the newly created GLX context" [Medium,Confirmed]
[02:11] <Sarvatt> that was a plesant surprise when I was testing SIS and nouveau earlier
[02:13] <bryceh> Sarvatt, no didn't see that
[02:14] <bryceh> btw in the scrollback I blathered a bit while looking at the usptream bug report.  It looks like testing some of the subsequent patches to the one jesse did (our #114) might scare up a fix
[02:14] <bryceh> but that said, I'd have nothing against just dropping the three patches
[02:15] <Sarvatt> the subsequent patches are all early versions of whats upstream though
[02:15] <bryceh> mm
[02:15] <bryceh> yeah I didn't check what actually got into the tree
[02:16] <Sarvatt> there is also a regression already with the upstream patches
[02:16] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=27767
[02:16] <ubottu> Freedesktop bug 27767 in Driver/intel "[bisected] bottom panel of gnome desktop is wrong" [Major,New]
[02:18] <bryceh> yeah I noticed the chatter about subsequent bugs
[02:19] <bryceh> although didn't see that one in particular
[02:20] <RAOF> Yeah; it seems the stack of four upstream patches seriously break compiz in particular circumstances.
[02:20] <Sarvatt> they work fine here oddly enough, i'm using them now
[02:21] <Sarvatt> but i dont use a bottom bar on this netbook :)
[02:21] <RAOF> Sarvatt: Have you started two copies of a GLX-using app?  Apparently doing that is likely to cause the second app to appear as a static snapshot of the first in compiz.
[02:21] <Sarvatt> like 2 glxgears?
[02:21] <RAOF> I think that f0006aa58f6cf7552a239e169ff6e7e4fda532f4 from master is sufficient to close the leak we have.
[02:21] <RAOF> Sarvatt: I guess so?
[02:22] <Sarvatt> 2 running fine
[02:22] <Sarvatt> 4 running fine
[02:22] <Sarvatt> trying quadrapassel
[02:23] <RAOF> There's an additional patch on xorg-devel to fix some corner case with compiz, at least.  Let me find it agian.
[02:23] <Sarvatt> quadrapassel is screwed up like you said
[02:23] <Sarvatt> (quadrapassel:7656): Clutter-WARNING **: The required ID of 1723017 does not refer to an existing actor; this usually implies that the pick() of an actor is not correctly implemented or that there is an error in the glReadPixels() implementation of the GL driver.
[02:23] <Sarvatt> tons of that spammed
[02:23] <bryceh> RAOF, yeah that looks sensible
[02:24] <RAOF> I've been running a server with that patch (and 114 dropped); gem objects seem stable, and everything appears to work ;)
[02:25] <Sarvatt> i must be missing mails from xorg-devel
[02:26] <RAOF> How does one turn a message ID into a link to the online archives?
[02:26]  * RAOF smells a *really* useful evolution plugin
[02:28] <Sarvatt> http://lists.x.org/archives/xorg-devel/2010-April/007663.html
[02:28] <Sarvatt> ?
[02:28] <Sarvatt> yeah thats not in my xorg-devel list, what the heck
[02:30] <Sarvatt> ah spam folder, go figure
[02:30] <RAOF> Hm.  That's not the one I was thinking of, either.
[02:30] <Sarvatt> hmm yeah
[02:31] <RAOF> http://lists.x.org/archives/xorg-devel/2010-April/007554.html is what I was after
[02:31] <RAOF> Anyway, you can reproduce craziness with quadrapassel
[02:32] <Sarvatt> yup
[02:33] <RAOF> Given that patch series is still receiving follow-ups like this it's clear that they won't be suitable for Lucid for a while, if ever.
[02:39]  * RAOF also wants a “mark thread as uninteresting” plugin
[02:40] <bryceh> I wrote something for mutt to do that
[02:41] <bryceh> store the message-ids when thread is marked uninteresting, then when new mail comes in check the reply-to to see if it matches any in the to-ignore message-id list
[02:59] <RAOF> Sarvatt: Also, why not do this here? :)
[03:01] <Sarvatt> oh boy the memory leak bug is starting to show signs of becoming the me-too bug for memory problems :)
[03:02] <RAOF> I can't imagine whyever for! :D
[03:16] <Sarvatt> probably should make it clear that a sure sign you are affected by the memory leak is 1GB+ object bytes or something, because some people are saying there's a leak with 280MB thats normal and is most likely a driver problem instead (like Conn O'Griofa's report)
[03:24] <Sarvatt> ah just realized I marked Yes under the bug fixed column even though the bug isn't here originally for SIS and nouveau, meant to imply I did not have any problems with it
[03:44] <Sarvatt> there, updated the wiki
[03:44] <Sarvatt> well whenever it goes through :)
[03:45] <Sarvatt> tried to make it clear what was considered as having this specific bug, and ask for testing by people who aren't experiencing it as well
[03:53] <Sarvatt> so what combination of patches need testing? f0006aa58f6cf7552a239e169ff6e7e4fda532f4 on top of the current lucid?
[04:06] <RAOF> Drop 114 from current lucid, replace with f0000
[04:07] <RAOF> I'll upload that to a PPA now.
[04:10] <RAOF> Nouveau doesn't seem adversely affected by rolling back GLX, as expected.
[04:10] <Sarvatt> yeah, only positively affected since clutter works again :)
[04:10] <RAOF> :)
[04:15] <Sarvatt> darn, fresh install reminded me that https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/510059 was still a problem after a year
[04:15] <ubottu> Launchpad bug 510059 in gvfs "Gvfs keeps asking for password when trying to mount Samba share" [Low,Confirmed]
[04:29] <Sarvatt> RAOF: shoot me links to anything you want me to try to break, will test them out tomorrow on a bunch of machines since I have some free time for a change :) night!
[04:51] <virtuald> does this mean 10.04 won't ever have GLX 1.4?
[05:07] <RAOF> Not necessarily, and that's not necessarily what you think it is.
[06:51] <RAOF> Sarvatt: I'll point you at https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa for your “can we get both GLX 1.4 *and* an X server that doesn't leak like a sieve” delectation.
=== |thade| is now known as Alexia_Death
[10:27] <RAOF> Ok.  I've managed to convince myself that f0006aa58f6cf7552a239e169ff6e7e4fda532f4 does the right thing.  That's applied to xorg-server 2:1.7.6-2ubuntu7~xtesting~dri2fixes in https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa.
[10:28] <RAOF> Feel free to test that, everyone.  I won't put it on the GEMLeak page yet, because I think dropping the GLX patches is safer, but we might want to pull this in later.
[10:28] <RAOF> Good night, all!
[10:51] <Dr_Jakob> Terribly sorry for nagging but I'm trying to figure out when the fix for bug 545298 will land in the debs? Will it make it into the RC?
[10:51] <ubottu> Launchpad bug 545298 in xserver-xorg-input-vmmouse "left mouse button unresponsive when running as VMware server guest" [High,Fix committed] https://launchpad.net/bugs/545298
[12:41] <bjsnider> tseliot, someone cam into the +1 channel last night, said he'd clean installed the beta 2 i386 cd, and when he tried to install nvidia-current, this happened: http://pastebin.com/xe0Wp3pk
=== vish is now known as mac_v
=== mac_v is now known as vish
[13:22] <tseliot> bjsnider: I don't see any real error there. He should try a daily image instead of the beta
[13:24] <bjsnider> well, the error is that it's trying to apply links to some 32-bit libs that aren't installed on i386
[15:53] <eax> Hi there - I have a problem with my Nvidia FX5600 -  I cannot chose other resolutions than 320x240 and 640x480. What can I do to run the correct resolution? Using the nvidia controlpanel this is..
[15:53] <tseliot> your /var/log/Xorg.0.log should tell you what's going on
[15:55] <eax> What should I be looking for? It seems like it is loading "nvidia-auto-select" and then "Virtual screen size determined to be 640 x 480"
[15:56]  * Ng idly wonders if either of the potential GEM leak fixes means DRI can come back on 855 :D
[15:57] <tseliot> eax: if put it on pastebin I'll have a look at it
[16:00] <eax> tseliot: Sure one moment :)
[16:02] <eax> tseliot: pastebin.org/168054
[16:03] <tseliot> eax: it can't read the EDID of your monitor. This is why it doesn't know what resolutions are available
[16:03] <eax> tseliot: How can I fix that? :)
[16:06] <eax> It might be because it's an old CRT monitor?
[16:06] <tseliot> eax: what resolution would you like to use?
[16:06] <eax> An old IBM P77
[16:06] <eax> 1280x1024:)
[16:08] <tseliot> eax: what's the refresh rate?
[16:08] <eax> tseliot: 75 I mean
[16:08] <tseliot> eax: and what's the output of this command? gtf 1280 1024 75
[16:10] <eax> Tseliot: Output is:   # 1280x1024 @ 75.00 Hz (GTF) hsync: 80.17 kHz; pclk: 138.54 MHz
[16:10] <eax>   Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
[16:18] <eax> Tseliot?
[16:19] <apw> bryceh, hey you have nvidia h/w ... could you confirm that nomodeset and noveau.modeset=0 still work on the -rc kernel?
[16:19] <tseliot> eax: sorry, I was on the phone
[16:19] <apw> someone is claiming they don't but i cannot test
[16:19] <eax> tseliot: Perfectly all right :)
[16:24] <tseliot> eax: can I see your xorg.conf?
[16:24] <tseliot> /etc/X11/xorg.conf
[16:30] <eax> tseliot: Sorry, 1 moment :)
[16:31] <eax> tseliot: http://eax.dk/xorg.conf
[16:32] <tseliot> eax: ok, I think I can give you a modified version of your xorg.conf which might solve your problem
[16:32] <eax> tseliot: Great! Thanks :D
[16:48] <eax> Tseliot: How's it going? :)
[16:49] <tseliot> I'm working on it (actually I'm working on multiple things at the same time)
[16:49] <eax> Tseliot: Cool thanks :)
[16:55] <tseliot> eax: try with something like this: http://pastebin.ubuntu.com/420496/
[16:55] <eax> tseliot: Thanks! :) Trying now
[16:55] <tseliot> and restart the xserver
[16:56] <eax> Yeah thanks :)
[17:02] <eax> tseliot: Didn't fix it :( I still cannot select 1280x1024 in the nvidia settings manager :/
[17:02] <tseliot> eax: can I see the new log, please?
[17:03] <eax> tseliot: http://pastebin.org/168139
[17:04] <tseliot> eax: how many screens are you using?
[17:05] <eax> tseliot: Two, but the second one is an LCD that works when activated :)
[17:07] <tseliot> eax: aah, I think I know what's going on
[17:07] <eax> tseliot: Yes? :)
[17:08] <tseliot> one sec
[17:12] <tseliot> eax: actually, I was wrong. You might have better luck asking here: www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14
[17:12] <tseliot> it might be a bug in driver 173
[17:17] <eax> Hey, sorry about that my internet connection crashed :S
[17:17] <tseliot> eax: actually, I was wrong. You might have better luck asking here: www.nvnews.net/vbulletin/forumdisplay.php?s&forumid=14
[17:17] <tseliot> (06:12:56 PM) tseliot: it might be a bug in driver 173
[17:18] <eax> tseliot: Okay thanks :)
[17:18] <tseliot> this is what you might have missed ^^
[17:18] <tseliot> np
[17:18] <eax> Yeah I missed that :)
[17:18] <eax> Okay, thanks a lot for your help :)
[20:28] <lotia> greetings all. any need for more reports (will likely be negative) from people using the x-updates x-swat ppa with proprietary drivers.
[20:32] <bryceh> lotia, nope
[20:34] <lotia> bryceh: thanks
[20:35] <lotia> i do have a machine using the nouveau driver, but I can't enable compiz with it. will any info from that be useful?
[20:36] <bryceh> lotia, maybe, although since it doesn't have 3D it's not expected to have the bug
[20:37] <bryceh> lotia, go ahead and test it and report what you find to RAOF
[20:38] <lotia> bryceh: RAOF? apologies. is that a nick or something else?
[20:39] <bryceh> lotia, nick
[20:39] <bryceh> lotia, he should be online within a couple hours
[20:41] <lotia> bryceh: thanks again.
[21:32] <rye> hi, just installed nvidia-current in current lucid and it appears that libglx was not updated/fixed via alternatives - is that supposed to be so?
[21:37] <Sarvatt> did you install it via jockey?
[21:38] <Sarvatt> bryceh: do we have notes on how to install blob drivers outside of X anywhere since its so specific and broken if you do it via a package manager?
[21:40] <bryceh> Sarvatt, don't think we've got official docs on that
[21:41] <Sarvatt> rye: if you installed it outside of jockey you need to sudo update-alternatives --config gl_conf, pick the one for the nvidia drivers you have installed, then sudo ldconfig and sudo nvidia-xconfig as the last step
[21:41] <Sarvatt> or do the easier method of just sudo apt-get purge nvidia-current, then activate them in hardware drivers or use sudo jockey-text -e xorg:nvidia_current
[21:41] <bryceh> Sarvatt, basically I think you have to uninstall the packaged nvidia completely first, then you can use the nvidia installer
[21:41] <bryceh> we don't support upgrading from one to the other.  breakage happens.
[21:41] <Sarvatt> bryceh: its more that you cant install the nvidia drivers via sudo apt-get install nvidia-current for instance
[21:42] <Sarvatt> all of the alternatives configuration is done by jockey..
[21:42] <bryceh> Sarvatt, ah
[21:42] <bryceh> huh, I thought the alternatives handling was done in the postinst?
[21:42] <Sarvatt> i wouldn't complain about it so much if it was :)
[21:42] <bryceh> Sarvatt, have you spoken with tseliot about this?
[21:45] <rye> Sarvatt, hm, when i started jockey I was not prompted to install any proprietary drivers at all, therefore i installed nvidia-current manually
[21:45] <Sarvatt> bryceh: yeah but I couldn't get ahold of him when he wasn't busy
[21:45] <Sarvatt> rye: sounds like you did a sudo apt-get purge nvidia-* at some point in the past, just reinstall nvidia-common
[21:46] <tormod> Sarvatt, with xorg-testing xserver -6 I got a server crash after closing quadrapassel
[21:46] <Sarvatt> xserver-6?
[21:46] <tormod> 2:1.8.0+git20100419+server-1.8-branch.7d5e6012-0ubuntu0sarvatt6
[21:48] <Sarvatt> interesting, so its not even fixed upstream? i've closed it at least 50 times over the past few days with no crashes on intel
[21:49] <Sarvatt> i'm about to update it from git, maybe the squashed patch I have is different
[21:52] <Sarvatt> just put everything in the main xorg-edgers PPA
[21:54] <lapion> I have a system with a frozen i915 driver and am logged in thru ssh, can anyone tell me what information I should gather before the terminal freezes up as well ?
[21:58] <bryceh> heh, I think we have more x freeze bug reports than we're likely to be able to look at
[21:58] <bryceh> lapion, there's guides at wiki.ubuntu.com/X if you want to troubleshoot the bug yourself
[21:58] <lapion> http://pastebin.com/01rSnYQA
[22:43] <tormod> looks like the PPA builders spend 10 minutes on installing updates and dependencies before they get to debian/rules build, is this normal?
[22:44] <tormod> build needed 55s :)
[22:45] <Sarvatt> tormod: yup, thank dpkg for being extra slow now :)
[22:45] <tormod> oh yes, it is syncing all the time, like firefox
[22:45] <Sarvatt> 13 minutes+ to install update the few base files for an x11proto package, 30 seconds to build it
[22:45] <tormod> can't they leave the syncing business to the OS damnit?
[22:48] <Sarvatt> still *nowhere* near as slow as yum so I can't complain about the extra safeguards :)
[23:06] <bigjools> the chroots prob need updating, then it will be quicker
[23:08] <rye> Sarvatt, thanks, i removed nvidia-common completely before to test nouveau with my setup. Given that it now starts up with more than one display I decided to return to nvidia until further notice on that bug report is found. Installed nvidia-common and jockey became helpful. Thanks again!
[23:12] <Sarvatt> muahaha got my eye on you mozilla daily team - https://edge.launchpad.net/ubuntu/+ppas
[23:14] <tormod> you're closing in :)
[23:17]  * ilmari loves the description of xorg-edgers
[23:50] <RAOF> The GEMLeak page is looking reassuringly green.
[23:51] <bryceh> RAOF, I've slapped a couple package downgrades into x-retro
[23:51] <RAOF> bryceh: For 8xx users?
[23:52] <bryceh> yeah an -intel for them, and an -ati for some of the recent corruption bugs
[23:53] <bryceh> RAOF, also ran across bug #565903
[23:53] <ubottu> Launchpad bug 565903 in xserver-xorg-video-ati "graphics corruption opening windows with glx 1.4 (ok with glx 1.2)" [Medium,Triaged] https://launchpad.net/bugs/565903
[23:53] <bryceh> RAOF, guessing that even if we fix that freeze there may still be some bugs
[23:54] <RAOF> That not an unreasonable guess :)
[23:55] <bryceh> fwiw, compared with past releases it feels like we have a higher proportion of graphics corruption bugs than usual
[23:56] <RAOF> Does that mean that we're getting more graphics corruption, or less wholesale crashes? :)
[23:57] <bryceh> well, I'd been guessing the latter, but after seeing 565903 now it is making me wonder