[05:26] <ripps> I think the Xorg slowdown is gone now, but it's been replaced with a pretty bad memory leak. Now my swap partition slowly fills up, even when I have no large apps open. It can fill my entire 2 gb partition in only a few hours.
[06:19] <Sarvatt> server 1.8 branch in edgers now, or wait for MM to open and keep lucid on 1.7.x I wonder..
[06:25] <Sarvatt> darn launchpad publisher got stuck not publishing libxdmcp and now theres a huge dep wait chain
[06:37] <vish> ripps: you are using ATI?  i'm having the same problem
[06:39] <vish> i have a 3.39GiB swap and sometimes it gets filled to 70% :s
[07:15] <Sarvatt> i get it on intel too but only with chromium here
[07:15] <Sarvatt> or chrome
[07:17] <vish> Sarvatt: only with the flash video or any video?
[07:17] <Sarvatt> flash is so invasive who knows
[07:17] <vish> it sometimes happens even without flash.. but easier/quicker to do it with flash ... i use inkscape a lot and view a lot of image folders but still it is really getting bad :(
[07:17] <Sarvatt> i dont go out of my way to watch videos though
[07:18] <Sarvatt> valgrind inkscape?
[07:19] <Sarvatt> guess you'd need to valgrind the server while running inkscape, thats fun
[07:19] <vish> havent had an inkscape update in a long time.. and the problem persists even after i close the apps.. 
[07:21] <Sarvatt> cat /sys/kernel/debug/dri/0/gem_objects wrapped over to negative numbers for you? :)
[07:23] <vish> hmm , not yet , but i have seen negative numbers when my swap is getting rapidly filled
[07:24] <vish> this is "ps aux" from last night >  http://paste.ubuntu.com/416321/
[07:25] <vish> and after 10hr >  http://paste.ubuntu.com/416492/  and all i did was open inkscape once and play a couple of videos in vlc
[07:25] <vish> $ free
[07:25] <vish>              total       used       free     shared    buffers     cached
[07:25] <vish> Mem:       2060208    1980144      80064          0      91052     503460
[07:25] <vish> -/+ buffers/cache:    1385632     674576
[07:25] <vish> Swap:      3550324       3612    3546712
[07:25] <vish> thats free , swap is just starting ;)
[07:26] <Sarvatt> hello cairo-dock
[07:26] <vish> lol!
[07:27] <vish> and that is slow right now , since i just had the system in idle and was probably using the sys only for ~1-2 hrs
[07:28] <Sarvatt> i'd try turning that off to see if it's any better :)
[07:29] <vish> will try that..  
[07:29] <vish> need to use something else for window list
[07:39] <Sarvatt> i dont see anything out of line besides that java maybe in those pastes?
[07:40] <vish> Sarvatt: yeah , that java is vuze but it has always been that way , is uses 6% of ram usually
[07:41] <vish> 6-7%
[07:41] <vish> i have a conky running so i notice that and firefox always in the top 2
[07:55] <Sarvatt> oh you're using cairo-dock in cairo mode, i was valgrinding it in gl
[07:59] <vish> Sarvatt: yeah the open gl doenst work well, has some problems , i'm using the "cairo-dock -c"
[08:02] <vish> Sarvatt: btw , i'm using their weekly ppa > https://launchpad.net/~cairo-dock-team/+archive/weekly/
[08:05] <vish> hmm , i used the reload in synaptic [which usually shoots the X cpu usage] and swap just jumped to 22MIb from ~7
[08:07] <vish> Bug #355355 is for the synaptic problem , but thats a different bug though
[08:07] <ubottu> Launchpad bug 355355 in synaptic "Update Manager causes high Xorg CPU usage when checking for updates" [Medium,Confirmed] https://launchpad.net/bugs/355355
[09:21] <ricotz> Sarvatt, are you still here?
[09:22] <Sarvatt> yeah just waiting for the next publisher run before i pass out. how is that ia32-libs working out?
=== lool- is now known as lool
[09:23] <ricotz> Sarvatt, my attempt is working great, so just download the packages on buildtime and one have a source of 100k
[09:25] <Sarvatt> sweet! i'll copy it over as soon as all of these libs build, thanks for doing that
[09:26] <ricotz> Sarvatt, only needs a rebuild on an update and everything is uptodate
[09:29] <Sarvatt> OOPS-1569EC308
[09:29] <ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1569EC308
[09:32] <Sarvatt> boo, canonical only :) uess i'll just bump the version and reupload since i cant rebuild
[09:46] <ricotz> Sarvatt, i could keep an eye on the ia32-lib package in the ppa if you add me to the team ;-)
[09:50] <Laney> hiya
[09:50] <Laney> so I just rebooted my Macbook running lucid, and noticed that the tap to click behaviour has changed
[09:50] <Laney> two fingers now is middle click instead of right click
[09:55] <vish> Laney: iirc , there was a huge flame war and it got changed ;)
[09:55]  * vish finds bug#
[09:56] <vish> Laney: Bug 432814
[09:56] <Laney> oh, good
[09:56] <ubottu> Launchpad bug 432814 in gnome-settings-daemon "Touchpad: Action for middle and right click is reversed since jaunty" [Low,Fix released] https://launchpad.net/bugs/432814
[09:56] <Laney> since jaunty?
[09:56] <Laney> the mind boggles
[09:56] <vish> Laney: not sure , i never used it , but the tap was reversed and got changed back it seems
[09:56] <Sarvatt> i'd say probably 90% of the synaptics bugs are just people complaining about the defaults :D
[09:57] <vish> ;)
[09:57] <Laney> I can't actually tell from that bug what happened
[09:57] <Sarvatt> now its really the same as upstream so they can complain upstream :)
[09:57] <Laney> too much text
[09:58] <Laney> is it back to 2 fingers for right click now?
[10:00] <tormod> some people should go to sleep soon ;)
[10:00] <tormod> Sarvatt, are you preparing xorg-edgers for server 1.8?
[10:03] <tormod> vish, from your ps aux I don't see that Xorg is eating memory
[10:05] <Sarvatt> tormod: thinking about it, started updating libs just to get some of the xcb fixes so people could test and it'd be pretty easy to move to 1.8.x. not sure if we should do it for lucid or wait for mm to open in a few weeks
[10:06] <\vish> oops !
[10:06] <\vish> !test
[10:06] <ubottu> hrm?
[10:06] <tormod> I think there can be a lot of people wanting to try out latest X without upgrading (with no return option) to MM
[10:07] <tormod> so you have my moral support :)
[10:07] <Sarvatt> staying the heck away from 1.9 for now though, thats for sure
[10:07] <Sarvatt> oh alrighty!
[10:07] <tormod> oh I was thinking 1.9/master :)
[10:08] <tormod> but once 1.8 is setup, throwing in master (once its ok) should be easy, no?
[10:08] <\vish> tormod: hi did i miss anything after "] <tormod> vish, from your ps aux I don't see that Xorg is eating memory"  
[10:08] <tormod> \vish, no
[10:08] <Sarvatt> it'll just break and we'll have to update a crapload of package deps every update if we do master is what i'm worried about :)
[10:09] <\vish> btw , this is the current one , now the swap is starting to be used , and i havent played flash video , will be doing that in a bit  http://paste.ubuntu.com/416561/
[10:10] <\vish> and the gem_objects is still fine now , hasnt gotten negative >  http://paste.ubuntu.com/416563/
[10:10] <tormod> well Xorg has grown from 36 to 56 MB, but that's not much compared to vuez and firefox and the other usual suspects
[10:11] <Sarvatt> do you really have that much crap running all the time? :D
[10:11] <\vish> hehe ;)
[10:11] <\vish> Sarvatt: which ones  inkscape.. or ?
[10:12] <\vish> btw , that is how i usually have the system running , this problem has been only for the past 10 days
[10:12] <tormod> well that's one 1GB of gem object bytes
[10:12] <tormod> Sarvatt, is that the kernel exploding?
[10:12] <tormod> \vish, how much video RAM do you have?
[10:13] <\vish> i think it is 512MB
=== \vish is now known as vish
[10:18] <vish> tormod: how do i find that without rebooting and checking my bios?
[10:19] <vish> video ram
[10:19] <tormod> you should see it dmesg and Xorg.0.log
[10:19]  * vish checks
[10:20] <tormod> dmesg|grep VRAM
[10:21] <vish> tormod: radeon: VRAM 128M   and radeon: GTT 512M
[10:22] <tormod> I guess GTT includes memory that can be "borrowed" from system RAM
[10:22] <Sarvatt> tormod: nice, xorg-edgers is annoying apparently :)
[10:23] <Sarvatt> (xorg-devel)
[10:23] <tormod> Sarvatt, you mean according to upstream with specific corporate affiliations?
[10:23] <vish> might be "radeon: 512M of GTT memory ready."   it mentions "upto 512MB HyperMemory"
[10:24] <tormod> I guess everything that makes people use something than Fedora is annoying
[10:24] <tormod> *else than
[10:28] <lapion> hello, anyone know how to set the value for hangtimer on i915, or even disabling it completely ?
[10:28] <Sarvatt> need to recompile your kernel to change it
[10:36] <vish> tormod: so. this is a kernel problem and not an X issue.. not needed to bisect the -ati  driver?
[10:37] <Sarvatt> need to change the #define DRM_I915_HANGCHECK_PERIOD 75 line in drivers/gpu/drm/i915/i915_drv.h
[10:37] <tormod> vish, well if another version of -ati makes a change, please do it
[10:38] <vish> k..
[10:39] <lapion> hmm can xserver add a timestamp to x.org.log ?
[10:39] <tormod> vish, check if the gem object bytes number correlate with the swapping issue
[10:40] <tormod> lapion, there are patches for it, but if you don't need high time resolution you can use some log stamper tools
[10:41] <vish> tormod: the gem_object keeps increasing:  http://paste.ubuntu.com/416616/ 
[10:44] <tormod> vish, you had a 71MB increase in used RAM (free, +/- buffers), can you track that with ps aux?
[10:48] <vish> tormod: the ps aux now > http://paste.ubuntu.com/416619/   X has increased from  56804 > 58456 , looks like everything just keeps creaping up a bit
[10:49] <vish> rrs  41316  >  43244
[10:49] <vish> rss*
[10:59] <lapion> tormod, thanks, working on compilation bit.
[11:00] <lapion> I have not compiled under ubuntu yet.. only SuSE, redhat and slackware
[11:10] <lapion> btw. in the recent update i955 was blacklisted was this done on kernel level ?
[11:13] <tormod> lapion, yes the latest kernel update (see its changelog) blacklisted KMS for a number of 915 cards, so they will use UMS instead
[11:14] <tormod> vish, but did you see some other app increase close to 71 MB over that time?
[11:14] <vish> tormod: nope..
[11:14] <lapion> hence the black screen I get with that kernel..
[11:15] <vish> no single app gains[ed] memory like that
[11:16] <tormod> lapion, so KMS worked for you, but now they forced broken UMS on you?
[11:18] <lapion> well it worked but crashed after a long time.. usually if I had the processor running on native-clockspeed, when underclocked it could run for days.. it's my tv/relzax searchs ystrem\
[11:19] <lapion> usually it would crash while tvtime was still active..
[11:19] <lapion> hence the reason I think the hangcheck is a bit buggy
[11:26] <lapion> git is go(o?)d !!
[11:28] <tormod> (l)? ;)
[11:31] <Sarvatt> tormod: ok protos all uploaded, will get a newer xserver in there when I wake up in a few hours :)
[11:31] <Sarvatt> tormod: btw can you renew my membership? can't renew myself :)
[11:32] <tormod> Sarvatt, cool! I guess updating many proto packages is not so much work as the rest (re the xorg-devel discussion)...
[11:33] <lapion> tormod, linus'changelog or ubuntu-dev changelog ?
[11:34] <tormod> lapion, ubuntu, /usr/share/doc/linux-image-2.6.32-21-generic/changelog.Debian.gz
[11:42] <lapion> hmm can't find any patches in launchpad to find out what needs to be reversed
[11:44] <tormod> lapion, are you building the kernel from ubuntu git?
[11:44] <lapion> no kernel-source
[11:44] <lapion> package
[11:47] <tormod> anyway, I see only i8xx cards blacklisted, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=summary
[11:52] <lapion> hmm of course I can allways enable kms at boot\
[12:55] <lapion> btw tormod I have never had a hangcheck related crash while the processor was set to run at a clock speed lower then native clockspeed
[19:22] <tjaalton> https://edge.launchpad.net/~tjaalton/+archive/test/+packages
[19:22] <tjaalton> "the final merge" for lucid :)
[19:23] <jcristau> hehe
[19:25] <tjaalton> if slangasek accepts it of course
[19:25] <tjaalton> wasn't completely refusing the idea when I asked..
[19:25] <tjaalton> bryceh, Sarvatt: ^
[19:26] <tjaalton> probably will say a thing or two about the new wacom & vmmouse
[19:31] <bryceh> tjaalton, nice, will be interesting to see if slangasek accepts it this late in the release though
[19:31] <tjaalton> bryceh: yeah
[19:31] <tjaalton> there are options though..
[19:31] <tjaalton> but they would be more work
[19:32] <tjaalton> (if the goal would be to just allow having /etc/X11/xorg.conf.d as well)
[19:33] <tjaalton> but we'll see
[19:33] <tjaalton> hmm getting dark, enough work it seems and time to head home ->
[20:04] <Sarvatt> hmm funky issue with the proto builds, I guess they all need a pkg-config dep now?
[20:05] <Sarvatt> http://launchpadlibrarian.net/44676877/buildlog_ubuntu-lucid-i386.x11proto-core_7.0.16%2Bgit20100418.81c3cc1c-0ubuntu0sarvatt_FULLYBUILT.txt.gz
[20:06] <Sarvatt> all the warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd lines in every one built on a PPA
[20:07] <jcristau> yeah XORG_DEFAULT_OPTIONS does that.
[20:09] <vish> is this something that can occur >  kernel: [78341.171633] radeon 0000:01:00.0: dadb8c00 reserve failed for wait
[20:09] <vish> i notice such messages in the syslog
[20:10] <Sarvatt> jcristau: should a pkg-config build dep be added to the build deps for all the protos or am I on the wrong track?
[20:11] <jcristau> Sarvatt: i think you're on the right track :)
[20:13] <Sarvatt> phew, wasn't sure if it was something funky because I updated xutils-dev with the newest tarballs
[20:13]  * Sarvatt just woke up and isn't all with it :)
[20:14] <Sarvatt> debian/rules get-tarballs rocks btw, thanks for that :)
[20:16] <jcristau> np :)
[20:16] <jcristau> was impossible to update those packages without at least some automation
[20:29] <Sarvatt> wow 15 minutes to build a proto package on launchpad
[20:30] <jcristau> 14'59 of them in autoreconf? :)
[20:30] <Sarvatt> well its been 13 minutes and its not even at the autoreconf stage yet, i was just guessing around 15 :D
[20:31] <Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa/+build/1698361
[20:31] <Sarvatt> just updating all of the essential files took most of the time, build deps went fast
[20:32] <Sarvatt> yeah like 30 seconds to do the actual build :)
[20:32]  * Sarvatt kills launchpad uploading all the rest of the protos and libs
=== Sinnerman is now known as Cobalt
[21:18] <Sarvatt> jcristau: so with this proto merge, the build deps on the world are going to have to change right?
[21:19] <jcristau> Sarvatt: need to avoid that, either with provides or empty transitional packages
[22:18] <Q-FUNK> re
[22:30] <tjaalton> bryceh: the merged packages have been uploaded for review <thumbs up>
=== raof is now known as RAOF