https://bugs.winehq.org/show_bug.cgi?id=39141
Bug ID: 39141 Summary: Freezing completely when adjusting date/time Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: aapmak@gmail.com Distribution: ---
I had a script running an ntpdate hourly and meanwhile, I intermittently had this machine completely seizing up. To the point where only a tap on the reboot button and/or powering off would work (which is rare in a Linux configuration).
The one element I could point out regarding this seizing up phenomenon was that it would only occur when running Wine (typically, a game of some sort but not limited to one individual title; it has happened with Banished, Heroes of the Storm, Diablo III).
Last night it occured to me to simply remove that ntpdate script to see if that would aleviate the problem; at first I suspected it was linked to the recent shift from ASM to C in the Linux kernel but multiple kernel versions have exhibited this phenomenon so that is unlikely. Again, the only constant seems to be Wine.
Since removing the ntpdate script, the problem has not shown itself again. I suspect there may be some issue with changing system date/time while Wine is running. In particular, I suspect that any minor time adjustment to the past might cause irregularities that end up causing very tight infinite loops or something to that effect; since not even the keyboard responded when the seizing up phenomenon occured.
This happened with multiple versions of time, all of which in the 1.7.4x series.
https://bugs.winehq.org/show_bug.cgi?id=39141
--- Comment #1 from Armin Altorffer aapmak@gmail.com --- OK, so, the ntpdate script was not at fault. Phenomenon occured just now; script was no longer part of the equation. So, something else is going on here. Going back to Linux kernel version 3.19.8. Maybe 4.0 and up are all just broken for AMD, at a low level. Still, odd that it is limited to just Wine that causes the issue.
https://bugs.winehq.org/show_bug.cgi?id=39141
--- Comment #2 from Armin Altorffer aapmak@gmail.com --- After installing Linux kernel 3.19.8.ckt5-low latency-x64, I ran a lengthy stress test; simply running a Windows demoscene demo on loop, using Wine. To see if the problem would resurface; so far, it has not.
Suggesting indeed that kernel 4.0 and up (all kernels from 4.0 and up have demonstrated this phenomenon for me) are different in some way that causes Wine to seize the machine up completely. Still, that seems odd still; since most of the very low ASM > C changes in the kernel since 4.0 are not in user space and I would imagine Wine operating purely in user space.
https://bugs.winehq.org/show_bug.cgi?id=39141
Armin Altorffer aapmak@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #3 from Armin Altorffer aapmak@gmail.com --- Issue has been determined to be related to something unrelated to Wine.
https://bugs.winehq.org/show_bug.cgi?id=39141
Armin Altorffer aapmak@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Armin Altorffer aapmak@gmail.com --- ...