[00:00] <bryceh> Sarvatt, 686164 can be closed now I gather, since it's xorg-edgers-specific?
[00:06] <Sarvatt> dang, _alf did an awesome job on the cairo-gl patches http://git.linaro.org/gitweb?p=people/afrantzis/cairo.git;a=shortlog;h=refs/heads/gl-remove-glew
[00:06] <Sarvatt> bryceh: yeah, sorry
[00:09] <bryceh> Sarvatt, btw thanks for the bug work, http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg is looking happy again
[00:11] <Sarvatt> thanks for doing that man, its so much easier if we track it as we go! making it interactive helped a lot
[00:11] <Sarvatt> i usually end up just looking at intel and spending hours in that mess, not even getting to the other drivers
[00:12] <bryceh> yeah it's quite gratifying
[00:13] <bryceh> as opposed to the more usual overwhelmed feeling ;-)
[00:13] <bryceh> I dialed up the graph to regen more frequently
[00:14] <Sarvatt> maybe it'd be nice to have a bug total next to the package name? gets hard to tell from the graph eventually
[00:14] <bryceh> mm, good idea
[00:15] <Sarvatt> fglrx-installer looks like more than one bug there but its one bug, hmm
[00:17] <bryceh> you mean nvidia?
[00:18] <Sarvatt> ohh
[00:18] <Sarvatt> couldnt tell them apart
[00:18] <bryceh> sorry, colors are pretty similar between those two
[00:18] <bryceh> kinda hard with gnuplot to force what colors things show up as
[00:19] <bryceh> I'm having kind of a love/hate relationship with gnuplot
[00:22] <bryceh> ok, mouse-overs are fixed...  if you hover over a color it'll now show a tooltip with the package name
[00:22] <bryceh> before it just said "Plot #10" or whatever, which is unhelpful ;-)
[00:31] <Sarvatt> RAOF bryceh tjaalton: what do you guys think about trying to SRU xserver 1.7.7-10 to lucid minus the xsfbs abi changes?
[00:32] <bryceh> Sarvatt, assuming the patches went through a careful review process, I'd not be opposed to it in principle
[00:34] <RAOF> I think our SRU requirements are stricter than the stable-branch requirements for xserver; we'd need to review the patches ourselves.
[00:34] <RAOF> That said, I also have no in-principle objections.
[00:39] <Sarvatt> heh, I could go through every commit and recreate the bugs and file those I guess
[00:39] <RAOF> Oh, apropos nothing, would you like to add an endorsement to wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication bryceh?
[00:40] <RAOF> Sarvatt: I don't think that's necessary, but we should look through each of the patches and ensure they (a) fix an actual bug we could concievably care about, and (b) are appropriately minimal.\
[00:41] <RAOF> I'm thinking here particularly of the discussion around the pulling of the Damage reporting changes into the 1.9 stable tree.
[00:41] <RAOF> That's an example of a patch that we shouldn't SRU.
[00:41] <Sarvatt> just about everything I've reviewed of it so far would be no problem to reproduce
[00:42] <Sarvatt> oh yeah i'm talking about the 3 release old stable branch basically maintained by the guy maintaining debian stable now :)
[00:44] <RAOF> Yeah, it's KiBi, right?  I'm actually not familiar with the reqirements for Debian-stable updates, so that's not a huge help to me :P.  I wouldn't expect them to be substantially laxer than LTS SRU requriements, though.
[00:44] <bryceh> RAOF, certainly
[00:44] <Sarvatt> jcristau :)
[00:48] <Sarvatt> yeah quite a lot of these are good fixes and would be easy to reproduce to show its a problem, maybe just a large patch bomb would work
[00:49] <Sarvatt> its not so bad now but we had patches fixed on 1.7 branch sitting on lp for review for 3-4 months at one point
[00:55] <RAOF> Oh, man.  RandR 1.4 starts looking scary.
[00:56] <Sarvatt> i'll start working on a patch review list since its bugging me :)
[00:56] <Sarvatt> RAOF: yeah tell me about it..
[01:10] <bryceh> RAOF, ok, posted
[01:16] <RAOF> Thanks muchly.
[01:17] <Sarvatt> ugh thanks for the reminder, i'm going to set aside a block of time to make sure my application is squared away in the morning
[01:18] <Sarvatt> december 20th then
[01:35] <RAOF> Ok, time to update the bgnoneroot patches so that I can actually test these X server patches.
[01:35] <RAOF> Sarvatt: You haven't yet updated those patches for xorg-edgers yet, have you?
[01:38] <Sarvatt> updated how?
[01:39] <RAOF> So as to build against 1.9.99
[01:39] <Sarvatt> oh nope, need to patch gdm/kdm/etc too :(
[01:40] <RAOF> Oh, yeah, it will.
[01:40] <RAOF> Hm.
[01:40] <RAOF> Bah.
[01:40] <Sarvatt> would it be evil to add -nr again? :)
[01:40] <RAOF> It won't be that hard to update gdm & kdm for the new option name.
[01:40] <Sarvatt> cus i'm thinking about it
[01:41] <Sarvatt> yeah but carrying those in the PPA..
[01:41] <RAOF> Oh, for xorg-edgers?  Totally.
[01:41] <Sarvatt> was waiting for the proto/lib changes coming to update edgers
[01:43] <RAOF> Hm.  Why could I install 1.9.99 without breaking all the drivers?
[01:45] <RAOF> Heh.  False alarm.  Everything's broken :)
[02:13] <DanaG> Say, how's the support for "magic trackpad" in Maverick?
[02:15] <bryceh> Sarvatt, alrighty, you have your wish...  http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
[02:15] <RAOF> DanaG: You get multitouch on it; cnd has one, so it's well supported :)
[02:16] <DanaG> Er, gotta go...
[02:16] <bryceh> Sarvatt, note you can mouse over and/or click the entries in the legend too, which might be more click-friendly
[02:17] <bryceh> hmm, why is fglrx-installer showing up with 1 bug?
[02:17] <Sarvatt> there was one bug last i looked
[02:18] <Sarvatt> and sweet!
[02:19] <bryceh> yeah, what's odd is the line graph shows it as 0
[02:22] <bryceh> btw, currently the workqueue chart excludes bugs that are open upstream
[02:22] <bryceh> Sarvatt, but I'm kinda on the fence as to whether we should exclude those or keep them in the chart.  What do you think?
[02:22] <Sarvatt> how much bigger does it get?
[02:23] <bryceh> I think it adds 3 or so
[02:24] <bryceh> for instance, bug #685767 would be excluded
[02:24] <ubot4> Launchpad bug 685767 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "Dim LCD Screen After Blank Screensaver Activated (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/685767
[02:25] <bryceh> nice thing about excluding them is that we can consider that a "finished for now" state, until the upstream bug gets closed, at which point it re-enters the chart
[02:25] <Sarvatt> hmm thats just not pulling from debian bugs right
[02:25] <bryceh> oh that's debbugs...
[02:26] <bryceh> I'm not sure whether or not bug syncing works with debbugs.  I suspect not.
[02:26] <Sarvatt> that one would be useful to have in there because we know the fix and could do work on it, would make sense to be in the workqueue
[02:27] <bryceh> it does show up in our patches report (but only because I grabbed the patch and attached it)
[02:30] <Sarvatt> to be honest I always used the non-workqueue graph for the last releases because I was interested in all of the bugs
[02:31] <Sarvatt> but it might make more sense, we'll see how it goes :)
[02:34] <bryceh> yeah I should linkify that one too at some point
[02:35]  * Sarvatt pins the http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg tab so it's always open in chromium :)
[02:37]  * RAOF looks at this patch again.  Man, I suck.
[02:39] <RAOF> Amazingly enough, unless you actually initialise the struct the contents are garbage.  C doesn't magically discern your intention :/
[02:40] <Sarvatt> what patch?
[02:43] <RAOF> Making DRI2 swapbuffers not an exercise in server crashes.
[02:43] <RAOF> Intel did it, radeon did it, I haven't tested, but it looks very much like nouveau does it now...
[02:45] <RAOF> Oh, pageflipping nouveau should be in xorg-edgers, shouldn't it?
[02:46] <Sarvatt> if the kernel stuff is upstream
[02:46] <Sarvatt> (and its <nv50 only)
[02:47] <RAOF> I think the kernel component is upstream.
[02:48] <RAOF> Anyway, it's going to crash the xserver when a client goes away with a pending swap.
[02:48] <RAOF> Just like when Intel implemented it, and then Radeon.
[02:49] <Sarvatt> disable page flip patch for nouveau: check
[02:51] <RAOF> It'd also be trivial to port those fixes to nouveau DDX, but when the big three drivers need exactly the same fix it's probably time to fix it once, in the server.
[02:53] <RAOF> Plus I can make it so that the server won't accidentally send a DRI2SwapComplete event to some poor unfortunate random client :)
[02:54] <RAOF> Boo.  udeb building is broken in 1.9.99
[02:56] <Sarvatt> got a build log? think kibi had patches for it
[03:01] <RAOF> Yeah; sdksyms dies.  I'd guess it's a binutils snafu, but DEB_BUILD_OPTIONS=noudeb is a better option anyway.
[03:04] <RAOF> At least for my purposes.
[03:08] <Sarvatt> hmm udeb built fine here
[03:09] <RAOF> Maybe my naieve patches surgery broke it.
[03:10] <Sarvatt> drop 06_dont_trap_access_to_timer_and_keyboard.diff upstream
[03:10] <Sarvatt> drop 16-xaa-fbcomposite-fix-negative-size.diff obsolete
[03:10] <Sarvatt> drop 121_only_switch_vt_when_active.diff fails
[03:10] <Sarvatt> drop 189_xserver_1.5.0_bg_none_root.patch upstream
[03:10] <Sarvatt> drop 190_cache-xkbcomp_output_for_fast_start_up.patch fails
[03:10] <Sarvatt> drop 197_xvfb-randr.patch fails
[03:10] <Sarvatt> drop 203_gestures-extension.patch fails
[03:10] <Sarvatt> thats what i did with origin/ubuntu debian/
[03:13] <RAOF> I think I dropped more; one of those is probably it.
[03:13] <Sarvatt> guessing 07-xfree86-fix-build-with-xv-disabled.diff
[03:14] <Sarvatt> probably should just drop 100_rethrow_signals.patch in the PPA too since it doesn't do anything
[03:18] <Sarvatt> argh I really need to file a bug about the NX stuff breaking grub on warm boots, other people hitting it on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/683775
[03:18] <ubot4> Launchpad bug 683775 in linux (Ubuntu) (and 1 other project) "Natty Alpha 1, i915 has blank screen after boot (affects: 12) (dups: 5) (heat: 92)" [High,Fix released]
[03:50] <Sarvatt> and here comes the mass of xserver commits :)
[03:50] <RAOF> ☺
[03:51] <RAOF> Cool, that works.  Now to prove to my satisfaction that it actually fixes the problem :)
[03:51] <Sarvatt> The last two in this list fix a nasty bug, since input ABI 12 all options
[03:51] <Sarvatt> set for statically configured xorg.conf devices got lost during the device
[03:51] <Sarvatt> initialisation process.
[03:51] <Sarvatt> eww
[06:54] <DanaG> Now, does xorg.conf.d in etc still break everything (by ignoring same dirs in /usr/share)?
[16:58] <ricotz> Sarvatt, hi are you around?
[16:59] <ricotz> seb128, hello
[17:01] <seb128> hey ricotz
[17:01] <ricotz> seb128, hi, it would be great if you could add a nice comment here https://wiki.ubuntu.com/ricotz
[17:02] <seb128> ricotz, what do you apply for?
[17:02] <ricotz> ubuntu-members
[17:03] <Sarvatt> heyo ricotz, sorry I haven't gotten to mesa yet man
[17:03] <Sarvatt> ricotz: why don't you apply for contributing developer instead?
[17:03] <seb128> ricotz, ok
[17:04] <Sarvatt> all the perks of members only acceptance is judged based on development contributions instead of community involvement
[17:04] <ricotz> Sarvatt, is there such a group, i finally wanted to get a ubuntu.com adress ;)
[17:04] <Sarvatt> they hounded me about that when I became a member :)
[17:04] <Sarvatt> https://wiki.ubuntu.com/UbuntuDevelopers#ContribDev
[17:05] <ricotz> seb128, thank you
[17:05] <Sarvatt> well either way will add a comment once this meeting is over
[17:05] <ricotz> Sarvatt, thank you
[17:07] <apachelogger> aloha
[17:08] <apachelogger> I tried compiling Qt with opengl es2 support on armel, now I get libEGL fatal: DRI2: failed to authenticate
[17:09] <apachelogger> that is with xserver-xorg-video-omap3, though a custom kernel
[17:10] <Sarvatt> surely you dont want to be using the mesa libEGL?
[17:10] <apachelogger> Sarvatt: what else is there?
[17:11] <Sarvatt> arm platforms all have proprietary blobs for acceleration, I don't know exactly what the package names are or where you get them but they might know if you ask in #ubuntu-arm
[17:12] <Sarvatt> probably has pvr in the package name
[17:12] <apachelogger> ok, thanks
[17:19] <Sarvatt> sorry I don't have more info on it, the arm stuff is totally separate.. I'm positive there are packages you can grab for acceleration *somewhere* though
[17:19] <Sarvatt> http://ppa.launchpad.net/tiomap-dev/release/ubuntu/dists/maverick/main/binary-armel/Packages
[17:20] <Sarvatt> hmm I see some in there
[17:21] <Sarvatt> https://launchpad.net/~tiomap-dev/+archive/release
[17:23] <Sarvatt> ah omap3.. thats all omap4
[17:24] <apachelogger> the sgx stuff sounds familiar
[17:25] <apachelogger> IIRC maemo is using that for gles ... what I found strange though was that meego does apparently not
[17:32] <vish> Sarvatt: hi, re: the X freeze i was whining about.. finally was able to backtrace, the only way bt was possible was how you had suggested. to attach & bt when it was frozen.. thanks. :)
[17:33] <vish> was able to run bt twice , both seem the same  : http://paste.ubuntu.com/540699/  & http://paste.ubuntu.com/540700/
[17:33] <vish> err twice ,in the sense two occurrences oops! 
[17:34] <vish> oops just sarvatt …
[17:45] <vish>  Sarvatt: hi, re: the X freeze i was whining about.. finally was able to backtrace, the only way bt was possible was how you had suggested. to attach & bt when it was frozen.. thanks. :)
[17:46] <vish>  was able to run bt , both seem the same  : http://paste.ubuntu.com/540699/  & http://paste.ubuntu.com/540700/  
[17:46] <vish> is that sufficient for submitting a bug upstream..? 
[17:49] <Sarvatt> vish: can you install libdrm-radeon1-dbg libdrm2-dbg, then echo 0x001ee62d | eu-addr2line -e /usr/lib/debug/lib/libdrm_radeon.so.1.0.0 ?
[17:49] <Sarvatt> and do that for those other lines without info at the top of the backtrace?
[17:49] <vish> sure thing.. thanks.
[17:51] <Sarvatt> if you can trigger it easier just getting a backtrace with those dbg packages would be better :)
[17:52] <vish> hehe, i wouldnt say easier to trigger , but just occurs randomly..
[17:52] <Sarvatt> hmm thats with stock natty stuff?
[17:53] <vish> nah, in maverick.
[17:55] <Sarvatt> oh.. quite a lot of ddx commits to go through
[17:56] <Sarvatt> ati 6.13.1 right?
[17:58] <vish> yea   -ati 1:6.13.1-1ubuntu5
[17:58] <apw> Sarvatt, is that machine which doesn't reboot with the graphics handoff from grub still doing that?  is there a bug?  if so could you tag it kernel-key-gfxpayload
[17:59] <Sarvatt> apw: nope that bug is fixed, but I've narrowed down warm boots being broken and hanging before the grub menu to the NX commits added in 2.6.37-3.11
[18:00] <Sarvatt> 2 steps left in the bisect on that one
[18:00] <Sarvatt> i haven't been able to reboot since 2.6.37-2.10, mainline kernels work fine
[18:02] <Sarvatt> apw: that intel commit fixed the graphics handoff for sure here
[18:03] <vish> Sarvatt: what is that echo supposed to do , is it to prepare for better bt at the next freeze?
[18:05] <vish> once i echo for those lines, i get   ??:0
[18:08] <Sarvatt> argh, it would be nice if ath9k wouldn't die under load
 apw: nope that bug is fixed, but I've narrowed down warm boots being broken and hanging before the grub menu to the NX commits added in 2.6.37-3.11
 2 steps left in the bisect on that one
 i haven't been able to reboot since 2.6.37-2.10, mainline kernels work fine
 apw: that intel commit fixed the graphics handoff for sure here
