[00:50] tomreyn: final version appears to be: https://lkml.org/lkml/2013/3/11/677 [02:18] thanks [05:11] tomreyn: huh? [05:12] uploading -intel 2.21.4 [05:12] yeah, it has that fix :) [05:12] ... is what i was referriing to [05:12] no [05:13] that was not the kernel.. [05:14] okay thanks [06:47] tjaalton, Sarvatt: Sounds like glamor works for 1.14 & 1.13.x; we should keep radeonsi enabled in -edgers. === ripps_ is now known as ripps [07:14] RAOF: oh cool [07:14] we still have it on raring too [07:14] but glamor needs an update? [07:15] hum, is it even in the archive? [07:15] what a mess :P [07:41] tjaalton: Nope, not in the archive; that needs to be done ): [07:41] :) [07:41] ooh fun [07:41] could it be made part of the xorg group? [07:42] i recently got an unreleased 8xxx series card, but it's not even si-based.. duh [07:42] el cheapo series [07:43] :> [07:43] was disappointed for not being able to test this stuff.. even to just notice it's "utter failure" or whatever phoronix calls it this week [07:44] hahah [07:56] mlankhorst: yeah it probably makes sense under pkg-xorg [07:59] yeah if it does get MIR'd, I'll ask to get pixman and all the blob packages in the xorg package list too :) [08:00] oh that list, right [08:05] but ok when you checked the race condition I'll upload xorg-server 1.13.3 :) [08:06] brb [08:07] well, at least the git version doesn't break anything here [08:07] although if you need the race case tested then yes, within the next hour [09:08] Lies! [09:10] hah [09:10] soon [09:10] disabled swap and eth0 bridge so it's actually able to hit it [09:11] it should show something in the xorg log if you do hit it [09:11] first I'll try with the current one [09:57] mlankhorst: ok, I have the current package obviously doing something there, now trying the new one [09:58] ooh, reproduce the race with it [09:58] +d [09:59] does it survive? [09:59] no [09:59] ah boo, logs? [09:59] low-graphics mode [10:00] http://pastebin.com/ebwTGe1C [10:01] here's the previous one http://pastebin.com/yRpBX0jA [10:02] it's happy about it though [10:02] afaict [10:03] so where does it go wrong? :S [10:04] beats me [10:04] can you paste correct log too? [10:05] with this kernel? [10:05] um, xserver [10:05] sure [10:05] * mlankhorst has the feeling it fails somewhere else in a similar fashion [10:05] this matches my old tests, so there's nothing new [10:07] [ 5.162] (II) intel(G0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen ) [10:07] is it a hybrid? [10:07] no [10:07] ivb sdp [10:08] the package is from the archive [10:08] here's a working one http://pastebin.com/kYRdDYv4 [10:09] it's saying G0 though [10:09] which is weird [10:10] iirc that was graphics offload [10:11] * mlankhorst rechecks [10:11] just (0) with the working one [10:13] yeah but what is it trying to bind to.. [10:13] [ 4.779] (==) Matched intel as autoconfigured driver 0 [10:13] [ 4.779] (==) Matched intel as autoconfigured driver 1 [10:13] o.O [10:14] oh well, both have that [10:15] when it fails plymouth doesn't have a chance of showing the splash, it's showing vt1 instead [10:16] but still would like to try with it disabled, can't remember what to put on cmdline [10:16] removing splash isn't enough [10:18] plymouth.enable=0, maybe [10:20] tjaalton: what if you remove the drmSetMaster call from plymouth? :p [10:20] it will probably fail [10:20] just checking if the race is gone then [10:22] I'll try without plymouth a few times, first was successful [10:22] or something like in activate if (!ply_terminal_is_active (backend->terminal)) return; [10:22] probably src/plugins/renders/drm/plugin.c or something [10:22] that should hopefully be enough to prevent it from stealing master [10:24] ha, failuer [10:24] -re [10:24] when [10:24] [ 4.765] drmSetMaster failed with -1(Operation not permitted) [10:24] without plymouth [10:25] o.O [10:26] http://pastebin.com/HzXGPRMS [10:28] oh duh [10:28] drmsetmaster doesn't return err code [10:30] tjaalton: pushed new version [10:31] my guess is it will fail with -EINVAL, lets see >:X [10:32] I'm hoping for -EINVAL, in fact [10:33] if so, I'll ask you to test a kernel patch [10:36] building [10:40] bah, plymouthd _was_ still running, I'll disable it harder [10:41] that's fine, I just want that error again :P [10:41] alright [10:43] [ 4.901] drmSetMaster failed with 22(Invalid argument) [10:43] yay [10:43] let me grab the raring kernel [10:44] guess I need it too?-) [10:44] oh I have it.. [10:44] is a .patch good enough? [10:44] yep [10:50] tjaalton: http://paste.ubuntu.com/5607392/ [10:52] blergh should probably have fixed it, missing fops_put(old_fops); ah well [10:52] wont be able to load drm module :p [10:53] the last hunk failed to apply [10:53] I'll try 3.8 ish [10:54] applies cleanly against 3.8.0 here [10:57] http://paste.ubuntu.com/5607407/ [10:57] not -12.21 [10:57] is that 3.8 kernel? [10:57] yep [10:58] maybe .2 or such [10:58] I'll try v3.8.x branch then [10:59] still applies cleanly o.O [10:59] just apply with hand, it's a small patch [11:00] idea is that f_op gets replaced only once, and not reset on failure [11:00] and then it drops drm_global_mutex before calling f_op->open [11:00] drm_open re-takes global_mutex to prevent races [11:01] hah [11:01] UBUNTU: SAUCE: drm -- stop early access to drm devices [11:01] that's a nearly three year old patch.. [11:02] why it didn't apply [11:02] mind reviewing that one? [11:03] zap it [11:03] this solution *should* work better [11:03] and apply yours? [11:03] yeah [11:03] k [11:04] wonder if that patch is what's causing the race in the first place.. [11:04] nah it's a fail attempt to work around it [11:04] then again maybe [11:05] though I would expect open to fail in that case with -EAGAIN [11:05] don't recall having this bug before maybe a year ago [11:06] I think it would still fail with that workaround because it's not complete [11:06] just taking global mutex seems to be a reasonable fix :p [11:07] it could otherwise return the second open call before firstopen is called in drm [11:09] building [11:10] hm or worse, possibly before load finishes [11:11] only it wouldn't happen on first open, but if 2 devices open in parallel, like xorg and plymouth [11:12] first one would nicely block on global_mutex, second one would race ahead without any locking at all [11:31] hmm no kms on vt [11:31] o.O [11:31] drm failed to load? [11:31] no it was fine [11:32] second boot, kms fine, vt change and the mouse cursor follows :) [11:33] and can't find the greeter again [11:34] restart lightdm and it's fine [11:37] ha, failure [11:38] was afraid of that, meh :/ [11:38] mlankhorst: same as before [11:38] still -EINVAL? [11:38] yep [11:38] on setmaster right? [11:38] [ 4.856] (II) config/udev: Adding drm device (/dev/dri/card0) [11:38] [ 4.856] drmSetMaster failed with 22(Invalid argument) [11:38] [ 4.861] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64 [11:39] was afraid of that [11:40] tjaalton: could you add a printk to drm_setmaster_ioctl to find out which exactly it triggers on? [11:40] where? [11:40] drm_stub.c === MonsterKiller_ is now known as MonsterKiller [11:49] I'm hoping it's complaining about file_priv->minor->master, in which case I should revive the first part of bryce's attempt [11:49] building [11:50] or better yet, plymouth should not call drmsetmaster and just bug out early if it didn't get master, it lost to xorg-server :P [11:51] or just wait for the system compositor.. [11:57] http://paste.ubuntu.com/5607513/ [11:58] could you try that? [11:59] so not the printk stuff? [11:59] could keep it, but this is for plymouth to not take master if not on active vt [11:59] at least, I guess it works like that === popey_ is now known as popey [12:20] mlankhorst: didn't try the plymouth patch yet, but the failing check was "if (file_priv->minor->master)" [12:21] good, plymouth one is probably the fix [12:21] I hope [12:21] funny that it follows the same pattern. first boot I get the cursor-on-vt issue, second one is fine, third one fails [12:22] fails with failsafe (hah) [12:23] resetting or full power off? [12:23] reset [12:30] mlankhorst: nope, still failed [12:31] I guess I'll revive the spin patch on setmaster then [12:41] pushed [12:42] tjaalton: can you retest xorg-server with the patch refreshed patch? [12:43] building [12:50] hm, it's probably not normal that on nearly every boot I have dmesg full of ext4_orphan_cleanup [12:50] ..messages [12:55] [ 4.888] (II) config/udev: Adding drm device (/dev/dri/card0) [12:55] [ 4.888] (II) spinning! [12:55] [ 5.111] (--) PCI:*(0:0:2:0) 8086:0162:8086:2211 rev 9, Mem @ 0xafc00000/4194304, 0xc0000000/268435456, I/O @ 0x00002000/64 [12:55] works [12:55] \o/ [12:56] now reset the rest to previous state, and see if it still works? [12:57] eg default plymouth and kernel [12:57] yep [13:00] * radeon_driver_firstopen_kms - drm callback for last close [13:00] void radeon_driver_lastclose_kms(struct drm_device *dev) [13:00] :D [13:14] works [13:17] now I have the mouse cursor on top of a vt (blinking cursor on top-left), heard the bongos [13:18] it didn't spin, but the intel driver spent half a second on "something" [13:18] [ 4.950] (++) using VT number 7 [13:18] [ 5.451] (II) intel(0): SNA compiled: xserver-xorg-video-intel 2:2.21.4-0ubuntu1 (Timo Aaltonen ) [13:18] could it be plymouth? :P [13:19] could, I enabled it again [13:19] booted fine a couple of times [13:19] presumably plymouth shouldn't attempt to attach if xorg-server ended up starting [13:20] could you try with the plymouth patch? [13:22] now I just got a blank screen [13:22] fun :/ [13:22] root 1638 1339 0 15:21 ? 00:00:00 plymouth --ping [13:23] plymouth doesn't exit [13:23] can you attach to plymouthd, see if it's stuck on something? [13:23] [+0.01s] DEBUG: Waiting for ready signal from X server :0 [13:23] [+0.01s] DEBUG: Stopping Plymouth, no displays replace it [13:24] from lightdm.log [13:25] ply_terminal_deactivate_vt [13:25] http://pastebin.com/C9wvXrF9 [13:25] I need to run -> [13:30] boo it needs debug symbols [13:32] oh that's from lightdm [13:40] blargh I need some way to reproduce this if I want to fix it :/ [13:54] boooo this one's too slow === ogra_` is now known as ogra_ === yofel_ is now known as yofel === maxb_ is now known as maxb [18:22] https://bugs.freedesktop.org/show_bug.cgi?id=62198 gen3 possibly messed up in x-x-v-intel 2.21.4 if anyone comes across corruption bugs on them [18:22] Freedesktop bug 62198 in Driver/intel "x11-drivers/xf86-video-intel-2.21.4 and transparency" [Normal,Reopened] [18:24] i'll check it out [18:24] or maybe not [18:24] forget 965gm is gen4 [18:25] my eee is gen 3 :P [18:25] I'll test tomorrow [18:29] Duke`_: probably what you're hitting [18:34] hum the last two updates seems ok for me [18:36] I remember having a glxgears with transparent background, instead of black [18:39] ok, I just installed 2.21.4, going to reboot [18:41] Duke`: ah sorry, another bug then [18:42] i updated edgers right after you complained in case it was a transient bug, so much changes every day and i hadn't for a week [18:42] eh ;) [18:43] the 20130301 version was terrible, X totally broken [18:44] black screen and it was hard to switch to a VT [20:41] dear ubuntu-x people [20:42] nvidia-current 304.84 in the precise ubuntu-x-swat PPA depends on xserver-xorg-core [20:42] but the new https://wiki.ubuntu.com/Kernel/LTSEnablementStack depends on xserver-xorg-core-lts-quantal [20:43] so they can't be readily installed together [20:43] (and maybe shouldn't :) [20:44] I haven't been able to find any more information on this [20:44] except these gentlemen on askubuntu who ran into the problem: http://askubuntu.com/a/257889 [20:44] will ubuntu-x-swat stick with the current situation, or are there plans for compatibility with the LTSEnablementStack? [20:46] what does the lts stack buy you if you're using nvidia's driver anyhow? [20:47] I'm not sure yet. :) [20:48] but currently if you install bumblebee on a 12.04.2 system, X doesn't startup anymore [20:48] that would be reason #1 to clear things up [20:48] also, bumblebee systems have Intel graphics as wel [20:48] l [20:49] (the LTSEnablementStack seems to be default on new 12.04.2 installs. I just got burned by this problem.) [20:49] sudo apt-get install xserver-xorg-lts-precise :) [20:50] yeah bumblebee should probably update their depends [20:50] that'll downgrade you back to the older stack [20:50] it's not bumblebee [20:50] bumblebee only depends on nvidia-current [20:50] but nvidia-current depends on xserver-xorg-core [20:50] is there no solution possible where the enablement stack is also supported? [20:51] don't use the ppa? [20:51] one needs the PPA if one has a NVIDIA 7xx no? [20:51] (this laptop has NVIDIA GeForce 710m) [20:51] burp, ah. mlankhorst was working on getting that resolved. Check with him. [20:52] well there are other versions available on precise [20:52] if bumblebee depends on nvidia-current then fix that [20:52] the nvidia driver is whats messed up in the ppa [20:53] sure [20:53] but why use the ppa? [20:53] bjsnider: ya didnt pick up tseliot's recent packaging changes it looks like [20:53] because newer blob drivers actually are worth upgrading to? :P [20:53] and there's nvidia-310, no? [20:54] 304.84 is still newer [20:54] probably doesn't matter for this hw? [20:55] so should I not want to install the latest nicely packaged nvidia binary drivers on this Ivy Bridge i7 with NVIDIA GeForce 710m in Optimus configuration? [20:55] it fixes a kde logout problem, xrandr rotation, and speeds up font rendering, perfectly valid reasons to want to update it.. [20:55] It felt like a logical thing to do at the time. [20:56] ok then, so wait for it to get fixed :) [20:56] :) [20:56] thanks for the heads up it was broken [20:56] I should probably double-check if it has been reported and if not report it, no? [20:56] burp: nah its not a distro bug, reporting it here was right :) [20:57] ok great thanks! [21:11] bjsnider: patch incoming for fixing the precise blob depends [21:12] bjsnider: http://paste.ubuntu.com/5608946/ [21:18] burp: just uploaded it, should be up in a few hours [21:19] wow, that's awesome, thank you very very much! [21:24] Sarvatt, is it just in precise? [21:25] bjsnider: it's only needed for precise, unless you want to backport the enablement stack to quantal ;)( [21:26] bjsnider: yeah, its a pain in the rear i know :( [21:26] but you could probably harmlessly sync those changes back to later [21:26] could just make them all except precise then make the precise at the end slapping that patch on though [21:27] mlankhorst: except he's still doing lucid blobs even :) [21:27] o.o [21:27] would need to extend the number of abis it provides [21:27] not for much longer? [21:27] burp, you have which chip? [21:27] i can't find a record of that one [21:28] bjsnider: rebadged 620m [21:28] http://www.notebookcheck.net/NVIDIA-GeForce-710M.84746.0.html [21:28] he shouldn't be using the ppa then [21:28] too new [21:29] only geforce 6k/7k hardware [21:29] I shouldn't? [21:29] burp: does it work? :P [21:29] hehehe [21:29] it seems to! [21:30] I'm only just installing the thing [21:31] but optirun glxspheres is doing the right thing much faster than the intel is doing it [21:31] -310 probably doesn't even work on it since the one in precise is so old [21:31] good sign [21:31] Sarvatt, :-/ [21:32] cancel that [21:32] actually the intel with vblank_mode=0 is much faster than than optirun [21:32] hah [21:33] try optirun glxinfo and see if it says nvidia [21:33] it does :) [21:33] OpenGL Renderer: GeForce 710M/PCIe/SSE2 [21:33] vs OpenGL Renderer: Mesa DRI Intel(R) Ivybridge Mobile [21:33] nvidia gives 120+ frames per second [21:34] intel almost 200 [21:34] :) [21:34] I sure hope that nvidia is sleeping most of the time [21:34] it has to copy twice [21:34] shees I should probably get me a real irc client [21:34] nobody said optimus worked well [21:34] * mlankhorst tests on lapptop [21:35] on a real app it'd probably be much better :) [21:35] I'm just happy that there's something with which I can keep it sleeping [21:36] lemme try primus just for reference [21:36] a much more respectable 160+ frames per second [21:38] I'm actually really happy with this cheapskate performance laptop so far [21:38] if anyone's interested [21:38] Acer V3 571G with Full HD IPS display (very pretty), Intel i7 quad core (real quad), 8G RAM and big slow hard disk for 800 eurobucks [21:38] seems to run ubuntu 12.04.2 fine! [21:39] (no I'm not selling) [21:39] * mlankhorst wonders where you get glxspheres from [21:39] mesa demos, we just dont package it [21:39] ah [21:39] jeez [21:39] on this system it seems to come from virtualgl [21:39] * mlankhorst builds [21:40] * burp wonders what IRC client is en vogue these days [21:40] irssi still? or something else? [21:40] oh nope, its packaged with virtualgl [21:40] icechat? [21:41] err, seems to be windows? [21:41] dno [21:41] it does say "the chat cool people use" [21:42] I see what they did there [21:46] hm guess you're right [21:46] ugh c# too [21:49] 275.781442 frames/sec - 289.647733 Mpixels/sec [21:49] what graphics? [21:49] radeon and i915 [21:51] 76.287995 frames/sec - 80.123756 Mpixels/sec whee ultrabook hd4000 :) [21:52] was with DRI_PRIME=1 so it rendered on the radeon [21:52] * mlankhorst tries i915 [21:52] erm native radeon* [21:54] oh 32 bit version is much faster [21:55] how do I kill off vblank? [21:55] vblank_mode=0 [21:55] that doesn't seem right :p [21:56] oh.. right, no syncing between i915 and radeon probably [21:56] isn't that what you're working on........? [21:56] * Sarvatt coughs [21:57] it's tear free! [21:57] but that doesn't mean userspace performs its own sync correctly [21:57] woohoo, starcraft 2: heart of the swarm time :) [21:58] lets see if this bugger works in wine [22:00] Sarvatt: anyway syncing should work tear free, but if both ddx drivers don't tell that they wrote or read something, you could have 2 reads off the same frame [22:01] so it shows as higher fps ;P [22:01] * mlankhorst will be sure to break wine this friday [22:25] mlankhorst: Hey, do you know off hand what would happen if I close() a prime dma-buf fd after importing it? Do I lose access to that buffer?