[08:17] <KitsuWhooa> alkisg: I ran xrandr -s 640x480 on X running under valgrind without any clients, and it segfaulted
[08:17] <KitsuWhooa> on a card that only had corruption before
[08:17] <KitsuWhooa> this is just getting worse and worse :p
[08:18] <KitsuWhooa> it doesn't segfault outside valgrind
[08:19] <alkisg> Heh
[08:19] <alkisg> Did valgring produce any helpful output on that segfault?
[08:20] <KitsuWhooa> I think it did but xterm doesn't have a buffer
[08:20] <KitsuWhooa> at least I don't think so
[08:20] <KitsuWhooa> is it possible to set a custom terminal for epoptes?
[08:20] <alkisg> If you're using the remote thing, it's screen, so you press Ctrl+[, then A, and you can scroll
[08:20] <alkisg> (GNU screen)
[08:20] <KitsuWhooa> Oh it's ran under screen
[08:20] <alkisg> Sry
[08:21] <KitsuWhooa> I tried ^B thinking it's tmux
[08:21] <alkisg> Ctrl+A, then [
[08:21] <KitsuWhooa> :p
[08:21] <KitsuWhooa> yeah
[08:21] <KitsuWhooa> thanks
[08:21] <alkisg> np
[08:21] <KitsuWhooa> I somehow broke it XD
[08:21]  * KitsuWhooa runs man screen
[08:22] <KitsuWhooa> it's definitely having update issues
[08:28] <KitsuWhooa> oh it's not a segfault
[08:28] <KitsuWhooa> it's a sigabrt
[08:29] <alkisg> When does that happen? Double free()?
[08:30] <KitsuWhooa> IIRC when an invalid pointer is being accessed/dereferenced
[08:30] <KitsuWhooa> could be wrong
[08:30]  * alkisg reads https://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-6 ...
[08:31] <KitsuWhooa> it seems to have been thrown by strdup in libdrm.so
[08:31] <KitsuWhooa> this is going well :p
[08:31] <alkisg> Haha
[08:31] <alkisg> You're catching a lot of fishes with this issue :D
 IIRC when an invalid pointer is being accessed/dereferenced <-- nope, got it confused with sigbus
[08:32] <KitsuWhooa> way too many
[08:33] <KitsuWhooa> I see nouveau_vieux  in the backtrace
[08:33] <KitsuWhooa> "nouveau_vieux_dri.so is a classic Mesa DRI driver, and not a Gallium3D driver, because these cards do not have enough shader capabilities to reasonably support the Gallium3D infrastructure. "
[08:33] <KitsuWhooa> "Do not file bug reports about this driver. "
[08:34] <alkisg> In the past I was adviced to "rm -f" it to work around some bugs in tnt2, and it did work around them, but in this case rm'ing it didn't help
[08:34] <alkisg> (I was adviced about it in #nouveau)
[08:35] <KitsuWhooa> yeah, the original segfault backtrace doesn't contain it
[08:39] <KitsuWhooa> I wonder if it's valgrind's strdup that causes the abort
[08:40] <KitsuWhooa> either way, it happens after I call xrandr to resize
[08:42] <KitsuWhooa> if you're curious, this is what gets thrown right after I call resize https://tasossah.com/txt/valgrind_x_resize
[08:50] <alkisg> KitsuWhooa: would that advice from the last line help? Use --track-origins=yes to see where uninitialised values come from
[08:53] <KitsuWhooa> I may do that later
[08:53] <KitsuWhooa> I deleted nouveau_vieux and it no longer crashes
[08:54] <KitsuWhooa> bad news is I don't think valgrind printed anything while switching resolutions
[09:01] <alkisg> I think xrandr is correctly initializing the previously uninitialized variables, so I wouldn't expect valgrind to complain when using xrandr...
[09:02] <KitsuWhooa> I'd assume initializing them means "using" them
[09:02] <KitsuWhooa> which is why I'd expect valgrind to complain
[09:03] <KitsuWhooa> Also, the moment the mate session started, epoptes killed the remote terminal that ran mate-session, and the session died :p
[09:04] <alkisg> x=1 initializes x without reading its uninitialized value
[09:04] <KitsuWhooa> Hm, fair enough I guess
[09:04] <KitsuWhooa> So, I can start the session with and without xrandr and compare
[09:05] <KitsuWhooa> because if I run xclock without the session running, it doesn't do double buffering and there's no corruption
[09:07] <alkisg> Maybe `caja -n` could reproduce it without a full session
[09:08] <KitsuWhooa> I doubt it, but I can try it
[09:09] <KitsuWhooa> So, epoptes died and I can't open a remote shell
[09:09] <KitsuWhooa> the currently open one is stuck and won't respond to Ctrl C
[09:09] <KitsuWhooa> I can't switch to a VT because X won't release the keyboard
[09:09] <KitsuWhooa> and I don't think sysrq is enabled
[09:11] <alkisg> KitsuWhooa: if you're still seeing the client in epoptes, try executing from epoptes this command: sudo openvt bash
[09:11] <KitsuWhooa> it's not seeing it
[09:11] <alkisg> Eh, would need to reboot then :/
[09:12] <KitsuWhooa> I'll go update the squashfs image since I'm at it, then
[09:12] <KitsuWhooa> it's getting annoying having to reinstall valgrind on every boot :p
[09:29] <KitsuWhooa> caja -n did nothing. It exited
[09:30] <KitsuWhooa> oh, compiz is installed
[09:30] <KitsuWhooa> compiz should do it
[09:30] <KitsuWhooa> nope
[09:31] <KitsuWhooa> neither compton
[09:31] <alkisg> The default display manager is marco
[09:32] <KitsuWhooa> Ah
[09:32] <KitsuWhooa> eeeeyup
[09:32] <KitsuWhooa> starting marco did it
[09:32] <KitsuWhooa> now I'm looking at a very groovy corrupt glxgears :p
[09:32] <alkisg> Hehe
[09:33] <alkisg> I think the following would make testing easier for you, in lts.conf: LDM_USERNAME=kitsu, LDM_PASSWORD=yourpass, LDM_GUESTLOGIN=True, LDM_SESSION=xterm.
[09:33] <alkisg> With those, on the client login screen, you'd click "login" and you'd get xterm and an sshfs /home/kitsu mount to be able to copy things around.
[09:33] <alkisg> And from that xterm, you'd run marco or whatever else
[09:34] <alkisg> (a [Login as guest] button would appear with those vars)
[09:34] <alkisg> (which would log you in as kitsu, not as "guest")
[09:37] <KitsuWhooa> I'll have a look in a bit
[09:37] <KitsuWhooa> thanks
[11:05] <KitsuWhooa> alkisg: I compared the valgrind output of starting marco with both double buffering enabled and disabled
[11:05] <KitsuWhooa> it was completely identical
[11:07] <KitsuWhooa> I'll try with glxgears to see if I get anything else
[11:07] <alkisg> KitsuWhooa: valgrind marco, or valgrind xorg and then start marco?
[11:08] <KitsuWhooa> the latter
[11:08] <alkisg> And "double buffering disabled" means "pageflip off"?
[11:09] <KitsuWhooa> yup
[11:10] <alkisg> Hrm, I feel that's bad news, that valgrind can't help in this case...
[11:10] <KitsuWhooa> nothing useful with glxgears either
[11:11] <KitsuWhooa> https://tasossah.com/txt/marco_pageflip
[11:11] <KitsuWhooa> this is after X is done initialising and from the moment marco was started
[11:11] <KitsuWhooa> none of these look related to me
[11:12] <alkisg> Well if they're the same in both cases, when it works and when it doesn't... meh
[11:13] <KitsuWhooa> yeah, they are
[11:15] <alkisg> KitsuWhooa: hmm would it be possible that it's actually a bug in marco and not in xorg? I mean, the one we're looking for...
[11:16] <alkisg> Would valgrind marco show it then?
[11:18] <KitsuWhooa> I really doubt it's a marco bug
[11:18] <KitsuWhooa> in any case, marco shouldn't make X segfault with the Riva
[11:18] <alkisg> I mean, of course "somexorgfunction(bad parameters)" crashing would be a problem in both sides,
[11:19] <alkisg> but if the problem of bad parameters is in marco, maybe that's the one we're looking for
[11:19] <alkisg> Other window managers might not send bad parameters and not make corruption/crashes
[11:19] <KitsuWhooa> if that was the case, the segfault would happen in the client handling code on X
[11:19] <KitsuWhooa> not exa
[11:20] <alkisg> I'm sure there's a problem in exa as well, but what I'm saying is, what if marco sends bad parameters and then exa can't handle them?
[11:20] <alkisg> in its server side code?
[11:21]  * alkisg wonders if its reproducible with any other manager
[11:21] <alkisg> marco --no-composite, compiz, compton...
[11:22] <KitsuWhooa> didn't happen with compiz and compton, but I think it's because they didn't enable double buffering
[11:23] <alkisg> It would also explain why it's not mentioned widely on the internet, since marco only has a limited number of users...
[11:23] <KitsuWhooa> maybe with ccsm
[11:23] <KitsuWhooa> hm
[11:24] <alkisg> I'm about to leave the office, but I'll test tomorrow if it happens e.g. in gnome
[11:24] <KitsuWhooa> mutter?
[11:24] <alkisg> Yeah
[11:25] <alkisg> (if you have enough ram, you could also just install it on the live client)
[11:25] <KitsuWhooa> I don't sadly
[11:25] <KitsuWhooa> but I don't think mutter would run well, if at all on something this old
[11:25] <KitsuWhooa> might fall back to software rendering
[11:26] <alkisg> I'll try to remember which school had the problem with a geforce 210, and test with that one...
[11:26]  * alkisg waves for now, bbl...
[11:26] <KitsuWhooa> see ya
[11:58] <mamarley> ricotz: I tried to package the 410.57 driver but it has major problems.  The computer boots to the (KDE) desktop, but if I launch any application that uses OpenGL, EGL, or Vulkan, it hangs immediately and permanently in disk sleep.
[11:59] <mamarley> I think it might have something to do with the fact that the old libglx.so.XXX.XX is gone and replaced with libglxserver_nvidia.so.XXX.XX.  It looks like they might have done something with GLVND.  I will see if I can figure it out.
[12:01] <ricotz> mamarley, hi, thanks :) (quite a version bump)
[12:09] <tjaalton> serverside glvnd
[12:09] <tjaalton> needs 1.20 most likely
[12:14] <tseliot> yes, that file if for server-side GLVND, it's in their docs
[12:24] <mamarley> Ah, thanks!
[12:24]  * mamarley wishes they would have a "packager's changelog" that would document changes like that and list the new libraries that were included.
[12:36] <mamarley> tseliot: Where in the docs?  It isn't obvious and it also isn't searchable.
[12:40] <tseliot> mamarley: if you extract the installer, and look in html/installedcomponents.html , you will see a line about libglxserver_nvidia.so
[12:40] <mamarley> Oh, I didn't realize that the documentation was extracted from the installer too, I thought it was just in https://download.nvidia.com/XFree86/Linux-x86_64/410.57/README/.
[12:41]  * mamarley beats himself with the cluestick.
[12:44] <tseliot> haha
[12:45]  * tseliot hopes NVIDIA will put libglx.so.$version back into the 410 release
[12:46] <mamarley> tseliot: If you don't mind my asking, where do you get this inside information?
[12:46] <tseliot> mamarley: what inside information?
[12:47] <mamarley> tseliot: You already seemed to know about this server-side GLVND thing before it happened.
[12:47] <tjaalton> it was bound to happen
[12:47] <tjaalton> nvidia added it to the server
[12:47] <tjaalton> so now they're finally using it
[12:48] <tjaalton> not that 1.20 is particularly old
[12:48] <tseliot> mamarley: I simply tried to package the new release, and noticed the lack of the libglx.so.$ver file, so I had a look at the docs
[12:49] <mamarley> Aaaand, it looks like the computer I was using for the packaging (and the only computer I have that can run the 410 drivers) hung when I tried to reboot it.  And I'm not there, so it looks like I won't be able to do anything else until I can get back home a hit the reset button. :(
[12:50] <mamarley> Oh wait, it finally time out and rebooted.
[13:02] <mamarley> tseliot: It still isn't working right.  When I moved the libglxserver_nvidia.so.410.57 file to /usr/lib/xorg/modules/extensions/ as specified in the documentation, X completely ignored the NVIDIA card and instead used the integrated graphics card (which doesn't even have a monitor attached).
[13:02] <tseliot> mamarley: are you on 18.10?
[13:03] <tseliot> or are you running xserver 1.20, somehow?
[13:06] <mamarley> tseliot: Yes.
[13:06] <tjaalton> mmm, beta ;)
[13:07] <tseliot> mamarley: do you have an X log I can have a look at?
[13:07] <mamarley> tseliot: Sure, just a sec.
[13:08] <mamarley> tseliot: https://paste.ubuntu.com/p/rW3Jcqth6C/
[13:09] <mamarley> It looks like it might be ignoring the NVIDIA driver (presumably because libglx.so is missing out of /usr/lib/x86_64-linux-gnu/nvidia/xorg/ ?)
[13:10] <tjaalton> I wonder if the server is actually built with glvnd support..
[13:10] <mamarley> Hmm, good point.
[13:12] <mamarley> The GLVND build dependencies are installed when the server is built, but there isn't anything containing "glvnd" in the actual build log.
[13:13] <tjaalton> no, but glxvnd is
[13:13]  * mamarley beats himself with the cluestick again.
[13:15] <tjaalton> something needed in the config snippet?
[13:15] <tseliot> was libglxvnd actually built?
[13:16] <tjaalton> it's not a separate lib
[13:16] <tjaalton> from what I can tell
[13:19] <tjaalton> does the doc have anything about it
[13:19] <tjaalton> ?
[13:19] <mamarley> Just where the libglxserver file should be installed, as far as I can tell.
[13:27] <mamarley> It would appear as if Phoronix has benchmarks of the 410 driver running on 18.04.  I wonder how they did that?
[13:39] <tjaalton> weird
[13:40] <tseliot> mamarley: that's not really documented in X... anyway, did you create libglxserver_nvidia.so, which points to the nvidia library?
[13:41] <tseliot> BTW, I'm going to test this when I get back home, next week
[13:54] <tjaalton> mamarley: it doesn't show anywhere that the nvidia driver is loaded
[13:55] <tjaalton> the logfile
[13:55] <tjaalton> what's in xorg.conf?
[14:13] <soee_> https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-410.57-Beta-Released
[14:26] <mamarley> soee_: Yeah, we were just talking about that.  It is being rather difficult to package.  Stay tuned…
[14:28] <soee_> mamarley: they chnage a lot ?
[14:29] <mamarley> They changed a little thing that is causing a big problem.
[14:34] <mamarley> tjaalton: Not much in xorg.conf, just a few lines to hardcode which monitor outputs are enabled since my monitors have a habit of crashing at inopportune times and the resulting hotplug events have historically screwed up the desktop configuration.  I may not need that anymore though.
[14:35] <tjaalton> it's weird that the log doesn't even mention nvidia.. is it a hybrid?
[14:36] <mamarley> tjaalton: Nope, it is a desktop.  I just have the Intel GPU enabled so I can use it for hardware video transcoding (it doesn't have the 2-stream limit that GeForce GPUs do).
[14:36] <tjaalton> ha
[14:37] <tjaalton> ok, surprised that it works 
[14:37] <tjaalton> or had worked
[14:39] <mamarley> tjaalton: That what works, the transcoding?  The program I am using uses the DRM interface, not the X interface.
[14:41] <tjaalton> ok, well it does make it harder to debug :)
[14:41] <tjaalton> at least confuses me
[14:42] <mamarley> tjaalton: Well, with both the original libglxserver_nvidia.so and the symlink in /usr/lib/xorg/modules/extensions, it uses the NVIDIA card correctly and OpenGL applications work, but EGL and Vulkan applications still hang in disk sleep.  I am checking what happens with the files in /usr/lib/x86_64-linux-gnu/nvidia/xorg/.
[14:44] <tjaalton> ah
[14:46] <mamarley> Disk sleep is the most annoying process state in the entirety of UNIX.
[14:51] <mamarley> tjaalton: With the files in /usr/lib/x86_64-linux-gnu/nvidia/xorg/, OpenGL and Vulkan work but EGL hangs.
[14:53] <tjaalton> k
[14:53] <tjaalton> beta.. :)