http://bugs.winehq.org/show_bug.cgi?id=31279
Charles Davis cdavis@mymail.mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #11 from Charles Davis cdavis@mymail.mines.edu 2012-07-22 22:33:06 CDT --- Well, it turns out SECDRV really wasn't caching the IDTR like I thought. Which is even worse, because it means there's a race between SECDRV and Wine reading the IDTR. If the scheduler changes the CPU NTOSKRNL is running on between the time SECDRV reads the IDTR and the time Wine reads the IDTR, SECDRV and Wine will end up reading different IDTR values.
I even tried to get Wine to remember all four IDTR values, and check each one. But it's still subject to this same data race. This sucks.
So after trying to fix this problem in Wine multiple times, I'm convinced now there are only two ways to make it work, and both of them require changing the kernel:
1. The easy way: make the kernel use the same IDT for all cores. Probably not realistic. I'm sure there's a good reason each core has its own IDT. (At the very least, it seems to be used to distinguish one processor from another.) 2. The hard way: implement "strong" affinity (i.e. the kind that Windows and Linux implement), as opposed to the "weak" kind Mac OS currently has. Then we can force the NTOSKRNL thread onto a specific CPU and avoid the race.
I'll see about implementing 2 and getting my patch upstreamed for the next version of Mac OS. For now, I'll just have to run a modified kernel.