[05:25] <KitsuWhooa> alkisg: I tested a https://www.asus.com/us/Graphics-Cards/A9250TD128M/overview/ and it worked out of the box, so I doubt ATi cards are affected
[05:26] <alkisg> KitsuWhooa: nice... do you think those horizontal lines in vbox were related? I haven't tested if pageflip off fixes vbox as well..
[05:27] <KitsuWhooa> Those go away by switching ttys, the ones on nvidia hardware don't
[05:38] <alkisg> And the one in tnt2 causes a segfault... those all might be bad codepaths, forced by a "central" bug somewhere...
[05:38] <alkisg> E.g. uninitialized resolution variable => may cause either corruption or segfault later on...
[05:39] <alkisg> The corruption can be fixed by xrandr -s other-resolution; xrandr -s original-resolution
[05:39] <KitsuWhooa> which is why a gdb backtrace would be useful
[05:40] <alkisg> Sure; I'll set up the tnt2 system within the week
[05:40] <KitsuWhooa> Yeah, I was just mentioning it
[05:40] <KitsuWhooa> Apologies if it sounded a bit harsh
[05:41] <alkisg> No no I very much appreciate all your input and help in this
[06:38] <KitsuWhooa> turns out I found a TNT2
[06:43] <KitsuWhooa> and also what identifies itself as "NV10GL Quadro"
[07:02] <KitsuWhooa> 01:00.0 VGA compatible controller: NVIDIA Corporation NV5 [Riva TNT2 Model 64 / Model 64 Pro] (rev 15)
[07:04] <KitsuWhooa> Yup, X crashes right after the login screen
[07:11] <alkisg> KitsuWhooa: do you have epoptes working in your ltsp setup? Could you run this at the login screen, before login, and see if it's still crashing or not? xrandr -s 640x480; xrandr -s original-resolution
[07:11] <KitsuWhooa> I don't have LTSP set up on epoptes, but I do have a shell
[07:11] <KitsuWhooa> two of them
[07:11] <alkisg> OK, you'd need to export DISPLAY and XAUTHORITY for xrandr to work
[07:12] <KitsuWhooa> would I need to rebuild the squashfs image to add epoptes?
[07:12] <alkisg> Yes
[07:12] <KitsuWhooa> Any way to rebuild the image without keeping the old one around during build?
[07:12] <KitsuWhooa> not enough disk space :p
[07:13] <alkisg> ltsp-update-image --no-backup -c /
[07:13] <KitsuWhooa> excellent, thank you
[07:13] <alkisg> ...stop nbd-server first so that it's not in use
[07:13] <KitsuWhooa> Also, I think I found a mate bug
[07:13] <KitsuWhooa> https://tasossah.com/s/3d40462bc831.jpg
[07:14] <KitsuWhooa> I don't even know what I did to make those two network indicators show up
[07:14] <alkisg> It goes away if you kill/rerun nm-applet, or on next login
[07:14] <alkisg> It's some race condition somewhere, I haven't pinpointed it
[07:15] <KitsuWhooa> So, I need both epoptes and epoptes-client on the server?
[07:15] <alkisg> Yes. apt install epoptes should be enough, it installs epoptes-client as well
[07:15] <KitsuWhooa> ah
[07:15] <KitsuWhooa> okay
[08:04] <KitsuWhooa> Right, after being distracted for a bit
[08:04] <KitsuWhooa> I can't seem to be able to find the nouveau debug symbol package
[08:11] <KitsuWhooa> Ah, they're on a separate repo
[08:43] <KitsuWhooa> alkisg: that did in fact make it not crash
[08:45] <KitsuWhooa> I have to say though, the TNT2 is really slow at 1680x1050
[08:45] <KitsuWhooa> and I got epoptes set up too, really cool 
[09:05] <alkisg> KitsuWhooa: it sounds like it's something in xorg initialization that goes wrong, and gets correctly initialized with xrandr
[09:22] <KitsuWhooa> Eeeeyup
[09:22] <KitsuWhooa> I'll try with gdb now and see if I can find anything interesting
[09:23] <KitsuWhooa> Also, wakeonlan works and it got me more excited than it should have :p
[09:23] <KitsuWhooa> s/and/to/
[09:41] <KitsuWhooa> alkisg: I ran startx, I attached gdb, and then after a while epoptes said my client went offline and killed my remote terminal
[09:41] <KitsuWhooa> any idea why?
[09:41] <KitsuWhooa> (X was in a frozen state)
[09:42] <KitsuWhooa> network never died either
[09:51] <alkisg> KitsuWhooa: how much ram does that client have?
[09:51] <alkisg> oom?
[09:51] <KitsuWhooa> I checked dmesg, not oom
[09:51] <KitsuWhooa> it has 3x256 DDR1
[09:52] <alkisg> Strange
[09:52] <alkisg> When the client is logged off, do you see it in epoptes as a blue icon?
[09:52] <alkisg> (fat client)
[09:52] <KitsuWhooa> yeah
[09:52] <KitsuWhooa> and I can even spawn a shell
[09:53] <alkisg> Btw epoptes is supposed to reconnect after a minute of inactivity, did it?
[09:54] <alkisg> The remote terminal was "root", not "user", right?
[09:54] <KitsuWhooa> yup
[09:54] <KitsuWhooa> it did not reconnect, no
[09:54] <alkisg> (root epoptes-client runs from systemd as root, while user runs from /etc/xdg/autostart as the user)
[09:54] <KitsuWhooa> and I checked that the network was still functioning
[09:55] <alkisg> That's rather strange, if you have a vt on the client it would be interesting to rerun epoptes-client as root, make it crash again, and see the stderr there
[09:55] <KitsuWhooa> I do yeah
[09:55] <KitsuWhooa> let me try again
[09:56] <KitsuWhooa> I have two vts and the remote shell
[09:56] <KitsuWhooa> I ran startx on the vt and attached gdb through the epoptes root shell
[09:57] <alkisg> (btw to open another vt if needed, it's openvt bash)
[09:57] <KitsuWhooa> I have two
[09:57] <KitsuWhooa> but I will, thanks
[09:57] <alkisg> e.g. if you want to attach gdb from a vt, so that it is more "stable"
[09:58] <alkisg> export $(/usr/share/epoptes-client/get-display) => gives you access to xorg btw
[09:58] <KitsuWhooa> I wanted the gdb session remotely so that it's more comfortable for me to work as I will be using my desktop keyboard
[09:58] <alkisg> (DISPLAY/XAUTHORITY)
[09:58] <alkisg> Yeah, I know the feeling :D
[09:58] <alkisg> I don't know why epoptes would do that though
[09:58] <alkisg> Ah maybe systemctl status epoptes-client would show the stderr
[09:58] <KitsuWhooa> service vboxadd stop
[09:58] <KitsuWhooa> ...oops
[09:59] <alkisg> Or journalctl something, for the previous crash
[09:59] <KitsuWhooa> I'll check, yeah
[09:59] <KitsuWhooa> is it python?
[09:59] <KitsuWhooa> I'm used to seeing segfaults in dmesg, but if it's python it probably won't be a segfault
[10:00] <alkisg> epoptes-client is mostly shell + socat
[10:00] <alkisg> A couple of python scripts are ran externally, as child processes
[10:01] <KitsuWhooa> https://tasossah.com/s/1ecf05d7e48b.jpg
[10:01] <KitsuWhooa> might need to recompile nouveau without optimisations 
[10:02] <KitsuWhooa> but nouveau_present_flip_exec definitely has to do with double/triple buffering
[10:40] <KitsuWhooa> alkisg: 13:24:22 ltsp162 epoptes-client[1561]: Could not detect or access the active display
[10:40] <KitsuWhooa> 13:36:34 ltsp162 epoptes-client[1561]: 2018/09/16 13:36:34 socat[1561] E waitpid(): child 1629 exited on signal 3
[10:41] <KitsuWhooa> former makes sense because X is frozen, not sure why socat died 12 minutes later though
[10:43] <alkisg> Not detecting the display shouldn't crash epoptes though
[16:44] <KitsuWhooa> alkisg: I traced the segfault down a bit
[16:44] <KitsuWhooa> It's an X issue
[16:45] <KitsuWhooa> exaGetPixmapDriverPrivate() returns a 0 pointer
[19:40] <alkisg> KitsuWhooa: is this enough info for a bug report?
[19:41] <KitsuWhooa> Possibly, but I'm going to look more into it tomorrow. X 1.19 also has the same issue, so it happened some time before it.
[19:42] <alkisg> Great!
[19:42] <KitsuWhooa> I tried disabling acceleration and it still crashed, which is a bit odd
[19:42] <KitsuWhooa> because the above gets called due to acceleration
[19:42] <alkisg> NoAccel was the first thing I tried yeah
[19:42] <KitsuWhooa> I also tried setting AccelMethod or whatever it is to none
[19:42] <KitsuWhooa> and that didn't help either
[19:43]  * alkisg has studied vga internals back in 1990, but has no idea about xorg internals :(
[19:46] <KitsuWhooa> I don't know much about it either to be honest.
[19:47] <KitsuWhooa> I will however say that this whole thing helped me uncover two kernel bugs that affect my desktop, that I'll need to look into/report at some point