13:27 karolherbst: imirkin: btw, I think one of the cts patches I have on my branch fixed that black rect issue with chromium, at least I didn't see them for a while now, .. hopefully that texture cache thing is it and it's really fixed :)
13:54 prOMiNd: imirkin, I have a question
13:54 prOMiNd: envy_bios_mem_type
13:55 prOMiNd: which pointer does that represent?
13:55 imirkin_: link to code?
13:55 imirkin_: (on the off chance that i'm lazy)
13:55 prOMiNd: https://github.com/envytools/envytools/blob/master/nvbios/mem.c
13:56 prOMiNd: I´m trying to find memory type, manufacturers and tweak entry points to each vendor
13:56 imirkin_: no such thing afaik
13:57 imirkin_: still unsure what you mean by "which pointer does that represent"
13:57 prOMiNd: BIT_MEMORY_PTRS (Version 2)
13:57 prOMiNd: Memory Information Table Pointer
13:57 prOMiNd: 16
13:57 prOMiNd: Pointer to the memory information table
13:57 imirkin_: ok
13:57 imirkin_: what's the question?
13:58 imirkin_: vbios stores pointers to tables in the vbios
13:58 prOMiNd: are memory information table structs known or at least partially
13:58 imirkin_: it's all 16-bit based addressing
13:58 imirkin_: yeah, completely (or mostly)
13:58 prOMiNd: where can i find the correct struct of memory information table
14:00 imirkin_: ok. less well documented than i thought.
14:00 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/bios/rammap.c
14:01 imirkin_: i think we know a bunch more of those
14:01 imirkin_: just not named in there
14:03 prOMiNd: :)
14:03 prOMiNd: thanks, will see what I can find
14:03 prOMiNd: I just need to know the current memory manufacturer
14:04 prOMiNd: why does nvidia have to make it ultra hard to find on linux
14:04 imirkin_: can you find that on windows?
14:04 imirkin_: afaik that info's just not there
14:04 imirkin_: i wonder if they reverse-engineer it from the timings
14:04 imirkin_: i.e. manufacturer A produces timings that look like this, B looks like that, etc
14:05 imirkin_: there's a spec for desktop memory iirc to query manufacturer info
14:05 imirkin_: i doubt it's implemented on those though
14:06 prOMiNd: yes on windows is pretty easy
14:06 prOMiNd: nvapi exposes it
14:06 prOMiNd: but since we have no nvapi on linux, I have to deal with vbios parsing and poking of undocumented tables
14:06 prOMiNd: just to match running register with prom vbios one
14:07 prOMiNd: all I suspect is that memory information table contains information of types by manufacturer used in tweaktable
14:08 imirkin_: it's common to have a table of values indexed into based on some other thing
14:16 prOMiNd: yeah but the table is not public :)
14:16 prOMiNd: only pointers to it
14:34 prOMiNd: imirkin_, can you recall of an unique register that can be used to determine memory manufacturer?
14:35 imirkin_: i doubt there's any such thing
15:09 imirkin_: karolherbst: actually i'd guess the text thing is more like it
15:10 imirkin_: i could definitely imagine an issue after a while where some bit of code becomes invalidated
15:10 imirkin_: iirc people only reported having issues "after a while"
15:10 karolherbst: mhh I see
15:10 karolherbst: I saw it shortly after starting the CTS though
15:10 imirkin_: the black rects?
15:10 karolherbst: yeah
15:10 karolherbst: but not always
15:11 karolherbst: it's kind of random ;)
15:11 imirkin_: coz the cts exacerbates the issue
15:11 imirkin_: anyways, dunno
15:11 imirkin_: either way, both issues are issues :)
15:11 imirkin_: if fixing them also fixes the black rects, so much the merrier
15:42 karolherbst: imirkin_: ... I don't think I can use my NV84 with the motherboard :(
15:43 imirkin_: ?
15:43 karolherbst: the uefi complains about missing GOP support
15:43 imirkin_: ah yeah.
15:43 imirkin_: bios boot?
15:43 imirkin_: should work
15:43 karolherbst: .....
15:43 karolherbst: mhhhh
15:43 imirkin_: except your booting won't work :)
15:43 karolherbst: well, there is this intel GPU on the CPU still
15:43 imirkin_: ah yeah, use that
15:44 karolherbst: need some trickery to convince mutter to not use it though then?
15:55 karolherbst: imirkin_: ohh, I have a normal display which advertises interlaced modes, fun
15:55 karolherbst: they don't over over DVI, but still
16:00 HdkR: Advertises interlaced over DVI even?
16:00 HdkR: How terrible :P
16:00 karolherbst: we don't check in nouveau if the output actually supports interlaced
16:01 karolherbst: I have patches, never got to actually upstream them
16:09 karolherbst: mhhh
16:09 karolherbst: I can't reproduce
16:10 karolherbst: so what do I have to do to get that RT_LINEAR_WITH_ZETA error :/
16:12 imirkin_: render on nvidia gpu with a linear rt + depth buffer
16:13 karolherbst: mhh, I have the gnome session running under wayland, displaying the desktop on two G84 GPUs
16:13 karolherbst: doesn't that count already?
16:14 imirkin_: i have no idea why they had depth
16:14 karolherbst: ohhhhh
16:14 karolherbst: it gets rendered on the intel one
16:14 karolherbst: ...
16:14 karolherbst: and only displayed on both nvidia ones
16:14 karolherbst: crazy stuff
16:14 imirkin_: yeah, you want rendering on one of the nvidia gpu's to hit this
16:15 karolherbst: so I have convince mutter to use the nvidia gpu for rendering, fun
16:15 karolherbst: maybe I should restart my session :D
16:15 karolherbst: I started with a display on intel and moved the display to the nvidia gpu
16:18 karolherbst: meh... the heck
16:22 karolherbst: that was more complicated than it should be... removed the intel GPU PCI device
16:24 karolherbst: wow, even moving the console to the nvidia GPU worked fine
16:31 karolherbst: guess I will have to use a live boot image... somewhere I should have one
16:32 imirkin_: silly question - you do have 2 GPUs plugged in right?
16:32 karolherbst: yeah
16:32 imirkin_: k :)
16:32 karolherbst: but apperantly I don't get the wayland compositor convinced to use the nvidia ones as the primary thing
16:32 imirkin_: oh
16:32 imirkin_: iirc there's a way to specify it
16:32 imirkin_: some env var. not sure.
16:32 karolherbst: yeah.. I will just boot from a live image, should be easier
16:32 karolherbst: overall
16:33 imirkin_: at least for wlroots, WLR_DRM_DEVICES? something like that
16:39 prOMiNd: imirkin_, I will rephrase , do you know how to find out which MemoryTweakIndex entry is for specific Memory type 0,1,2,3...
16:40 prOMiNd: https://bitcointalk.org/index.php?topic=1882656.msg21221727#msg21221727
16:40 prOMiNd: the type he mentions is not know as entry or pointer
17:29 imirkin_: prOMiNd: that comes from fuses, iirc
17:30 prOMiNd: meaning?
17:30 imirkin_: PFUSE
18:06 manio: hello, I am trying to run VDPAU on NVA5/VP4.0
18:06 manio: no matter what codec i am trying to run it is stuterring at the beginning and kodi is crashing
18:07 manio: i have the following in the dmesg: https://pastebin.com/eW83Sprx
18:07 manio: am i missing something or it is just working like this - so "mostly" :)
18:08 manio: kernel 5.0.0-rc2 fyi
18:15 imirkin_: does mplayer -vo vdpau work ok?
18:22 prOMiNd: imirkin_, I got a little help and now vendors can be identified
18:22 prOMiNd: so we have 0x35 as samsung, 0x31 as micron and 0x34 as hynix
18:22 prOMiNd: now PFUSE is something I dont know where to search
18:22 prOMiNd: at least on pascal
18:30 imirkin_: manio: basically, vdpau + gl = major fail for now
18:31 imirkin_: if kodi uses opengl, which iirc it does, then you'll get to enjoy that fail
18:36 imirkin_: karolherbst: did you end up trying to run igt on nouveau?
18:37 karolherbst: nope
18:37 karolherbst: Lyude maybe?
18:37 karolherbst: manio: willing to build mesa yourself?
18:37 karolherbst: I have a branch you might be able to try out
18:38 imirkin_: might not be enough - i'm not sure the vdpau stuff invalidates state correctly
18:38 karolherbst: mhh :/
18:38 imirkin_: although i guess if it's a separate context, should be ok ... mostly?
18:38 karolherbst: should be
18:39 karolherbst: I never tried it
18:40 karolherbst: should test it on the desktop at work
18:40 imirkin_: i don't know that it's ever been tried tbh :)
18:40 imirkin_: usually one is happy enough that the goddamn thing works at all
18:40 karolherbst: :D
18:40 imirkin_: that all of the hardening falls to "later"
18:40 imirkin_: aka "never"
18:41 karolherbst: imirkin_: ohh, random idea: if we get a dead channel. Say we would detect this inside mesa and would simply allocate a new one and move on with life, how much fail do we have to expect?
18:42 imirkin_: like a new hw ctx?
18:42 karolherbst: yes
18:42 imirkin_: if we marked everything dirty, i don't think it'd be that much
18:42 imirkin_: would have to make sure the VM gets copied over
18:42 karolherbst: mhhh, interesting
18:42 imirkin_: otherwise all the backing data goes *poof*
18:42 karolherbst: sure
18:42 karolherbst: question is, how long does it take until the applications are okay again
18:42 karolherbst: or kind of okay
18:43 imirkin_: yes ... the eternal question of how long to wait until declaring that something's hung
18:43 karolherbst: I came up with a new idea how to do dead channel detection
18:43 karolherbst: which is much simplier than my older one
18:43 imirkin_: i think in the kernel we have a 5s timeout? or maybe 15s?
18:43 imirkin_: (for waiting on a fence before declaring it dead)
18:43 karolherbst: it depends
18:44 karolherbst: but normally the kernel doesn't kill channels just because they still work on something
18:44 imirkin_: i dunno man
18:44 imirkin_: talk to skeggsb
18:44 karolherbst: most of the time it's some trap and the kernel just kills it
18:44 karolherbst: that's not the issue though. the kernel tracks it
18:44 karolherbst: so if a channel is dead, it gets marked as such
18:44 karolherbst: sooo
18:44 karolherbst: we could simply ask for that from mesa
18:45 karolherbst: if we run into timeouts, we ask via an ioctl if the channel is actually dead, if so, do whatever recovery or kill the application, else: wait longer
18:48 karolherbst: imirkin_: well, I talked with skeggsb about that, and he was fine with such an ioctl. He simply prefers fixing the driver on a more fundamental instead of trying to do easy/fast fixes
18:48 karolherbst: which is understandable, but doesn't really change much of the outcome imho
18:48 karolherbst: I mean, doing the ffast stuff now will delay the proper fixing by a few days at most
18:48 imirkin_: if his argument is to have a perfect userspace, then that's bogus
18:48 imirkin_: at the very least, we need to be able to debug the userspace
18:48 karolherbst: true
18:49 karolherbst: he didn't go into specifics, so I don't know what he actually ment
18:49 karolherbst: *meant
18:49 karolherbst: "it means fixing the 3d driver to be sane" was what he said
18:49 imirkin_: i like sanity.
18:49 imirkin_: much better than the alternative.
18:49 karolherbst: how boring
18:50 joepublic: sanity in moderation's not bad
18:50 karolherbst: anyway, I hope I will get something working by tomorrow and try it out to just continue with the new channel, will be fun I guess
18:51 karolherbst: joepublic: the real deal is to accept that we all are insane, and that everything we do, is insane as well :p everything else is just lieing to yourself
19:05 joepublic::: nod ::
21:27 pmoreau: karolherbst: Seems that the sub thing is working on Maxwell, but it’s no longer converting it to an iadd.
21:27 karolherbst: huh?
21:27 karolherbst: try dissasembling the binary
21:28 karolherbst: the emiter magically converts it to an add
21:28 pmoreau: Oh true
21:30 pmoreau: Hum
21:30 imirkin_: imho, we should nuke sub
21:30 karolherbst: I actually had some patches for that...
21:30 imirkin_: lots of special cases
21:30 karolherbst: probably should finish those
21:30 imirkin_: zero benefit
21:35 pmoreau: karolherbst: re “I have a later patch to add all of those combinations. The integer ones don't need special handling, although I guess we could move those into here as well.”, why not merge that patch with the one introducing handleCVT()?
21:36 pmoreau: “The integer ones don't need special handling, although I guess we could move those into here as well” given that handleCVT is only handling integers at the moment, what do you mean by that?
21:36 karolherbst: pmoreau: 32<->64 integer conversions are merge/splits
21:38 pmoreau: Sure, and for 8|16<->64 you only add some masking to it
21:39 karolherbst: pmoreau: I wanted to split the conversions required for CL from the ones required by GL
21:40 pmoreau: Ah, and this first series is not about CL, that’s the later one, gotcha
21:40 karolherbst: pmoreau: https://github.com/karolherbst/mesa/commit/7391136004b04df0a875f816b5c0c279eb6c5a70 + https://github.com/karolherbst/mesa/commit/a32355a21ac56a3a4f77ab42907c782eb84346ec
21:41 pmoreau: I see :-)
21:42 karolherbst: that was too fast :p
21:42 pmoreau: Ah ah ah, I ended up adding the Rb to the wrong patch
21:43 pmoreau: There we go, that’s the one I wanted to tag
21:43 pmoreau: I only had the few points I commented about that remained about that patch, and both points were cleared up, no point in waiting longer for the Rb. :-)
21:50 pmoreau: So, now I only have the final boss to clear, aka the first patch in the series. :s
22:14 Lyude: What's the recommended way for one to return a variable length piece of data through nvif?
22:15 Lyude: Asking since I'm trying to start off the manual lt trainign stuff for nouveau by adding a way to get a list of the possible link rate/lane count combos for a given outp
22:15 Lyude: *training
22:15 Lyude: oops, *manual link training
22:15 Lyude: lt training is redundant
22:16 imirkin_: zero-sized array at the end
22:16 imirkin_: with the true number passed via one of the struct members
22:16 imirkin_: at least a lot of data is passed in that way
22:16 Lyude: imirkin_: perfect, sgtm
22:17 Lyude: imirkin_: btw, mind showing an example in the source?
22:17 karolherbst: Lyude: grep for [] arrays ;)
22:17 karolherbst: there is one in the nvif.h file
22:17 Lyude: cool, thanks!
22:17 imirkin_: i can in an hour.
22:17 karolherbst: Lyude: nvif_ioctl_map_v0
22:17 Lyude: imirkin_: don't worry about it :p, I should be set with the info karolherbst just gave me
22:18 karolherbst: in drivers/gpu/drm/nouveau/include/nvif/ioctl.h
22:19 karolherbst: Lyude: but essentially you just kmalloc witht he sizeof(struct) + len * sizeof(*array) or something
22:19 karolherbst: I think sizeof(struct) doens't include the variable length array
22:19 karolherbst: not 100%
22:19 karolherbst: sure
22:19 Lyude: I'm sure I can probably figure that out just by going through the source
22:19 karolherbst: probably
22:22 Lyude: huh, if we don't pass any of these structs back and forth between the GPU what is the point of some of the padding in the nvif structs, out of curiosity
22:22 imirkin_: api between linux glue and core driver
22:41 cosurgi: whoa, plenty of people!
22:41 cosurgi: and nickserv registration worked :)
22:41 cosurgi: imirkin_: thanks :)
22:43 cosurgi: so about this xserver segfault upon startup: https://lists.freedesktop.org/archives/nouveau/2019-January/032028.html
22:43 cosurgi: I have found out that it does not sefault when I don't use all three LCD monitors.
22:45 cosurgi: also - if I start xserver with just one screen, and afterwards using arandr I reconfigure it to use all thre, the upon clicking 'apply' button the xserver crashes.
22:45 cosurgi: also - if I start xserver with just one screen, and afterwards using arandr I reconfigure it to use all three, then upon clicking 'apply' button the xserver crashes.
22:45 cosurgi: imirkin_: so I guess I should write some xorg.conf with three monitors, and see if that solves the problem? Instead of using xrandr?
22:59 cosurgi:writes specific xorg.conf
23:02 RSpliet: cosurgi: not to be too discouraging, but in my humble experience nouveau definitely locks up more often than once every three months. Sessions can sometimes be salvaged, but that's definitely not the norm today.
23:03 cosurgi: ouch
23:05 RSpliet: I'm sure people more knowledgeable on the topic of display in nouveau are happy to try and get your set-up to work w/ nouveau, but I'd rather warn you in advance that stability tends to be more of an issue with nouveau than with the blob. It depends heavily on the card and the workloads, rah rah rah
23:06 cosurgi: damn. But I'll try to give it a chance.
23:06 HdkR: RSpliet: What are you talking about. I personally adore my headless computer to constantly lose the ability to talk to the GPU with the blob
23:07 HdkR: Stability is laughable everywhere when it comes to Nvidia hardware :P
23:07 cosurgi: so I should switch to fglrx instead?
23:08 HdkR: I'm just throwing shade. I doubt you'll encounter my particular issue
23:09 imirkin_: cosurgi: so ... trying to understand what the issue is
23:09 RSpliet: HdkR: I'm sure the more common case of a 4-monitor 6480x3840 desktop is a lot more stable with the blob :')
23:09 imirkin_: cosurgi: did you try my suggestion?
23:09 HdkR: Could be
23:10 imirkin_: cosurgi: also, do you want to use the same monitor configuration for each X server?
23:11 cosurgi: imirkin_: yes, the same monitor configuration for each X server
23:11 cosurgi: imirkin_: I suspect that there is not enough memory to allocate for second xserver...
23:11 imirkin_: so then a single xorg config should work -- have a look at the one i sent, should be fine
23:11 imirkin_: no, plenty of memory
23:11 imirkin_: you have a newish card
23:11 cosurgi: imirkin_: to be clear, your suggestion is to use xorg.conf right? Yes, I am trying it right now.
23:11 imirkin_: however i would strongly recommend using the nouveau ddx over the modesetting one, esp for lots-of-monitors
23:14 cosurgi: imirkin_: I didn't have any xorg.conf file before. So I start with an empty file and paste the config from you email. I get faatal error no screens found.
23:15 cosurgi: please tell me what is ddx?
23:15 cosurgi: Is that the case where instead of xrandr I use a non-empty xorg.conf?
23:18 cosurgi: I can use ddx, I only need to know how to enable it :) Does ddx also work good for OpenGL ? Because I use some OpenGL code in my work (e.i. I write C++ OpenGL code to draw stuff)
23:18 RSpliet: "Display Driver for X.org" - the user-space module that acts as a communication layer between X.org and the in-kernel graphics drivers... basically telling the kernel driver what to do.
23:19 cosurgi: RSpliet: thanks! Does that correspond to the line Driver "nouveau" in xorg.conf ?
23:20 RSpliet: "nouveau ddx" is tailored for nouveau, "modesetting ddx" is writte for the framework nouveau is written in (called DRM), this framework is shared with the amdgpu and intel i915 driver. the latter is thus more generic, but also less well tested/debugged with nouveau
23:20 RSpliet: I... believe it does yes
23:20 cosurgi: Or maybe I should write there Driver "nouveau ddx" ?
23:20 RSpliet: Long time since I've last written an xorg.conf
23:21 RSpliet: No no, the name of the module is simply nouveau
23:21 cosurgi: Long time for me too!
23:21 cosurgi: I have some old files, like 5 or 8 years old.
23:21 imirkin_: cosurgi: Driver "nouveau" does the trick
23:22 imirkin_: note that my file is tailored for my outputs
23:22 imirkin_: ideally you will have adjusted yours to match the outputs that you ahve
23:22 imirkin_: but perhaps you can put up your xorg log on hastebin.com and it could be instructive
23:23 cosurgi: question do I need to write InputDevice sections, I see they are present in my old xorg.conf files.
23:23 imirkin_: just what i have.
23:23 imirkin_: nothing else.
23:23 cosurgi: ok
23:28 cosurgi: imirkin_: I have tailored thisxorg.conf a bit.
23:29 cosurgi: Uh, I don't know how to share text on hastebin.com
23:29 cosurgi: https://pastebin.com/gteBRmXU
23:29 imirkin_: ^S to save :)
23:30 imirkin_: that looks right.
23:30 cosurgi: I press it, and nothing happens :/ is my chromium broken? I will try qupzilla
23:30 imirkin_: (or at least not obviously wrong)
23:30 imirkin_: oh, their site is broken
23:30 imirkin_: happens every so often =/
23:30 cosurgi: ah, ok
23:30 cosurgi: if there is anything better than pastebin, just tell me
23:31 imirkin_: hastebin usually is :)
23:31 cosurgi: so the first iteration of my config is there.
23:31 imirkin_: except when it doesn't work. then it's much worse.
23:31 cosurgi: By the names you can see that DP-2 is my Left monitor, DP-1 is center and DP-3 is right.
23:32 cosurgi: and that's Xorg.0.log
23:32 cosurgi: https://pastebin.com/m7RebeB1
23:33 imirkin_: [126262.011] (EE) Unknown chipset: NV136
23:33 imirkin_: that's ... not great
23:33 imirkin_: module version = 1.0.13
23:33 imirkin_: you need 1.0.15
23:33 cosurgi: you mean kernel version?
23:33 cosurgi: Sure I can recompile
23:33 imirkin_: xf86-video-nouveau
23:34 cosurgi: I have 4.20.3 right now
23:34 imirkin_: that's the kernel
23:34 imirkin_: you want to update xf86-video-nouveau
23:34 cosurgi: ach, the debian package?
23:34 cosurgi: ok.
23:35 RSpliet: imirkin: just for what it's worth... I think with 3*4K monitors, I think the boot DRAM clock of that card must exceed ~185MHz to keep up with scanout. I take it these cards initialise to like 400MHz?
23:35 imirkin_: RSpliet: no clue
23:35 imirkin_: 3x 4k is a lot
23:35 imirkin_: that's like... 12k
23:35 imirkin_: cosurgi: the debian package might be called something else
23:35 cosurgi: I don't know. How do I check that? With nvidia drivers (and even right now) I seem to have a nice 60Hz refresh rate
23:35 imirkin_: like xorg-server-video-nouveau or something
23:36 cosurgi: I see this one xserver-xorg-video-nouveau 1:1.0.13-3 ?
23:36 imirkin_: yeah
23:36 imirkin_: make that say 1.0.15 :)
23:36 cosurgi: Can do!
23:36 imirkin_: (and there's a 1.0.16 coming out today if i can get the release scripts to work)
23:36 imirkin_: (nothing particularly useful for your situation though)
23:36 cosurgi: Just need 10 minutes at least to investigate how much recompiling is necessary
23:37 RSpliet: imirkin: Yeah... in western currency as well. I did the maths based on a 192b DRAM bus and 24bpp, which seems to match the card. Anyway, that's relevant for step 3 in debugging, first fix that outdated set up ;-)
23:37 imirkin_: RSpliet: yeah, that's when you start seeing the white snow in the output
23:38 cosurgi: I'll see what version is on devuan ceres
23:39 cosurgi: yay! ceres has 1.0.15
23:39 cosurgi: now I only neet do ap-tget source it, and apt-get build-dep
23:39 imirkin_: you're on your own for that. i know nothing about debian
23:40 cosurgi: yeah, I know this stuff
23:40 cosurgi: once I modified xserver source code to increase max window limit from 256 to 512. I was frequently opening more than 256 windows, and xserver wuold not allow that!
23:41 imirkin_: so restrictive...
23:41 imirkin_: and i thought i had a lot of windows
23:41 imirkin_: but i don't remember running into such a limit
23:43 cosurgi: recompiling xserver-xorg-video-nouveau shal be enough? I'd prefer to avoid pulling in more dependencies
23:44 imirkin_: quite enough
23:45 cosurgi: is library libcom-err2 critical?
23:45 imirkin_: never heard of it
23:45 cosurgi: If it is, I would have to pll it. Ok, will try withut it.
23:45 cosurgi: *pull(backport) it from ceres
23:46 imirkin_: the only real deps are X and libdrm_nouveau
23:46 imirkin_: and it's meant to compile with ANCIENT versions of those
23:46 imirkin_: (ok, maybe not going back to the XFree86 days...)
23:47 cosurgi: ok. Now I hope that this will work with older version of debhelper, because backporting this one is a real PITA
23:50 cosurgi: yay!
23:50 cosurgi: I have it
23:50 cosurgi: xserver-xorg-video-nouveau_1.0.15-3_amd64.deb
23:50 imirkin_: now start X again
23:50 cosurgi: xserver-xorg-video-nouveau-dbgsym_1.0.15-3_amd64.deb
23:51 cosurgi: yeah!
23:51 cosurgi: should I install debug symbols too? *dbgsym*deb ?
23:51 imirkin_: sure, why not
23:52 imirkin_: that way when it crashes, we'll know where
23:53 cosurgi: hey! first xserver started with success!
23:53 cosurgi: but I'll paste Xorg.0.log anywa for you :)
23:53 karolherbst: ahh... why doesn't the kernel sees my value I pass in :/
23:54 cosurgi: https://pastebin.com/9LGs7895
23:54 cosurgi: imirkin_: now I'll try starting a second one :)
23:55 imirkin_: [127841.651] (EE) NOUVEAU(0): Error creating GPU channel: -19
23:55 imirkin_: [127841.651] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel
23:55 imirkin_: doh!
23:55 imirkin_: can you pastebin your dmesg?
23:56 cosurgi: 2nd xserver did not work :(
23:56 cosurgi: sure one second, dmesg.
23:57 cosurgi: https://pastebin.com/Gn7hgENs
23:58 karolherbst: hihi
23:58 karolherbst: cosurgi: do you have linux-firmwares installed?
23:58 cosurgi: imirkin_: and here is the failure when starting a second xserver: https://pastebin.com/HtyFe1DS