wine causing system slowdown

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
andrewyates
Newbie
Newbie
Posts: 2
Joined: Sat Jan 24, 2009 2:33 am

wine causing system slowdown

Post by andrewyates »

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.
Rico
Moderator
Moderator
Posts: 91
Joined: Sat Feb 23, 2008 12:10 pm

Re: wine causing system slowdown

Post by Rico »

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.
I think the problem is the nvidia driver (32bit on 64bit system) in combination with wine.

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.
andrewyates
Newbie
Newbie
Posts: 2
Joined: Sat Jan 24, 2009 2:33 am

Post by andrewyates »

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):

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 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?
Locked