| 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:17 |
| KitsuWhooa | it doesn't segfault outside valgrind | 08:18 |
| alkisg | Heh | 08:19 |
| alkisg | Did valgring produce any helpful output on that segfault? | 08:19 |
| 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:20 |
| 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:21 | |
| KitsuWhooa | it's definitely having update issues | 08:22 |
| KitsuWhooa | oh it's not a segfault | 08:28 |
| KitsuWhooa | it's a sigabrt | 08:28 |
| alkisg | When does that happen? Double free()? | 08:29 |
| 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:30 | |
| 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 | 08:31 |
| KitsuWhooa | <KitsuWhooa> IIRC when an invalid pointer is being accessed/dereferenced <-- nope, got it confused with sigbus | 08:32 |
| KitsuWhooa | way too many | 08:32 |
| 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:33 |
| 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:34 |
| KitsuWhooa | yeah, the original segfault backtrace doesn't contain it | 08:35 |
| KitsuWhooa | I wonder if it's valgrind's strdup that causes the abort | 08:39 |
| KitsuWhooa | either way, it happens after I call xrandr to resize | 08:40 |
| KitsuWhooa | if you're curious, this is what gets thrown right after I call resize https://tasossah.com/txt/valgrind_x_resize | 08:42 |
| alkisg | KitsuWhooa: would that advice from the last line help? Use --track-origins=yes to see where uninitialised values come from | 08:50 |
| KitsuWhooa | I may do that later | 08:53 |
| KitsuWhooa | I deleted nouveau_vieux and it no longer crashes | 08:53 |
| KitsuWhooa | bad news is I don't think valgrind printed anything while switching resolutions | 08:54 |
| alkisg | I think xrandr is correctly initializing the previously uninitialized variables, so I wouldn't expect valgrind to complain when using xrandr... | 09:01 |
| KitsuWhooa | I'd assume initializing them means "using" them | 09:02 |
| KitsuWhooa | which is why I'd expect valgrind to complain | 09:02 |
| KitsuWhooa | Also, the moment the mate session started, epoptes killed the remote terminal that ran mate-session, and the session died :p | 09:03 |
| 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:04 |
| KitsuWhooa | because if I run xclock without the session running, it doesn't do double buffering and there's no corruption | 09:05 |
| alkisg | Maybe `caja -n` could reproduce it without a full session | 09:07 |
| KitsuWhooa | I doubt it, but I can try it | 09:08 |
| 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:09 |
| 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:11 |
| 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:12 |
| KitsuWhooa | caja -n did nothing. It exited | 09:29 |
| KitsuWhooa | oh, compiz is installed | 09:30 |
| KitsuWhooa | compiz should do it | 09:30 |
| KitsuWhooa | nope | 09:30 |
| KitsuWhooa | neither compton | 09:31 |
| alkisg | The default display manager is marco | 09:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| KitsuWhooa | I'll have a look in a bit | 09:37 |
| KitsuWhooa | thanks | 09:37 |
| 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:05 |
| 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:07 |
| KitsuWhooa | the latter | 11:08 |
| alkisg | And "double buffering disabled" means "pageflip off"? | 11:08 |
| KitsuWhooa | yup | 11:09 |
| 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:10 |
| 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:11 |
| alkisg | Well if they're the same in both cases, when it works and when it doesn't... meh | 11:12 |
| KitsuWhooa | yeah, they are | 11:13 |
| 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:15 |
| alkisg | Would valgrind marco show it then? | 11:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| * alkisg wonders if its reproducible with any other manager | 11:21 | |
| alkisg | marco --no-composite, compiz, compton... | 11:21 |
| KitsuWhooa | didn't happen with compiz and compton, but I think it's because they didn't enable double buffering | 11:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:58 |
| 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. | 11:59 |
| ricotz | mamarley, hi, thanks :) (quite a version bump) | 12:01 |
| tjaalton | serverside glvnd | 12:09 |
| tjaalton | needs 1.20 most likely | 12:09 |
| tseliot | yes, that file if for server-side GLVND, it's in their docs | 12:14 |
| 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:24 | |
| mamarley | tseliot: Where in the docs? It isn't obvious and it also isn't searchable. | 12:36 |
| 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:40 |
| * mamarley beats himself with the cluestick. | 12:41 | |
| tseliot | haha | 12:44 |
| * tseliot hopes NVIDIA will put libglx.so.$version back into the 410 release | 12:45 | |
| mamarley | tseliot: If you don't mind my asking, where do you get this inside information? | 12:46 |
| tseliot | mamarley: what inside information? | 12:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| mamarley | Oh wait, it finally time out and rebooted. | 12:50 |
| 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:02 |
| tseliot | or are you running xserver 1.20, somehow? | 13:03 |
| mamarley | tseliot: Yes. | 13:06 |
| tjaalton | mmm, beta ;) | 13:06 |
| tseliot | mamarley: do you have an X log I can have a look at? | 13:07 |
| mamarley | tseliot: Sure, just a sec. | 13:07 |
| mamarley | tseliot: https://paste.ubuntu.com/p/rW3Jcqth6C/ | 13:08 |
| 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:09 |
| tjaalton | I wonder if the server is actually built with glvnd support.. | 13:10 |
| mamarley | Hmm, good point. | 13:10 |
| 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:12 |
| tjaalton | no, but glxvnd is | 13:13 |
| * mamarley beats himself with the cluestick again. | 13:13 | |
| tjaalton | something needed in the config snippet? | 13:15 |
| tseliot | was libglxvnd actually built? | 13:15 |
| tjaalton | it's not a separate lib | 13:16 |
| tjaalton | from what I can tell | 13:16 |
| 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:19 |
| mamarley | It would appear as if Phoronix has benchmarks of the 410 driver running on 18.04. I wonder how they did that? | 13:27 |
| tjaalton | weird | 13:39 |
| tseliot | mamarley: that's not really documented in X... anyway, did you create libglxserver_nvidia.so, which points to the nvidia library? | 13:40 |
| tseliot | BTW, I'm going to test this when I get back home, next week | 13:41 |
| tjaalton | mamarley: it doesn't show anywhere that the nvidia driver is loaded | 13:54 |
| tjaalton | the logfile | 13:55 |
| tjaalton | what's in xorg.conf? | 13:55 |
| soee_ | https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-410.57-Beta-Released | 14:13 |
| mamarley | soee_: Yeah, we were just talking about that. It is being rather difficult to package. Stay tuned… | 14:26 |
| soee_ | mamarley: they chnage a lot ? | 14:28 |
| mamarley | They changed a little thing that is causing a big problem. | 14:29 |
| 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:34 |
| tjaalton | it's weird that the log doesn't even mention nvidia.. is it a hybrid? | 14:35 |
| 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:36 |
| tjaalton | ok, surprised that it works | 14:37 |
| tjaalton | or had worked | 14:37 |
| mamarley | tjaalton: That what works, the transcoding? The program I am using uses the DRM interface, not the X interface. | 14:39 |
| tjaalton | ok, well it does make it harder to debug :) | 14:41 |
| tjaalton | at least confuses me | 14:41 |
| 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:42 |
| tjaalton | ah | 14:44 |
| mamarley | Disk sleep is the most annoying process state in the entirety of UNIX. | 14:46 |
| mamarley | tjaalton: With the files in /usr/lib/x86_64-linux-gnu/nvidia/xorg/, OpenGL and Vulkan work but EGL hangs. | 14:51 |
| tjaalton | k | 14:53 |
| tjaalton | beta.. :) | 14:53 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!