[00:00] <RAOF> cnd: Nope.  I think I've just fixed Mr Barriers, but that should bake for just a tiny bit longer.
[00:00] <cnd> cool
[00:00] <Sarvatt> bryceh: so from my own bugs i've filed, i'm getting a segfault, then stuff is happening in the signal handler that is causing a SIGABRT later, and it keeps getting duped to doko's SIGABRT bug by apport even though i dont think its the the same
[00:00] <cnd> it's uploaded now
[00:00] <bryceh> Sarvatt, interesting
[00:01] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/948697
[00:01] <bryceh> yeah I've noticed with a lot of these stacktraces, that there's a dozen lines of input related goo that happens *after* it enters the abort code
[00:01] <Sarvatt> thats definitely a segfault, the abort is later but apport only cares about the later stuff
[00:02] <bryceh> yeah, or see https://launchpadlibrarian.net/95731570/ThreadStacktrace.txt
[00:02] <bryceh> there's a Sigio one
[00:03] <RAOF> Huh.
[00:03] <Sarvatt> bryceh: wait, thats someone elses bug? thats the same bug i'm hitting from the looks of it
[00:03] <RAOF> You know what we should do?  Block signals after we get a SIGSEGV
[00:04] <bryceh> yeah that's lp #948792
[00:04] <RAOF> If we're dying we don't want to handle input anyway.
[00:04] <bryceh> Jeroen's bug
[00:04] <bryceh> iirc he's able to repro that one fairly reliably
[00:05] <Sarvatt> its really really hard to reproduce, i only hit it because when my lids closed my touchpad wigs out thinking its getting touched from the lid and it takes like 10 hours closed to hit from what i can see
[00:06] <bryceh> Sarvatt, hey you're right these stacktraces do look the same
[00:06] <Sarvatt> both bcm5974 devices too
[00:07] <cnd> RAOF, so you want to block signals after a SIGSEGV from within a signal handler?
[00:07] <RAOF> Maybe?
[00:07] <Sarvatt> i'm amazed he got a crash report for the same thing apport actually retraced, i've filed 3 and all got duped to doko's totally different bug
[00:07] <RAOF> Once we hit the server abort path we should unhook the SIGIO handler at least.
[00:08] <cnd> RAOF, I guess the better question is why are we returning from the SIGSEGV handler?
[00:08] <bryceh> Sarvatt, interesting [291953.349] bcm5974: not enough space for touch events (max 5 touchpoints). Dropping this event.
[00:09] <Sarvatt> oh i get spammed with those constantly
[00:09] <RAOF> cnd: I think because we do strange things - particularly, we go through the SEGV handler and then re-raise SEGV so that apport can dump.
[00:09] <cnd> bryceh, Sarvatt: I wonder if that's due to the memory leak I just fixed
[00:09] <Sarvatt> except its 8 touchpoints here
[00:09] <Sarvatt> cnd: that would be freaking awesome
[00:09] <Sarvatt> i'll switch back to synaptics to check
[00:10] <cnd> Sarvatt, so that means we got stuck in sigio context long enough that many touchpoints came in before we were able to resize the touch record array
[00:10] <cnd> though if it's dying at only 8 touch points then you aren't seeing the memory leak
[00:11] <cnd> because the memory leak is the touch record array growing ad infinitum
[00:11] <bryceh> cnd, is there a bug # for that memory leak?
[00:11] <bryceh> oh wait, there is, you mentioned it already
[00:11] <cnd> yeah
[00:11] <cnd> it doesn't say it's a memory leak
[00:11] <Sarvatt> oh it changes
[00:11] <Sarvatt> [291953.349] bcm5974: not enough space for touch events (max 5 touchpoints). Dropping this event.
[00:11] <Sarvatt> [291953.349] [dix] bcm5974: unable to begin touch point 6
[00:11] <cnd> but that's another symptom
[00:11] <bryceh> bug 929408
[00:11] <Sarvatt> [291958.903] bcm5974: not enough space for touch events (max 8 touchpoints). Dropping this event.
[00:11] <Sarvatt> [291958.903] [dix] bcm5974: unable to begin touch point 8
[00:12] <cnd> Sarvatt, that sounds like the server regular context is hung
[00:12] <cnd> and the input sigio is still working
[00:13] <RAOF> cnd: Wow.  The xserver build sure is chatty with the new xorg-macros.
[00:13] <cnd> RAOF, what do you mean?
[00:13] <cnd> the macros I added for CXX?
[00:13] <bryceh> cnd, what's the version number for this new xserver?
[00:14] <RAOF> I wanted to rebuild xorg-gtest, so I pulled the new xorg-macros, because you've made it depend on the newer macros.
[00:14] <cnd> 1.11.4-0ubuntu5
[00:14] <bryceh> thanks
[00:14] <cnd> RAOF, it will still work with the older macros
[00:14] <RAOF> Someone has apparently added ALL THE WARNINGS to xorg-macros.
[00:14] <cnd> oh, they weren't there before?
[00:14] <Sarvatt> RAOF: fun isn't it!
[00:14] <RAOF> cnd: Not here it didn't; autogen bailed wanting a newer xorg-macros
[00:14] <Sarvatt> no debian hasn't updated to util-macros 1.16 yet
[00:14] <Sarvatt> for that reason :)
[00:15] <Sarvatt> 1.16.1 is a little better
[00:15] <cnd> RAOF, hmm, I thought it wouldn't require the latest xorg-macros
[00:15] <cnd> I guess I'll need to double check that
[00:15] <RAOF> Sarvatt: I pulled trunk.  You mean this is the *less bad* version? :)
[00:15] <Sarvatt> if you think 1.16.2 with the gtest stuff in it is chatty you should have seen 1.16.0
[00:16] <RAOF> Win!  That *was* the problem.
[00:16] <RAOF> cnd: Once again, xorg-gtest is awesome.
[00:16] <cnd> RAOF, hmmm?
[00:16] <cnd> what was the problem?
[00:16] <RAOF> Oh, a problem in the barrier code.
[00:17] <cnd> ahh, cool
[00:17] <cnd> RAOF, where are your tests?
[00:17] <cnd> I want to see how you're using it
[00:17] <RAOF> Only the first barrier event on the screen edge was getting triggered.  And because xorg-gtest is awesome, it was easy to find and verify.
[00:17] <cnd> so I can try to provide for us both :)
[00:18] <cnd> I'm going to add a method to xorg::testing::Test that will create a hierarchy of windows
[00:18] <cnd> that's next on my plate, since it's needed for testing of touch grabs and selections and such
[00:19] <RAOF> You can find them in the ubuntu-barrier-tests branch of xorg-server in my alioth repository.
[00:19] <bryceh> Sarvatt, think https://launchpadlibrarian.net/95610521/ThreadStacktrace.txt is the same?  it's also got that <signal handler> ...fail... ...Device futzing... end style
[00:20] <bryceh> different stack trace though
[00:20] <Sarvatt> nope i wouldn't assume it was
[00:20] <RAOF> cnd: http://anonscm.debian.org/gitweb/?p=users/raof-guest/xorg-server.git;a=summary
[00:20] <cnd> just when I had already navigated to it...
[00:20] <Sarvatt> mine *always* segfaults in valuator_mask_set_double
[00:20] <bryceh> ok
[00:20] <cnd> RAOF, so it's all in a debian patch?
[00:20] <cnd> just checking
[00:21] <RAOF> cnd: Yes.  Because now I'm going to submit MIRs for gtest and xorg-gtest, and this'll be enabled on the buildds.
[00:21] <Sarvatt> that ones in pixman_region_intersect
[00:22] <cnd> RAOF, are you planning to push the tests into precise?
[00:22] <RAOF> cnd: Yes.
[00:22] <cnd> RAOF, ok, before you do let me get integration tests proposed upstream at least
[00:22] <cnd> I hope to have that by the end of this week
[00:22] <RAOF> Integration tests for touch?
[00:23] <cnd> for anything
[00:23] <cnd> but the first proposed tests will be for touch :)
[00:23] <RAOF> Why should these tests block on that?
[00:23] <cnd> RAOF, actually, I suppose there's no reason they should
[00:24] <cnd> RAOF, you aren't using evemu replaying are you?
[00:24] <RAOF> No; just xtest.
[00:24] <cnd> I guess if you have it working with debuild, then it's good
[00:24] <cnd> sadly, evemu requires root or special udev rules
[00:25] <cnd> so we probably can't enable them by default during the build
[00:25] <cnd> RAOF, why do you have your own main()?
[00:26] <cnd> instead of linking against xorg-gtest_main
[00:26] <RAOF> cnd: So I can set options.  Specifically, so I can set the Xorg binary to ../../hw/xfree86/Xorg, and have my own conf file.
[00:27] <cnd> oh, I see where you set those now
[00:27] <cnd> I thought you were just providing the default options
[00:27] <RAOF> Nope.
[00:27] <cnd> cool
[00:28] <RAOF> I'd also like to pass -dumbSched to the server; it makes debugging more pleasant.
[00:28] <cnd> is that not possible with xorg-gtest today?
[00:29] <cnd> hmmm, I guess not
[00:30] <cnd> RAOF, if you find the time, xorg::testing::Environment could use a dumbSched boolean option and a generic "extra parameters" option
[00:30] <RAOF> Yeah, was planning to do that.
[00:31] <cnd> cool
[00:31] <cnd> I'm glad it's been helpful :)
[00:32] <cnd> RAOF, for the SIGIO corruption, maybe --gtest_repeat=-1 for a day on a test machine would help?
[00:33] <cnd> though I think gtest_repeat may be broken due to it attempting to restart the server each time, and the shutdown not being handled properly
[00:35] <RAOF> But it's not going to receive SIGIO, is it?
[00:35] <cnd> ahh, good point
[00:35] <cnd> because it's XTest
[00:36] <RAOF> Indeed.  It presumably would with evemu.
[00:36] <cnd> yeah
[01:25] <RAOF> cnd: gtest in Debian is going to lose the static lib entirely; I don't think building with -fPIC will be accepted.
[01:25] <cnd> RAOF, huh?
[01:25] <cnd> they just dropped the shared lib
[01:25] <cnd> so is it going to be source only?
[01:25] <RAOF> Yes.
[01:26] <RAOF> As Google intended :)
[01:26] <RAOF> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639795
[01:27] <cnd> interesting...
[01:28] <cnd> RAOF, I suppose that's ok, but then it raises the question of: how do we find the sources?
[01:29] <cnd> pkgconfig won't help, will it?
[01:29] <RAOF> Assume they're in /usr/src/gtest; we could provide a pkgconfig file.
[01:29] <cnd> but upstream doesn't provide a pkgconfig file, so that won't really help
[01:30] <cnd> I fear a future where we have to use --with-gtest-source=/usr/src/gtest
[01:30] <cnd> which then begs the question: should we be doing the same for xorg-gtest?
[01:31] <cnd> oh well, we'll deal with the fallout when it comes I guess
[01:34] <RAOF> Yeah.  That won't actually be terrible, though.
[01:34] <RAOF> Just needs some autofoolery.
[01:36] <cnd> yeah
[01:54] <Sarvatt> yay non-crashy Xv fglrx finally released
[01:57] <bryceh> oh yeah?  sweet
[02:08] <Sarvatt> the march fglrx is like a week away though, that was the target for precise
[05:42] <RAOF> I hate it when I realise that something only accidentally works.  Bah!
[08:35] <jcristau> this gtest stuff sounds like xtrans all over again
[09:46] <FernandoMiguel> morning
[18:00] <cnd> RAOF, ping me when you are available, I want to chat with you about gtest
[18:51] <jussi> hello all!
[18:51] <jussi> anyone know if there are currently issues witht the nvidia driver in precise? I cant seem to get it to install - see: http://paste.ubuntu.com/874989/
[18:58] <bryceh> jussi, have you had it installed on that hardware previously?
[18:58] <jussi> bryceh: yes, updated a few days back and it was gone
[18:58] <jussi> cant enable anymore
[18:58] <bryceh> jussi, here's the nvidia bugs reported against precise so far - http://bit.ly/wFEQec
[19:00] <jussi> bryceh: at first glance, seems similar/same as https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/949330
[19:01] <bryceh> jussi, yeah was just looking at that myself
[19:01] <bryceh> sounds like jockey may be confused
[19:02] <jussi> bryceh: right. Is there any further info I can provide to help diagnose? 
[19:03] <bryceh> hmm, doesn't look like nvidia-current has changed in the last couple weeks
[19:03] <bryceh> jockey did get a change on the 5th (minor stuff), and more major changes on t he 3rd
[19:04] <bryceh> jussi, perhaps try downgrading to jockey 0.9.6-0ubuntu1?
[19:05] <jussi> bryceh: forgive me, but how do I actually downgrade? 
[19:07] <bryceh> three options:  1) apt-get install <package>=<version>
[19:08] <bryceh> 2) if the .deb is in your /var/cache/apt/archive, then dpkg -i <path-to-deb>
[19:08] <bryceh> 3) Go to the launchpad page for the package, and go to the version history section, find the version you want and drill down to get the .debs.  Then as in #2.
[19:09] <jussi> right, Im on it. I assume I want jockey-common?  (not just the kde frontend)
[19:09] <bryceh> jockey-common and whatever frontend you usually use (jockey-gtk maybe?)
[19:11] <jussi> nah, its kde :) but yeah. do I need hte dh-modaliases? 
[19:13] <bryceh> possibly
[19:15] <jussi> bryceh: ok, it still fails: http://paste.ubuntu.com/875021/
[19:15] <bryceh> jussi, which version of the nvidia driver did you have installed before?  -current?
[19:16] <jussi> bryceh: I havent complete memory, but that is what I would usually install, yes.
[19:17] <bryceh> jussi, alright so we've ruled out a regression in jockey
[19:17] <bryceh> jussi, can you try purging all -nvidia from your system and then reinstalling it?
[19:17] <bryceh> (if you haven't already)
[19:17] <jussi> sure. sudo apt-get remove nvidia* ?
[19:18] <jussi> or do I need to purge?
[19:18] <bryceh> sudo apt-get purge nvidia*
[19:18] <jussi> ok :)
[19:19] <jussi> The following packages will be REMOVED:
[19:19] <jussi>   kubuntu-desktop* nvidia-173* nvidia-173-updates* nvidia-common* nvidia-current*
[19:19] <jussi>   nvidia-current-updates* nvidia-settings* nvidia-settings-updates*
[19:19] <jussi> curious that the 173 ones are there...? 
[19:20] <bryceh> in fact I've been wondering if that could be the problem
[19:20] <jussi> right, do I need to reboot or restart something before attempting again?
[19:20] <broder> and the -updates ones, too
[19:20] <bryceh> I'm not great at grokking jockey logs however it keeps talking about 173 like it would prefer to install that
[19:20] <bryceh> however we don't have a compatible version of -173 yet, so it's uninstallable
[19:21] <jussi> 01:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1)
[19:21] <jussi> is the HW
[19:21] <bryceh> hmm
[19:21] <bryceh> I think that's reasonably modern enough
[19:21] <bryceh> let's do the purge and then see what jockey thinks you should install
[19:21] <jussi> ok, purge is done, Ill give jockey a go now.
[19:22] <jussi> whoa, just got much faster.
[19:22] <jussi> right, so I can choose current and current updates
[19:22] <bryceh> you want current
[19:22] <jussi> ok
[19:23] <bryceh> (during development the two should be one and the same)
[19:23] <jussi> it appears to be installing now...
[19:25] <jussi> right, it installed. let me just reboot
[19:30] <jussi> bryceh: right, it seems to be working now. Im not sure what caused jockey to install all of the drivers there tbh.
[19:31] <jussi> Is there any other tests that are needed? or simply case closed forget about it? 
[19:32] <bryceh> jussi, there was a jockey bug before where it'd prefer -173 over -current.  I think that may be fixed now.  Could be this is just fallout from that.
[19:33] <jussi> bryceh: ahh that would make sense. I guess I just dont want to leave the situation without a bug report or something if it would be useful for others.
[19:33] <bryceh> jussi, debugging this with you has been helpful.  I'll keep an eye out for others with the same trouble, and if it appears to be a pervasive problem it may be worth deeper exploration, to see fi we can set up a reproducible case.
[19:34] <jussi> bryceh: sure. ping me if you need something, I idle here anyway :)
[19:34] <bryceh> jussi, well what I think we would need is to know how to get your system back into that broken state.  If you have any ideas shout.
[19:35] <bryceh> -nvidia installs have never been perfect, and the purge trick is well utilized
[19:35] <jussi> bryceh: one thing I could try that just came to mind, is to see if its a bug with jockey not removing things - ie, if I now go try to install the current-updates, will it remove the current?
[19:36] <jussi> so if in the past, I tried to install all 3 at different times, but it never actually removed them
[19:36] <bryceh> I think it can cope with having both installed side by side, but only one will be in use at a time
[19:36] <jussi> ok
[19:37] <bryceh> you mention things had been slower, so I wonder if you had -173 loaded
[19:37] <jussi> it was strange, I had some slowness, as well as a disappearing mouse cursor
[19:38] <jussi> but not slow enough to really comment on, just a little. 
[19:39] <bryceh> yeah, sounds like something that could be explained by an old driver
[19:40] <bryceh> fwiw, bug 949330 appears to be a missing kernel driver, which I think is different from what you saw.  could be a weird dkms build issue (which is not unusual)
[19:40] <jussi> ok. well lets leave it at that for now, if you need more, feel free to ping, I am very willing to help out where I can.
[19:40] <bryceh> sure thing
[19:41] <jussi> thanks forall the help :=)
[21:40] <FernandoMiguel> anyone else having GPU crashes ?
[22:04] <bryceh> FernandoMiguel, you'd have to be more specific
[22:05] <FernandoMiguel> bryceh: I've seen traces replace my screen after login, and on shutdown it got locked on another trace
[22:08] <bryceh> FernandoMiguel, do you have a bug#?
[22:08] <FernandoMiguel> not yet
[22:08] <FernandoMiguel> trying to gather info and reproduce it
[22:08] <bryceh> FernandoMiguel, do you have a pastebin of the trace?
[22:09] <FernandoMiguel> couldn't capture it
[22:09] <FernandoMiguel> the 1st one was gone when I moved my mouse
[22:09] <FernandoMiguel> the other locked on shutdown, so I forced rebooted
[22:09] <bryceh> FernandoMiguel, alright well I going to be of little use to you without knowing some details ;-)
[22:10] <bryceh> FernandoMiguel, "yes" people have gpu lockups, kernel crashes, and so on all the time
[22:10] <FernandoMiguel> I know I know bryceh
[22:10] <FernandoMiguel> any typs to debug it furhter ?
[22:10] <FernandoMiguel> or to collect a log of what happened on last boot ?
[22:10] <bryceh> steps to reproduce are always helpful.  See if you can reproduce it.
[22:11] <FernandoMiguel> will see on the next shutdown :)
[22:11] <bryceh> we need to have the trace.  You can check dmesg or /var/log/kern.log, etc.
[22:11] <bryceh> file bug reports via 'ubuntu-bug linux'
[22:11] <bryceh> or 'ubuntu-bug xorg' if you're certain its X failing.  Sounds like a kernel BUG or some such though, if it's printing on the screen
[22:11] <FernandoMiguel> k
[22:12] <bryceh> if it is a gpu lockup, then an i915_error_state.txt is required
[22:12] <bryceh> if it is an X server crash, then we want a full backtrace from gdb
[22:13] <FernandoMiguel> its on kern.log
[22:13] <FernandoMiguel> http://paste.ubuntu.com/875270/
[22:14] <FernandoMiguel> filing a bug now
[22:14] <bryceh> aha
[22:14] <bryceh> cifs
[22:14] <bryceh> FernandoMiguel, so, looks like you had a filesystem error, perhaps related to crypto
[22:15] <bryceh> FernandoMiguel, you'd be wanting to speak with the kernel folks then
[22:15] <FernandoMiguel> ill
[22:15] <FernandoMiguel> danka
[22:15] <bryceh> no prob
[22:27] <RAOF> cnd: Pong about gtest.
[22:27] <cnd> RAOF, let me get back to you
[22:27] <cnd> about to start a meeting
[22:27] <RAOF> :)
[22:38] <glosoli> Who is responsible for Ubuntu FGLRX ? 
[23:20] <cnd> RAOF, ok, I am ready to chat :)
[23:20] <cnd> so xorg-gtest is undergoing a huge change so that it can be built by projects instead of using precompiled libraries
[23:20] <glosoli> Anyone knows who is reponsible of fglrx being 2 versions out of date ? 
[23:21] <cnd> RAOF, I don't know if we should be including it in main for the LTS
[23:25] <bryceh> cnd, does anything depend on it?
[23:25] <bryceh> or, do you anticipate we'll be having large numbers of users running it?
[23:25] <cnd> bryceh, not yet, but RAOF wants to upload an xorg-server with tests that use it
[23:27] <bryceh> can it be an optional dependency in that case?
[23:29] <cnd> bryceh, I guess the bigger issue is that RAOF has asked for a MIR of xorg-gtest, but I don't think we can commit to support of xorg-gtest as it exists today
[23:30] <bryceh> in terms of security updates you mean?
[23:30] <cnd> any updates, really
[23:30] <cnd> I'm concerned about how we have a stack of precompiled libs
[23:30] <cnd> that upstream gtest says is the wrong way to do things
[23:31] <cnd> if the libstdc++ abi changes, we might be caught it a bad place
[23:31] <cnd> or something like that
[23:31] <bryceh> ah, gotcha
[23:32] <bryceh> however once the LTS is shipped, it's unlikely libs would go through ABI changes, right?  Plus, you'd have the same problem if it's in universe
[23:32] <cnd> true
[23:32] <cnd> yeah, but I don't *have* to support universe :)
[23:36] <bryceh> anyway, guess it boils down to how RAOF intends to use it.  having it in main does have some cost to it, but I don't think it's an unreasonable amount if there's sufficient value.
[23:36] <cnd> yeah, I suppose it will be ok
[23:37] <bryceh> there's lots of X packages we never update post-release, so this would be in good company ;-)
[23:38] <cnd> heh
[23:40] <RAOF> So, I'd quite like the tests to ship in the xserver.
[23:40] <RAOF> They *are* currently optional; they'll only build if xorg-gtest is installed.
[23:43] <RAOF> I guess there's not a high risk that the barrier tests get broken by post-release updates, so it's not terrible if they're not built on the buildds.
[23:43] <RAOF> cnd: So, if you don't want to support xorg-gtest in main, then I can live with that.
[23:44] <cnd> RAOF, I think it may be ok, but there will not be any further updates to xorg-gtest in precise
[23:45] <cnd> I guess that's an assumed thing since we're past FF anyways
[23:45] <cnd> meh, I'm getting my thoughts twisted in knots
[23:45] <cnd> I think it'll be fine
[23:45] <RAOF> Yeah.  What sort of bugs are we likely to see in xorg-gtest that require an SRU? :)
[23:46] <cnd> heh
[23:49] <cnd> so I've spent the entire day so far trying to get gtest to build inside a project
[23:49] <cnd> I'm getting close
[23:49] <cnd> I think I have xorg-gtest itself all figured out
[23:49] <cnd> now I'm trying to convert xorg-gtest
[23:51] <RAOF> What problems were you running in to?
[23:51] <RAOF> I build gtest as a part of the xserver tests, and it's no biggy.
[23:52] <cnd> RAOF, just trying to get it all set up "correctly"
[23:52] <cnd> the google example Makefile is not very good...
[23:53]  * RAOF does need to add the autofoo to allow you to specify the source directory.
[23:53] <RAOF> But I did it the cheater's way, by adding gtest-all.cc to _noinst_SOURCES :)
[23:53] <cnd> RAOF, you can see my work in progress at: http://cgit.freedesktop.org/~cndougla/xorg-gtest/log/?h=source
[23:57] <RAOF> Looks good.
[23:57] <RAOF> You'll still be shipping a pkg-config file, right?
[23:58] <cnd> no
[23:58] <cnd> what would be in it?
[23:58] <RAOF> The version, at least.
[23:59] <cnd> hmmm
[23:59] <RAOF> You could also include the path to the source directories.
[23:59] <cnd> how would you encode the path to the source directories?
[23:59] <RAOF> As a pkg-config variable.
[23:59] <cnd> you can define arbitrary vars?