00:05 Lyude: hm
00:05 Lyude: gating has changed since a lot of these traces were done
00:09 mupuf: Lyude: hopefully, that helps figuring out what is really important :)
00:09 Lyude: mm, strangely as well they don't touch the delays, but I think they might just check whether or not they need to based on the pre-existing value, then do a two step programming sequence if the delays need to be changed
00:10 Lyude: would be nice to know if this is different with the modern nvidia driver on other people's nvf0s though
00:12 Lyude: or not, there's the delay programming I was wondering about :)
00:16 Lyude: btw: if anyone else has any nvf0 cards, doing an mmiotrace today and putting your results in the vbios repo might help me learn a bit more about this
00:16 Lyude: also mupuf or anyone else: do you have any idea what PTHERM.FECS_IDLE_FILTER is?
00:17 mupuf: isn't that for power gating?
00:17 Lyude: it might be, just wanted to make sure there isn't something else I need to program here for basic level clockgating
00:17 Lyude: (not blcg, cg_ctrl)
00:47 Lyude: does nouveau have any magic macro for looping through a card's subdevs?
00:47 imirkin_: i think that's just aka a regular for loop
00:47 imirkin_: it's an enum
00:48 imirkin_: or you mean the literal subdev ptrs?
00:48 Lyude: imirkin_: yeah, basically I need to do something in the same order as the subdevs are initialized in nouveau; however I can't just stick it onto the end of the subdev init
00:49 imirkin_: look at how device does it
00:50 Lyude: ahhh, i see
02:50 Azur_Lighting: is still possible to reclock? im using a nvidia GT 730 (Fermi)
04:35 imirkin: Azur_Lighting: no reclocking on fermi, sorry
08:10 AndrewR: Hello. Anyone already upgraded to 4.14 ? It seems I have strange issue: my build of seamonkey started to eat much more CPU over few hours of use than on 4.12.0 kernel... Not just seamonkey, but also X itself. There definitely some difference in .config, I enabled audit subsystem in 4.14, yet it usualy enabled anyway ... Guess I should test with fbdev for ruling out nouveau, but then everything will use more cpu by definition ....
09:36 karolherbst: Lyude: so, can you confirm that my mmiotrace patches improve the situation?
10:50 karolherbst: uhm.. and maybe the issue with the secboot thing is, that the interrupts are simply disabled...
10:53 karolherbst: fun...
10:57 karolherbst: mwk: how can I check if an interrupt of a falcon gets routed to the host?
11:11 karolherbst: weird
11:12 karolherbst: 0x140 7fffffff PMC.INTR_EN_HOST => { HARDWARE | SOFTWARE | 0x7ffffffc } (same for 0x144)
11:28 karolherbst: FUN.... indeed
11:29 karolherbst: there is a interrupt waiting to be handled on the SEC2
11:29 karolherbst: but nouveau doesn't get anything
11:29 karolherbst: the hell
11:35 karolherbst: yep, no interrupts whatsoever
11:40 karolherbst: and that isn't just SEC2
11:40 karolherbst: but also TIMER and IBUS
11:44 karolherbst: okay... I am like 99.99% sure this is an issue, I am not 100% sure if this issue is the reason why secboot doesn't work. But it should be one reason of one or more
11:44 karolherbst: there are no interrupts whatsoever
11:44 karolherbst: from nothing
11:45 karolherbst: basically on unloading nouveau something disables those interrupts completly
11:45 karolherbst: and if nouveau gets loaded again, it doesn't get activated
11:45 karolherbst: and we end up not getting any interrupts at all from the gPU
11:47 karolherbst: and with config=NvMSI=0 it works....
12:07 mupuf: karolherbst: well done!
12:07 karolherbst: I guess the msi rearm is wrong
12:07 karolherbst: gp100 writes 0 into 704
12:07 karolherbst: but guess what
12:07 karolherbst: nvidia doesn't touch that reg in my trace
12:11 karolherbst: but nouveau doesn't even try as well...
12:11 karolherbst: well no clue. I don't really feel like digging into all that interupt and msi mess
12:11 karolherbst: not today
12:12 karolherbst: I need mwk now... mabye imirkin also knows this stuff? dunno
12:30 karolherbst: ohh right, we have this: http://download.nvidia.com/open-gpu-doc/pascal/1/gp100-msi-intr.txt
12:48 oday: So, as I said, I passed through my optimus gpu to a vm
12:48 oday: Nouveau initializes it successfully
12:48 oday: But obviously, it has no outputs
12:49 oday: How would I run a vnc server on the vm that's accelerated by that gpu?
12:49 oday: As in, a vnc server that's accelerated by the gpu
12:49 karolherbst: oday: vgl
12:50 oday: Trying that right now
12:52 oday: So, I can't generate a xorg.conf with nvidia-xconfig because I'm not using the nvidia drivers, so I have to write one manually, right?
12:52 oday: For use with virtualgl, I mean
12:53 oday: Found documentation, ignore
12:55 karolherbst: well usually you don't need any xorg.conf
13:42 karolherbst: pmoreau: okay... I think your mesa spirv branch doesn't build anymore, because libclc defines " #define cl_khr_gl_sharing 1" and there is stuff like "SP.cl_khr_gl_sharing = 0;" in mesa
13:43 pmoreau: karolherbst: Maybe? I haven’t had any issues so far, but maybe was I not building against libclc.
13:43 karolherbst: well dunno, maybe
13:44 karolherbst: I think clover depends on libclc, doesn't it?
13:44 pmoreau: It did build last time I tried, and that was after pushing the "SP.cl_khr_gl_sharing" patch.
13:44 karolherbst: mhh
13:45 pmoreau: I think so too, but libclc has always been something I had issues grasping.
13:47 pmoreau: karolherbst: Got bored with the interrupts on the falcon? :-D
13:47 karolherbst: I wait until somebody shows up with proper knowledge about those
13:47 pmoreau: Sounds good :-)
13:48 karolherbst: anyway, super tired right now... I should sleep
13:50 pmoreau: :-/ You got polled too much and didn’t have time to switch to a lower power mode?
14:21 feaneron: karolherbst: did your commit [1] make its way to linux 4.14?
14:21 feaneron: [1] https://github.com/karolherbst/nouveau/commit/6a77db9908bbde2c72c31e562d4e96f9c562b761
14:43 pmoreau: feaneron: It does not look like it’s in 4.14.
14:44 pmoreau: It hasn’t even been merged yet.
14:45 feaneron: ok, thanks
14:45 feaneron: to refrain myself from asking those stupid questions again, may i know where did you actually look at?
14:46 feaneron: i'm checking https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git but there are only merge commits
14:47 pmoreau: https://github.com/skeggsb/nouveau is the (out-of-tree) repo from the Nouveau maintainer, and will contain all the patches that have been merged (but not necessarily yet submitted to the DRM maintainer).
14:47 pmoreau: There is a branch for each new kernel release, containing the commits that will be sent for that release’s merge window.
14:49 feaneron:finally connects the dots
14:51 feaneron: thanks pmoreau, really appreciate it
14:51 pmoreau: No problem :-)
14:51 pmoreau: feaneron: That patch is part of the latest series from karolherbst, which you can find here: https://patchwork.freedesktop.org/series/33967/
14:53 feaneron: great, thanks. so, this patchset goes to skeggsb's tree → drm maintainer tree → linus tree?
14:53 feaneron: (after the reviews, of course)
14:54 pmoreau: Right (I don’t think it goes through any other tree)
14:55 feaneron: got it
14:55 feaneron:silently celebrates with a mug of coffee
14:56 pmoreau: Regarding the DRM maintainer (airlied)’s tree, it lives here: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
14:58 feaneron: it's a fine blend of github, cgit.freedesktop and git.kernel
17:32 imirkin: feaneron: technically it goes through https://github.com/skeggsb/linux, which is a proper linux tree, not an out-of-tree module
17:32 imirkin: however i think ben tends to land things into the out-of-tree module first
17:46 pmoreau: karolherbst: BTW, the incompatibility with libclc, did you hit it by compiling my SPIR-V work, or were you just looking at the code and thought it might break things?
18:14 feep: home!
18:14 feep: tobijk: did I miss anything yesterday night?
18:23 imirkin: gah. looks like the claims of 30bpp support were overstated.
18:25 feep: karolherbst: also hi :D
18:25 imirkin: i just get a black fb =/
18:26 tarragon: mmm.. nouveau magically fixed itself.
18:26 imirkin: skeggsb: looks like XB30 is busted with both a GK208 and G92.
18:26 imirkin: skeggsb: i suspect the LUT isn't doing it any favors
18:27 tarragon: mesa or an application improperly using nouveau can hard lock the entire system.
18:27 imirkin: tarragon: yep, sure can!
18:28 imirkin: even properly using it.
18:29 tarragon: I wasn't aware of this fact, until recently stuff been working smoothly where it previously crashed.
19:00 imirkin: skeggsb: nevermind - XB30 works. modetest was wrong.
19:01 tobijk: feep: i belive its that buggy vcore entry 55, but a bit more debugging on your site where exactly your system generates the "ret" for the error message you are seeing would be nice
19:01 feep: tobijk: I already did that yesterday :p
19:02 feep: ramcfg is 1
19:02 feep: in the timing mapping table, row 1 of entry 0 starts with 0xf
19:02 feep: 15 is bigger than the 12 entries in the timing table.
19:03 feep: hence, ret.
19:05 feep: of course, I have no idea what ramcfg means or how it's determined
19:05 feep: ramcfg_index, rather
19:20 tobijk: meh i should have seen it earlier
19:20 tobijk: feep: do you have the strap_peek value for your vbios
19:21 feep: no, how do I find that?
19:21 feep: oh, it says "Missing strap_peek!"
19:21 tobijk: yep and with it you get the actual selected timing row
19:21 tobijk: *6:0x0000731c: 02 10 40 51 00 02 00 14 04 01
19:22 tobijk: for my bios with that value
19:22 tobijk: imirkin: which reg did we have to poke for strap_peek again?
19:23 tobijk: feep: nvapeek 0x101000
19:23 tobijk: hope karolherbst's github is right :D
19:25 feep: 00101000: 9f40a484
19:26 tobijk: feep: yep you are luck with that one :D
19:26 tobijk: *1:0x000071c1: 0f 34 a0 50 00 02 00 01 00 01
19:27 feep: the point being 0f is too large :P
19:27 tobijk: feep: just making sure why your system bugs and others dont
19:27 feep: orite
19:28 feep: yeah that was bugging me :D
19:46 karolherbst: pmoreau: it broke compilation
19:48 pmoreau: OK. Could you send me how you have everything configured? I’ll try to have a look as soon as I get home.
19:49 karolherbst: pmoreau: just like written on your page
19:50 pmoreau: Eh, hum
19:50 pmoreau: I did follow my own instructions as well, will need to check
19:52 karolherbst: I have 0.2.0 of libclc
19:52 karolherbst: whatever that means though
19:53 pmoreau: I’ll have a look whichever one I have
19:53 pmoreau: I think I have it, but maybe not
19:54 pmoreau: I should have opencl-mesa installed, which requires libclc.
19:54 pmoreau: karolherbst: Do you have a link to the build error/log?
19:54 kherbst: mhh weird, it doesn't use the system CL/cl_gl.h
19:55 kherbst: pmoreau: https://gist.githubusercontent.com/karolherbst/517646ff27b5651ab971a52156bc0a40/raw/b775881bfe0b29e95e77a08f856773fa6b26065c/gistfile1.txt
19:55 pmoreau: Thanks :-)
19:56 pmoreau: Ugh, I think I have seen this one, at some point. But it was some time ago.
19:57 kherbst: maybe you just didn't push the fixes :p
19:57 pmoreau: I am not sure why CL/cl_gl.h gets included
19:59 pmoreau: By “some time ago”, I mean a reaaaalllly long time ago. I might have one or two patches which I haven’t pushed to my branch, but that is the stuff I did on the plane on Sunday.
19:59 karolherbst: mhhh
19:59 pmoreau: Anyway, macros evilness into full play
20:00 karolherbst: does the C people think about adapting constexpr?
20:00 pmoreau: No clue
20:01 karolherbst: would reduce the usage of macros by quite a lot
20:07 tobijk: feep: i have now looked at the available nve7 vbios, and they tend to get worse the older they get, or better the newer they get
20:08 tobijk: and the timing configurations get fixed, i even found one for your 1 configuration line with "ff"
20:08 tobijk: :D
20:08 tobijk: the worst and oldes one
20:08 tobijk: not sure what to do with it
20:08 feep: ah geez, lol.
20:08 feep: fwiw, just skipping the entry doesn't seem to have hurt it any.
20:09 karolherbst: feep: well might be. What we have to figure out is what nvidia does in your situation
20:11 feep: which might be hard, cause I really don't wanna go back to nvidia :(
20:12 karolherbst: well maybe skeggsb knows more
20:14 tobijk: karolherbst: mh we could try to guess the timing entry from the other enries at hand, so if we have 0f -> 01 -> 02 -> 02 the first one is likely 01 :)
20:14 karolherbst: no, we can't
20:14 karolherbst: 0f might mean skip
20:14 karolherbst: might mean something else
20:14 karolherbst: we have to figure that out
20:18 tobijk: feep: in your case, its most likely 01, but a trace of the nvidia driver would be indeed nice
20:19 feep: maybe when it crashes again~
20:19 feep: gonna take advantage of it while it's working
20:20 kherbst: well trying to fix that MSI issue now...
20:21 kherbst: tobijk: no, in his case it is 0f and it stays 0f
20:21 kherbst: we can't just randomy change values like we like it
20:23 feep: I still think it means "skip this entry".
20:23 tobijk: feep: so no timing entry for it? then better use the timing entry for the next or last entry
20:23 tobijk: but none is meh
20:23 feep: yep, and that seems to work fine.
20:24 feep: er, to clarify, skipping that entire block seems to work
20:24 oday: I'm bad at rtfm, apparently
20:24 oday: Couldn't get vgl to work
20:24 tobijk: feep: as it is the entry for Entry 0: 0 MHz - 162 MHz
20:24 tobijk: so it could just happen to work that way because you actually boot with those timings
20:25 oday: I have to run a display manager over vnc, right? But how do you configure a dm to work remote-only?
20:26 karolherbst: oday: yeah, vgl is a bit messy. basically you do something like that: have a X server and VNC server running
20:26 karolherbst: configure vgl to run OpenGL stuff on the X server and transport the stuff to the VNC one
20:26 karolherbst: oday: nono, you do vgl on that server
20:27 karolherbst: not locally or anything
20:27 oday: So I do need an output capable gpu in there?
20:27 karolherbst: no
20:27 oday: Xvfb?
20:27 karolherbst: nope
20:27 karolherbst: just a X server
20:28 oday: I tried just initializing X without any configuration
20:28 karolherbst: wait vgl does it more like doing DISPLAY=$SOME_DISPLAY and copies the stuff over the network to wherever you want to display it
20:28 karolherbst: *what
20:28 oday: I see
20:28 karolherbst: so if your VNC is running on :0 and your X server on :1 it runs the OpenGL stuff on :1 and copies the frames over to your VNC session on :0
20:29 karolherbst: more or less
20:29 oday: And the dm runs on :1?
20:29 nyherba: moved to a
20:29 karolherbst: you don't need a dm
20:29 karolherbst: you can have one on your VNC session if you really want to though
20:29 nyherba: moved to a "free" distro, seeing "nouveau probe of 0000:01:00.0 failed with error -22" and
20:30 karolherbst: but that doesn't matter regarding vgl
20:30 oday: Alright, I see
20:30 nyherba: i keep hitting enter on this laptop keyboard trying to type quotes
20:30 karolherbst: that's also basically what bumblebee does if you have multiple GPUs
20:30 oday: Will try that and report back, thanks for the explanation
20:30 karolherbst: start a second X server on :8 running the drivers of the dedicated GPU
20:31 karolherbst: copy frames over TCP to your main X on :0
20:31 oday: optirun == vglrun?
20:31 nyherba: nouveau 0000:01:00.0: gr: failed to load gr/sw_nonctx
20:31 nyherba: any ideas?
20:31 karolherbst: oday: yeah, with some fancy extra stuff
20:31 oday: Cool
20:31 karolherbst: nyherba: what GPU?
20:31 nyherba: karolherbst: nvidia gtx 970
20:31 karolherbst: nyherba: full dmesg please
20:31 oday: So if I wanted to run bumblebee on my host, I could just manually remove the xdm dependency and have it still work
20:32 nyherba: karolherbst: well if I don't boot with nomodeset it just freezes and I can't do anything
20:32 karolherbst: oday: well, bumblebee requires two OpenGL contexts
20:32 oday: Which I can start manually?
20:32 karolherbst: nope, because you don't get OpenGL with VNC in the first place
20:32 nyherba: karolherbst: not sure if I can get dmesg output from a previous boot
20:32 karolherbst: bumblebee just works if both side provides OpenGL
20:33 karolherbst: I just wanted to give you the right idea how the VNC situation should be like
20:33 oday: Alright, I see
20:33 oday: Setting that up right now
20:34 nyherba: i can only get to login with 'nomodeset'
20:35 nyherba: but then I can't start X because from what I gather nouveau requires modeset lol
20:36 tobijk: feep: i stay with it, it should have been a 01, yet the vbios creator messed up, but what to do with it to be sane only a trace helps :)
20:36 nyherba: (even though it appears to load with nomodeset anyway judging by lsmod output)
20:36 imirkin: nyherba: you need to install firmware
20:36 imirkin: there was a recent regression in that firmware is now required or else the load fails
20:37 imirkin: (normally that should just lose you acceleration, but still get modesetting)
20:38 nyherba: imirkin: i'm wondering if the firmware is proprietary and that's why it's not included in linux-firmware on this distro
20:38 imirkin: (not sure what you mean by 'free' distro... if you mean linux-libre, then you're SOL - they disable all firmware loading)
20:38 nyherba: yes lol
20:38 imirkin: the firmware is proprietary, and it is included in linux-firmware.
20:38 nyherba: so what does one do in this situation? can I just not have video firmware? lol
20:38 oday: Does that even make sense? The firmware is going to be run anyway
20:39 oday: Whether it comes pre-loaded or is loaded by the os
20:40 oday: For a wifi card, for example
20:40 oday: It obviously runs firmware
20:40 nyherba: imirkin: how does a libre distro user get video firmware then? lol
20:41 feep: tobijk: I mean it's not like nvidia are gonna soft-patch their own vbios
20:41 feep: they gotta do something when they hit an invalid value, and I suspect that something is "skip that entry".
20:41 oday: Whether it's stored in some flash mem or your disk, it's still proprietary
20:41 imirkin: nyherba: i believe they nerf request_firmware to always return an error
20:41 tobijk: feep: i'm more for: use the next matching entry
20:41 imirkin: nyherba: in combination with the bug i mentioned, that means no nouveau for you at all with that gpu
20:41 feep: that seems incredibly hacky and unlikely.
20:42 imirkin: i can point you at a patch which fixes that if you like, but you still won't get acceleration
20:42 tobijk: feep: yeah well we only find out with a trace :/
20:42 nyherba: imirkin: so it's gpu dependent? are there nvidia gpu's with free firmware? just trying to understand
20:42 karolherbst: \o/
20:42 imirkin: oday: it makes no sense at all. but arguing with insane people is ... insane.
20:42 karolherbst: https://gist.githubusercontent.com/karolherbst/a853652753859880bd5e752dcb478b4c/raw/eeebe56715ceb709881926e953601f20e8f6b855/msi_fix.patch
20:42 karolherbst: fixes my secboot issue
20:42 nyherba: yeah that doesn't make a whole lot of sense
20:43 nyherba: i'll probably just rollback to the proprietary driver
20:43 imirkin: nyherba: yes, prior to GM200 we could write our own firmware. GM200+ requires signed firmware for the hw to enable sufficient access.
20:43 nyherba: ahh
20:43 imirkin: your GPU is a GM204 most likely.
20:43 tobijk: karolherbst: so we messed up msi before and that messes with fw loading
20:43 karolherbst: tobijk: kind of
20:43 tobijk: fix msi instead ;-)
20:43 karolherbst: no
20:43 karolherbst: pascal moved over to msi-x
20:44 karolherbst: it is probably the right thing to use msix here instead of msi
20:44 nyherba: guess it's back to proprietary I go. sorry stallman.
20:44 karolherbst: "NVIDIA replaced the old interrupt control tree in Pascal and later architectures to migrate away from a legacy PCI interrupt based scheme toward MSI-X interrupts."
20:44 imirkin: nyherba: well, you could also use a regular kernel
20:44 karolherbst: nyherba: kernel version?
20:44 imirkin: nyherba: in which case the firmware will get loaded properly
20:44 karolherbst: nyherba: there was this silly RAM memory controller bug with those 970
20:44 nyherba: karolherbst: 4.13-13
20:45 imirkin: karolherbst: he's on libre.
20:45 karolherbst: imirkin: uhhhhhh
20:45 karolherbst: k
20:45 tobijk: karolherbst: well you seem to got a source, if its credtable, so yeah msi-x it is
20:45 karolherbst: yeah don't use libre on maxwell2+
20:45 nyherba: lol
20:45 karolherbst: well if you want OpenGL that is
20:45 nyherba: so I can still use nouveau just not on libre then?
20:45 karolherbst: nyherba: well... you need propritary blobs on maxwell2 and newer
20:45 imirkin: nyherba: anyways, you took a kernel where they randomly lopped off a bunch of code and now are asking questions like "why doesn't it work"
20:46 imirkin: moral of the story: "don't do that"
20:46 nyherba: well, it was an interesting experiment to say the least
20:46 karolherbst: well, it is their goal to have a kernel with no propritary blobs
20:46 karolherbst: which I fully understand
20:46 imirkin: that said, nouveau on GM20x+ sucks if you care about perf and lots of other things
20:47 karolherbst: imirkin: does this msi patch looks sane to you?
20:47 imirkin: karolherbst: yeah, i don't get it - it's stuff that should be in a ROM on the board, but they were too cheap to ship the rom.
20:47 imirkin: karolherbst: i have no clue about anything MSI
20:47 karolherbst: k
20:47 imirkin: karolherbst: what's the result of the patch? that MSI is disabled?
20:47 imirkin: or that MSI starts to work correctly?
20:47 karolherbst: that MSI works correctly
20:47 karolherbst: I think
20:47 karolherbst: let me check the IRQ I get
20:48 tobijk: msi-x that is
20:48 karolherbst: on MSI I got like 175 and without it I got 16
20:48 imirkin: then i like it. but i prefer to ask PCI people about things like that
20:48 imirkin: since i have no hope of ever understanding it.
20:48 imirkin: Bjorn is pretty responsive usually
20:48 imirkin: at least to well-phrased questions
20:49 karolherbst: imirkin: well the nvidia docs about pascal/msi say they changed their controller and moved to MSI-X
20:49 karolherbst: but yeah
20:49 karolherbst: using the functions correctly might be difficult
20:49 imirkin: not sure how that's relevant to "how do i use these kernel api's properly"
20:50 karolherbst: mhhh interesting
20:50 karolherbst: I should have read the dmesg output
20:50 karolherbst: pci_enable_msi failed. MSI disabled
20:51 karolherbst: ohh right, I can't pass NULL to that
20:59 nyherba: dang, I was hoping for hi-rez TTY's too lol
21:03 tobijk: karolherbst: when looking a bit at mxi-x and its configurable interrupt vectors you might have to change a bit more than just insert an vector to "entries" :D
21:04 karolherbst: yeah...
21:04 karolherbst: but it should work in theory... with the old code
21:04 karolherbst: maybe pci_enable_msi is just a bit borked
21:05 karolherbst: or we have to do something in addition to that
21:09 tobijk: karolherbst: msi-x allows more intrerrupts msi: up to 32 , msix:up to 2048
21:09 karolherbst: yeah
21:09 karolherbst: we use one
21:09 tobijk: so you may have to configure it to only use 32
21:09 karolherbst: well, we use one IRQ
21:09 karolherbst: but we get enough metadata to know what triggered an interrupt
21:45 oday: How do I even start an X server without any output-capable providers or xvfb?
21:46 oday: When I just run Xorg without any configuration, it just segfaults
22:03 karolherbst: oday: why does it segfault?
22:07 oday: It tries to initialize with the nvidia gpu
22:07 oday: Which has no outputs
22:07 oday: But I just remembered
22:07 oday: GVT is a thing
22:08 oday: So I can actually pretend there is an output compatible gpu on the VM
22:09 oday: But how do I attach my nvidia gpu to its own xserver that runs without an output/display?
22:37 oday: So I just installed bumblebee
22:37 oday: I don't think it's working
22:37 oday: It says it failed to load the module "nv"
22:38 tobijk: oday: you dont want nv, you want nouveau :)
22:38 oday: Obviously
22:39 oday: So why is it looking for nv?
22:39 tobijk: not sure, maybe nouveau is not loaded, or bb is plain bad
22:39 tobijk: i dont know anything about bb
23:14 pmoreau: karolherbst: OK, I hit the error as well.
23:30 pmoreau: karolherbst: There, fixed :-D https://hastebin.com/hicuzasofe.diff
23:35 karolherbst: push it!
23:37 pmoreau: It’s pushed to my tree ;-)