Comme=
nt # 52
on bug 10542=
5
from iive@yahoo.com
(In reply to MirceaKitsune from comment #51)
> Created attachment 139103 [details]
> Output of: systemctl | grep running
>=20
> (In reply to iive from commen=
t #50)
>=20
> I've preformed many more tests during the past two hours, getting near=
ly a
> dozen freezes in the process. I tried with both the glx and sdl versio=
ns of
> Xonotic, and even ran the "Alt + SysRq + RESUB" combination =
at different
> rates (instantly as well as 1 minute in between each press). Before ea=
ch
> test I made sure the SysRq keys are working, by using "Alt + SysR=
q + H" then
> checking that the help message appears at the end of the "dmesg&q=
uot; output.
>=20
> In all cases the trace file never catches the crash: Either I find a z=
ero
> byte file when I reboot, either it ends several seconds before the cra=
sh.
>=20
> I couldn't find any obviously useless systemctl services that I can sh=
ut
> down (such as Apache). In case there is anything dangerous or that I c=
ould
> disable in there, I'm attaching the output of "systemctl | grep r=
unning".
>=20
> I'm clearly going to need a different approach to recording this trace:
> apitrace must be dying the moment the lockup occurs, so it never finis=
hes
> writing the complete trace file. I found some info on how a trace can =
be
> played back from a remote machine, but not how to record it from one. =
What
> should I do next?
I'm running out of ideas.
I just want to make sure that the `apitrace` you are using is recent enough.
The last release of apitrace-7.1 is almost 3 years old and there are many f=
ixes
that it is missing. For example, there is 2 years old commit that calls
"localWrite.flush()" on "_exit".