[18:09] <Sarvatt> not sure if that went through
[18:09] <vish> Sarvatt: we heard that. but you missed mine.. :)
[18:09] <vish>  <vish> Sarvatt: what is that echo supposed to do , is it to prepare for better bt at the next freeze?
[18:09] <vish>  <vish> once i echo for those lines, i get   ??:0
[18:09] <Sarvatt> vish: ah darn
[18:09] <vish> Sarvatt: and nothing else on the channel.. :)
[18:10] <Sarvatt> vish: could you try https://launchpad.net/~ubuntu-x-swat/+archive/x-updates ?
[18:11] <vish> sure..
[18:11] <Sarvatt> x-x-v-ati 6.13.2 in there and there are quite a few commits touching the functions you're crashing in
[18:15] <vish> Sarvatt: should i just install xserver-xorg-video-ati 6.13.2  alone or the xserver-xorg-video-radeon 6.13.2 too? 
[18:15] <Sarvatt> both, i guess you can do that because I built ati in there before bumping libdrm :)
[18:16] <vish> cool, installing..
[18:20] <Sarvatt> might want the dbg packages too
[18:28] <vish> yupp got those too.. restarting X … brb
[18:39] <vish> the frustrating thing about the random freezes is that we can never be sure(for a while) if the update really fixes the issue.. :s
[18:39] <vish> i guess i'll have to stress-test scrolling  ;)
[18:40] <Sarvatt> there was a site that was super good about stress testing scrolling freezes, hmm
[18:40] <Sarvatt> http://www.woodtv.com/
[18:40] <Sarvatt> thats it
[18:44] <vish> ooh, thanks.
[18:48] <bryceh> Sarvatt, is bug 686388 a known lockup?
[18:48] <ubot4> Launchpad bug 686388 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup 94ada031 (EIR: 0x00000010) (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/686388
[18:49] <bryceh> Sarvatt, oh btw don't forget to shoot me your ideas on how we could improve the apport crash handler.  I am planning on spending a week or two on apport hook improvements in the coming weeks
[18:49] <Sarvatt> nope
[18:49] <Sarvatt> Invalid GTT entry during Display B Fetch
[18:49] <Sarvatt> haven't seen that one
[18:50] <bryceh> Sarvatt, where do you find "Invalid GTT entry during Display B Fetch"?
[18:51] <bryceh> is that in one of the logs, or an external doc?
[18:51] <Sarvatt> wonder if its hotplug related
[18:51] <Sarvatt> intel_error_decode on the i915_error_state.txt
[18:52] <Sarvatt> https://launchpad.net/~sarvatt/+archive/intel-gpu-tools
[18:52] <Sarvatt> newer ones show a lot more info
[18:52] <Sarvatt> bryceh: I need to file a bug on this NX problem breaking warm boots, give me a bit
[18:52] <bryceh> Sarvatt, no hurry
[18:57] <bryceh> hrm, still not seeing where that display b fetch error message came from
[19:15] <Sarvatt> bryceh: did you upgrade intel-gpu-tools to the one in the ppa?
[19:15] <bryceh> Sarvatt, yeah
[19:15] <bryceh> $ apt-cache policy intel-gpu-tools
[19:15] <bryceh> intel-gpu-tools:
[19:15] <bryceh>   Installed: 1.0.2+git20100927+dbc547d-0ubuntu1
[19:15] <bryceh>   Candidate: 1.0.2+git20100927+dbc547d-0ubuntu1
[19:15] <bryceh>   Version table:
[19:15] <bryceh>  *** 1.0.2+git20100927+dbc547d-0ubuntu1 0
[19:16] <bryceh>         500 http://ppa.launchpad.net/sarvatt/intel-gpu-tools/ubuntu/ maverick/main i386 Packages
[19:16] <bryceh>         100 /var/lib/dpkg/status
[19:16] <bryceh>      1.0.2+git20100324-0ubuntu1 0
[19:16] <bryceh>         500 http://us.archive.ubuntu.com/ubuntu/ maverick/main i386 Packages
[19:16] <bryceh> $ intel_error_decode ./i915_error_state.txt|more
[19:16] <bryceh> Time: 1291713055 s 678993 us
[19:16] <Sarvatt> huh
[19:16] <bryceh> PCI ID: 0x2a02
[19:16] <bryceh> EIR: 0x00000010
[19:16] <Sarvatt> 0927?
[19:16] <bryceh>   PGTBL_ER: 0x00000100
[19:16] <bryceh>   INSTPM: 0x00000000
[19:16] <Sarvatt> oh sorry man, my bad
[19:16] <Sarvatt> i'm using the xorg-edgers one
[19:16] <bryceh> ah
[19:16] <Sarvatt> it required a newer libdrm and failed in that ppa
[19:16] <bryceh> looks like your 20101029 package didn't build
[19:17] <Sarvatt> you can just grab intel-gpu-tools deb from xorg-edgers, it'll work with natty
[19:17] <Sarvatt> faster than a rebuild will be at least :)
[19:17] <bryceh> unfortunately my scripts run on a maverick box...
[19:17] <Sarvatt> hmm
[19:17] <Sarvatt> intel_error_decode shouldn't need the newer libdrm
[19:18] <Sarvatt> intel_gpu_dump will probably be busted though, is it a intel box?
[19:18] <bryceh> radeon
[19:18] <bryceh> oh well, I'll todo it for later
[19:19]  * bryceh peeks at the source
[19:19] <Sarvatt> i added a get-orig-source target to it to make it easier to update
[19:19] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/686705 -- apport sure leaves a lot to be desired there..
[19:19] <ubot4> Launchpad bug 686705 in linux (Ubuntu) "System hangs at GRUB loading screen every warm boot since 2.6.37-3.11 (affects: 1) (heat: 8)" [Undecided,New]
[19:22] <bryceh> yeah, won't build from source (‘I915_EXEC_BLT’ undeclared)
[19:23] <bryceh> however...
[19:23] <bryceh> Sarvatt, is it always just the PGTBL_ER we care about?
[19:25] <Sarvatt> bryceh: http://sarvatt.com/downloads/patches/0001-Revert-Prepare-for-split-BLT-ring-on-Sandybridge.patch
[19:25] <Sarvatt> nope, there usually isn't a PGTBL_ER
[19:29] <bryceh> $ ./intel_pgtbl_err 0x00000100
[19:29] <bryceh> 256
[19:29] <bryceh>     Invalid GTT entry during Display B Fetch
[19:29] <bryceh> sweet, I've rewritten it in python
[19:45] <ilmari> how do i compile just a single module (i915) from a patched ubuntu kernel tree? I've checked out the tag corresponding to my currently running kernel
[19:47] <ilmari> can I just copy /boot/config-$(uname -r) to .config and make oldconfig && make drivers/gpu/drm/i915/i915.ko ?
[19:47]  * ilmari tries
[20:16] <bjsnider> is pitti in any ubuntu channels at the moment?
[20:23] <Sarvatt> ubuntu-desktop but he's gone for the night
[20:24] <bjsnider> i see
[20:26] <ilmari> nope, that did not work (not even with LOCALVERSION="" and EXTRAVERSION=-23-generic)