On Thu, May 20, 2021 at 10:10:14AM +0200, Matthieu Herrb wrote: > > > > Looking at what appears in the log (/var/log/messages) the time when X > > freezes corresponds very well with when those messages are recorded. > > > > The question is, how do I usefully debug this? I've gone over the README's > > procedure a few times now and it unfortunately does not produce any > > coredumps > > or traces. > > When the X server is locked up I can still ssh into the machine and > attach a debugger to the running process. I've got a few backtraces > from that, but without full symbols it's even harder to understand > what's going on. > > I suspect issues with our futex implementation; in every case I find > one thread stuck in a drm ioctl while others are blocked on futex > waits. > > Running an X server + Mesa fully built with debug symbols seem to make > the issue less frequent and when it happenned I didn't have time to > launch a debugger on it so far...
I could dig into that, building xenocara now with CFLAGS='-O0 -g3' > > One option is of course to trade up or sideways to something like > > https://www.power.no/data-og-tilbehoer/pc-og-mac/baerbar-pc/asus-zenbook-s-ux393ea-pure2-13-laptop/p-1115705/ > > (Intel Core i7-1165G7 with Iris Xe graphics), but would that have a better > > chance of success (or for that matter be helpful to the project)? > > Which window manager / desktop environment are you using ? I've tried > to back to WindowMaker (from xfwm4) and it also seems to not trigger > the lock ups on a Ryzen Vega. But it hasn't been long enough. Sometime > I can run for days without a lockup and sometimes it locks up after > minutes. I've been using xfce4 from packages. That has been well behaved on earlier laptops (my main problem there has been as on this one that thunderbird coredumps a lot) > BTW this also leads me to wonder if KARL could have an impact on the > issue in case there is some un-initialized memory access somewhere in > the code... That could certainly be. Let's see if I can extract any useful info with a debug-enable system. All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
