| RAOF | bjsnider: You were asking about how state trackers and drivers interact? The recent patches to hook r600g up to the xorg state tracker would be a good example ;) | 00:27 |
|---|---|---|
| bjsnider | sounds like a page turner | 00:34 |
| bryceh | ahahaha, figured out that xvfb bug | 01:00 |
| RAOF | bryceh: Oooh, what's that? | 01:37 |
| bryceh | RAOF, after a lot of digging through xvfb code, it ended up being a bug in fakeroot instead | 01:38 |
| bryceh | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630591 | 01:38 |
| ubot4 | Debian bug 630591 in apt "apt: apt-cache fails with current fakeroot" [Minor,Fixed] | 01:38 |
| RAOF | Awesome :) | 01:38 |
| bryceh | 829470 has the analysis | 01:38 |
| RAOF | Would you believe that (a) compiz is super slow running under valgrind and (b) leaks like a sieve? | 01:38 |
| RAOF | Which is a bit annoying, 'cause I was hoping that it'd be more obvious where (probably mesa is) leaking gem_objects | 01:41 |
| bryceh | ugh, firefox is substituting some sort of graphic for "ff" | 01:41 |
| bryceh | RAOF, I would indeed believe that | 01:41 |
| RAOF | ==27498== ERROR SUMMARY: 4941712 errors from 2347 contexts (suppressed: 867727 from 65) | 01:42 |
| RAOF | Almost as many errors as I have bytes in gem_objects! | 01:42 |
| RAOF | :) | 01:42 |
| bryceh | yay! | 01:43 |
| bryceh | RAOF still around? | 02:56 |
| bryceh | I think we could maybe test Xvfb in xserver's debian/rules, but xvfb-run depends on xauth being available so I'm not sure if we can invoke that. | 03:08 |
| RAOF | bryceh: Now post-lunch, yeah. | 03:42 |
| RAOF | We could, I guess, build-depend on xauth? | 03:42 |
| bryceh | RAOF, yeah that's what I'm wondering | 06:02 |
| bryceh | I've been experimenting with just calling Xvfb directly, but utilizing xvfb-run would give a better test | 06:03 |
| RAOF | There doesn't seem to be any circular dependency issue there; it just depends on libx11 and friends. | 06:03 |
| bryceh | ok lemme give it a go | 06:03 |
| tjaalton | i merged 1.10.4 yesterday, might want to pull that too | 06:12 |
| tjaalton | at least before you try to push ;) | 06:12 |
| bryceh | tjaalton, yeah saw that in git | 06:12 |
| tjaalton | ah, cool | 06:12 |
| tjaalton | i've done a procmail rule to put the git commits in a separate folder. easier to follow when no debian-x bugmail is there to distract you :) | 06:15 |
| bryceh | aha got it | 06:32 |
| RAOF | Oh, man. apitrace is pretty awesome. | 06:33 |
| bryceh | RAOF, ok you can cross xvfb off your todo list :-) | 06:34 |
| RAOF | Sweet. | 06:34 |
| RAOF | What intel hardware do you have trivially available? | 06:35 |
| bryceh | I've pushed it to the git tree, you can roll it out when you do the 1.10.4 deploy. Hopefully it shouldn't require any tweaking; if it does let me know. | 06:35 |
| bryceh | RAOF, an i945 running natty and an arrandale running oneiric but failing to run X for some reason | 06:36 |
| RAOF | I guess I'm particularly interested in arrandale, actually; it doesn't seem like this leak appears on GM45, so I presume gen 4 and earlier are ok, and it appears on this SandyBridge, so it looks like gen 6 is affected, leaving only gen 5 :) | 06:36 |
| RAOF | I'll just test that hypothesis again, though. | 06:37 |
| tjaalton | I have oneiric on sandybridge | 06:37 |
| tjaalton | so compiz leaking memory? | 06:37 |
| RAOF | tjaalton: Yeah; on alt-tab. | 06:38 |
| tjaalton | ah that, well it ceases to work after some time | 06:38 |
| RAOF | Ceases to work? | 06:38 |
| tjaalton | don't have the popup anymore, though I use the more sane traditional one :) | 06:38 |
| RAOF | Ah. | 06:38 |
| RAOF | Yeah, it's the unity alt-tab that's got problems for me. | 06:39 |
| tjaalton | windows do change though | 06:39 |
| tjaalton | here compiz is taking 860MB atm | 06:39 |
| tjaalton | which is kinda lot | 06:39 |
| RAOF | And by "problems" I mean "leaks ~25MB per alt-tab, leading to fairly rapid OOM" | 06:39 |
| tjaalton | heh, ok | 06:39 |
| tjaalton | compiz is also constantly taking at least 30% cpu | 06:41 |
| RAOF | Oooh, interesting. | 06:41 |
| RAOF | The trace of alt-tab madness has the same behaviour on my GM45, but I don't see that just running compiz. | 06:42 |
| tjaalton | apitrace would probably need to be packaged, no? | 06:43 |
| RAOF | I've got a Debian ITP up. It does really want to be packaged, yes. | 06:45 |
| tjaalton | ah, good | 06:45 |
| RAOF | It doesn't quite work properly on compiz, but it works enough. | 06:45 |
| RAOF | tjaalton: Could you switch to Unity's alt-tab and check that it doesn't leak gem_objects for you? | 06:51 |
| tjaalton | RAOF: yeah | 06:56 |
| tjaalton | i mean, yeah I can do that :) | 06:56 |
| RAOF | :) | 06:58 |
| RAOF | while true; do echo "********************************"; sudo egrep "[[:digit:]]+ objects" /sys/kernel/debug/dri/0/i915_gem_objects ; sleep 5 ; done | 06:59 |
| RAOF | Quite useful. | 06:59 |
| tjaalton | hum, the default alt-tab does the same | 07:01 |
| tjaalton | i mean stock compiz version | 07:01 |
| tjaalton | had 3720 objects, now after a few it's up to 3773 | 07:01 |
| tjaalton | and the popup does appear, after holding alt down for a few secs | 07:02 |
| RAOF | The stock compiz version has a known leak, but it's much smaller. | 07:02 |
| tjaalton | ah ok | 07:02 |
| tjaalton | RAOF: I can't seem to reproduce the leak on a sandybridge laptop | 07:50 |
| RAOF | tjaalton: Strange. DBO's just fixed it in trunk, though. | 07:51 |
| RAOF | At least, for me. | 07:51 |
| tjaalton | the first alt-tab increases the number of gem_objects, but another one doesn't | 07:51 |
| RAOF | I generally did about 40 alt-tabs; that raised the bytes used by a lot. | 07:52 |
| RAOF | (About 1GB or so) | 07:52 |
| tseliot | is this still the case? | 07:52 |
| RAOF | With the unity in Oneiric, yes. With the unity in trunk, no. | 07:53 |
| tseliot | and they're going to upload the fix, aren't they? | 07:53 |
| tjaalton | sigh, yet another thunderbird beta and all plugins incompatible | 08:08 |
| * RAOF is still soldiering on with Evolution | 08:08 | |
| tjaalton | and addresbook just as broken as with version 6 | 08:08 |
| RAOF | tseliot: I'm not sure if they're going to upload the fix before beta freeze; DBO's gone to bed because it's insane-o-clock where he is. | 08:09 |
| tjaalton | "welcome to shredder", you don't say! | 08:12 |
| tjaalton | (the codename of tb 7beta) | 08:12 |
| tseliot | RAOF: it's ok, as long as they'll upload before the release ;) | 08:12 |
| tseliot | s/'ll// | 08:12 |
| tseliot | upload it | 08:13 |
| RAOF | tseliot: I think it's a fair bet there'll be at least one unity upload between here and release :) | 08:13 |
| tseliot | what's wrong with me today? | 08:13 |
| tseliot | RAOF: and not leaking memory doesn't sound like a feature to me :) | 08:13 |
| RAOF | tseliot: Thanks for following up on that nvidia corruption-after-suspend bug. | 08:14 |
| tseliot | RAOF: np. Now that they've confirmed that disabling grub's fb doesn't help, I can bug Nvidia to death ;) | 08:15 |
| alkisg | Hi, 1 out of 10 times, after suspend/resume, I'm getting the following errors, and I have to restart X: | 09:46 |
| alkisg | dmesg: [ 9626.944239] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung | 09:46 |
| alkisg | Xorg.0.log: (EE) intel(0): Failed to set tiling on front buffer: Input/output error | 09:46 |
| alkisg | Complete dmesg: http://paste.ubuntu.com/674409/ Complete Xorg.0.log: http://paste.ubuntu.com/674410/ | 09:46 |
| alkisg | Under which package should I report this? xserver-xorg-video-intel? Against the kernel? | 09:47 |
| tjaalton | alkisg: .38 is fail, intel-wise. try a newer kernel | 09:47 |
| jcristau | and if your gpu hangs, you want to capture the error state | 09:48 |
| alkisg | Ah, thank you tjaalton - that also happens with .32 and .35, but I'll try the kernel ppa | 09:48 |
| bryceh | /sys/kernel/debug/dri/0/i915_error_state | 09:48 |
| jcristau | yeah, that. | 09:48 |
| alkisg | Got it, thanks a lot guys | 09:48 |
| bryceh | if you can reproduce against the current 3.0 kernel, upstream will be interested | 09:49 |
| alkisg | Sure, as long as I can get that to my lucid box... /me searches the kernel ppa... | 09:50 |
| alkisg | https://launchpad.net/~kernel-ppa/+archive/ppa ==> linux-lts-backport-oneiric , as easy as it gets :) | 09:51 |
| tjaalton | lucid?? | 09:51 |
| alkisg | Yeah sorry... I'm an LTS guy | 09:51 |
| tjaalton | a ton of backports then | 09:52 |
| bryceh | tjaalton, might be better off backporting the entire kernel rather than bits and bobs | 09:52 |
| alkisg | Ouch, hmm... I might just stop using suspend then, and install oneiric to another partition just for the bug report | 09:53 |
| tjaalton | bryceh: yeah it was running .38 already, not just drm backported | 09:53 |
| tjaalton | alkisg: you probably have libdrm, -intel and mesa already backported? | 09:53 |
| bryceh | alkisg, that probably would be a bit easier | 09:53 |
| tjaalton | the livecd should work as well | 09:54 |
| alkisg | tjaalton: I think no, I think I'm using the version from lucid-updates | 09:54 |
| alkisg | Thanks, livecd is probably what best suits me | 09:54 |
| tjaalton | actually | 09:55 |
| tjaalton | somehow I thought you had sandybridge, so no heavy backporting necessary | 09:55 |
| * alkisg is all ears... | 09:55 | |
| alkisg | Just libdrm, intel and mesa? | 09:56 |
| tjaalton | but if you can reproduce it with oneiric, all the better | 09:56 |
| alkisg | Sure I don't think it'll take me more than half an hour | 09:56 |
| alkisg | dmesg, xorg.log, and error state - anything else? | 09:56 |
| tjaalton | i guess that'll do | 09:57 |
| * alkisg will also read https://wiki.ubuntu.com/X/Reporting | 09:57 | |
| tjaalton | well, you can use apport-cli -p xorg | 09:58 |
| bryceh | alkisg, if you've booting oneiric, there is a apport-gpu-error-intel.py udev hook which *should* automatically capture gpu hangs and collect all the required data automatically | 09:59 |
| alkisg | Perfect, thanks again guys | 10:02 |
| bryceh | heh, Michael Larabel found my wayland-demos package | 10:14 |
| tjaalton | so it seems | 10:30 |
| tseliot | :) | 10:55 |
| ricotz | might be a dump question, but why isnt libegl1-mesa-dev depending on mesa-common-dev? | 11:23 |
| ricotz | RAOF, hi ^ | 11:25 |
| tjaalton | should it? | 11:25 |
| ricotz | libgl1-mesa-dev depends on it | 11:26 |
| ricotz | so it would guess so | 11:26 |
| ricotz | but i might not too little about it | 11:26 |
| ricotz | s/not/know | 11:26 |
| tjaalton | well, if there are no headers importing the ones in mesa-common-dev then I don't see why it should depend on it | 11:28 |
| ricotz | ok, so if an application depends on libegl...-dev it should pull in mesa-common-dev by itself to use them | 11:31 |
| tjaalton | if it uses the headers provided by mesa-common-dev, yes | 11:32 |
| ricotz | i was just thinking that it is more convinient if mesa does this | 11:32 |
| ricotz | that is reasonable, of course | 11:32 |
| tjaalton | compiz fails to run with swrastg complaining that tfp is missing, though at least glxinfo says it's there | 11:41 |
| tjaalton | meh | 11:41 |
| tseliot | tjaalton: is compiz supposed to work with swrastg? | 12:47 |
| tjaalton | tseliot: so I'm told, that at least gnome-shell worked with it on fedora 15 | 12:54 |
| tjaalton | could be that it's llvm failing somehow, since it feels as if it's timing out | 12:56 |
| tseliot | ah, with llvm | 12:56 |
| tjaalton | swrastG :) | 12:56 |
| tseliot | right, I didn't notice the g | 12:56 |
| Prf_Jakob | Hmm I need to install two udev rules if I want the PRIMARY_DISPLAY_THINGY to work correctly. | 13:37 |
| bryceh | alright, new xdiagnose 1.1 uploaded; keep an eye out for any issues in apport bug reports... I've been testing it and seems to be working solid, but I did a good bit of refactoring so bugs are certainly possible | 20:36 |
| RAOF | Prf_Jakob: The PRIMARY_DISPLAY thing is a boot-time optimisation; you can safely ignore it if you don't mind until udev has finished probing everything before starting X. | 22:10 |
| Prf_Jakob | ok | 22:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!