[01:12] <Ng> soo
[01:13] <bryce> oso
[01:13] <Ng> my performance issue has to do with EXA, not particular versions. 2.6.3 and the git snapshot both show it when set to EXA. Setting either to UXA pretty much completely eliminates the slowdowns
[01:13] <Ng> which doesn't really help us, I suspect
[01:14] <Ng> I sure wish I'd thought to check it wasn't that before I bisected 3 months of the git tree ;)
[01:15] <Ng> on the upside, I know now how to bisect and I also know that checkinstall does a good job of building a IDON'TCAREJUSTMAKEITWORK package for such testing :)
[01:17] <Ng> I think I've missed Sciri at this point, but I've left him a message to flip over to UXA to see if his 950 speed problems are the same, and I'll check Matt's X61 tomorrow if he's in the office
[01:17] <Ng> but having used UXA myself for a few days I don't think it's really in a usable state yet. I'd rather they were slow than crashy
[01:18] <Ng> (and I'll do a followup to platform and -x about this)
[01:18] <bryce> Sciri?
[01:18] <Ng> Sean (OEM sysadmin in Lexington)
[01:19] <bryce> Ng: ok, sounds like you've arrived at the same general conclusion as the rest of us
[01:19] <Ng> heh, I do like to be fashionably late to the party ;)
[01:19] <bryce> :-)
[01:19] <Ng> do we know when Intel are likely to next cut a release?
[01:20] <bryce> I think 2.7 should be here any day now, not sure of the exact schedule but I think it's this month
[01:21] <Ng> perhaps we could do a semi-official PPA of that for affected souls?
[01:21] <Ng> and by "we" I mean "someone who can do a good job of that, so not me" ;)
[01:21] <bryce> that said; we've been burned by poor qa troubles with 2.5.0 and 2.6.0 so while I trust cworth will do a great job, experience so far suggests waiting for the .1
[01:22] <bryce> Ng: ah, did you check the xorg edgers ppa?
[01:22] <bryce> fairly sure tormod has bleeding edge -intel in there
[01:22] <Ng> yep, that's what I used initially to try out UXA, and mistakenly latched onto the idea that it was the newer code that was saving me, rather than just UXA
[01:23] <bryce> ahh
[01:23] <bryce> ok that starts to make more sense, and seems consistent with most of the data we've gotten so far
[01:24] <Ng> for my part I'd rather have everything lovely in the future, so regardless of the results I see from Matt/Sean I'm going to stick with git and see if I can catch the hang bug(s) I had with from tormod's, so at least we can be damn sure we can use UXA for karmic
[01:24] <Ng> err, "I had with UXA/git"
[01:25] <bryce> good man
[01:25] <Ng> my desktop is sufficiently stateless that I can weather the crashes, and the slowness drives me crazier than they do
[01:25] <bryce> also make sure as you file bugs, to ensure they're also forwarded upstream
[01:25]  * Ng nods
[01:26] <bryce> I've been deliberately not doing this with UXA bugs, to stay focused on jaunty issues, and because I know it'll take a lot of back and forth troubleshooting which I don't want to be the bottleneck for
[01:26] <bryce> but getting the bugs upstream is the best chance we have to make all this better in karmic
[01:31] <Ng> I had an idea on the bus home that maybe we could encourage/sponsor a compiz plugin for stress testing desktop operations. development releases could have a special extra GDM session that fires up a bunch of apps and just goes at a load of windowing operations as fast as possible and measures the results, as well as potentially pushing it into crashing without the reproduction steps being "uhh, I
[01:31] <Ng> just kinda use my computer for a few days"
[01:32] <LordMetroid> S-video support is there any way to make it automatic?
[01:32] <LordMetroid> Cause xrandr denies me usage
[01:35] <bryce> Ng: yeah we need that sort of stress tool to help make bugs more easily reproduced
[01:36] <bryce> LordMetroid: see the config page in the Ubuntu-X wiki
[01:45] <LordMetroid> I did
[01:45] <LordMetroid> it didn't work
[02:00] <pwnguin> heh. i think larabel just volunteered to be the xorg release managemener
[02:03] <bryce> pwnguin: ?
[02:05] <bryce> ah, in the he-who-complains vein
[02:05] <pwnguin> yea
[02:15] <bryce> hmm at least the ubuntu 9.04 beta vs. fedora 11 comparison turned out in our favor
[02:15] <bryce> although I notice he didn't include gl performance comparisons
[10:38] <Ng> bryce: that's interesting, I would have guessed they'd be similar or f11 slightly ahead through having newer bits
[10:44] <seb128> Ng: what is f11 using?
[10:45] <Ng> seb128: afair they're using a newer kernel for KMS
[11:08] <mnemo> they also have mesa 7.5-devel and intel ddx 2.6.99
=== seb128_ is now known as seb128
[13:15] <mifritscher> hi
[13:16] <mifritscher> the 20090326 version of https://launchpad.net/~xorg-edgers/+archive/ppa worked for me, but not the current
[13:17] <mifritscher> (uxa mode crashes somewhere in UXA_polygon_something)
[13:17] <mifritscher> (sorry, xorg already killed the log)
[13:17] <mifritscher> on 4 gb ram without pae, which workd on the 0326 version
[13:18] <mifritscher> +g965
[13:18] <mifritscher> xaa+exa with pae still works, but crashes/hangs with 3dmark2001
[13:19] <mifritscher> a8and has the same artifacts as in uxa with the 26 driver)
[13:37] <mnemo> mifritscher: please open a bug on bugs.freedesktop.org and mention the info you just gave
[13:37] <mnemo> output of "uname -a", "lspci -nn | grep VGA", "dmesg" is also useful
[13:38] <mnemo> plus xorg.log, xorg.conf and ~/.xsession-errors
[14:28] <Ng> tjaalton: in case your mesa goes into jaunty, https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/324854 may want to be looked at (I've not checked the code, but with your mesa I see the symptoms, and didn't with tormod's 7.3+git which has that stuff cherrypicked)
[14:28] <ubottu> Launchpad bug 324854 in xserver-xorg-video-intel "DRI2: (UXA) white transparency artifacts with compiz [patch]" [Undecided,Invalid]
[14:35] <tjaalton> Ng: yeah, there's another bug open already
[14:35] <tjaalton> uh no
[14:35] <tjaalton> this is the one
[14:36] <Ng> I just figured I'd mention it :)
[14:37] <tjaalton> hmm so I didn't push it
[14:37] <tjaalton> the patch is on my repo
[14:38] <tjaalton> I've been on a "sick" leave the past two days, tending the kids
[14:39] <tjaalton> so haven't given much thought about how to actually get this in jaunty
[14:39] <Ng> :/
[14:39] <Ng> hope everyone is recovering :)
[14:40] <tjaalton> the noise level is getting higher, so I'd say so
[14:40] <Ng> hehe
[14:40] <tjaalton> forgot :)
[15:07] <tormod> Ng: the 7.3+git from xorg-edgers should be pretty much the same as 7.4
[15:08] <tormod> but timo's 7.4 has some Ubuntu patches
[15:08] <tormod> did you also check with the different libdrm2's btw?
[15:09] <Ng> I did all of my testing last night with the -edgers drm
[15:09] <Ng> EXA => fail in all cases, UXA => win in all cases (where "fail" means "slow, but works" and "win" means "fast, but may render badly or hang or segfault on resume" ;)
[15:25] <tormod> Ng, I was thinking about the symptoms you mentioned 15:28
[15:26] <tormod> oh sorry that was my own PPA, not xorg-edgers that you mentioned
[15:27] <tormod> or maybe not
[15:35] <Ng> tormod: I had tjaalton's mesa installed and an edgers ddx, and I was seeing the split-second white rendering
[15:35] <Ng> tormod: just flipped over to your mesa and indeed that is fixed
[15:37] <tormod> Ng: flipped to xorg-edgers mesa? or downgraded to my ppa mesa which I mention in that bug report?
[15:37] <Ng> tormod: flipped to edgers mesa
[15:38]  * Ng all edgers atm, although not the very very latest ddx because I need to work and don't want to potentially hit the problem mifritscher was having earlier
[15:39] <tormod> did mifritscher report it upstream? has anyone confirmed it?
[15:39] <Ng> it was suggested that he report it upstream, don't know if he did yet
[15:39] <Ng> I'll certainly upgrade to the new snapshot tonight
[15:40] <tormod> I got confused because I forgot that I cherrypicked 661775aa in both ppas...
[15:40] <Ng> his problem may be related to having 4GB and no PAE, but I'm not sure
[15:41] <seb128> hi tormod
[15:41] <seb128> tormod: do you need any other information about this intel crasher?
[15:42] <tormod> hi seb128, I don't think I get further myself
[15:42] <tormod> either the devs recognize something or someone needs to debug hands-on
[15:43] <tormod> since it is so reproducible, some gdb watchpoints might work
[15:44] <tormod> but I do not know how many unrefs there are on a VT switch to keep track off
[15:44] <tormod> maybe valgrind could help?
[15:47] <seb128> I tried to valgrind the xorg server without luck
[15:47] <tormod> xorg is allergic to debugging
[15:50] <tormod> one could set up some gdb stuff to log every unref with some info
[15:50] <seb128> what variable should be watched?
[15:50] <jcristau> there's a libdrm patch to help with valgrind
[15:51] <jcristau> it's been posted recently on intel-gfx@
[15:51] <tormod> seb128: yeah you only know that afterwards :)
[15:51] <seb128> jcristau: well I got issue with valgrind complaining about setuid too
[15:51] <seb128> jcristau: do you know how to workaround that?
[15:52] <seb128> I manage by some way but they I had nothing in the xorg log out of the X command and argument
[15:52] <seb128> no error, etc
[15:52] <seb128> it seems valgrind exit or something
[15:52] <tormod> a gdb "breakpoint command list" could be used at the unref function
[15:54] <tormod> I'd suggest at first just to count the number of calls to see if it's worthwhile, if it's only a few then log the caller and object address on each call, to see which two callers want to free the same object address
[15:55] <seb128> right
[15:55] <seb128> I will do that
[15:56] <tormod> but in many cases the right developer will recognize his mistake when he sees such a symptom, and fix it faster than any debugger in-from-the-cold can do
[15:57] <seb128> let's see, the bug seems to have enough informations but nobody is picking it up yet
[15:57] <tormod> seb128: if you're successful with gdb, please send me the gdb session, so I can learn how you do it
[15:57] <seb128> ok will do
[16:37] <jcristau> seb128: run valgrind on /usr/bin/Xorg instead of the wrapper, i guess
[16:39] <seb128> jcristau: that's what I did, I renamed Xorg to Xorg.binary and create an Xorg wrapper calling valgrind
[19:31] <tseliot> federico1: did you have a look at the final version of my patch? http://bugzilla.gnome.org/show_bug.cgi?id=568160
[19:31] <ubottu> Gnome bug 568160 in libgnome-desktop "Gnome Settings daemon causes high CPU usage with an expensive call" [Major,Unconfirmed]
[19:32] <federico1> tseliot: oops, no - thanks for the reminder
[19:32] <tseliot> federico1: np
[19:32] <federico1> let me see if I can finish something in gnome-panel really quickly and I'll get to it
[19:33] <tseliot> bryce or bryce_: can you upload the new nvidia driver, please? The source is in comment 5 of this bug report (which is assigned to you): https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/348852
[19:33] <ubottu> Launchpad bug 348852 in nvidia-graphics-drivers-180 "nvidia driver 180.44 is available" [High,Triaged]
[19:42] <bryce> tseliot: will do
[19:43] <tseliot> bryce: thanks a lot :-)
[20:22] <bryce> tseliot: uploaded
[21:02] <tseliot> bryce: thanks a lot
[21:02] <bryce> tseliot: also requested all -180 bug reporters do a retest
[21:03] <tseliot> bryce: good idea :-)
[21:03] <tseliot> just to be sure
[21:29] <tormod> seb128: are you gdbugging? :) actually which line of gen4_render_state_cleanup explodes?
[21:29] <seb128> no I'm not and I don't have the computer with the intel card with me now
[21:29] <seb128> did you read the bug comments?
[21:30] <seb128> I've wrotten what free leads to crash there
[21:30] <seb128> and bryce copied the corresponding code
[21:30] <seb128> I will put a break on the free call tomorrow
[21:30] <seb128> and get a bt for each call
[21:37] <tormod> seb128: yes I saw it was line 1727, just want to make sure it is the same line number in my code
[21:38] <seb128> I wrote in a comment what line is the crash one
[21:38] <seb128> let me open the bug
[21:38] <seb128> "the crash is on "free(block);" in free_block()"
[21:39] <seb128> intel_bufmgr_fake.c:473
[21:39] <seb128> in the current jaunty source
[21:39] <tormod> seb128: is the calling line in gen4_render_state_cleanup I wonder about
[21:40] <tormod> this? -> drm_intel_bo_unreference(render_state->sf_state_bo); 
[21:41] <seb128>     drm_intel_bo_unreference(render_state->sf_state_bo);
[21:41] <seb128> yes
[21:41] <tormod> thanks. it would mean the preceding drm_intel_bo_unreference(render_state->vs_state_bo); was fine
[21:44] <seb128> could be that both calls lead to free the same thing?
[21:44] <bryce> I contacted Intel about this bug.  I will follow up today.  They said it sounded like something that could be an easy fix.
[21:46] <seb128> bryce: thanks, I get it every time on my d630 so let me know if you need any debug informations
[21:46] <seb128> I didn't manage to run the xserver under valgrind yet
[21:46] <bryce> ok great
[21:46] <seb128> but otherwise I should be able to get infos ;-)
[21:46] <seb128> bryce: should I open an another bug about the UXA crash?
[21:46] <seb128> that one is on guest session opening
[21:47] <seb128> I mentioned it in the bug because I've been asked to try UXA but that's rather a different issue
[21:47] <bryce> seb128: yes, although I think there is already one open on it with UXA
[21:47] <seb128> ok, I will not bother with that one now then
[21:48] <bryce> if it appears to be different at all, file a new bug (we can always dupe later)
[21:48] <seb128> I will check for dups and open it directly on freedesktop if there is no similar bug there
[21:48] <seb128> or do you prefer having it in launchpad too?
[21:49] <bryce> I do prefer having it in launchpad for tracking purposes
[21:49] <tormod> seb128: about valgrind and your setuid issues, can't you just run the second "/usr/bin/Xorg :20" as root?
[21:49] <bryce> with UXA bugs I'm appending "(UXA bug)" to the subjects so we can easily get a list of all open UXA bugs
[21:49] <seb128> bryce: ok
[21:50] <tormod> you can reproduce with two barebones X servers right?
[21:50] <seb128> I did manage to run xserver under valgrind
[21:50] <bryce> this will be useful in helping make the determination on when UXA is ready to go, and/or prioritize attention to those bugs when we get near to switching
[21:50] <tormod> ok
[21:50] <seb128> but I got nothing else that the command and arguments in the log
[21:50] <seb128> ie no error printed there when it crash
[21:55] <tormod> bryce, just so that you know, I'll be off and mostly far away from internet the next 12 days or so, in case you see people pinging in bug reports etc
[21:55]  * tormod goes to the mountains
[21:56] <bryce> tormod: ok thanks for letting me know.  Have fun, and hope the internet withdrawl symptoms aren't too severe ;-)
[21:56] <tormod> I'll try to cope with launchpad abstinence
[22:00] <tormod> cool we have jbarnes on #ubuntu-bugs
[22:09] <bryce> yeah I'd invited him earlier.  I was hoping we'd be seeing more triaging activity on #ubuntu-bugs, but at least the hug day page is slowly getting filled in
[22:42]  * Ng tests latest edgers -intel :)
[22:44] <tormod> Ng: curious if you get the fbFill seen on phoronix forum (UXA)
[22:44] <tormod> *crash
[22:56] <Ng> tormod: yup
[22:57] <Ng> the guy this morning seemed to be seeing something else
[22:57] <Ng> [13:17] < mifritscher> (uxa mode crashes somewhere in UXA_polygon_something)
[22:59] <tormod> on phoronix it was uxa_check_poly_fill_rect which sounds like a close relative
[23:00] <tormod> you get the same backtrace as http://phoronix.com/forums/showpost.php?p=69074&postcount=132 ?
[23:01] <Ng> 5: /usr/lib/xorg/modules/drivers//intel_drv.so(uxa_check_poly_fill_rect+0xd5) [0xb782a985]
[23:06] <Ng> tormod: looks the same
[23:06] <Ng> tormod: I don't see a fdo bug :/
[23:07] <Ng> forums are such epic fail ;)
[23:07] <bryce> heh
[23:07] <Ng> http://pastebin.com/f742caee4 is my log
[23:07] <tormod> you have all these people posting tons on the forum but never touched a bug tracker :(
[23:07] <Ng> just gonna quickly ask in #intel-gfx before filing a bug
[23:08] <Ng> (maybe they're in the middle of something atm and expect it to be broken)
[23:08] <tormod> Ng: I just asked jbarnes on #ubuntu-bugs
[23:08] <Ng> ah
[23:08] <Ng> hrm, not on there
[23:08] <tormod> <jbarnes> tormod: ah looks like one of the PAT bugs
[23:08] <tormod>  tormod: try booting with 'nopat'
[23:08] <Ng> okidoki, re-installing it and rebooting :)
[23:13] <jbarnes> Ng: I didn't see your whole log... I assume you're on a fairly recent kernel
[23:20] <tormod> jbarnes: we're talking 2.6.28 here (Jaunty). maybe not recent for intel :)
[23:21] <tormod> but doesn't 2.6.28 have GEM?
[23:22] <jbarnes> 2.6.28 should have gem
[23:22] <Ng> jbarnes: http://pastebin.com/f742caee4 is without nopat, http://pastebin.com/f4e93c41e is with nopat (whole cmdline was root=/dev/mapper/kodachi-root ro elevator=noop quiet splash nopat)
[23:22] <jbarnes> but it doesn't have the master bits...
[23:23] <jbarnes> ah I just posted a fix for this to intel-gfx
[23:23] <jbarnes> "fix offset in begin_gtt_access case"
[23:23] <jbarnes> care to test for me? :)
[23:23] <Ng> absolutely :)
[23:34] <Ng> tormod: hrm, is the -edgers drm actually 2.4.6?
[23:35] <jbarnes> tormod, Ng: so there are bleeding edge builds of libdrm & xf86-video-intel for ubuntu out there already?
[23:35] <jbarnes> I've been wanting that for some of my machines here
[23:38] <Ng> jbarnes: tormod has been doing a PPA with periodic snapshots, deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu jaunty main
[23:39] <jbarnes> nice, I've been meaning to set up daily builds of git master but haven't had a chance yet
[23:39] <Ng> jbarnes: your patch seems to work :)
[23:39] <jbarnes> Ng: great
[23:42] <tormod> Ng: I added the commit that warranted 2.4.6 to the 2.4.5+ package, and deps for it in -intel
[23:43] <Ng> tormod: ah good, I was just a bit confused when I tried to test jbarnes's patch against -intel git and it whined my drm was too old, but your package (which currently matches git afaict) built fine :)
[23:43] <tormod> jbarnes: I have scripts that build xorg pieces pretty much automatically. well, the -intel stuff always needs some hand-tweaking ;)
[23:44] <jbarnes> tormod: due to bleeding edge dependencies I guess
[23:44] <tormod> Ng: I commented on the libdrm deps (although not so clear) in the changelog
[23:45] <tormod> if you look at the PPA, everything is in the changelog, my manual tweaks are marked with "+"
[23:46] <tormod> https://edge.launchpad.net/~xorg-edgers/+archive/ppa is a better link than the above
[23:47] <tormod> jbarnes: yes the kernel/kms/libdrm stuff...
[23:48] <Ng> tormod: I did read the changelogs, but i didn't absorb that. would it be worth bumping the package version to 2.4.6?
[23:49] <tormod> they haven't even released 2.4.6 properly :)
[23:49] <Ng> oh right :)
[23:50] <tormod> I thought I had a reason for just cherry-picking that commit and not just get git-head...
[23:50]  * tormod googles his mind
[23:51] <tormod> laziness I think, would have to all the manual steps again (or merge in master again)
[23:52] <tormod> Ng (and jbarnes), are you interested in auto-xorg-git and uploading to the ppa, I could add you to the team
[23:53] <jbarnes> tormod: are there docs on how to create a repo?  I know nearly nothing about making debs so I don't think I need upload privs yet :)
[23:53] <tormod> s/laziness/time constraints/
[23:53] <Ng> tormod: I'd definitely like to get my hands on the script. checkinstall does ok for -intel, but would clearly fail for drm :)
[23:54] <tormod> the script does everything: auto-xorg-git -g -D -H ../xorg-pkg-tools/hooks intel
[23:54] <Ng> outstanding :)
[23:55] <tormod> see https://edge.launchpad.net/~xorg-edgers there are even README files :)
[23:55] <Ng> it might be interesting to have daily builds going in
[23:55] <tormod> automation would be awesome, see the "ppa-update" script that I use for the packages which do not need any tweaking
[23:56] <Ng> I've been meaning to track down a daily PPA builder for my own stuff. I know jcastro was talking about one at the last UDS, and jkakar has such a thing
[23:56] <tormod> if there's a tweak I need semi-permanently, I add it to the "hooks"