09:24 mupuf: karolherbst: so... what about the nouveau presentation?
09:24 mupuf: I will be busy the whole day on saturday, so we need to get this done ASAP!
09:24 karolherbst: do we have it on sat or sun?
09:24 karolherbst: I can work on it while traveling tomorrow
09:25 mupuf: saturday
09:26 mupuf: seriously, share what you have right now. Is it on google docs or latex? If the latter, put it in a public repo!
09:26 karolherbst: I don't have anything right now
09:26 karolherbst: but I will have enough time tomorrow for all this
09:26 mupuf: what about the presentation you gave last week?
09:26 karolherbst: it wasn't a status update
09:26 mupuf: pretty sure it is a good starting point
09:27 karolherbst: I mean, right
09:27 karolherbst: I have some "todos" on there
09:27 mupuf: ok, then xdc's presentation then
09:27 karolherbst: well
09:27 karolherbst: you can tell me what you want us to talk about
09:27 karolherbst: pmoreau does the same
09:27 karolherbst: and I merge all this into a presentation
09:30 mupuf: I added you to a github repo where we put all the previous latex-based presentations
09:30 mupuf: please push what you have from XDC2017 there (in a xdc2017 branch)
09:30 mupuf: I will make my changes there, and you'll do yours
09:30 mupuf:does not want to repeat xdc's way of working where I had to go to your PC
09:31 karolherbst: k
09:31 karolherbst: but I seriously don't know when I will find time for that today
09:31 mupuf: for a git push? :o
09:31 karolherbst: I meant to work on doing proper slides
09:32 mupuf: well, do it no later than tonight, so I can at least work on it in the morning, when going to brussels
09:32 mupuf: what do you mean by proper?
09:32 karolherbst: well, I pushed my devconf stuff into my repository at least, but I could merge the stuff with the other repository
09:32 mupuf: otherwise, I do it today based on the latest presentation I have and the info from xdc 2017
09:33 mupuf: and you'll fix it as it pleases you tomorrow
09:33 mupuf: deal?
09:33 karolherbst: yeah, that sounds perfect
09:33 mupuf: pmoreau: ^
09:33 mupuf: ok, good!
09:33 karolherbst: I have my stuff in here: https://github.com/karolherbst/nouveau_presentations
09:33 mupuf: cool!
09:35 karolherbst: I think we could talk about everything I have on the "Current Challenges" slide
09:36 karolherbst: but besides that? I doubt something is useful from the devconf one for fosdem
09:36 mupuf: ok, cool, thanks :)
09:36 karolherbst: CTS, CI, Vulkan and Compute as the biggest topics
09:36 karolherbst: basically
09:36 karolherbst: and we could complain about signed firmwares again :p
09:37 karolherbst: but as it seems I won't be able to talk about what I do at RH for Nouveau? Let me ask what I am free to say here
09:37 mupuf: well, you can talk about what you are doing, not why
09:38 mupuf: I mean, I don't know why you are doing stuff :D
09:38 karolherbst: :D
09:38 karolherbst: yeah right
09:38 mupuf: but you have patches for reclocking
09:38 mupuf: and power management
09:38 karolherbst: but there are other things going on which may cause other issues
09:38 karolherbst: yeah
09:38 karolherbst: but that's not future work :p
09:38 mupuf: well, leave them out
09:38 mupuf: yeah, true :D
09:38 karolherbst: that's "Currently in the Pipeline:
09:38 karolherbst: "
09:38 karolherbst: anyway
09:39 karolherbst: I am not even sure I can talk about NIR stuff there.....
09:39 mupuf: you;ll fix that section
09:39 karolherbst: anyhow, I'll ask what I am free to talk about, so that I know for sure
09:39 mupuf: if you can't talk about something there, you should not talk about it here, on #nouveau anyway :D
09:39 karolherbst: well
09:39 karolherbst: it is on the mailing list anyway
09:40 mupuf: then you are free to talk about that
09:40 karolherbst: but fosdem might get a broader audience
09:40 karolherbst: I hoped it would be as simple
10:03 RSpliet: karolherbst: You can talk about it, but make sure to manage expectations. Don't make people think it's done in two weeks if it'll take 6+ months, and assume everything takes three times as long as you think it does ;-)
10:03 karolherbst: that
10:04 karolherbst: 's not the issue here
10:05 RSpliet: I don't see how secrecy can be an issue. IRC is logged and your RFC have already hit phoronix. Surely if this had to be kept behind closed doors you already cocked up way earlier ;-)
10:09 mupuf: RSpliet: let's instead use years as a time frame :D
10:10 RSpliet: "I still have lightyears of code to write. As a stack of printed double-sided A4 sheets at 10px font"
10:17 pmoreau: karolherbst, mupuf: I’ll start working on the slides today, and continue tomorrow. I have nothing yet, besides some ideas. The slot is only 25 minutes, so including questions, it will go rather fast.
10:18 RSpliet: Good, I hate long talks! ... but that's none of my business
10:18 RSpliet:sips some tea
10:19 pmoreau: :-p
10:20 pmoreau: mupuf: Sure, that presentation is better than nothing, but don’t we have more recent Nouveau presentations than 2011? :-D
10:20 mupuf: check the branches ;)
10:21 pmoreau: 2014, Ohhhh
11:42 karolherbst: uhm... I have here a really annoying to debug issues
11:43 karolherbst: when the dracut image is loaded and an external display connected, nouveau somehow screws up and even the internal display turns black (optimus laptop)
11:43 karolherbst: painful part is: this happens before I am able to enter the LUKS password
11:43 karolherbst: and somehow I don't get netconsole to work at all
12:05 karolherbst: anyway, using nouveau.runpm=0 "fixes" this
12:05 imirkin: i've been running with runpm=0 for a long time now
12:06 imirkin: too many bugs, and zero gain from it for a desktop board
12:06 karolherbst: does it even matter on a desktop?
12:06 karolherbst: but I am trying to debug issues on a P50
12:06 karolherbst: and there are many of those
12:07 karolherbst: most related to runpm and display hotplugging
12:11 imirkin: it doesn't. which is why it's so frustrating when it results in additional bugs.
12:11 karolherbst: mhhh
12:11 karolherbst: I see
12:12 karolherbst: anyway, that display hotplugging thing through a MST dock is broken as well, even with runpm=0
12:39 imirkin_: yeah, someone else was reporting issues
12:39 imirkin_: when they were testing my xf86-video-nouveau changes for DP-MST
12:40 karolherbst: currently I am on modesetting though
12:40 imirkin_: yeah
12:40 imirkin_: the issues were with nouveau kms
12:40 imirkin_: not with xf86-video-nouveau
12:41 imirkin_: but it made testing of my patches impossible
12:41 karolherbst: anyway, I have some time to dig into those issues for a few weeks
12:41 imirkin_: if you do have a working DP-MST situation, i would appreciate it if you could test that patch
12:41 karolherbst: mhh interesting
12:41 imirkin_: [PATCH] drmmode: update logic for dynamic connectors, paths, and tiles
12:42 karolherbst: yeah, but first I want to fix the issues here
12:42 karolherbst: then I can test your patches :)
12:42 imirkin_: right, without kms working, it's all a bit futile
12:42 karolherbst: on DP connect into the Dock: https://gist.githubusercontent.com/karolherbst/39c5b9736d219a01d7bfbec29c56fb82/raw/e3870a939e573301ae599098a73858ad7871841f/gistfile1.txt
12:42 karolherbst: link address failed -5
12:42 karolherbst: any ideas?
12:43 imirkin_: hopefully that's not directed at me :)
12:43 karolherbst: sure it is :p
12:43 karolherbst: skeggsb sleeps now :D
12:43 imirkin_: none whatsoever then!
12:43 imirkin_: glad i could be of help
12:43 karolherbst: !
12:43 karolherbst: nice
12:43 karolherbst: thanks
12:43 imirkin_: i know little about DP, and even less about DP-MST
12:43 karolherbst: fun part is, sometimes it works, sometimes not
12:43 imirkin_: however i *do* know a lot about copy & paste, which is how that patch came to be
12:43 karolherbst: :)
12:44 karolherbst: mhh
12:44 karolherbst: maybe if I plug in the connected slowly it doesn't work
12:44 karolherbst: and if I di it fast, it works
12:44 imirkin_: airlied may have had DP specs, test hardware, etc. but i had something he didn't have -- his code to copy from! :)
12:46 karolherbst: imirkin_: I guess DVI on a DP-MST hub makes no difference?
12:46 karolherbst: or VGA
12:46 imirkin_: impossible.
12:46 imirkin_: you can't have DVI on a DP-MST hub
12:46 imirkin_: you can have DP on a DP-MST hub, and then an active DP -> DVI adapter however
12:47 karolherbst: well
12:47 karolherbst: I am sure this is what happens
12:47 karolherbst: it's one of those lenovo docks
12:47 imirkin_: the difference is important for understanding how things work
12:47 karolherbst: I am sure they have all kind of fancy stuff in there
12:47 imirkin_: i realize that you can stick it all inside a single piece of plastic
12:47 karolherbst: right
12:47 karolherbst: anyway, this "link address failed -5" errors seems to be persistent
13:13 karolherbst: imirkin_: add && i->op != OP_TXLQ to https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp#n909 ?
13:14 imirkin_: erm
13:14 karolherbst: you know, that txlq bug I talked to you some days agao
13:14 imirkin_: yes.
13:15 karolherbst: that code produces a sill cvt
13:15 imirkin_: hmmmmmmmmmmmmmmm
13:15 imirkin_: i wonder if the proper approach is to fix the tex target
13:15 imirkin_: to be non-arrayed
13:15 karolherbst: mhhh
13:15 imirkin_: when generating it on nv50 ir input
13:15 karolherbst: but I mean it is, right
13:16 karolherbst: but I assume for txlq it doesn't matter if it is an array or not
13:16 imirkin_: yeah ... i guess i'd fix it up in handleTXLQ or something
13:16 imirkin_: i.e. change the tex->target to not be arrayed
13:16 imirkin_: handleTEX does *not* need more special cases
13:16 karolherbst: :D
13:16 imirkin_: in fact i don't really know why handleTXLQ calls handleTEX
13:16 karolherbst: let me check
13:16 imirkin_: again, could be due to silliness of youth
13:17 imirkin_: i guess it still needs the stupid indirect handling :(
13:17 imirkin_: anyways
13:17 imirkin_: i'd rather handleTEX get broken up a bit
13:17 imirkin_: than keep adding special cases to it
13:17 karolherbst: I see
13:17 imirkin_: it's incomprehensible enough as it is
13:17 karolherbst: in handleTEX it runs through that line: "i->tex.r += prog->driver->io.texBindBase / 4;"
13:17 imirkin_: e.g. note that i handle it explicitly in handleTXQ
13:18 imirkin_: without calling handleTEX
13:18 imirkin_: i guess handleTXLQ still wants cube normalization... urgh.
13:18 karolherbst: and there is this as well: XXX HACK: We insert 0 sources to avoid the 5 or 6 regs case.
13:18 imirkin_: can't happen with TXLQ
13:18 karolherbst: k
13:19 imirkin_: that's when you have a lot of args to tex
13:19 imirkin_: which you can't have with TXLQ
13:19 karolherbst: I see
13:19 karolherbst: even if using indirects?
13:19 imirkin_: most coord args is 3
13:19 imirkin_: indirect is another arg
13:19 imirkin_: so it all fits in 4
13:19 karolherbst: k
13:20 imirkin_: i guess i dunno - maybe it really wants the array anyways
13:20 imirkin_: in which case you're SOL and have to keep the full handleTEX lowering
13:20 karolherbst: well, I will put in the "&& i->op != OP_TXLQ" for now and run piglit to check if this is a valid approach, then I check if changing the target breaks something
13:20 imirkin_: i don't think that'll work
13:20 imirkin_: it would need more haxing
13:20 karolherbst: mhh
13:21 imirkin_: or maybe not?
13:21 imirkin_: like i said, that code is very confusing ;)
13:21 karolherbst: it does
13:21 karolherbst: segfault in nv50_ir::RegAlloc::InsertConstraintsPass::condenseSrcs :)
13:21 karolherbst: for whatever reason
13:21 imirkin_: coz it uses tex.target.getArgCount
13:22 karolherbst: ahh
13:22 imirkin_: (and you're short an arg)
13:22 imirkin_: this is why i was saying it's better not to lie too much to the instructions
13:22 karolherbst: if (tex->op != OP_TXQ) { ... }
13:22 karolherbst: :)
13:22 karolherbst: it seems like there are hacks everywhere
13:22 imirkin_: yeah, coz TXQ's arguments aren't coordinates *at all*
13:22 imirkin_: it's just an LOD and that's it
13:23 imirkin_: so that's not that much of a hack
13:23 karolherbst: ohh, right
13:23 imirkin_: i realize it's a lot of info to keep in your head
13:23 imirkin_: but i strongly recommend looking at ALL the glsl texturing functions
13:23 karolherbst: mhh, at least with those two lines changed it passes
13:23 imirkin_: and make sure you understand *clearly* what each does
13:24 imirkin_: i'm happy to explain any particular one you're unsure of
13:24 karolherbst: I hope I will find time for that in the near future :)
13:24 imirkin_: it took me something like a year to work it all out
13:24 karolherbst: uff
13:24 imirkin_: (not full time obviously)
13:24 imirkin_: i did it in bits and pieces
13:24 imirkin_: but i think i have a strong understanding of it all now
13:25 karolherbst: best way to change the target of the tex instructions?
13:25 imirkin_: i->tex.target = foo ;)
13:25 karolherbst: :)
13:25 karolherbst: I guess there is no target.withoutArray() or something?
13:26 imirkin_: i don't think so - but easy enough to write such a helper
13:27 karolherbst: okay, replacing the target seems to work at least for the 1D case
13:28 imirkin_: test passes?
13:28 imirkin_: or just compiles?
13:28 karolherbst: test
13:28 imirkin_: just coz code generates doesn't necessarily mean it's correct =/
13:28 imirkin_: (if only ...)
13:28 karolherbst: mhh
13:28 karolherbst: there is something more though
13:28 karolherbst: mov (SUBOP:1) u32 $r2 $r3
13:28 imirkin_: that's an export
13:28 karolherbst: with $r3 being not set
13:29 imirkin_: pastebin DEBUG=1 output
13:29 karolherbst: https://gist.githubusercontent.com/karolherbst/44aae2c592bbd5fa39cc5bab83c42ab9/raw/fad1543199fe8ebe7293cac1c72896e9f1ba6c83/gistfile1.txt
13:30 karolherbst: but I guess it is there for the z component of the color thing
13:30 imirkin_: 4: texquerylod 1D_ARRAY $r0 $s0 f32 { %r3 %r4 } %r1 %r5 (0)
13:30 imirkin_: so that's passing the array arg
13:30 imirkin_: even though it's not initialized
13:30 imirkin_: and that arg is never dropped
13:30 karolherbst: ahh
13:30 imirkin_: i don't think that's the full extent of the problems
13:30 imirkin_: but it's a start.
13:30 karolherbst: I see
13:31 karolherbst: well
13:31 karolherbst: in nir I don't have it :)
13:31 imirkin_: when doing withoutArray(), also drop the last src
13:31 karolherbst: nir case: https://gist.githubusercontent.com/karolherbst/f648a9817b2c6866b59b949703f1cabf/raw/37bf74a526315384bba3bd7a51273ebd695dcf92/gistfile1.txt
13:31 karolherbst: but also that pointless mov
13:31 karolherbst: well "pointless"
13:32 imirkin_: oh wait
13:32 imirkin_: that's all correct
13:32 imirkin_: MOV OUT[0], TEMP[2]
13:32 imirkin_: but only TEMP[2].xy are intialized
13:32 karolherbst: yeah
13:32 imirkin_: adn .wz are undefined
13:32 imirkin_: so that's why you get that
13:32 imirkin_: $r3 is undefined
13:32 imirkin_: which it then also carefully copies into $r2 ;)
13:32 karolherbst: I was wondering if we could just remove outputs from non initialized values...
13:33 imirkin_: i have a pass to do that
13:33 imirkin_: but not for frag shaders
13:33 karolherbst: ahh
13:33 karolherbst: I see
13:33 imirkin_: i drop exports with nops
13:33 imirkin_: but i don't drop MOV_SUBOP_1's
13:33 imirkin_: i should
13:33 imirkin_: i think i spaced on that
13:33 karolherbst: okay
13:33 imirkin_: let me find where i do that...
13:34 karolherbst: but it wouldn't free a GPR, right?
13:34 imirkin_: ah, i do it in MemoryOpt
13:34 karolherbst: because 2 and 3 are still occupied by the output
13:34 imirkin_: when processing OP_STORE || OP_EXPORT
13:34 imirkin_: yeah
13:34 imirkin_: maybe that's why i never did that
13:34 karolherbst: makes sense
13:34 karolherbst: mhh
13:35 karolherbst: maybe replace by those by movs from 0?
13:35 karolherbst: and then the shader can do whatever with those regs before
13:35 karolherbst: or wouldn't that work?
13:35 imirkin_: yeah dunno. never seemed like a priority.
13:35 karolherbst: right
13:36 karolherbst: have to think about it. Just wanted to spend some time on this until I got my kernel compiled on the P50 :)
13:38 imirkin_: the exports thing was a nice bump though
13:38 imirkin_: coz it happens a lot in vertex shaders
13:38 karolherbst: imirkin_: maybe from_tgsi could be fixed up as well? For me it looks rather pointless adding that one source in the first place... but mhh, things will get odd a little
13:38 imirkin_: that some random attrib never gets initialized, but the code calls for the whole vec4 to be exported
13:38 karolherbst: uhh
13:38 imirkin_: for TXLQ?
13:38 imirkin_: from_tgsi should def get fixed up
13:39 imirkin_: but need to first investigate if things work the way i really think they do
13:40 karolherbst: okay
17:03 mupuf: oh god, so much work to do on this presentation
17:03 mupuf: ... I'll try my best to find an angle of attack for it that will not require explaining the world
17:03 mupuf: I guess it will not be a complete status
17:03 imirkin_: in 30 words or less!
17:03 mupuf: ;)
17:04 mupuf: Let's make the Q&A longer :p
17:04 Ananace: Hopefully you'll not run into the same heart attack I had with my slides for a presentation on CfgMgmtCamp
17:04 Ananace: Suddenly the presentation view stopped rendering text
17:05 imirkin_: he's already had his share of heart attacks
17:05 imirkin_: e.g. reclocking code not working with dual screens
17:06 feaneron: fosdem?
17:06 imirkin_: what doesn't kill him only makes him stronger
17:06 imirkin_: yeah, i think so
17:07 feaneron:hopes fosdem talks are gonna be recorded
17:07 imirkin_: they usually are
17:07 Ananace: Luckily I found a workaround in disabling hardware accelerated rendering, with just today left before losing all my free time to FOSDEM and then CfgMgmtCamp itself
17:32 pmoreau: feaneron: They should even be livestreamed, I think
17:34 mupuf: yeah, https://www.fosdem.org/2018/schedule/event/nouveau/
17:35 mupuf: I wonder why karol put me first in the author list :o
17:37 feaneron: pmoreau: awsome. i'll keep an eye on it
17:37 feaneron: good luck with the presentation, folks
17:40 pmoreau: Thanks! :-)
17:41 pmoreau: mupuf: It’s a reverse alphabetical order! ;-)
17:41 mupuf: yeah, I went for the more boring order, the alphabetical one
17:41 pmoreau: Pfff
18:05 otherflow: hello
18:19 otherflow: i've tried to compile the module "nouveau" from the master branch of github but it failed on this error : error: unknown type name ‘refcount_t’. Someone can tell me which dependencies are missing ?
18:20 imirkin_: did you do "cd drm; make"?
18:20 imirkin_: er ... which git tree btw?
18:22 otherflow: imirkin_, yes, i did "cd drm; make"
18:22 imirkin_: what kernel are you building against?
18:22 otherflow: i've just retry with the tree from git (git clone https://github.com/skeggsb/nouveau.git).
18:23 imirkin_: refcount_t has existed since like the dawn of time
18:23 otherflow: 4.9.0-4-amd64 on debian
18:23 imirkin_: ah, you need to build that module against 4.15 probably
18:24 otherflow: ok thank you :)
18:24 imirkin_: (it's a system that basically only works for ben, since it only builds against whatever kernel he happens to be running at the time)
18:27 otherflow: (ok)
18:32 imirkin_: of course since he contributes 99.99% of the code, it works out in the end
18:33 imirkin_: (but perhaps others would be encouraged to contribute more if the dev branch situation wasn't so confusing? we'll never know.)
18:54 otherflow: ok
18:57 sooda: hey mupuf, pmoreau etc, any lunch/dinner agenda for fosdem yet? cyndis, peter & i are going; we should meet up!
20:18 pmoreau: sooda: Awesome! \o/ I’m looking forward to seeing you guys again. We should definitely organise an NV dinner. I don’t know if Karol and Martin have RH/Intel lunch/dinners planned already.
20:20 sooda: our flight lands tomorrow 18.20 and we're leaving on sunday 19.15 (really earlier to catch that), and there are quite a few presentations worth watching, but let's find some common timeslot
20:22 pmoreau: Karol is landing around 20:00 IIRC
21:17 mupuf: Sooda: Yeepee!! Wonderful! Let's catch dinner Saturday or Sunday!
21:18 mupuf: Seems like sunday is .ot an option, then saturday!
21:52 Jimi-James: would anyone know anything about if a system suddenly stopped activating DRI3, after it worked for almost 2 years, without you having changed any conf files, package versions (at least not the kernel, xorg, or xf86 packages), or installed GPU(s)?
21:53 Jimi-James: that's happening to me right now
21:53 imirkin_: pastebin dmesg and xorg log
21:54 Jimi-James: is there anything you'd recommend grepping in dmesg to get all the info about graphics? or just the whole dmesg?
21:55 imirkin_: whole dmesg is faster
21:55 imirkin_: avoids you having to do work, and me being annoyed at incomplete info
21:56 Jimi-James: alright
21:56 Jimi-James: here's xorg: https://pastebin.com/1rV7xwiS
21:56 Jimi-James: and dmesg: https://pastebin.com/khDiiDGk
21:58 imirkin_: how about LIBGL_DEBUG=verbose glxinfo > /dev/null
21:59 Jimi-James: libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so libGL: Can't open configuration file /home/jimi/.drirc: No such file or directory. libGL: Can't open configuration file /home/jimi/.drirc: No such file or directory. libGL: Using DRI2 for screen 0
21:59 Jimi-James: oh it didnt keep the newlines
21:59 Jimi-James: sorry, i dont IRC Much
21:59 Jimi-James: ill pastebin it
21:59 imirkin_: no worries
21:59 imirkin_: that's ... interesting.
22:00 imirkin_: i like it.
22:00 imirkin_: means i get to think
22:00 Jimi-James: ha i know what you mean
22:01 imirkin_: mind pastebinning 'glxinfo' and 'xdpyinfo'?
22:02 Jimi-James: respectively:
22:02 Jimi-James: https://pastebin.com/pUiLg9cz
22:02 Jimi-James: https://pastebin.com/fdHsS4VB
22:03 imirkin_: oh WTF
22:03 imirkin_: only DRI2 in that list
22:03 imirkin_: should be a DRI3 in there... even when you don't really support DRI3
22:03 Jimi-James: weird
22:04 Jimi-James: id wonder if maybe arch linux did something to their xf86-video-nouveau package, but downgrading to a version that definitely worked hasnt changed this behavior
22:04 imirkin_: and you just have Option "DRI" "3" in the device section right?
22:05 Jimi-James: yeah
22:05 Jimi-James: 10-nouveau.conf is Section "Device" Identifier "NVidia" Driver "nouveau" Option "DRI" "3" EndSection
22:05 Jimi-James: (only with newlines)
22:05 imirkin_: eeeinteresting
22:05 imirkin_: in my log, i see a "loading sub module dri3"
22:06 imirkin_: whereas in yours i only see dri2
22:06 imirkin_: (mine has both dri2 and dri3)
22:06 Jimi-James: that was what it seemed like to me, too
22:06 Jimi-James: that it just wasnt even trying to use DRI3, rather than not supporting it
22:06 imirkin_: admitteldy i'm on intel
22:06 imirkin_: but those logs should be pretty similar
22:08 imirkin_: yeah, i have no idea what's happening
22:08 imirkin_: i'd have to compare to my system at home
22:08 imirkin_: which is actually running nouveau in a similar config
22:08 imirkin_: to see what the messages are supposed to look like
22:08 imirkin_: that'll happen in a few hours... until then, sit tight
22:08 imirkin_: that said, i blame arch
22:09 imirkin_: (it's so easy... and it's so defenceless against such baseless accusations)
22:11 Jimi-James: haha thanks
22:45 Booti386: imirkin_: BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
22:45 Booti386: This is not supposed to happen, right?
22:45 imirkin_: no.
22:46 Booti386: https://hastebin.com/upeniloliy.go
22:46 imirkin_: skeggsb: you have a customer
22:47 imirkin_: Booti386: most likely a result of the vmm rework
22:47 imirkin_: the whole vm subsystem got rewritten, so probably a handful of bugs lurking
22:47 Booti386: When did it happen?
22:47 imirkin_: 4.145
22:47 imirkin_: 4.15, sorry
22:49 Booti386: It seems more stable though, I didn't manage to crash the whole desktop as usual (but I have to test with DRI 3 enabled, still)
22:50 imirkin_: afaik there should be little to no functional change as a result. however some OTHER bugs iirc may have gotten fixed.
22:51 skeggsb: Booti386: can you find a way to reproduce that?
22:51 Booti386: Errrr
22:52 karolherbst: mupuf, pmoreau: if you worked on stuff, could you push it somehwere? I will leave around 11am tomorrow
22:52 Booti386: I can try, it happened quite unexpectedly inside an app
22:52 pmoreau: karolherbst: Will do. Currently finishing a first draft of my part. If it’s too long, I can easily cut out things.
22:53 karolherbst: yeah, no worries about that, I will finish it tomorrow anyway :p
22:54 Booti386: And now it's dead, Jim
22:54 pmoreau: karolherbst: ;-p
22:55 Booti386: skeggsb: Well, it just happened again
22:55 Booti386: Broken state, I guess
22:55 pmoreau: karolherbst: I pushed the current v3 for clover to github by the way, and will host my other work on Mesa there as well: https://github.com/pierremoreau/mesa
22:55 Booti386: I just had to relaunch the app (without rebooting)
22:56 karolherbst: pmoreau: nice
22:57 karolherbst: anyway, I will go to sleep now, so that I can prepare tomorrow morning without having to hurry
22:58 pmoreau: Sounds good, see you later!
22:58 pmoreau: Have a safe travel!
22:59 pmoreau: karolherbst: And btw, before you leave: “sooda │ [19:57:40] hey mupuf, pmoreau etc, any lunch/dinner agenda for fosdem yet? cyndis, peter & i are going; we should meet up!”
23:03 karolherbst: sooda: sounds good!
23:03 karolherbst: we will meet there I guess
23:10 Booti386: skeggsb: It looks like cli is NULL at nouveau_mem.c:99 (don't know if it is useful at all)