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