00:25 imirkin: cosurg1__: as i recall, uptime was what was important to you
00:26 imirkin: what i'd recommend is sticking something like LIBGL_ALWAYS_SOFTWARE=1 into your /etc/environment to ensure stray applications don't try to use GL for no reason
00:26 imirkin: and then enable it explicitly when you want
00:27 imirkin: i forget if you had updated your xf86-video-nouveau ddx to a sufficiently new version to get pascal accel (as well as your kernel) - if not, that's going to be a big change too
10:19 cosurgi: imirkin: thanks. I am now in the process of upgrading both kernel and all packages. Going from devuan ascii to devuan beowulf (testing). I will compile newest kernel 5.2.1 too.
11:10 cosurgi: whoa
11:13 cosurgi: this is super strange. I didn't restart yet. The packages are installed, but I have no new kernel and no new mesa packages. And suddenly `LIBGL_DEBUG=verbose glxinfo -B` shows "Device: NV136 (0x1c03)" Instead of "Device: llvmpipe (LLVM 3.9, 256 bits) (0xffffffff)". And that steam game works!
11:13 cosurgi: Before reboot!
11:13 cosurgi: This bodes well for the future :)
11:14 cosurgi: I didn't even restart the xserver. Which is strangest of all.
11:47 cosurgi: Correction to previous statement: I have new mesa packages. In fact all my packaes are new, from newer linux distribution. I just didn't restart xserver
11:47 cosurgi: and suddenly the game has working graphics acceleration :)
11:57 karolherbst: tagr: I've got myself a jetson nano and I was wondering what's the best way to run nouveau with it :D I guess I would need to use the arm-next tree or wherever the tegra code was merged in, but I am more interested in how I can just flash just a custom distribution to the disc (I already downloaded the tools to prepare the disc image with all the partitions and stuff, so that works)
11:58 karolherbst: I am sure I will run into random nouveau issues, but those I can handle myself then
11:58 karolherbst: I think the bootloader looks for a /boot/Image file or something... but is there a partition I can mess with to add custom entries? I know something like that was possible with the TX1
11:59 karolherbst: (I also want to compile a custom uboot at some point to be able to netboot the jetson nano, but that's for later)
12:03 cosurgi: imirkin: I've put "export LIBGL_ALWAYS_SOFTWARE=1" to ~/.xsession; I use startx and .xsession does all preparation locales and other config stuff for my X session.
12:04 cosurgi: imirkin: it means that if I want GPU acceleration I just "export LIBGL_ALWAYS_SOFTWARE=0" in some xterm, and then start that program which can use it?
12:05 cosurgi: pmoreau: ?
13:27 cosurgi: looks like I can't start a new xserver though
15:02 karolherbst: ufff
15:02 karolherbst: nouveau doesn't boot with the jetson nano.. werid
15:02 karolherbst: *wierd
15:03 karolherbst: uff, some IOMMU fail
15:03 karolherbst: tagr: any ideas?
15:04 karolherbst: heh.. third time booting and it works
15:04 karolherbst: now just gdm fails, but that's expected
15:56 karolherbst: tagr: "Tegra210: unknown SKU 0x8f"
16:06 imirkin: cosurgi: unset it to be safe, yeah
16:07 imirkin: cosurgi: the only bit you had been missing was a newer mesa to get accel - no restart of things needed - that was expected.
16:08 imirkin: cosurgi: did you work out your xserver woes?
16:14 cosurgi: imirkin: not yet. I am compiling kernel now. Still didn't reboot. I suppose that a new xserver can'tstart because all the (newly installed) binaries are compiled with another compiler than the running kernel.
16:15 cosurgi: It's surprising that the old xserver which I didn't stop, is still running :)
16:15 imirkin: check the logs
16:15 imirkin: binaries tend to run once they start ...
16:17 cosurgi: imirkin: https://paste.ubuntu.com/p/3CrTZQDsPG/ - this is Xorg.log of xserver that refuses to start. But as I said: this is an xserver from devuan bewulf package gcc 8.3 while kernel was compiled with gcc 6.3
16:17 cosurgi: I am compiling kernel 5.2.1 now.
16:18 imirkin: actually this is expected.
16:18 imirkin: i tried to fix this bug, but ... basically couldn't
16:18 imirkin: without rewriting a lot of core X stuff
16:18 imirkin: long story short, there's a workaround
16:18 cosurgi: but this is fun: graphics acceleration works on an xserver which was sterted before devuan stable→testing upgrade and is already running
16:19 imirkin: X must be run with -noreset
16:19 cosurgi: oh, I will try that.
16:20 imirkin: the issue is that when you hit a CloseScreen, it tries to tear things down. but there's an ordering issue between tearing down of EXA and of the shadow pixmaps used to implement monitor rotation
16:20 imirkin: without reordering things in X core, this is unfixable. however doing so will likely have other side-effects
16:20 cosurgi: `startx -- -nolisten tcp -dpi 100 -noreset` ← like this? It didn't help.
16:20 imirkin: yes
16:21 cosurgi: Do you want to see the new Xorg.log ?
16:21 imirkin: sure
16:21 imirkin: the old backtrace is definitely dying in xf86RotateCloseScreen
16:21 imirkin: which is precisely the issue i had
16:21 cosurgi: https://paste.ubuntu.com/p/TYX2mZmX2C/
16:21 imirkin: ok, same backtrace...
16:22 cosurgi: error liks exactly the same. Only dates have changed.
16:22 imirkin: i'm not familiar with startx
16:22 imirkin: i mean - i am (or was), but not with its args
16:22 cosurgi: I can try X directly.
16:22 imirkin: does that -noreset make it to X directly?
16:22 cosurgi: I am not sure :/
16:22 cosurgi: should I try `X -noreset` ?
16:22 imirkin: or are those args to like xinit
16:22 imirkin: welllll...
16:22 imirkin: the issue isn't with X itself
16:22 imirkin: the issue is that some client starts and then exits
16:23 imirkin: this triggers a screen "do-over"
16:23 imirkin: and that do-over is what fails
16:23 cosurgi: I am prepared for a reboot anyway. There is no need to try to fix this :)
16:23 imirkin: this isn't a reboot issue
16:23 cosurgi: Unless you are courious, in that case I am glad to produce more backtraces :)
16:23 cosurgi: oh
16:23 imirkin: i mean, it's not an issue that will be fixed by reboot
16:24 cosurgi: whoops. Now it sounds bad.
16:24 imirkin: it's an issue that happens when you use the nouveau ddx + exa + screen rotation
16:24 imirkin: (or really, when you use exa + screen rotation)
16:24 cosurgi: But I have a fresh new devuan testing. All packages reinstalled. I made sure there is nothing leftover.
16:24 imirkin: like i said, i was unable to fix this issue
16:25 imirkin: the -noreset workaround works for me
16:25 imirkin: i have 2x rotated monitors too
16:25 cosurgi: You mean that in new version it won't work?
16:25 imirkin: yes.
16:25 cosurgi: oops :(
16:25 imirkin: yes.
16:25 imirkin: oops.
16:25 imirkin: noreset fixed it for me... the issue i had was that gdm would hand off to the window manager
16:25 cosurgi: ok. Se we better find how to use this -noreset or anything else before I reboot. Otherwise without graphics it will be tough deal.
16:26 imirkin: and in that hand off is where it would crash
16:26 imirkin: so ... i see you're starting the screen on :6 -- where is that configuration done?
16:27 imirkin: also this is only an issue with xorg 1.20 i think?
16:27 imirkin: not 100% sure
16:27 imirkin: i had tracked this down... now just need to dreg through irc logs
16:28 cosurgi: Which configuration? I press ctrl-alt-F4 (not F6 actually) and type `startx -- -nolisten tcp -dpi 100 -noreset`
16:28 imirkin: btw - it's also expected that it will crash on exit
16:28 cosurgi: perhaps it is allocating :6
16:33 imirkin: well, you can also run it with NoAccel which will "fix" the issue
16:33 cosurgi: that is something.
16:34 imirkin: iirc it's new in xorg 1.20
16:34 imirkin: which probably explains the discrepancy - you were on 1.19 before but on 1.20 now?
16:36 cosurgi: yes, xserver-xorg-core was 1.19
16:36 cosurgi: Should I downgrade maybe?
16:36 imirkin: if it's easy, sure. otherwise i bet i can figure out what's going wrong in your .xsession
16:37 cosurgi: Section "Device"
16:37 cosurgi: Identifier "Card0"
16:37 cosurgi: Driver "nouveau"
16:37 cosurgi: BusID "PCI:4:0:0"
16:37 imirkin: basically the issue happens when the LAST x client disconnects
16:37 cosurgi: Option "Monitor-DP-2" "MonLeft"
16:37 cosurgi: Option "Monitor-DP-1" "MonCenter"
16:37 cosurgi: Option "Monitor-DP-3" "MonRight"
16:37 cosurgi: Option "NoAccel"
16:37 cosurgi: EndSection
16:37 cosurgi: I added Option "NoAccel" - it didn't help
16:37 imirkin: so ... the idea is make sure your window manager is the only X client
16:37 imirkin: probably have to give it a value
16:37 imirkin: like "true"
16:38 cosurgi: Hm, still doesn't work.
16:38 imirkin: log?
16:39 cosurgi: https://paste.ubuntu.com/p/7CmF4JbBRW/
16:39 cosurgi: [1360136.275] (**) NOUVEAU(0): Option "NoAccel" "true"
16:39 imirkin: note that it's a different cras h;)
16:39 cosurgi: but you said that something in my .xsession is the problem, because it usually happens when exiting X, not when starting X ?
16:40 imirkin: yes
16:40 imirkin: so ... imagine that the year is 1970
16:40 imirkin: you start the X server once
16:40 imirkin: and then you might have multiple sessions on it
16:40 imirkin: you have to clean things up in between
16:40 imirkin: so once the last X client disconnects, it goes through a "reset" cycle
16:40 imirkin: that's what -noreset prevents
16:40 imirkin: but i really don't know why that's not helping you
16:42 cosurgi: downgrading xserver is simple for me. I can do that.
16:42 imirkin: try that.
16:42 cosurgi: ok. give me 10 to 15 minutes
16:42 imirkin: make sure xf86-video-nouveau gets rebuilt
16:42 cosurgi: ok.
16:42 imirkin: otherwise there will be an ABI mismatch
16:43 cosurgi: Tha would mean rebuilding xserver-xorg-core and xserver-xorg-video-nouveau, right?
16:43 cosurgi: I think xf86-video-nouveau is called xserver-xorg-video-nouveau in devuan.
16:43 imirkin: well ... downgrade xorg-core
16:43 imirkin: but ...
16:43 imirkin: if you're game, i'd like to figure out wtf is going on
16:43 cosurgi: sure
16:43 cosurgi: we can do that
16:43 cosurgi: remember I still didn't reboot.
16:43 imirkin: remind me - you're a developer, right?
16:44 cosurgi: yeah, but not kernel developer :)
16:44 imirkin: sure. but i can get you to add prints in places without sending you diffs :)
16:44 cosurgi: scientific software developer. My package is this https://yade-dem.org/doc/ and https://gitlab.com/yade-dev/trunk/activity
16:44 imirkin: right yeah
16:45 cosurgi: yeah. You would just need to tell me the line numbers :)
16:45 imirkin: ok, so let's think...
16:46 imirkin: why is there no debug info for nouveau_drv?
16:47 cosurgi: that one is from kernel package?
16:47 imirkin:wonders if it *would* be fixed by a reboot ...
16:47 imirkin: no - [1350557.831] (EE) unw_get_proc_name failed: no unwind info found [-10]
16:47 imirkin: [1350557.831] (EE) 10: /usr/lib/xorg/modules/drivers/nouveau_drv.so (?+0x0) [0x7f195349de70]
16:47 cosurgi: if you promise me that text virtual terminal rotation will work after reboot, then I can reboot :)
16:48 cosurgi: heheh. I cant rotate back these huge screens. If it doesn't it will be top priority to fix, before fixinf xservers.
16:48 imirkin: just lie down on your desk :p
16:48 cosurgi: hahah :)
16:48 imirkin: here's the alternative
16:49 imirkin: you build a copy of X
16:49 cosurgi: anyway. The kernel 5.2.1 is compiled. I could reboot soon. Or recompile xserver-xorg-core, xserver-xorg-video-nouveau. Whichever you think is more useful.
16:49 imirkin: and run *that*
16:49 imirkin: and then we can add prints and whatnot
16:49 cosurgi: ok. So which version. 1.20 or 1.19 with print in it? I can do both also :)
16:49 imirkin: so here's a question...
16:49 imirkin: actually hold
16:50 imirkin: can i just see your xsession?
16:50 imirkin: like why are there all these "UnloadModule" thigns at the end
16:50 cosurgi: you mean ~/.xession file ?
16:50 imirkin: it feels like X is trying to exit, and is just crashing on exit
16:50 cosurgi: sure: https://paste.ubuntu.com/p/p3b5hzdfP7/
16:51 imirkin: can you simplify it
16:51 imirkin: and like ... on line 1
16:51 cosurgi: I didn't clean it up. Perhaps I should. Yeah.
16:51 imirkin: just do like
16:51 imirkin: "exec xterm" ?
16:51 cosurgi: sure, can do :)
16:53 cosurgi: wow. Now it started :)
16:53 imirkin: if that works, then try to execute that AppRun thing
16:53 imirkin: from within the xterm
16:53 imirkin: my GUESS is that it will fail somehow
16:53 cosurgi: okay.
16:54 cosurgi: but funny thing: when I switched back to the xserver where I was compiling kernel - that xserver crashed.
16:54 imirkin: hilarious =/
16:55 cosurgi: actually every other xserver where I switch - is crashing. I had a few of them still running.
16:55 imirkin: that could be because of dynamic library stuff :(
16:55 imirkin: dunno
16:56 cosurgi: not a problem. OK. I will try that AppRun stuff
16:59 cosurgi: uh.
16:59 cosurgi: exec "${HOME}/usr/share/ROX/ROX/ROX-Session/AppRun" -w
16:59 cosurgi: that line closes the xterm in which I run it
16:59 imirkin: you probably don't want the exec :)
16:59 cosurgi: ahhh
16:59 cosurgi: yeah. It's all clear now:
16:59 cosurgi: libpangoxft-1.0.so.0: cannot open shared object file: No such file or directory
17:00 imirkin: aha, that's probably not ideal
17:00 cosurgi: sorry for bothering you with this.
17:00 imirkin: so anyways, it tries to exec, then on X server exit, hits the thing i was talking about
17:00 imirkin: which is expected
17:00 imirkin: (albeit unfortunate)
17:00 cosurgi: I upgraded everything. But my rox-session binary is a local stuff, not the one from devuan distro
17:00 imirkin: i do believe the -noreset should fix the "normal" case of the last X client disconnecting
17:01 imirkin: which really should happen VERY rarely in practical setups
17:01 cosurgi: ok. I need to find that libpangoxft-1.0.so.0 :)
17:01 imirkin: btw, downgrade of X wouldn't have helped
17:01 imirkin: at least i don't think
17:04 cosurgi: yes! It works :)
17:04 cosurgi: I installed necessary libraries and my xserver start just like before
17:04 cosurgi: and I still didn't reboot!
17:05 cosurgi: with that fancy ~/.xsession which you have seen.
17:06 cosurgi: wow. I can toggle between 'Device: llvmpipe (LLVM 7.0, 256 bits) (0xffffffff)' and 'Device: NV136 (0x1c03)' with export LIBGL_ALWAYS_SOFTWARE=0
17:07 imirkin: neat-o
17:08 cosurgi: so I don't need to recompile xserver-xorg-core, xserver-xorg-video-nouveau ?
17:08 imirkin: nope
17:08 cosurgi: but still I was planning to recompile latest mesa packages
17:08 imirkin: what version are you on?
17:09 cosurgi: 18.3.6-2
17:09 cosurgi: I was thinking about switching to 19.1.2-1
17:10 imirkin: meh - only very mild improvements
17:11 imirkin: note that you will now be getting acceleration on the "2d" operations that the X server does, whereas i'm not sure that you did previously
17:11 cosurgi: Is there more risk involved, or these were bugfixes?
17:11 imirkin: both :)
17:12 cosurgi: I'm not sure either. But xcompmgr transparent and inverse colors windows worked. For 5 minutes, then I had xserver crash - you told me it's because it's poor memory managment.
17:13 cosurgi: they work now too.
17:13 imirkin: you could try it again and see what happens
17:13 imirkin: maybe it'll last 6 mins now :)
17:13 cosurgi: yeah. We will see, yeah.
17:13 imirkin: 20% improvement!
17:13 imirkin: (secretly, i work in marketing)
17:13 cosurgi: :-))
17:15 cosurgi: so I wonder - I am safe to reboot now? I just installed the just compiled 5.2.1 kernel
17:16 cosurgi: xserver works nicely on old kernel. So it should work after reboot, right?
17:16 imirkin: make sure your seatbelt has been tightened
17:17 imirkin: (one way to find out, eh)
17:17 cosurgi: :)
17:17 imirkin: if i never hear from you again, i guess i'll know why
17:17 cosurgi: ehh (No space left on device) while installing kernel
17:17 cosurgi: I need to clean up
17:17 imirkin: haha
17:24 cosurgi: ok! rebooting now.
17:25 cosurgi: I logged into irc from another device. Watching my computer reboot now :)
17:26 cosurgi: yay! text terminal are rotated!
17:26 cosurgi: oops. I've set too high debug level in nouveau
17:26 cosurgi: lots of "FAN target request: 40%" messages
17:27 cosurgi: I fiddled with kernel config a bit :)
17:27 imirkin: lot of good that does - we can't control the fan directly
17:27 imirkin: yeah, you really don't want to change those options from the defaults
17:27 imirkin: unless you are ... skeggsb.
17:27 imirkin: and even there, it's questionable
17:32 imirkin: cosurgi: most importantly don't increase the "max" debug level config option
17:33 imirkin: i.e. make sure NOUVEAU_DEBUG stays at 5
17:34 cosurgi: ok :)
17:34 cosurgi: Is it configurable runtime, or I need to recompile kernel?
17:34 imirkin: NOUVEAU_DEBUG is the max to compile for
17:34 cosurgi: and yeah, I changed exactly this one, to 6 :) Sorry about that
17:35 imirkin: the higher levels are super-expensive
17:35 imirkin: even when not enabled
17:35 imirkin: NOUVEAU_DEBUG_DEFAULT should stay at 3
17:35 cosurgi: I think these were 5 and 3.
17:35 imirkin: but that is runtime configurable
17:35 cosurgi: before I changed them
17:35 imirkin: yes
17:35 cosurgi: Also I disabled something legacy _CTX, because in description you said it is better disabled
17:36 imirkin: this doc has a nice section on defaults: https://www.dourish.com/goodies/see-figure-1.html
17:36 imirkin: yeah, that one's ok to disable :)
17:37 cosurgi: ok. So I need to rebuild kernel with new DEBUG settings?
17:37 imirkin: i'd encourage that
17:37 cosurgi: btw, startx worked!
17:37 cosurgi: OK :)
17:38 imirkin: and while you build, read that link :)
17:38 imirkin: (if you haven't seen it before)
17:38 cosurgi: ok. Thanks!
17:41 cosurgi: omg lolol :)))
17:41 cosurgi: I get it "mandatory defaults" :)
17:41 cosurgi: Usually I kept copying kernel config from previous kernel and recompiled with the new.
17:42 imirkin: ya that's what i do
17:42 imirkin: make oldconfig
17:42 imirkin: i figure it out from ~scratch whenever i get a new computer
17:42 imirkin: so it happens every 10y or so :)
17:42 cosurgi: Then one day sdcard stopped working opn my laptop after an upgrade. But it worked on debian stock kernel
17:43 imirkin: yeah..... that happens =/
17:43 cosurgi: After some digging I found out that this make oldconfig somehow disabled by default the driver which I needed.
17:43 cosurgi: And that was part of raid-0, so I had no access to home. The builtin HDD was too small for me
17:44 cosurgi: So since then I sometimes compare my config with the debian stock kernel config.
17:44 imirkin: wise.
17:44 cosurgi: And that's what I did today. And I get it - it wasn't wise that I saw the NOUVEAU settings. And since I'm concerned with that one, I wanted to make settings better than default ones ;)
17:45 cosurgi: Sorry for that
17:45 cosurgi: So I disabled backlight (not needed for regular PC), disabled *_CTX and increased DEBUG :>
17:46 imirkin: dumping that legacy context thing is fine
17:46 imirkin: it's for a fairly old version of xf86-video-nouveau
17:46 imirkin: but i wouldn't mess with the debug settings
17:46 cosurgi: aye, aye sir!
17:46 cosurgi: but it's still compiled as module though. Do I want to built it into kernel?
17:47 imirkin: i would advise against that
17:47 cosurgi: good :)
17:47 cosurgi: so it will stay as module
17:47 imirkin: if you build it into the kernel, then you have to build the firmware into the kernel too iirc
17:47 imirkin: via CONFIG_EXTRA_FIRMWARE
17:47 cosurgi: ouch
17:49 cosurgi: ok. sorry. I need to leave now. I'm going with my wife to see some interesting popular science lecture. She found this one. Something about lunar bases, chineese radiotelescope and photographing a blackhole.
17:49 cosurgi: I should be back in couple hours.
17:49 imirkin: and i think you know this, but i'll say it anyway - your card is running at lowest clocks and nouveau can't change it. so expect MUCH worse perf than with blob.
17:49 imirkin: like ... 5-10% of perf.
17:49 cosurgi: yeah I know
17:49 cosurgi: performance is not a problem
17:50 cosurgi: the real problem with nvidia was that it totally locked up my computer once every 4 or 6 months
17:50 imirkin: i suspect nouveau will too =/
17:50 cosurgi: nouveaus just crashes an xserver. Much better. I still have other xservers running.
17:50 imirkin: hehe
17:50 imirkin: well, once you start playing games ...
17:51 cosurgi: it's a separate xserver that can crash with the game in it.
17:51 cosurgi: We will see
17:51 cosurgi: once it locks up my computer totally. I will buy amdgpu, like you told me to
17:51 imirkin: we do tend to have reasonable isolation, but sometimes the card just gets wedged
17:51 imirkin: hehe
17:51 cosurgi: ok. See you later :)
20:33 cosurgi: imirkin: I found option CONFIG_DRM_FBDEV_OVERALLOC=100; Could it help with these 'poor memory managment' issue which causes xserver to crash? With xcompmgr it's 5 minutes, without it's a month or two.
20:33 cosurgi: Or it's just totally unrelated?
20:33 imirkin: entirely unrelated.
20:33 cosurgi: ok
20:33 imirkin: does xcompmgr still die?
20:33 cosurgi: Ah, I don't know yet.
20:33 cosurgi: I will start it. Kernel recompilation is in screen, so xserver can die :)
20:34 cosurgi:makes a dozen of transparent windows.
20:35 cosurgi: heh, refresh is noticeably slower. But manageable.
20:35 cosurgi: we have to wait a bit, though.
20:35 imirkin: you're not using NoAccel anymore, right?
20:36 cosurgi: no. But I have this `export LIBGL_ALWAYS_SOFTWARE=1
20:36 imirkin: right
20:36 cosurgi: ` inside ~/.xsession.
20:36 imirkin: not 100% sure how xcompmgr works ... i assume Xrender, which should still be accelerated
20:37 imirkin: yeah looks like it
20:38 cosurgi: that's my present Xorg.log: https://paste.ubuntu.com/p/qDyzmxBvms/
20:39 cosurgi: I think it says we have acceleration:
20:39 cosurgi: [ 9448.151] (II) Composite (RENDER acceleration)
20:39 imirkin: looks fine ... except those -2's ... ENOENT ... hmm
20:39 imirkin: we have a few places where we print a raw error code like that
20:39 cosurgi: yeah, you promiset last time to improve this error message ;)
20:39 imirkin: my promises are soon forgotten
20:40 cosurgi: heheh :) I don't mind. The point is, you know what these -2 mean
20:41 cosurgi: interesting. Still no xserver crash. With so many windows open it should crash.
20:41 cosurgi: I remember I real stress test: open a .pdf file, and make window 5 times the size of my screens.
20:41 cosurgi: Let's try that.
20:42 cosurgi: window has size 16000x16000
20:42 cosurgi: And is transparent
20:42 cosurgi: I see small part of it
20:42 cosurgi: still no crash
20:42 cosurgi: wow
20:42 cosurgi: I'm carefully optimistic.
20:43 cosurgi: I have a hotkey in my window manager (sawfish) to make window twice the size and half the size.
20:43 cosurgi: It's useful sometimes ;)
20:43 cosurgi: lol.
20:44 imirkin: ok, so that -2 is the return of nouveau_bo_new
20:44 cosurgi: the pdf viewer dies when I tried to make it twice the size, again.
20:44 imirkin: ENOENT means ... i have no idea what
20:44 imirkin: skeggsb: how can nouveau_bo_new return ENOENT??
20:44 imirkin: cosurgi: max RT size is 16k. i'm sure we don't handle windows larger than that.
20:45 cosurgi: no. The pdf viewer didn't die! I just stopped seeing it. I had to press 'q' because it was on top, invisible and I had no access to other windows below it.
20:45 imirkin: yeah. probably because the blit failed
20:45 imirkin: do you see something in dmesg?
20:45 imirkin: about invalid bits being set?
20:45 cosurgi: uhh
20:46 cosurgi: my dmesg is a mess. I am recompiling kernel with smaller DEBUG level
20:46 cosurgi: but I can grep it
20:46 imirkin: grep 'nouveau E'
20:46 imirkin: er crap, that doesn't work anymore
20:46 cosurgi: nope, nothing. dmesg empty
20:46 imirkin: the "dmesg" tool somehow knows what's at what level
20:47 cosurgi: I can dmesg to file, and search there
20:47 imirkin: "dmesg -l err"
20:47 imirkin: do you see anything nouveau-related int here?
20:47 cosurgi: hm. Actually it comes up empty
20:47 imirkin: ok, so no errors
20:47 cosurgi: like I had no errors at all, recently
20:48 imirkin: aha - we always fall back for RT > 8192
20:48 imirkin: this is bogus, but i guess we're lazy
20:48 imirkin: iirc the 2d engine can handle 32k
20:48 imirkin: (coz no MS)
20:49 cosurgi: what is MS ?
20:49 imirkin: multisampling
20:50 cosurgi: yeah, definitely xserver would have crashed by now with all the xcompmgr stuff around.
20:50 cosurgi: But it didn't.
20:50 imirkin: alright, well, let us know if you run into bugs
20:51 cosurgi: sometimes it was crashing after plenty of xterm scrolling or chromium website refreshes
20:51 cosurgi: and that was due to the same problem right?
20:52 imirkin: xserver should never crash
20:52 cosurgi: that's my wet dream :)
20:52 imirkin: i haven't personally seen that
20:52 imirkin: now, certain applications destroy the channel
20:52 imirkin: which in turn takes down the X server
20:52 imirkin: which shouldn't happen since they're all separate, but does anyways
20:53 imirkin: the X server ends up waiting on something? or something else? dunno.
20:54 cosurgi: ahh.. I will have to test hibernation on this new kernel.
20:54 imirkin: there's a 97% chance that will fail
20:55 cosurgi: I'm more optimistic :)
20:55 cosurgi: There are 3 lines of my code in the kernel that fixed one bug which I had with hibernation.
20:55 cosurgi:goes on to unplog UPS frmo the electric outlet.
20:57 imirkin: looks like our accel ends at 8k right now. this could easily be 16k on fermi+, but we never bothered
20:57 imirkin: should probably enable that, since 3x 4k screens side-by-side blow through the 8k limit
21:05 cosurgi: imirkin: should I enable this in mu computer?
21:05 cosurgi: or doesn't matter too much?
21:06 cosurgi: I'm not planning to play games 'full3screens'
21:07 imirkin: enable what?
21:13 cosurgi: 'accel that ends at 8k right now.' ?
21:13 cosurgi: yay! resuming from hibernation worked!
21:14 cosurgi: and kernel has just finished compiling.
21:14 imirkin: well, that would require code changes
21:14 imirkin: and most importantly - testing
21:14 imirkin: with pixmaps that are > 8k in size.
21:15 cosurgi: you mean 8000x8000 pixels?
21:16 imirkin: 8192
21:16 cosurgi: or 8192x8192
21:16 cosurgi: ok
21:16 cosurgi: funny thing with these Dell LCD screens. They produce annoying quiet noise. But when I do `xset dpms force off`, wait 30 seconds, then wake them up - the noise is gone and they are silent/
21:34 cosurgi: ok. I booted the new (hopefully final) kernel.
21:35 cosurgi: with default debug level :)
21:35 imirkin: well, default debug level can be changed. the max debug level is the important one
21:35 cosurgi: yeah. I changed both
21:35 cosurgi: back.
21:36 cosurgi: I see some oops message in kernel.
21:37 cosurgi: I will paste it, if you want to see it.
21:37 cosurgi: That's the Xorg.log: https://paste.ubuntu.com/p/9QhnwrNnC4/ and that's dmesg: https://paste.ubuntu.com/p/nZKh55jmz8/
21:38 cosurgi: it's at the end of dmesg
21:38 imirkin: yeah, don't worry about that
21:38 imirkin: everyone except skeggsb gets that
21:38 cosurgi: why doesn't? :)
21:39 cosurgi: why he doesn't? :)
21:39 imirkin: if he saw it, he'd fix it
21:39 cosurgi: ah okay :)
21:39 imirkin: as is, he says it can't happen
21:39 cosurgi: makes sense.
21:39 imirkin: :)
21:39 imirkin: (obviously it does, but it's unclear how it can)
21:39 imirkin: all this stuff is behind 30 levels of abstraction (VMs are hard), so ... not surprising
21:46 karolherbst: :( it seems like our tegra code is a little broken
21:47 karolherbst: https://i.imgur.com/p9mqGoI.jpg
21:47 karolherbst: but... I kind of blame the iommu stufff
22:03 cosurgi: in separate xserver I launched steam game 'cities skylines' lets see if it will be playable...
22:03 cosurgi: hm. need to decrease graphcis settings, but performance is not abysmal which is good
22:04 cosurgi: also I made that window to be only 2160x1680
22:05 karolherbst: well, perf wise you won't have much fun witha gp107
22:05 karolherbst: uhm gp106
22:06 cosurgi: Device: NV136 (0x1c03)
22:06 cosurgi: I don't mind
22:06 cosurgi: hm, with lowest graphics settings it is almost playable.
22:11 imirkin: cosurgi: reduce resolution more ... you can do it by reducing the mode on a monitor
22:11 imirkin: (which you can do dynamically with xrandr)
22:11 imirkin: and e.g. run it at 1024x768 or whatever
22:22 cosurgi: hm. I've set window size to 800x600 and the speed feels the same as when it was 2160x1680
22:22 cosurgi: though no fps counter setting. At least I didn't found it.
22:37 imirkin: yeah, could be other constraints