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