[00:00] nite [08:45] RAOF, hey i have just had another of those X lockups, triggered by touching the edge of teh screen to pull out the launcher [08:46] any suggested triage, before i start restarting bits? [08:47] apw: Still there? [08:47] RAOF, yep [08:47] apw: Has X crashed, or frozen? [08:47] If it's frozen, could you ssh in, attach gdb, and nab a backtrace? [08:47] xserver still there, its in a futex wait [08:48] RAOF, no idea if its X or compiz, or another [08:48] Oh, really. [08:48] Is compiz in D state by any chance? [08:48] compiz is Sl [08:50] Hm. [08:50] RAOF, X appears to be in an intel_drv.so thingy, called out of _CallCallbacks [08:50] Ah. Could you pastebin a backtrace please? [08:52] RAOF, http://paste.ubuntu.com/869540/ [08:53] * RAOF is confused. [08:53] Could you do the same, with debugging symbols installed? [08:53] RAOF, this is a relativly recent behaviour, and i am pretty sure bjf has also hinted at similar behaviour -- cirtainly this is the third of this behaviour i've seen [08:53] RAOF, where doth i get those [08:54] apt-get install xserver-xorg-core-dbg xserver-xorg-video-intel-dbg xserver-xorg-input-evdev-dbgsym [08:54] And let's throw in libdrm2-dbg libdrm-intel1-dbg [08:54] That looks an *awful* lot like a deadlock caused by a signal handler, doesn't it. [08:55] E: Unable to locate package xserver-xorg-input-evdev-dbgsym [08:55] Oh, *ARSE* [08:55] Ignore evdev, then. [08:56] * RAOF has a sneaking suspicion that he knows what the problem is. [08:56] something i can type to get confirmation for you [08:57] No, I don't think so. [08:57] But a backtrace with function names would help me to check. [08:58] http://paste.ubuntu.com/869546/ [08:58] RAOF, ^ [09:00] Had you closed a window shortly before this happened? [09:00] RAOF, i had just touched the left edge about to reel out the launcher [09:00] the odd shadow thing is still there i think [09:01] sending events from the sigio handler sounds wrong. [09:01] evdev... with a mouse, right? [09:01] jcristau: Yeah, I just noticed thatc. [09:01] RAOF, indeed mouse in motion [09:01] no wonder it deadlocks [09:01] jcristau: Hence my *ARSE* :/. [09:01] The wonder is that it deadlocks so infrequently. [09:02] are you allowed to do _anything_ in a signal handler? [09:02] apw: not much. [09:02] you're supposed to read the input event, queue it, and get the hell out. [09:02] i am supprised reading input is allowed, let alone any of the other milarki [09:02] You can write() [09:03] so you can send yourself a hint [09:03] signal(7) has a list of functions you're allowed to call [09:03] *much* of writing events qualifies; probably something mallocs in a certain case. [09:04] I was just incautious and wasn't thinking that ConstrainCursorHarder was called from a signal context. [09:04] well in X sending events is not allowed from the sighandler, because it does more than write() [09:04] Yeah. [09:04] * apw would be supprised if malloc was safe most of the time [09:04] apw: it's not [09:05] malloc takes a lock [09:05] so if malloc gets interrupted by the signal and you call it again from the handler, it goes boom [09:05] Indeed. [09:06] RAOF, its a good job Intel graphics arn't common ... sigh [09:06] In this case, probably not malloc; looks like drmIoctl takes out a lock. [09:07] RAOF, yeah you'd hope wouldn't you [09:07] Anyway, time to rework this sucker. [09:07] RAOF, need anything mroe from this hang, or shall i kill it off [09:07] Kill it with extreme prejudice. [09:08] RAOF: is that bug upstream too? [09:08] jcristau: No; it's in my code (a prototype of which is languishing on the list) [09:08] ok [09:09] Would have been nice for someone to point out that CursorConstrainCursor is called in a signal context, though :) [09:09] The input code does a scary amount of work in that context. [09:10] having annotations in the code about it could be helpful.. [09:10] but i guess it'd easily get stale [09:10] Maybe [09:11] maybe sparse could handle that [09:11] Well, easily get stale, but the flow of the sigio handler shouldn't change *that* much between releases. [09:11] How well does sparse handle calls chained through function pointers? [09:11] no idea [09:12] i should try and play with it some time [09:12] It would seem to be something amenable to static analysis, but as I say, there's a surprising amount of code there. Fun fact! It calls into the nvidia blob now. [09:12] read input calls into nvidia?? [09:12] Yes. [09:13] RAOF, i hope you don't mean the intel driver :) [09:13] for hw cursor, or something else? [09:13] Because read input wraps into ConstrainCursorHarder, and nvidia now has a ConstrainCursorHarder hook. [09:13] ah. [09:13] To handle the same thing as xrandr's ConstrainCursorHarder hook. [09:14] One might think that the xrandr/ subdirectory would be free of the sigio context; you'd be mistaken. [09:14] RAOF, ok just in case i took a gcore of it [09:15] apw: Well, I now know of at least one critical bug in my code. [09:16] RAOF, heh well something came out of my hang :) [09:16] And with that, dinner. === yofel_ is now known as yofel [16:05] is this the right place to discuss regressions in X between Ubuntu 12.04 Alpha and Beta? [16:06] I did a dist-upgrade this morning (last one was a week ago, before Beta was released) and now it will only start in low graphics mode [16:09] which driver do you use? [16:09] sorry, it's radeon [16:10] so no fglrx? [16:10] installed [16:10] correct [16:10] never installed [16:10] pastebin /var/log/Xorg.0.log [16:10] yep, just a sec [16:13] (pastebinit $foo) [16:13] sorry, I'm otherwise distracted currently :) [16:14] it's at http://ossguy.com/xorg/20120305/1010/Xorg.0.log now [16:14] and http://ossguy.com/xorg/20120305/1010/Xorg.0.log.old [16:14] (running 2 different kernel versions; I got the same issue with all of them (including -18, which I tried before these)) [16:15] dualscreen? [16:16] yes [16:16] identical model screens [16:17] so which version was the last working one? [16:18] neither of the 2 I posted are from working X sessions [16:18] I will try to find you a log from a working session [16:18] just try an older kernel abi version [16:18] if you have those installed [16:18] how much older do you mean? [16:19] one that works [16:19] I have 3.2.0-12, -15, -17, and -18 [16:19] so try -12 [16:19] I've tried the last 3 [16:19] ok [16:19] I will once I'm in a state where I can reboot the system I'm on [16:23] actually, the logfile says it's using 19x12 [16:23] log from working sessions is here: http://ossguy.com/xorg/20120216/1628/Xorg.1.log [16:23] s/sessions/session/ [16:23] [ 73.483] (II) RADEON(0): Output DisplayPort-0 using initial mode 1920x1200 [16:23] [ 73.483] (II) RADEON(0): Output HDMI-0 using initial mode 1920x1200 [16:24] yes, I noticed the screen was the usual res [16:24] but I got the box saying it was running in low graphics mode [16:24] and there didn't seem to be an easy way to get around it [16:24] huh? [16:26] after I did the dist-upgrade this morning, I rebooted the system and X started up with the "you're running in low graphics mode" message [16:26] but as far as I could tell, it was running at 19x12 (and the logs confirm this) [16:26] ahah, so xdiagnose fired up for some reason [16:27] right (I guess :) ) [16:27] well you didn't say it looked normal [16:27] also, the screens were in mirroring mode [16:27] not side-by-side, as I had configured [16:28] it's a per-user setting [16:28] ah, right [16:28] ok, so we didn't even get there [16:28] any ideas why xdiagnose might have decided to run? [16:28] no.. [16:28] or how to get it to not run? [16:28] it runs on every boot? [16:28] yes [16:28] bryceh: ^ :) [16:29] (or maybe a different venue where it's more appropriate to ask this question?) [16:29] no this is fine [16:29] ok [16:30] basically it would mean that lightdm had failed to start [16:30] check /var/log/lightdm/* [16:31] oh, dist-upgrade.. check that you have lightdm _installed_ [16:31] lightdm produced logfiles the last time I started Ubuntu [16:31] so I presume it is installed [16:31] ok, check what's in them [16:32] [+0.67s] DEBUG: Failed to load session file /usr/share/xgreeters/.desktop: No such file or directory: [16:32] [+0.67s] DEBUG: Failed to start greeter [16:32] perhaps that is an issue? [16:32] I will post the full log; just a sec [16:33] is unity-greeter installed? [16:33] apt-cache policy unity-greeter [16:33] sorry, I'm not booted into Ubuntu right now (I'm in a different distro on the same machine) [16:34] I can check some apt-related files, though [16:34] check the upgrade log [16:34] dpkg.log [16:34] ok [16:35] and you can always chroot into the partition :) [16:35] lightdm log here: http://ossguy.com/xorg/20120305/1010/lightdm.log [16:35] true; I'd rather not do anything funny there, though :) [16:36] do you have /usr/share/xgreeters/unity-greeter.desktop [16:36] no, /usr/share/xgreeters does not exist [16:36] so no /usr/sbin/unity-greeter either? [16:37] grep unity-greeter /var/log/dpkg.log ? [16:37] it suggests unity-greeter was removed [16:37] there you go [16:38] never blindly run dist-upgrade [16:38] I presume something was unexpected here [16:38] ah, ok, good lesson I suppose :) [16:38] what's the best/easiest way to get back to working? [16:38] but first upgrade and then see if dist-upgrade would remove stuff [16:39] ubuntu-desktop got removed as well I guess, so install it [16:39] yep, looks like it was removed, too [16:39] so what was the way I should have done this upgrade? [16:39] I mean eventually I want to run "dist-upgrade" [16:40] only when it's not doing silly things [16:40] so how should I determine when is the right time to do so? [16:40] ok [16:40] so in alpha/beta I should expect silly things [16:40] a good indicator is when it's removing *-desktop.. [16:40] yes [16:40] right :P [16:41] transitions etc [16:43] tjaalton: thanks very much for all your help [16:43] and for bearing with a dumb user ;) [16:45] yw === Sinnerman is now known as Cobalt === FernandoMiguel is now known as FM_fewd === FM_fewd is now known as FernandoMiguel [22:45] hmm, haven't seen this input related crash come up before, just hit it http://paste.ubuntu.com/870647/ [22:52] RAOF, thoughts on bug 931967? [22:52] Launchpad bug 931967 in OEM Priority Project "Corrupted graphics after the login until the unity launcher appears" [Critical,Triaged] https://launchpad.net/bugs/931967 [22:53] I'm assuming it's just that when lightdm hands off to X, the framebuffer isn't zero'd out. something lightdm should be doing? [22:54] I started looking at that, then got pulled into more pressing issues. [22:54] What I had was: lightdm draws to the root window. [22:55] Or, rather *unity-greeter* draws to the root window. [22:55] This should mean that whatever unity-greeter leaves on the display stays there until something else draws; that something else should be compiz. [22:56] However, on *some* drivers that isn't happening; it doesn't happen on intel, it does on radeon and nouveau. [22:57] Which suggests it might be an EXA issue, or something. [22:57] fglrx and -nvidia too aiui [22:57] yep, just repro'd on -nvidia [23:04] I wonder if RetainPermanent is horribly unimplemented. [23:05] What I was going to try is to replace unity-greeter's cairo render-to-root-pixmap code with a straight X11 CopyArea from a pixmap to the root window. [23:07] hmm, wonder if unity-greeter has some better debugging output... [23:53] bryceh: Hey, you know those xlib-xcb asserts we've been seeing? Think http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/29102 might have something to do with it?