Date: Fri, 9 Mar 2018 22:53:57 +0100 From: Riccardo Mottola <riccardo.mott...@libero.it> Message-ID: <2135aaf6-afc5-f10b-1511-cf59e0df2...@libero.it>
| X does not get "killed" either, I do not return to console. If it gets killed, that (not returning to console) is expected. | On this system usually the X driver is decently well-behaved, That I believe takes assistance from the X server. | so while things work I can switch to terminals, Yes, the working server helps with the transition. | if X was being killed by | out-of-swap, I'd expect to get to the console again. I wouldn't. But you can easily test that - just start X (no need for anything huge like ruse - the "by out of swap" is not important for this test) and kill -9 the X server process. Observe what happens. You might want to make sure you can ssh in (or have already done that) so you can gracefully reboot. Of course, this does not mean that this is what is happening in the situation in question, it could also be dropping to DDB and hanging (because the console is still in X mode) as you indicated you think is happening. That one can be tested by disabling ddb.onpanic ( sysctl -w ddb.onpanic=0 ) and doing the rust build again - if the kernel crashes, it will simply crash and reboot now. Or you could do the rust build from a wscons console, and not run X at all, and see what happens then, if it is dropping into DDB, you should see it happen, and be able to interact. kre