+- Xonotic Forums (https://forums.xonotic.org)
+-- Forum: Support (https://forums.xonotic.org/forumdisplay.php?fid=3)
+--- Forum: Xonotic - Help & Troubleshooting (https://forums.xonotic.org/forumdisplay.php?fid=4)
+--- Thread: [SOLVED] Xonotic causes severe system crashes (Linux + fglrx driver) (/showthread.php?tid=4021)
Xonotic causes severe system crashes (Linux + fglrx driver) - MirceaKitsune - 03-23-2013
Since a few weeks ago, I started experiencing severe system crashes when running Xonotic. After a few hours of opening and closing Xonotic, the game suddenly freezes as you play, and the operating system becomes unusable and unrecoverable. The computer has to be force restarted and sometimes after I log back in, I notice the crash corrupted settings of existing programs and caused data loss. Those are the things I know so far:
- It's a known issue with the fglrx (proprietary ATI) driver on Linux, though the exact cause is not yet known.
- Disabling r_glsl_skeletal reduces the problem but doesn't fix it. With it I had approximately 4 crashes a day, now I have about 1.
- It only happens after approximately 6 hours since starting up the system, and / or starting up Xonotic and closing it for more than approximately 6 times.
- The freeze takes place when new models or textures are loaded into the view. For example, if a player spawns behind a wall then you move past that wall and see it for the first time. It also happens when selecting the Laser after holding the Shotgun (for the first time since starting Xonotic). Note that at first the freezes were happening in the menu (before even loading a map).
- I noticed that normally, whenever viewing a model for the first time, Xonotic freezes for just a moment (without causing any damage) and messages are printed in the console in cyan saying "GLSL shader compiled" or something like that. I'm imagining it might be related to that, and at some point a GLSL shader breaks and somehow kills the whole system.
- Once Xonotic freezes, the entire OS becomes unusable. Not even the num lock / caps lock / scroll lock keyboard leds can be toggled any more, and you can't even switch to a system console using control + alt + f#.
This is a very major issue and threatening to the whole operating system, and I believe it should be fixed urgently. Unfortunately I can't do much debugging since the computer gets broken once the problem happens. If there is anything I can do to further debug it however let me know. divVerent suggesting I try remote desktop with SSH while it's stuck, but I don't know how to set that up so no overly advanced stuff please.
Until it's fixed, are there any cvars you suggest changing or ideas on how to prevent the crashes, and perhaps recover the machine without hard restarting?
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - Spaceman - 03-23-2013
What versions of DarkPlaces and fglrx have you tried? GLX or SDL? It could help find the issue if you knew what are safe combinations of DP and fglrx.
Using the DP binary from Xonotic does Nexuiz also crash? What happens when you run Xonotic in a window (not full screen)?
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - MirceaKitsune - 03-23-2013
(03-23-2013, 08:08 AM)Spaceman Wrote: What versions of DarkPlaces and fglrx have you tried? GLX or SDL? It could help find the issue if you knew what are safe combinations of DP and fglrx.
Using the DP binary from Xonotic does Nexuiz also crash? What happens when you run Xonotic in a window (not full screen)?
I'm always using the autobuild engine from http://beta.xonotic.org/autobuild/ (Xonotic-latest-engine.zip). I believe the last time I updated it was 2 days ago. As for fglrx, the package version is 9.012-1, while Catalyst Control Center shows Driver Packaging Version 9.012-121219a-151962C-ATI. The repository I maintain the ATI driver from is http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.3/ Otherwise I'm not aware of a specific version of either DP or fglrx where the issue wasn't happening.
I haven't tried using the SDL version (only glx), but that sounds like a good idea and I'll consider it. Thanks for the suggestion.
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - Samual - 03-23-2013
I told you not to worry about it, we already know about the bug for quite some time now and it's already fixed in DarkPlaces master and div0-stable branch. I don't understand why you felt it necessary to post all this... I told you it was already fixed.
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - MirceaKitsune - 03-23-2013
(03-23-2013, 12:32 PM)Samual Wrote: I told you not to worry about it, we already know about the bug for quite some time now and it's already fixed in DarkPlaces master and div0-stable branch. I don't understand why you felt it necessary to post all this... I told you it was already fixed.
Erm... you told me a possible fix is pending but not in the Xonotic engine yet. You also said it's an issue with r_glsl_skeletal, but the problem still happens with it off. Also, I got the latest engine right after we spoke about it, and I still have the problem. So at best it was fixed yesterday or today... if so I will get the latest engine and try it out again.
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - Cyber Killer - 03-24-2013
translated from developer-speak Wrote:the fix is done in a separate branch and is waiting to be merged into the main Xonotic one
There, I fixed Samuals post for you :-)
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - MirceaKitsune - 03-24-2013
(03-24-2013, 05:32 AM)Cyber Killer Wrote: There, I fixed Samuals post for you :-)
I heard it was during the last hours. Got the latest engine last night and it felt like Xonotic only freezes for 1 second where it would previously freeze permanently. But one can never be sure, so I'll wait for a few days / weeks to be certain.
RE: Xonotic causes severe system crashes (Linux + fglrx driver) - Samual - 03-24-2013
Nope, it was already merged when I made my post, not even waiting. The 1 second freeze (actually more like 300ms btw) always happened, it's the compilation of the shader, that is no different. Closing, we're done here.