[00:00] <RAOF> tjaalton: Certainly. Could you add the reproduction steps from the patch to the bug?
[02:25] <ml|vacation> RAOF: hm, am I mistaken or is 1aud$ still .50$ in terms of what you can buy with it, except the echange rate says otherwise?
[02:26] <RAOF> ml|vacation: Depends on what you're buying.
[02:26] <ml|vacation> food
[02:26] <RAOF> ml|vacation: *Domestic* prices haven't changed much with the higher AUD, obviously.
[02:26] <RAOF> It's now substantially cheaper to buy things from the US in AUD, though.
[02:27] <ml|vacation> yeah :s
[02:27] <ml|vacation> but as an outsider paying 4$ for some honey...
[02:29] <ml|vacation> used to pay half of that  or less  :)
[02:31] <RAOF> Yeah. Sucks to be travelling *to* Australia.
[02:34] <ml|vacation> unfortunately for you if the exchange rate n
[02:34] <ml|vacation> ormalizes again, they use that as excuse to bump the prices*
[02:41] <tjaalton> RAOF: alrighty, I'll add that
[02:42] <tjaalton> actually those steps need a newer xinput than what precise has, but you can simulate it with suspend/resume
[02:43] <RAOF> Whatever works :)
[02:44] <tjaalton> ml|vacation: hey, your valgrinding helped fixing the synaptics bug :)
[02:44] <tjaalton> RAOF: ha, dronus added it already
[02:44] <tjaalton> but I'll edit the header
[02:50] <ml|vacation> tjaalton: great :)
[02:50] <ml|vacation> will it be sru'd to precise too? :)
[02:51] <tjaalton> uploaded already :)
[02:51] <tjaalton> and accepted, it seems
[02:51] <tjaalton> and works, I verified it
[02:52] <ml|vacation> so all the scary x bbugs are gone now?
[02:52] <tjaalton> nice that the new version of xinput lets you disable/enable devices
[02:52] <tjaalton> not exactly
[02:52] <tjaalton> there's still this weird intel gpu hang causing compiz to spin (black screen, cursor changes). happens on quantal too :/
[02:53] <ml|vacation> oh, but the xi bugs are gone?
[02:53] <tjaalton> and thumper said he could reproduce it immediately after login with the proposed unity stack from a ppa
[02:53] <tjaalton> ah, hope so
[02:53] <tjaalton> (i tried to reproduce the hang but couldn't)
[02:53] <thumper> new driver?
[02:53] <tjaalton> oh hey :)
[02:54] <ml|vacation> ok well great, back to vacationing, ttyl :)
[02:54] <tjaalton> ml|vacation: yeah, cya
[02:54] <tjaalton> thumper: so, I can reproduce it but only on resume, and not that frequently
[02:55] <tjaalton> thumper: was wondering if your compiz/unity setup was something else than the ~default I have
[02:56] <thumper> yes, yes it is
[02:56] <thumper> I'm running pre-quantal branches
[02:56] <thumper> as in, stuff that should land in quantal soon
[02:56] <tjaalton> me too, but the configuration of compiz?
[02:56] <thumper> ppa:unity-team/staging has new compiz and unity
[02:56] <thumper> nothing special
[02:56] <tjaalton> k
[02:57] <thumper> sorry, have to go
[02:57] <thumper> time to get kids
[02:57] <thumper> and take the rest of the weekend off
[02:57] <thumper> kiwi pycon \o/
[02:57] <tjaalton> mine will wake up in 1-2h
[02:57] <thumper> ew
[02:57] <tjaalton> :P
[02:57] <tjaalton> early
[02:57] <thumper> that's rough
[02:57] <RAOF> tjaalton: Is that compiz spinning, or compiz blocked waiting for a vblank?
[02:57] <thumper> hi RAOF
[02:58] <RAOF> thumper: Yo!
[02:58] <tjaalton> thumper: got the strace somewhere?
[02:58] <thumper> RAOF: it is inside the driver
[02:58]  * thumper digs
[02:58] <tjaalton> could get it from irclog..
[02:58] <tjaalton> actually, my other laptop is hung like that now
[02:58] <RAOF> Is compiz burning CPU, or is it just not doing anything?
[02:58] <tjaalton> I could dig one from that too
[02:58] <tjaalton> not burning cpu here
[02:58] <tjaalton> unless I try to restart it iirc
[02:59] <thumper> http://pastebin.ubuntu.com/1173379/
[02:59] <thumper> RAOF: I do have to run
[02:59] <thumper> RAOF: no, compiz is idle
[02:59] <RAOF> Ooooh.
[02:59] <thumper> 100% cpu on something
[02:59] <thumper> but none of the htop line items
[02:59] <thumper> so kernel maybe?
[02:59]  * thumper really runs
[03:00] <RAOF> tjaalton: You've got the same thing?
[03:00] <tjaalton> RAOF: dunno of the trace, but hung yes
[03:00] <RAOF> Can you attach gdb to compiz?
[03:00] <tjaalton> probably, should get the symbols first
[03:01] <RAOF> Yeah.
[03:02] <RAOF> From thumper's trace, I guess one of two things: (a) compiz has taken out a ServerGrab and either it's on one of its other connection or mesa has its own X connection, or (b) compiz is currently GLX throttled, which would happen if it's got a SwapBuffers pending.
[03:02] <tjaalton> this is bug 966744 btw
[03:07] <RAOF> Right. So, Chris' UXA fix would be a fix for a pending swap that'll never complete, suggesting (b)
[03:08] <tjaalton> those are already in quantal
[03:08] <tjaalton> and on the package for precise I put there, but someone could reproduce it still
[03:08] <RAOF> Which means we've got another bug; and the same reasoning applies.
[03:09] <tjaalton> right, entirely possible :)
[03:09] <RAOF> If you can attach gdb to compiz, I'd guess you're blocking in _XReply, like thumper.
[03:10] <RAOF> The next thing to do is to attach to the server, and see if you can match up compiz' Client.
[03:10] <RAOF> Well, actually, the *next* thing to do is to attach to the server and see if someone's got a servergrab, because that's easy.
[03:11] <tjaalton> http://pastebin.com/raw.php?i=qBtsGKcE
[03:11] <tjaalton> it's the same
[03:11] <tjaalton> (got some more symbols)
[03:11] <RAOF> Right. So, it's most likely either a server grab or the client being GLX throttled.
[03:12] <RAOF> We can't really tell from the client side.
[03:12] <tjaalton> ok how do I check the server=
[03:12] <tjaalton> ?
[03:12] <RAOF> Attach to the X server; there's a global serverGrab symbol you can print.
[03:15] <RAOF> Sorry, grabState
[03:16] <tjaalton> $1 = 0
[03:17] <RAOF> Ok, so the quick and easy test is failed.
[03:17] <tjaalton> bummer
[03:18] <RAOF> Oh. Is the server blocked?
[03:18] <RAOF> ie: where was the server when you connected gdb to it?
[03:19] <tjaalton> WaitForSomething
[03:19] <RAOF> Yeah, that'd be right.
[03:26] <RAOF> Hm.
[03:26] <RAOF> You know, you could iterate through the Client list, and see if any are throttled by GLX.
[03:28] <tjaalton> ok, how do I do that?
[03:31] <tjaalton> my gdb-foo is limited :/
[03:34] <RAOF> There's a global clients[] array.
[03:36] <tjaalton> should I know it's length to print it?
[03:36] <RAOF> It's of length MAX_CLIENTS
[03:37] <RAOF> Each client will have an ->ignoreCount; if that's positive, the X server is ignoring it.
[03:38] <tjaalton> sure it's 'client[]'?
[03:38] <tjaalton> uh
[03:38] <tjaalton> too early :)
[03:39] <tjaalton> ok, got pointers
[03:40] <tjaalton> I mean, it returns ClientPtr
[03:42] <tjaalton> 30 clients
[03:43] <RAOF> Right.
[03:43] <RAOF> Are any of them ignored?
[03:44] <RAOF> You can use such constructs as for() and such :)
[03:45] <tjaalton> still figuring out how to get that info from the pointer :)
[03:48] <RAOF> It should be the ignoreClient member of the ClientPtr; ?print clients[0]->ignoreClient? should print an integer?
[03:48]  * RAOF spots a probable bug in IgnoreClient/AttendClient
[03:49] <tjaalton> There is no member named ignoreClient.
[03:49] <RAOF> Sorry, ignoreCount
[03:49] <RAOF> Sorry.
[03:49] <tjaalton> yeah
[03:49] <tjaalton> ok let's see..
[03:51] <tjaalton> ok got one with = 1
[03:51] <tjaalton> ignoreCount = 1
[03:52] <RAOF> That's *likely* to be the compiz one.
[03:52] <RAOF> Particularly if it's the only one with ignoreCount = 1
[03:52] <tjaalton> yeah just one
[03:54] <RAOF> To be sure, we'd want to work out whether any of Compiz's drawables have DRI2DrawablePtr->swapsPending > 1.
[03:54] <RAOF> I can't, off the top of my head, think of a way to verify that, though.
[03:55] <RAOF> I think its' reasonable at this point to blame this on the intel driver scheduling a swap that never completes.
[03:56] <tjaalton> yeah, I could show the trace to #intel-gfx once someone is awake
[05:04] <shadeslayer> tjaalton: \o
[05:04] <shadeslayer> so here's some fun news, I got some time and messed about with grub a bit
[05:04] <shadeslayer> I can now disable the ATi discrete graphics
[05:05] <shadeslayer> still have to boot with nomodeset since the lvds dual channel patches are not there in the ubuntu kernel
[05:05] <shadeslayer> in dmesg : [   20.258413] i915: `2' invalid for parameter `lvds_channels'
[05:06] <shadeslayer> unfourtunately, I don't how to compile my own kernel with lvds patches
[05:20] <tjaalton> shadeslayer: huh, someone clearly failed to send them upstream then
[05:21] <shadeslayer> dunno, I think I saw them on lkml at one point
[05:21] <shadeslayer> though I don't follow lkml so I don't know
[05:21] <shadeslayer> atleast now the thing doesn't heat up like a frying pan
[05:22] <tjaalton> right
[09:18] <ml|vacation> tjaalton: yay just applied the fixed version to this laptop, think it was having the same issue on suspend ;)
[09:19] <tjaalton> yep
[09:19] <tjaalton> wait, another bug?=
[09:19] <tjaalton> -=
[09:19] <ml|vacation> no, just didn't have proposed enabled
[09:19] <tjaalton> ah
[10:08] <tjaalton> mesa 9.0 branched
[10:08] <ml|vacation> great :)
[13:03]  * apw is seeing some background corruption on quantal, trying to work out if this is X or compiz
[13:04] <ogra_> apw, might be our new cubistic theme for ubiquity ....
[13:04] <ogra_> https://launchpadlibrarian.net/113965811/IMG_0170.JPG
[13:04] <ogra_> :P
[13:05] <apw> ogra_, luckily not that :)
[13:21] <tjaalton> apw: there's a known regression on intel < 965
[13:21] <tjaalton> compared to mesa 8.0.x
[13:22] <apw> tjaalton, we got any idea of a fix or is beta shipping wit this?
[13:23] <apw> tjaalton, this is an atom netbook, would i expect that to have the right version
[13:27] <tjaalton> if it's i945, that's your bug
[13:27] <apw> tjaalton, how do i tell
[13:31] <tjaalton> i just learned about the bug today
[13:32] <tjaalton> lspci
[13:32] <tjaalton> also, we have a snapshot that's over a week old
[13:35] <tjaalton> bug 1042211
[13:36] <apw> tjaalton, sysfs says this is an is_g33, and the pci_id points to intel_pineview_info ... so i assume its not 945
[13:37] <apw> the damage i am seeing could easily be compiz as some of it is aligned well with the places it puts things
[13:37] <apw> tjaalton, that said the description is definatly the same i recon
[13:38] <tjaalton> apw: yeah sounds like it's no the same bug
[13:38] <tjaalton> oh :)
[13:38] <tjaalton> well, try the previous packages
[13:38] <apw> bacground a solid colour, menus appear and return to menu background
[13:40] <apw> so the background being mashed is being triggered by nautilus running there
[13:45] <apw> tjaalton, yeah seem to be this issue as far as i can tell, all the mitigations work as per daniel, though performance is mindbogglingly slow with them
[13:47] <tjaalton> apw: but does downgrading fix it?
[13:49] <apw> which packages do nead, there seem to be 40 binary packages here for mesa
[13:52] <tjaalton> libgl1-mesa-glx, -dri should be enough
[13:53] <tjaalton> the bug has links
[14:06] <apw> tjaalton, thanks, here goes nothing
[14:07] <apw> needs -glapi as well for reference
[14:08] <apw> tjaalton, ok confirmed, downgrading those mesa packages fixes it here
[14:09] <tjaalton> ah
[14:10] <apw> tjaalton, added the information to the bug, looks like basic netbooks are affected
[14:11] <tjaalton> i believe it has i945 gfx, it should use i915_dri
[14:15] <tjaalton> but anyway, too late to update the snapshot today, but monday :/
[14:15] <ml|vacation> hehe :p
[14:16] <ml|vacation> argh forgot to copy the whole git tree over, linux kernel has no git history now :s
[14:16] <tjaalton> started looking at the update but didn't get far before eod
[14:18] <tjaalton> gone again ->
[14:25] <apw> ml|vacation, sounds like a mistake :)