After upgrading to a 64bit system with new hardware, running 3d games with wine now results in my entire system becoming unresponsive until I kill wine (wineserver -k). I am using Arch Linux with the bin32-wine package from AUR, and have experienced this problem with wine 1.1.10, .12, and .13. Wine does use 100% of a single core, but it did this with my previous system as well. I've gotten this with both the 2.6.27 and 2.6.28 driver, with nvidia 177.82 and 180.22 drivers.
It's not anything to do with ~/.wine, because I tried installing Red Alert 3 to a new WINEPREFIX and I experienced the same problem with it. The other game that freezes is EVE Online. Both EVE and RA3 worked fine with my previous 32bit arch install.
Does anyone have any idea how I can fix this or what might be causing it? I've been trying various things for the past two weeks with no success.
wine causing system slowdown
Re: wine causing system slowdown
I think the problem is the nvidia driver (32bit on 64bit system) in combination with wine.andrewyates wrote:After upgrading to a 64bit system with new hardware, running 3d games with wine now results in my entire system becoming unresponsive until I kill wine (wineserver -k).
...
I've gotten this with both the 2.6.27 and 2.6.28 driver, with nvidia 177.82 and 180.22 drivers.
You could have a look at these bugs and you could try the attached workarounds.
http://bugs.winehq.org/show_bug.cgi?id=10778
http://bugs.winehq.org/show_bug.cgi?id=15290
You could also have a look at the console output. There should be some OUT_OF_MEMORY errors.
Also sometimes I got some kernel panics because the nvidia driver tries to free some memory and hangs in an endless loop. Probably because it had allocated the memory beyond the 4GB border.
-
- Newbie
- Posts: 2
- Joined: Sat Jan 24, 2009 2:33 am
I've patched wine 1.1.13 with the nvidia bug and preloader patches, and while it takes longer for the game to slow down and the system slowdown isn't as bad, it still happens.
I have gotten the OUT_OF_MEMORY errors before, but that causes a crash, whereas this brings everything running to a halt. I originally thought it was an EVE bug, but then thought it might be a wine/64bit bug because it also happened with RA3. I'm now wondering if it may be a bug that happens to show up in both of them, because of this output (the line about software emulation, in particular):
I do remember having this bug several times with my 32bit install, but it didn't occur nearly as much as it is now; it occurred maybe two dozen times over a year of use, whereas this has occurred dozens of times in two weeks.
I suppose this should be moved to the EVE appdb entry, unless you're aware of anything that would indicate it isn't game-specific?
I have gotten the OUT_OF_MEMORY errors before, but that causes a crash, whereas this brings everything running to a halt. I originally thought it was an EVE bug, but then thought it might be a wine/64bit bug because it also happened with RA3. I'm now wondering if it may be a bug that happens to show up in both of them, because of this output (the line about software emulation, in particular):
Code: Select all
err:ole:CoGetClassObject class {9a5ea990-3034-4d6f-9128-01f3c61022bc} no
t registered
err:ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc}
could be created for context 0x1
fixme:heap:HeapSetInformation 0x8d0000 0 0x33fc44 4
fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex sampl
ers and 32 total samplers
fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) > combined_samplers
fixme:win:EnumDisplayDevicesW ((null),0,0x33aed4,0x00000000), stub!
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1680x1050x
32 @85! (desktop)
fixme:wtsapi:WTSRegisterSessionNotification Stub 0x3002a 0x00000000
fixme:imm:ImmReleaseContext (0x3002a, 0x121f68): stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:reg:GetNativeSystemInfo (0x33a3a0) using GetSystemInfo()
fixme:d3d_texture:basetexture_set_autogen_filter_type >>>>>>>>>>>>>>>>> GL_INVAL
ID_ENUM (0x500) from glTexParameteri(textureDimensions, GL_GENERATE_MIPMAP_HINT_
SGIS, GL_NICEST) @ basetexture.c / 135
fixme:d3d_texture:basetexture_set_autogen_filter_type >>>>>>>>>>>>>>>>> GL_INVAL
ID_ENUM (0x500) from glTexParameteri(textureDimensions, GL_GENERATE_MIPMAP_HINT_
SGIS, GL_NICEST) @ basetexture.c / 135
fixme:d3d_texture:basetexture_set_autogen_filter_type >>>>>>>>>>>>>>>>> GL_INVAL
ID_ENUM (0x500) from glTexParameteri(textureDimensions, GL_GENERATE_MIPMAP_HINT_
SGIS, GL_NICEST) @ basetexture.c / 135
<repeats>
fixme:d3d_texture:basetexture_set_autogen_filter_type >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glTexParameteri(textureDimensions, GL_GENERATE_MIPMAP_HINT_SGIS, GL_NICEST) @ basetexture.c / 135
fixme:d3d_draw:drawPrimitive Using software emulation because not all material properties could be tracked
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:d3d9:Direct3DShaderValidatorCreate9 stub
fixme:imm:NotifyIME NI_CLOSECANDIDATE
I suppose this should be moved to the EVE appdb entry, unless you're aware of anything that would indicate it isn't game-specific?