00:01 trippeh_: no dice. but didnt crash.
00:03 imirkin_: oh well. i think we might have to flip some extra bits on somewhere
00:04 imirkin_: if you want to help make this work for nouveau, you could record a mmiotrace of the nvidia blob doing the modesetting
00:04 imirkin_: or maybe skeggsb has a screen like that sitting around, but has only been testing DP on it
00:04 trippeh_: mmiotrace works in Linux right?
00:04 imirkin_: yes
00:05 imirkin_: hold on, let me see if there was a commit that went into 4.10 that enables it first
00:05 skeggsb: i've never seen a hdmi 2.0 display as of yet, it's entirely possible more stuff needs to be figured out for it
00:05 skeggsb: mmiotrace would definitely be useful
00:05 skeggsb: and vbios
00:06 trippeh_: I'm fed up with the random ~1sec hangs when windows change focus in the binary blob driver (at least with Unity)
00:06 trippeh_: figured I'd spend a few minutes getting nouveau up and running
00:06 imirkin_: well, note that accel-wise, perf will suck because you're running at the lowest perf level
00:07 imirkin_: and nvidia is not releasing the signed pmu blob that's required to make reclocking work
00:07 trippeh_: as long as it is fast enough to display video :-)
00:07 imirkin_: no hw video decoding either
00:08 trippeh_: it has a beefy cpu - so that is fine.
00:08 trippeh_: at least for now, before HEVC starts taking off.
00:09 imirkin_: that stuff is murder on cpu's
00:09 imirkin_: but then again, so was MPEG2, with 1080i @18mbit
00:10 trippeh_: skeggsb: this is a TV, it is more common there
00:10 trippeh_: HDMI 2.0 that is.
00:12 RSpliet: skeggsb: btw, haven't gotten round to it, but GK107 on Wayland seems to get transparency wrong in various cases
00:13 trippeh_: imirkin_: haha yeah, it feels like the old days all over again
00:13 trippeh_: this system seems to handle up to 30fps 4K HEVC OK in software
00:14 trippeh_: anything above that gets iffy quick
00:14 skeggsb: RSpliet: gtk apps?
00:14 RSpliet: Pidgin in particular, but yes
00:14 RSpliet: Fedora 25
00:14 skeggsb: yeah, i noticed that here too, didn't know if it was our bug or someone else's
00:15 skeggsb: for some reason, i have no working glx under wayland either
00:15 skeggsb: passed it off as being related somehow :P
00:15 RSpliet: skeggsb: how do I test whether that works? glxgears runs fine
00:15 skeggsb: skeggsb@nisroch ~/git/mesa $ glxinfo
00:15 skeggsb: name of display: :0
00:15 skeggsb: Error: couldn't find RGB GLX visual or fbconfig
00:15 skeggsb: that's what i get :P
00:16 RSpliet: http://paste.fedoraproject.org/507590/14819337/
00:16 skeggsb: yeah that's fine
00:16 RSpliet: that might just be your set-up then :-D
00:16 skeggsb: pretty sure you're right :)
00:16 imirkin_: skeggsb: you need X for glx
00:17 imirkin_: skeggsb: like Xwayland, presumably
00:17 skeggsb: yeah, Xwayland is working, just not the glx part
00:17 imirkin_: hm ok. i got nothin'
00:17 imirkin_: trippeh_: if you decide to make a mmiotrace, this is a good set of instructions: https://wiki.ubuntu.com/X/MMIOTracing
00:19 RSpliet: skeggsb: pidgin looks fine on Intel HD 520
00:19 trippeh_: cool, thanks
00:19 skeggsb: ok, so, i'm not entirely sure, but how does gtk render under wayland? gl?
00:19 airlied: cairo/sw
00:20 RSpliet: I'll just take that from airlied, but DRI_PRIME=1 pidgin renders it the same
00:20 RSpliet: and I'm sure there's a GM107 hooked up there :-)
00:21 skeggsb: airlied: any ideas how we'd fuck up the transparency thing in that case?
00:21 RSpliet: it's no longer exa?
00:21 imirkin_: RSpliet: wayland uses glamor
00:21 airlied: something interprets alpha wrong somewhere
00:22 imirkin_: or rather, Xwayland
00:22 airlied: takes RGBx maybe and actually does RGBA
00:22 airlied: or vice-versa
00:22 skeggsb: imirkin_: well, if it's cairo/sw, i'd presume that's not relevant :P
00:22 imirkin_: skeggsb: why not?
00:22 imirkin_: still gotta draw the picture on there
00:22 airlied: likely a nouveau bug aorund gbm
00:22 airlied: or somewhere like that
00:23 skeggsb: imirkin_: sw rendered?
00:23 imirkin_: skeggsb: the sw renders an image
00:23 imirkin_: skeggsb: that image has gotta go up on the screen somehow
00:23 imirkin_: skeggsb: the compositor does a GL blit of it, probably
00:23 imirkin_: or who knows what
00:23 skeggsb: presumably that'd be the whole window, not individual icons etc
00:24 imirkin_: if the sw produces a RGBX image, and nouveau treats it as RGBA. for example.
00:27 trippeh_: I'll take a look at mmiotrace tomorrow, I think. bedtime now. thanks for the help so far
00:28 RSpliet: imirkin_, skeggsb: http://nouveau.spliet.org/wayland-trans.png - just so we all are talking about the same issue :-)
00:29 RSpliet: see the background on the tabs in pidgin
00:29 imirkin_: what's the issue?
00:30 airlied: picture looks fine to me :)
00:30 skeggsb: imirkin_: black around some of the icons on the tabs
00:30 imirkin_: ohhh i see
00:30 skeggsb: notice the difference with the first tabs, and the end ones
00:30 imirkin_: yep, got it
00:30 RSpliet: and emoticons
00:30 skeggsb: i see similar things in deluge
00:30 imirkin_: ok, so you're getting black when you were supposed to get transparent
00:30 imirkin_: which means we're treating RGBA as RGBX, potentially
00:31 philhug_: "BIT table 'A' not found" on GTX1060. is this expected?
00:31 imirkin_: or we're blitting things wrong - that could happen
00:31 skeggsb: philhug_: yep, ignore it, i'll get around to silencing those at some point
00:33 RSpliet: imirkin_: it's not reliably black - the "Randomdata" tab is half-misrendered
00:34 RSpliet: or rather
00:34 RSpliet: http://nouveau.spliet.org/Wayland-jetpack.png
00:35 RSpliet: it's related to uninitialised buffers?
00:36 imirkin_: weird. dunno. would require debugging.
00:36 imirkin_: make me an apitrace i can repro with and i'll have a look
00:36 imirkin_: otherwise you're on your own
00:36 imirkin_: (or at least without my debugging assistance)
00:38 RSpliet: heh, fair enough. Not sure though if it's apitracable if we're talking about cairo/sw, but unless skeggsb beats me to it (likely, I'm on holiday very very soon) I'll see what I can do
00:38 imirkin_: the idea would be to apitrace your compositor
00:38 imirkin_: which should at least tell us wtf is going on
01:50 abbemsly: Where can I find out if my graphics card is supported?
01:50 abbemsly: I'm pretty sure it is (gtx 970)
01:52 abbemsly: NV124 (GM204) GeForce GTX (970, 980)
01:52 abbemsly: found it
01:52 abbemsly: do any of you have this card? if so, how well is it supported. I dont like closed source, anything
01:53 abbemsly: and what i mean by "how well is it supported" i mean how is performance (2d) and if 3d is supported
08:32 mupuf_: that's a first, reclocking makiing the gpu more stable :o
11:17 karolherbst: if somebody wants to try out my dynamic reclocking branch: use better_dr and you still have to select the pstate, but the engine clocks should be set automatically
11:18 karolherbst: I would be interested how it reacts to spikey loads and normal desktop usage
11:19 karolherbst: especially because I have the timer be 100ms and would like to know how noticable the lag is in those situations
11:25 Yoshimo: well a delay of over 100ms in an online game is noticed
11:42 karolherbst: Yoshimo: not "delay"
11:42 karolherbst: Yoshimo: but delay until the clocks are changed
11:43 karolherbst: don't know, I guess with most games the clocks would be at max all the time anyway
11:43 karolherbst: it really only matters for things running at vsync speed and then there is a sudden spike in performance needed
11:48 karolherbst: well, I have a HDMI2 display here, but no desktop system to plug in gpus yet...
11:49 karolherbst: mupuf_: ohh that actually happens from time to time when the default state isn't perfect, even had a situation where after reclocking the voltage increased a little for the same clocks
11:49 mupuf_: hmm
11:50 karolherbst: it shouldn't happen though
11:50 mupuf_: yeah
11:50 mupuf_: it is wonderful fuckup though :D
11:50 karolherbst: and I assume those things are super rare and the differences are super small
11:50 mupuf_: because his lowest perf lvl has a voltage too low
11:50 karolherbst: yeah
11:50 karolherbst: my default is 0.05V too high :D
11:50 karolherbst: but this is fine usually
11:50 mupuf_: I assume this is also why they decided to characterize each gpu
11:50 karolherbst: just annoying for laptops
11:50 karolherbst: yeah, most likely
11:51 karolherbst: usually the default voltage is pretty close to the correct one
11:52 karolherbst: it is just silly, that some GPU models come with shitty vbios
11:58 mupuf_: yop
12:04 Yoshimo: well the official nvidia code has to handle that as well
12:04 karolherbst: they do by reclocking the gpu
12:29 karolherbst: okay, hang in tf2 now :)
12:29 karolherbst: no checking updated mesa
12:37 karolherbst: ohh, I got a CTXSW_TIMEOUT
13:37 karolherbst: mupuf_: we also need to implement underclocking :(
13:45 karolherbst: there are some pstates where they have lower min clocks than lower pstates
13:45 karolherbst: I know how to read out those ranges nvidia uses, but we have no cstates for them
14:04 thican: Well, hello again everyone
14:05 thican: I was trying to make my own patch from the 4.10 code source for nouveau
14:05 thican: but unfortunately, it fails to compile because I always miss some files
14:06 thican: So, I wonder if there is a dedicated branch or repo just with Nouveau's stuff, isn't it?
14:07 karolherbst: thican: what kernel are you on?
14:07 thican: I am on 4.8.11, but I was working on 4.9
14:07 thican: .0
14:08 thican: but I don't want to try the unclosed 4.10 kernel currently
14:08 thican: So, I was just trying to make my own patch just for Nouveau from 4.10
14:08 karolherbst: drm-next
14:11 thican: this? https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=2cf026ae85c42f253feb9f420d1b4bc99bd5503d
14:16 karolherbst: yeah
14:32 thican: Strange, I don't understand why the command patch doesn't find any of the targeted files … https://paste.pound-python.org/show/x2KQTFM5HZZALHTiafAQ/
14:32 thican: "drm-next_GP106_support.patch" is the name I gave to the patch frome the previous link
14:33 thican: *from
14:33 karolherbst: you won't need the patch with drm-next
14:35 thican: Oh, I tought I had to patch it myself
14:35 thican: well, I guess I still want the kernel support from my distribution
14:35 thican: Hence the patch.
14:36 thican: but this is odd it fails, when the files actually exist
14:54 iterati: Hi. There is a known issues with eclipse and nouveau that it doesn't show the cursor correctly ? Not sure if it's general mesa issue, though.
14:55 imirkin: iterati: no one's reported such a thing yet, doesn't mean it's not a nouveau issue.
14:57 imirkin: thican: you're best off grabbing dave's drm-next branch
14:57 imirkin: thican: don't try to generate patches. it'll end in tears. just use the branch.
14:57 imirkin: and life will be good
14:57 iterati: imirkin: yeah, with the nvidia driver the issues is not there. I use the modesetting driver, though. And the cursor doesn't blink somewhat. It's like it leaves white vertical lines if you try to select a line as well.
14:57 thican: I didn't generated it, I just took it from the page :/
14:57 thican: *generate
15:03 abbemsly: I'm confused on the whole "nvidia vs nouveau" thing. Is the issue just as simple as nvidia only releasing binary blobs instead of being open-source? Or does it go farther than that?
15:05 imirkin: abbemsly: no, that's about it - nvidia expects you to download a binary off the interwebs and expects that you'll be happy running it inside of your kernel
15:07 abbemsly: well, if im not happy with that, is there any docs where I can configure nouveau to run nicely with GTX 970?
15:07 imirkin: is it a GTX 970 with 4GB of vram?
15:08 abbemsly: yeah the lawsuit one. 4gb/3.5gb
15:08 imirkin: yeah ok - that one doesn't have working accel at all on nouveau
15:08 abbemsly: 2d or 3d?
15:08 imirkin: there's only one accel.
15:08 abbemsly: oh
15:08 imirkin: and it ain't working.
15:09 imirkin: (everything is handled by the "PGRAPH" engine which can present 2d- and 3d-related operations)
15:09 imirkin: other GM20x chips are hampered by the fact that nvidia has chosen not to release the firmware required to perform reclocks.
15:09 imirkin: in the past, nouveau developers could write their own
15:10 imirkin: but start with GM200, the firmware has to be cryptographically signed
15:10 abbemsly: so if you guys got the firmware needed for reclocks, it would help a ton
15:10 imirkin: not the GTX 970 + 4GB case - that's an unrelated issue. but for GM20x - yeah, it'd be nice.
15:10 imirkin: but i doubt it'll happen ... ever.
15:11 abbemsly: i dont understand why nvidia made their drivers closed source
15:11 abbemsly: in the first plcace
15:11 abbemsly: *place
15:11 imirkin: every business tries to cling to IP as if it's what will cause it to succeed
15:14 abbemsly: so it would be more beneficial to use the nvidia drivers
15:15 imirkin: if that's an option for you, sure
15:15 imirkin: i don't personally consider running blobs i download from the internet in my kernel as an option.
15:16 imirkin: every so often someone will switch to nouveau because the nvidia driver doesn't handle their use-case well, but i suspect that's rare
15:16 abbemsly: im no gamer
15:16 imirkin: stuff to do with multiple displays, integration with other GPUs, etc
15:16 abbemsly: but i have two displays and there are little graphical aspects of gnome i would like to keep/see
15:17 huehner: imirkin: i noticed that with debian 4.8 on my gm206 (960) with missing firmware now module init fails (so screen does not light up)
15:17 huehner: is that some intentional recent change? as i think before modesetting part worked without firmware a while ago (but not sure if remember that correctly)
15:18 imirkin: huehner: afaik that's SUPPOSED to work
15:18 abbemsly: also, if nvidia made their drivers open source, would nouveau be a thing anymore?
15:18 imirkin: the init of the gr unit should fail, but the rest should keep working
15:19 imirkin: abbemsly: probably... nouveau's in the kernel, so unless there's a decision to wholesale drop nouveau and integrate nvidia's driver, nouveau would remain.
15:19 huehner: imirkin: thx, i'll try to re-test that later again to be sure and report a bug then
15:19 imirkin: abbemsly: and in fact, nvidia has been contributing to nouveau for things where they care about upstream support, like GK20A and GM20B (the newer tegra parts)
15:25 abbemsly: last question, would it be wiser to download nvidia driver from the internet, or find a nvidia support in a distribution (in this case, its in debian-backports)
15:26 imirkin: my experience is that it's best to play nice with a distro
15:26 imirkin: rather than try to go behind the back of its package manager
15:27 abbemsly: i used to just dl from the official website, but i recently found out that it was supported in backports
15:27 abbemsly: thanks
15:27 abbemsly: that will be all, good luck
15:34 imirkin: huehner: sounds good - all that logic has been getting a bit of churn, so it may be helpful to check out what's in https://github.com/skeggsb/nouveau/commits/master
15:57 karolherbst: does anybody know if skeggsb published his branches with the concurrency fixes?
16:00 imirkin: i think he's largely stopped publishing his pending work
16:01 imirkin: and i doubt that one is in any kind of working state
16:01 imirkin: and you can thank all the distros trying to integrate mine for me taking mine down.
16:41 karolherbst: hakzsam: did you forget to turn reator off?
16:42 hakzsam: yeah looks like I forgot
17:46 thican: Wait, why does the kernel version from branc drm-next in repo https://cgit.freedesktop.org/~airlied/linux/ says "4.9.0-rc8"?
17:46 thican: *say
17:46 thican: why isn't it updated to the current 4.9.0?
17:47 thican: I just made a silentoldconfig from a 4.9.0, and now I have 4.9.0-rc8
17:47 karolherbst: it doesn't matter
17:47 thican: okay then
17:48 karolherbst: it just say, that the last merge was after the rc8
17:48 thican: By the way, why can't I find the whole patch from branch 4.9.0 to the last current commit from drm-next?
17:49 karolherbst: what do you mean?
17:49 thican: I mean, I tought it would be nice to only have the modifications concerning drm-next
17:50 thican: in case we would patch ourself from 4.9.0, for example
17:51 karolherbst: ohh I see
17:51 karolherbst: mhhh
17:51 karolherbst: I think you should be able to merge a 4.9.0 branch ontop of drm-next if you really wanted to
17:52 thican: I am not that skilled :/
17:52 karolherbst: git merge :p
17:52 karolherbst: if there is a merge conflict, then it may get hairy
17:52 karolherbst: but there shouldn't be one
17:52 thican: from my 4.9.0 directory?
17:53 thican: (the command I should execute)
17:53 karolherbst: no, you need both remotes inside your git repository of the kernel
17:58 thican: Hmmm, it seems the directory of the kernel 4.9.0 from Gentoo's mirrors doesn't have the git repository
17:59 karolherbst: nope
17:59 karolherbst: well
17:59 karolherbst: you can simply use the drm-next tree for now
17:59 karolherbst: and wait until the rcs are out for 4.10
17:59 karolherbst: takes 2 weeks usually
18:00 karolherbst: rc1 might have heavy issues though
18:00 karolherbst: so I would start with rc2 or rc3
18:00 thican: yes, I read Linus will close the window the 23rd
18:34 thican: So, I just compiled and installed the kernel from drm-next: unfortunately, it doesn't work, still with the error message "unknown chipset"
18:34 thican: code 137000a1
18:35 karolherbst: huh
18:35 karolherbst: dmesg then
18:35 thican: I did, for reading this message
18:36 karolherbst: yeah, but I want to see the full dmesg
18:36 thican: do you need more informations from my system?
18:36 thican: ah, okay
18:37 karolherbst: ohh wait
18:37 karolherbst: it is a 1050?
18:37 karolherbst: it's a gp107, right?
18:39 thican: 1050 Ti
18:39 thican: I don't recall :/
18:39 karolherbst: both are gp107 actually
18:39 karolherbst: mhhh
18:40 imirkin: GP107 is entirely unsupported by nouveau atm
18:40 karolherbst: yeah
18:40 imirkin: GP106 support went in recently
18:40 imirkin: but only for modesetting
18:40 imirkin: accel will have to wait until nvidia feels like making it available for nouveau
18:41 thican: dmesg: https://paste.pound-python.org/show/ruHD9cRLxzaDa19xSXNo/
18:41 karolherbst: go107 is a die shrink as well
18:41 karolherbst: *gp107
18:41 imirkin: which they are in no way incentivized to do
18:41 thican: oh, sad :/
18:41 karolherbst: did anybody try it out on a gp107 already?
18:41 karolherbst: I fear there are significant differences
18:41 karolherbst: but maybe not modesetting related
18:41 thican: do you think it will be available before the end of the window for the kernel 4.10?
18:41 imirkin: i suspect that GP107 should "just work", it's just that ben doesn't have one to verify that no changes need to be made
18:41 karolherbst: thican: fell like trying something out?
18:41 imirkin: thican: no, all the changes have already gone into 4.10
18:42 imirkin: any further enablement will be for 4.11
18:42 thican: karolherbst: I can, yes, just hope it won't burn my stuff :/
18:42 karolherbst: thican: you have to do the same as in the gp106 patch, just for gp107
18:42 thican: imirkin: 4.11? oh, it will be not before March or April
18:42 thican: karolherbst: okay, do you have the link, please?
18:43 thican: let me reboot with my previous card, I am without graphical interface right now :-)
18:44 karolherbst: thican: https://cgit.freedesktop.org/~airlied/linux/commit/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c?h=drm-next&id=1fe487d7d2858265e23f10fa6b4565112f9a17fe
18:44 karolherbst: same struct, just nv137_chipset
18:44 karolherbst: and adjust the .name
18:44 karolherbst: and the second thing has to be case 0x137: device->chip = &nv137_chipset; break;
19:00 thican: okay, I am back
19:04 thican: ah yeah, indeed, it's a GP107 … I don't know why, I tought it was GP106
19:05 thican: karolherbst: so, you mean I have to copy/paste this structure inside the same file, with only 2 modifications?
19:06 karolherbst: yeah
19:06 karolherbst: and add the entry further down so that it gets used
19:06 thican: "nv137_chipset = {" and ".name = "GP107", and the bottom line "case 0x137: device->chip = &nv137_chipset; break;"?
19:06 karolherbst: yeah
19:06 thican: yes :-)
19:07 thican: oh, dumb me, I worked in tmpfs, I have to redownload the repository again …
19:07 karolherbst: :(
19:07 karolherbst: --depth 1
19:07 karolherbst: it speed things up
19:08 karolherbst: if you do a git clone
19:08 thican: ah yeah, thanks, because 1 GB of data is too much
19:09 imirkin: best to just keep a single tree around, then you only do it once and everything else is very much incremental
19:10 thican: I am not very familiar with pure dev, so I did this: git clone -b drm-next --single-branch --depth 1 'git://people.freedesktop.org/~airlied/linux' linux-drm-next-4.9
19:10 karolherbst: you could work with git remotes
19:10 karolherbst: but for that, you already need a cloned linux kernel
19:10 imirkin: yeah, so that minimizes your download today, but makes it useless if you want to grab e.g. a different branch
19:11 thican: okay, I will be careful next time
19:13 thican: By the way, I don't understand why you said it's already over for 4.10, I tought it was until December 23rd
19:15 karolherbst: merge windows is closed for drm in hteory
19:15 karolherbst: *theory
19:17 imirkin: merge window for drm. however merge window for drm development (and all trees) closes when 4.10 opens for merging.
19:17 imirkin: the merge window is to merge the submaintainer trees to linus, not to get work merged into the submaintainer trees
19:18 thican: could you check my modifications, please? :-) https://paste.pound-python.org/show/7jwJZJz1BrnFscRi4u6K/
19:18 thican: (I know it was trivial)
19:18 imirkin: lgtm
19:20 thican: ok, thanks, I am compiling, will again replug the card, and I keep you updated :-)
19:24 karolherbst: nice :)
19:26 thican: By the way, (I might already talk about this a previous day) I have a nasty bug while I use wine with currently one specific application (I don't have a lot to try, though)
19:27 thican: my system freezes exactly 3 secondes after I launch the application, and I have nothing in logs, it's the same as I unplug the power.
19:27 thican: Do you think this is related to a segmentation fault?
19:28 thican: Do you have an idea how I could temper this issue?
19:28 thican: because I noticed my FS was a bit damaged
19:57 karolherbst: thican: well, your drive could be damages
19:57 karolherbst: check the SMART status
19:57 thican: it's a RAID1 device
19:57 thican: and I did, of course :-)
19:57 karolherbst: mhh
19:57 karolherbst: otherwise check the logs
19:57 karolherbst: and dmesg
19:58 thican: about the little broken FS or about the freeze?
19:58 thican: the little broken was just a badly uninstall old kernel sources
19:59 thican: but I saw nothing else, and scanned all the libraries
19:59 thican: about the freeze, this is instant shutdown of the system, while the computer has still power running through it, frezzing the last display
20:01 karolherbst: memory corruption maybe
20:10 thican: I did a memory test, and it's always 3 sec and only happened with this application
20:10 thican: (yet)
20:10 thican: But I didn't do a memory test of the GPU's one :-)
20:21 karolherbst: thican: well, did you try out nouveau on the gp107 yet?
20:26 karolherbst: mupuf_: might wanna take a look and check if this looks okay? https://github.com/karolherbst/nouveau/blob/13f4d91d0d33b2eeea41b86c3cb316ebc2e88726/drm/nouveau/nvkm/subdev/pmu/fuc/perf.fuc
20:39 thican: karolherbst: not yet, it's tidious too switch my cards inside my computer …
20:39 thican: s/too/to/
20:40 thican: poweroff, switch off the power device, unplug, unscrew the panel and the card from the "box", rince and repeat in the other way
22:55 thican: Wow, finaly my computer boots, what a relief, this damn machine wasn't even executing BIOS ...
22:55 thican: but unfortunately, dmesg displays some errors about this new driver
22:57 thican: imirkin (and karolherbst when he/she will come back): https://paste.pound-python.org/show/v9E8IC1wPTf0EpNsPGIQ
22:58 thican: I forgot the last slash at the end
23:15 thican: line 1055: [ 22.868459] nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22
23:56 imirkin: thican: that's expected