https://bugs.winehq.org/show_bug.cgi?id=38953
Bug ID: 38953 Summary: Linux kernel version 4.2 will prevent Battle.net App from launching in Wine Product: Wine Version: 1.7.47 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: aapmak@gmail.com Distribution: ---
When using Linux kernel version 4.2 (all of the release candidates exhibit this phenomenon), the Battle.net will fail to launch in Wine (1.7.47). When switching back to the stable 4.1.2, it will resume functioning as expected.
Obviously, this hints at an issue somewhere in the Linux kernel but, ultimately, there is no way to bug report on kernel.org when the problem is one individual application.
There have been some (very) low level changes in the Linux kernel between 4.1 and 4.2 and consequently, it may have affected Wine in some fashion. I suspect something related to the low level ASM changes (see changelogs for the 4.2 rc's).
This was tested with all currently available release candidates for Linux kernel version 4.2 (rc1, rc2, rc3).
Hardware: AMD A6-3650 Kernel versions: 4.1.2 amd64 low latency (works); 4.2rc1/rc2/rc3 amd64 low latency (does not work) Wine: 1.7.47 Graphics stack: Mesa 10.7 (git, oibaf).
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #1 from Austin English austinenglish@gmail.com --- Attaching the output from wine when it fails to launch would be helpful.
However, given that the change was in the kernel (even if it only affects one app), it would be very helpful to bisect the kernel: https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html https://wiki.ubuntu.com/Kernel/KernelBisection https://wiki.gentoo.org/wiki/Kernel_git-bisect
see also wine's regression testing page for more info about git bisect: http://wiki.winehq.org/RegressionTesting
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #2 from Armin Altorffer aapmak@gmail.com --- The offending event/output:
"wine: Unhandled page fault on write access to 0x0e03e9f6 at address 0x38607d98 (thread 004f), starting debugger..."
At which point it will simply abort execution and return to prompt. As stated, 4.1.x (and all versions prior) did not exhibit this phenomenon.
Personally bisecting the kernel is something that has always surprised me; even though I do have the technical aptitude for it, it does remain something of a time consuming and daunting process. It surprises me that people are requested to personally do this sort of thing.
Moreover as in this particular case, the list of commits that is involved in this phenomenon occurring is rather extensive. 4.1.2 is the last known working kernel; 4.2.rc1 already sees it failing. The list of individual commits for 4.2.rc1 is quite extensive; it is one of the larger rc's in the history of the Linux kernel. And as there are no individual compiles for each and every individual commit, I would have to personally bisect the entire 4.2 rc1 kernel, each individual commit. Compiling manually for every bisect attempt. Obviously, it can be narrowed down a bit, but still, there are numerous possible causes. Personally bisecting this on a less than cutting edge machine is probably going to take weeks.
Most likely, it is related to low level ASM changes (a lot of work is being done to migrate the low level ASM to C, in the kernel) but still, it could also be related to some DRM work or maybe something else entirely.
https://bugs.winehq.org/show_bug.cgi?id=38953
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #3 from Austin English austinenglish@gmail.com --- (In reply to Armin Altorffer from comment #2)
Moreover as in this particular case, the list of commits that is involved in this phenomenon occurring is rather extensive. 4.1.2 is the last known working kernel; 4.2.rc1 already sees it failing. The list of individual commits for 4.2.rc1 is quite extensive; it is one of the larger rc's in the history of the Linux kernel. And as there are no individual compiles for each and every individual commit, I would have to personally bisect the entire 4.2 rc1 kernel, each individual commit. Compiling manually for every bisect attempt. Obviously, it can be narrowed down a bit, but still, there are numerous possible causes. Personally bisecting this on a less than cutting edge machine is probably going to take weeks.
You don't need to test every individual commit. Essentially, git bisect automates the process of dividing the list of changes in half and testing the midway point to find the broken commit, greatly reducing the needed number of compiles (last time I bisected the kernel, I think it was around 15 compiles).
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #4 from Armin Altorffer aapmak@gmail.com --- Meet 4.2:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.2-rc1-unstable/CHANGES
On a AMD A6-3650? That would literally still take days of almost non-stop building/installing/testing, straight off kernel.org's git of the kernel. No, thank you very much. I am not THAT comfortable with git.
https://bugs.winehq.org/show_bug.cgi?id=38953
sobkas sobkas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sobkas@gmail.com
--- Comment #5 from sobkas sobkas@gmail.com --- I have bisected kernel long time ago and filled https://bugzilla.kernel.org/show_bug.cgi?id=101061
So apparently problems started with: 53e9accf0f7682d717c7b578b6e01fd297ba6630
Any idea how make kernel devs give a s*** about that bug?
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #6 from Armin Altorffer aapmak@gmail.com --- The best way for them to take the phenomenon seriously is by providing more data, more samples, more evidence. It would also help if the wine devs confirmed the bug and, consequently, confirmed it to the kernel devs. A major project such as wine is cause enough to further investigate this particular issue.
https://bugs.winehq.org/show_bug.cgi?id=38953
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #7 from Armin Altorffer aapmak@gmail.com --- Pardon the double post but I have some additional test results. In response to the aforementioned bug report for the kernel, which specifically mentioned issues when running 32 bit applications on AMD64, I decided to create a new prefix, a 64 bit prefix and to see if the Battle.net would then run properly on 4.2.x.
It does not.
And now, it does not even mention a specific error at which point it crashes; it mentions the odd fixme here and there but no consistent one that would point in a definite direction.
Of the last attempt I made to run it, the final message was:
"fixme:process:GetLogicalProcessorInformationEx (3,(nil),0x33ef3c): stub"
https://bugs.winehq.org/show_bug.cgi?id=38953
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |UPSTREAM
--- Comment #8 from Ken Sharp imwellcushtymelike@gmail.com --- If Linus himself responds it's safe to say that they're interested.
Upstream.
https://bugs.winehq.org/show_bug.cgi?id=38953
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.kernel.org | |/show_bug.cgi?id=101061
https://bugs.winehq.org/show_bug.cgi?id=38953
--- Comment #9 from Armin Altorffer aapmak@gmail.com --- As of Release Candidate 4 of kernel 4.2 (July 26th 2015), the issue has been resolved.
https://bugs.winehq.org/show_bug.cgi?id=38953
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Austin English austinenglish@gmail.com --- (In reply to Armin Altorffer from comment #9)
As of Release Candidate 4 of kernel 4.2 (July 26th 2015), the issue has been resolved.
Fixed upstream > closing.