http://bugs.winehq.org/show_bug.cgi?id=23578
Summary: Team Fortress 2: Significant "lag" spikes disrupt gameplay... Product: Wine Version: 1.2-rc6 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: immanuel.ortego@gmail.com
Valve, as of yesterday, has introduced a major update that has broken the application. When playing in an active game server --at sporadic times-- the game will become unplayable with the framerate being under 10 FPS and the ping climbing past 200ms. This is not due to hardware or network issues but the application and WINE itself. The game continues to work normally for native Windows users. A couple of other WINE users have reported this issue in TF2's WINE AppDB comment section.
http://bugs.winehq.org/show_bug.cgi?id=23578
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Alias|Immanuel | Severity|major |minor
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2010-07-09 11:31:32 --- http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=23578
Jeff Cook cookiecaper@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cookiecaper@gmail.com
--- Comment #2 from Jeff Cook cookiecaper@gmail.com 2010-07-09 11:32:32 --- I get this issue too. The timeframe is really unpredictable, but it does happen eventually during prolonged play.
The console outputs information about glsl errors when this occurs. I have a snippet saved but have to reboot out of Windows to get it. ;)
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #3 from Jeff Cook cookiecaper@gmail.com 2010-07-09 12:09:55 --- Created an attachment (id=29466) --> (http://bugs.winehq.org/attachment.cgi?id=29466) console output from crossover games's wine 9.0.0
Ah, it seems that the output isn't differentiated from the rest when I hit this issue in WINE 1.2rc6. However, the output in WINE from Crossover Games 9.0.0 _does_ output something different. I'll post it here in case it's useful anyway.
In WINE 1.2rc6, I just get a console spammed with lines like fixme:d3d_surface:IWineD3DSurfaceImpl_LoadLocation 0x1b2964b8: Downloading rgb texture to reload it as srgb, but that happens during normal gameplay too and I don't see any distinct messages.
http://bugs.winehq.org/show_bug.cgi?id=23578
Jeff Cook cookiecaper@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #29466|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #4 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-09 13:46:45 --- I will also note that after a "lag spike" the game will remain unplayable until I quit and reopen the game entirely.
http://bugs.winehq.org/show_bug.cgi?id=23578
Jeff Cook cookiecaper@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #5 from Jeff Cook cookiecaper@gmail.com 2010-07-09 14:10:27 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=23578
Kfir Itzhak mastertheknife@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mastertheknife@gmail.com
--- Comment #6 from Kfir Itzhak mastertheknife@gmail.com 2010-07-09 15:48:45 --- I have the same problem after the engineer update. I have wine 1.2_rc3, but i tried wine 1.2_rc5 and i still suffer the same problem.
After about anywhere from 10-30 minutes of gameplay, the game will become really slow, something like 2-5 fps and the only fix is to exit the game and reopen it, which makes playing tf2 really frusturating and unplayable.
I noticed that during the time its really slow, wineserver is using like 70% CPU and HL2 is using 20-30%.
Please let me know of any way i can help to solve this bug.
http://bugs.winehq.org/show_bug.cgi?id=23578
Immanuel Ortego immanuel.ortego@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Team Fortress 2: |Team Fortress 2: |Significant "lag" spikes |Significant lag disrupts |disrupt gameplay... |gameplay... Alias| |Immanuel
http://bugs.winehq.org/show_bug.cgi?id=23578
Immanuel Ortego immanuel.ortego@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Alias|Immanuel |
http://bugs.winehq.org/show_bug.cgi?id=23578
Paaru pcxunlimited@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pcxunlimited@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23578
Lars Blomqvist knaprigt@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |knaprigt@gmail.com
--- Comment #7 from Lars Blomqvist knaprigt@gmail.com 2010-07-09 22:06:31 --- I seem to have the same problem, but with Modern Warfare 2. The game slows to a crawl and wineserver is using 80% - 90% of the CPU, until I'm booted from the game.
No idea if this is something new when it comes to MW2 though since I up till recently had problems with the game, but I suspect my router was at fault that time.
Someone that's had no problems running MW2 (multiplayer) before might want to see if there's any difference in performance after the latest Steam update though, since I guess it wouldn't be that strange if this issue touched more than one Steam application.
http://bugs.winehq.org/show_bug.cgi?id=23578
webmaster@flippeh.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |webmaster@flippeh.de
--- Comment #8 from webmaster@flippeh.de 2010-07-09 22:44:56 --- Same problem here, only I do not have to restart TF2. It starts randomly, suddenly drops from 50 - 150 FPS down to (suspiciously constant) 7 - 10 FPS and after a few minutes (2 - 3) suddenly climbs back to 50 - 150. Rinse and repeat.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #9 from Kfir Itzhak mastertheknife@gmail.com 2010-07-10 07:59:24 --- (In reply to comment #8)
Same problem here, only I do not have to restart TF2. It starts randomly, suddenly drops from 50 - 150 FPS down to (suspiciously constant) 7 - 10 FPS and after a few minutes (2 - 3) suddenly climbs back to 50 - 150. Rinse and repeat.
I haven't tried waiting for 2-3 minutes to see what happens, i will try that sometime.
http://bugs.winehq.org/show_bug.cgi?id=23578
Stuart Freeman stuart@tyro.homelinux.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stuart@tyro.homelinux.com
--- Comment #10 from Stuart Freeman stuart@tyro.homelinux.com 2010-07-10 14:19:24 --- I'm experiencing this too. I've found that disconnecting from the server without exiting the game will often restore my framerate.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #11 from Paaru pcxunlimited@gmail.com 2010-07-10 16:06:49 --- comment #8: I tried waiting, but after a few minutes the game stops, and I get disconnected with a "Client has timed out" error. If I disconnect from the server, but remain in TF2, everything in the menu is awfully sluggish. For me, the only way to fix it is to restart TF2 completely.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #12 from Kfir Itzhak mastertheknife@gmail.com 2010-07-10 17:10:11 --- (In reply to comment #11)
comment #8: I tried waiting, but after a few minutes the game stops, and I get disconnected with a "Client has timed out" error. If I disconnect from the server, but remain in TF2, everything in the menu is awfully sluggish. For me, the only way to fix it is to restart TF2 completely.
I can confirm, game becomes timed out and only real fix to solve sluggishness is to restart tf2.
http://bugs.winehq.org/show_bug.cgi?id=23578
Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |an.unwashed.stripy.stocking | |@gmail.com
--- Comment #13 from Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com 2010-07-10 17:23:02 --- Like others have said, TF2 was running fine until the Engineer Update which was released 08/7/2010. Gameplay is smooth initially but after a short while playing, framerate drops to around 3 frames per second, finally freezing and causing the client to be dropped by the server.
I am using wine-1.1.42 with DX8 selected in the Steam TF2 startup option.
http://bugs.winehq.org/show_bug.cgi?id=23578
Dave acct-winehq@slicer.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acct-winehq@slicer.ca
--- Comment #14 from Dave acct-winehq@slicer.ca 2010-07-10 19:15:22 --- I get this too (latest wine from Git, gentoo x86_64). This may be related or not, but top shows, at least in my case, that Steam.exe spikes to 20% processor, causing wineserver to jump to 80% processor (both normally sit around 5%). This is the source of the lag I experience, renicing doesn't help. When I kill Steam, TF2 returns to full speed full framerate no lag, for a while, before it realizes that Steam is gone and it quits.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #15 from Paaru pcxunlimited@gmail.com 2010-07-10 19:45:57 --- Some more information: I created a listenserver and just walked around in it. There was nobody else connected to it, not even bots. I was the ONLY person in it.
It took over 30 minutes, but eventually the bug happened and TF2 slowed to a crawl. I open up gnome-system-monitor and looked at hl2.exe and wineserver.
When TF2 became insanely laggy, it was using up ~10% CPU, with wineserver using as much as it could get it's hands on. Normally it's ~10 CPU for wineserver and ~50% for TF2.
Something rather odd: the hl2.exe status would start at "Sleeping", a couple seconds later would change to "Stopped", then go back to "Sleeping", etc. This repeated multiple times until my client timed out.
wineserver's status remained at "Running" the whole time.
http://bugs.winehq.org/show_bug.cgi?id=23578
Scott Carrier scarrier_sonichero@comcast.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scarrier_sonichero@comcast. | |net
--- Comment #16 from Scott Carrier scarrier_sonichero@comcast.net 2010-07-10 20:25:53 --- When the lag hits me, the following two lines constantly repeat themselves:
fixme:d3d:fixed_get_input Unsupported input stream [usage=WINED3DDECLUSAGE_POSITION, usage_idx=1] fixme:d3d:fixed_get_input Unsupported input stream [usage=WINED3DDECLUSAGE_NORMAL, usage_idx=1]
One thing I noticed is that the lag didn't hit me while I was by myself or with one other person in a local server, or even with 15 bots. Yet, when I went online to a server with 5 other people, it hit me.
Oh, and using glsl-disable in winetricks did nothing to help the bug, so I'm thinking that this isn't a GLSL issue, unlike what the crossover log says.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #17 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-10 21:19:29 --- What are the chances of this bug being fixed within the next few weeks?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #18 from Jeff Zaroyko jeffz@jeffz.name 2010-07-10 22:22:10 --- (In reply to comment #17)
What are the chances of this bug being fixed within the next few weeks?
It's not clear what the problem is. Could be the existing source engine performance bug 12453.
There's been mention of network latency problems here, but I don't know that you can verify the problem to be with Wine only. I've seen intermittent network latency issues since the same update in CS:S on Windows.
http://bugs.winehq.org/show_bug.cgi?id=23578
Karsten Elfenbein kelfe@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kelfe@gmx.de
--- Comment #19 from Karsten Elfenbein kelfe@gmx.de 2010-07-11 03:13:40 --- the same thing happens in crossover games 9.0 after the engi update
http://bugs.winehq.org/show_bug.cgi?id=23578
Alfie Day winehq@azelphur.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@azelphur.com
--- Comment #20 from Alfie Day winehq@azelphur.com 2010-07-11 11:18:38 --- Another crossover games 9.0 user with the same problems.
Before the update I had an issue where every now and again the game would slow down for a few seconds, then return to normal.
Now, after the update, I get the same slow down problem, however it doesn't speed up again unless I completely restart the game.
I also have network (lag) issues that I didn't have prior to the update.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #21 from Jeff Zaroyko jeffz@jeffz.name 2010-07-11 12:41:38 --- (In reply to comment #20)
Another crossover games 9.0 user with the same problems.
This isn't the place to report issues with crossover games, try here instead http://www.codeweavers.com/support/
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #22 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-11 14:16:20 --- If Crossover fixes it I'm assuming it will be passed onto us? If they manage to fix it, they will most definitely get my financial support. It's about time for me to give back to the WINE project.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #23 from Henri Verbeet hverbeet@gmail.com 2010-07-11 15:30:10 --- Can anyone confirm this happens while playing online only? Does disabling sRGB sampling (http://bugs2.winehq.org/attachment.cgi?id=18409) make any difference? Is it possible to reproduce this with a timedemo?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #24 from Lukas Niederbremer webmaster@flippeh.de 2010-07-11 18:01:11 --- (In reply to comment #23)
Can anyone confirm this happens while playing online only? Does disabling sRGB sampling (http://bugs2.winehq.org/attachment.cgi?id=18409) make any difference? Is it possible to reproduce this with a timedemo?
I can confirm this happening offline. I just tested it.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #25 from Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com 2010-07-11 21:38:57 --- (In reply to comment #23)
Can anyone confirm this happens while playing online only? Does disabling sRGB sampling (http://bugs2.winehq.org/attachment.cgi?id=18409) make any difference? Is it possible to reproduce this with a timedemo?
Confirmed. I recorded demos until I caught the bug, replayed and the cpu load/ framerate death happens again at the exact same point when the demo is replayed offline.
http://bugs.winehq.org/show_bug.cgi?id=23578
Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|acct-winehq@slicer.ca, | |an.unwashed.stripy.stocking | |@gmail.com, | |cookiecaper@gmail.com, | |kelfe@gmx.de, | |knaprigt@gmail.com, | |mastertheknife@gmail.com, | |pcxunlimited@gmail.com, | |scarrier_sonichero@comcast. | |net, | |stuart@tyro.homelinux.com, | |webmaster@flippeh.de | CC|winehq@azelphur.com |
http://bugs.winehq.org/show_bug.cgi?id=23578
Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |an.unwashed.stripy.stocking | |@gmail.com
--- Comment #26 from Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com 2010-07-11 22:09:59 --- (In reply to comment #25)
Confirmed. I recorded demos until I caught the bug, replayed and the cpu load/ framerate death happens again at the exact same point when the demo is replayed offline.
Sorry, please discard this comment. On further investigation the apparent replication of the effect is just the recorded result of the direct impact on demo recording. The bug is not triggered again by playing back the demo.
http://bugs.winehq.org/show_bug.cgi?id=23578
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acct-winehq@slicer.ca, | |cookiecaper@gmail.com, | |kelfe@gmx.de, | |knaprigt@gmail.com, | |mastertheknife@gmail.com, | |pcxunlimited@gmail.com, | |scarrier_sonichero@comcast. | |net, | |stuart@tyro.homelinux.com, | |webmaster@flippeh.de
--- Comment #27 from Vitaliy Margolen vitaliy@kievinfo.com 2010-07-11 22:15:38 --- You removed all those people why?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #28 from Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com 2010-07-12 08:14:09 --- (In reply to comment #27)
You removed all those people why?
That is a very good question.
The answer is that a rather silly mistake has taken place, which will not be repeated.
Humble apologies to all inconvenienced.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #29 from Lars Blomqvist knaprigt@gmail.com 2010-07-12 17:29:56 --- Has anyone tried to run Steam/game with sound disabled (Alsa and OSS unchecked in winecfg)? At least on my system wineserver seems to behave better with the sound gone.
Note though that I'm running Modern Warfare 2, not TF2, but it seems like the same bug considering wineserver is eating up a lot of resources here too.
http://bugs.winehq.org/show_bug.cgi?id=23578
Brian sickwookie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sickwookie@gmail.com
--- Comment #30 from Brian sickwookie@gmail.com 2010-07-12 17:43:58 --- Disabling sound had no effect for me.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #31 from Brian sickwookie@gmail.com 2010-07-12 18:50:19 --- Switching windows version to XP in wine config seems to stop this problem. Can anyone else confirm this?
http://bugs.winehq.org/show_bug.cgi?id=23578
Corey coreyhtml@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |coreyhtml@gmail.com
--- Comment #32 from Corey coreyhtml@gmail.com 2010-07-12 22:05:02 --- (In reply to comment #31)
Switching windows version to XP in wine config seems to stop this problem. Can anyone else confirm this?
Nope, I've seen this issue while running TF2 in Windows XP mode.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #33 from Dave acct-winehq@slicer.ca 2010-07-12 22:29:32 --- (In reply to comment #31)
Switching windows version to XP in wine config seems to stop this problem. Can anyone else confirm this?
Nope here too, I get it in XP mode (and all other modes in which Steam works).
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #34 from Henri Verbeet hverbeet@gmail.com 2010-07-13 05:29:21 --- One thing you could try is running oprofile or some other profiler at the moment this happens.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #35 from Jeff Cook cookiecaper@gmail.com 2010-07-13 06:53:04 --- For the record, http://www.codeweavers.com/compatibility/browse/name/?app_id=3379;forum=1;ms... that post on Crossover's Compatibility Forum claims that this problem no longer exists in Crossover 9.1 beta. If anyone has access and can corroborate, that'd be nice.
I would test with wine from git but am currently not able to do so due to connection anomalies. Looking over the changes from rc6, I don't see anything that stands out as a potential fix, and I'm somewhat skeptical that this problem would not exist in rc7 or git, but we'll see if my connection behaves properly again soon.
http://bugs.winehq.org/show_bug.cgi?id=23578
Caron Jensen caron@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |caron@codeweavers.com
--- Comment #36 from Caron Jensen caron@codeweavers.com 2010-07-13 08:25:33 --- (In reply to comment #35)
For the record, http://www.codeweavers.com/compatibility/browse/name/?app_id=3379;forum=1;ms... that post on Crossover's Compatibility Forum claims that this problem no longer exists in Crossover 9.1 beta. If anyone has access and can corroborate, that'd be nice.
This report is in error. This issue is not resolved with CrossOver Games 9.1 beta1.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #37 from Jeff Cook cookiecaper@gmail.com 2010-07-13 10:27:16 --- Created an attachment (id=29567) --> (http://bugs.winehq.org/attachment.cgi?id=29567) oprofile log while bug occurs
This is a log from oprofile while the bug occurs. I am using the latest git HEAD. I sed'd out all lines that didn't mention wine. I'm new to oprofile so please let me know if this is incorrect or if you need anything else from me. It does seem that there are some errors on the % field, not sure if that matters or not.
Hope that helps.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #38 from Jeff Cook cookiecaper@gmail.com 2010-07-13 10:32:07 --- Tested with latest wine and noticed no change. The game can be playable for a long time -- I played for over an hour without hitting the bug. I also was able to leave the application running for several minutes after the bug occurred, I timed out from the server I was on, and after reconnecting I didn't have the bug anymore and I wasn't effected for the rest of the run of wine. I restarted the whole thing in an attempt to trigger the bug again. Still got nothing. Restarted again and got the bug almost immediately. I'm not sure if it's a one-time-per-run thing that most of us just aren't patient enough to power through or not. Has anyone gotten this multiple times after recovering without a restart/relaunch?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #39 from Caron Jensen caron@codeweavers.com 2010-07-13 14:01:32 --- (In reply to comment #38)
Has anyone gotten this multiple times after recovering without a restart/relaunch?
For me, this can happen every time I play 'offline' within cp_dustbowl, default settings (and by default I mean, I keep the 15 bots, always let the computer choose my character, etc). The first two stages are fine, and I can complete the third stage without getting the error. But, if I remain in the third stage for any amount of time (gain the first control point and then hang out), I'm bound to lose fps and eventually time out. When I time out, I return to the TF2 menu and from this point, I can relaunch and restart an offline session. However, I am more prone to see the behavior earlier on (like in the first stage as I connect).
Originally, I thought the five minute warning was triggering the behavior, but now I have had the drop in fps well before the warning and also after the warning.
The behavior seems to occur within 20-30 minutes of play.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #40 from Lukas Niederbremer webmaster@flippeh.de 2010-07-13 14:21:10 --- (In reply to comment #38)
Check response #8 from me. I can play this and (like everyone else) the bug will hit me sooner or later unless I quit before it can happen. It just seems random.
Now the part that differs from most other people: I can sit it out and wait for it to end and actually keep playing, whether I'm offline or online, on any server. I just have to sit through it for 2 - 3 minutes and everything is back to normal.
This keeps happening again and again until I don't want to play anymore.
Tested with latest wine and noticed no change. The game can be playable for a long time -- I played for over an hour without hitting the bug. I also was able to leave the application running for several minutes after the bug occurred, I timed out from the server I was on, and after reconnecting I didn't have the bug anymore and I wasn't effected for the rest of the run of wine. I restarted the whole thing in an attempt to trigger the bug again. Still got nothing. Restarted again and got the bug almost immediately. I'm not sure if it's a one-time-per-run thing that most of us just aren't patient enough to power through or not. Has anyone gotten this multiple times after recovering without a restart/relaunch?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #41 from Brian sickwookie@gmail.com 2010-07-13 14:26:01 --- (In reply to comment #38)
Tested with latest wine and noticed no change. The game can be playable for a long time -- I played for over an hour without hitting the bug. I also was able to leave the application running for several minutes after the bug occurred, I timed out from the server I was on, and after reconnecting I didn't have the bug anymore and I wasn't effected for the rest of the run of wine. I restarted the whole thing in an attempt to trigger the bug again. Still got nothing. Restarted again and got the bug almost immediately. I'm not sure if it's a one-time-per-run thing that most of us just aren't patient enough to power through or not. Has anyone gotten this multiple times after recovering without a restart/relaunch?
I can confirm that after waiting for about 2 minutes the frame rate increases back to normal. The timeouts seem to be related to inactivity from the client not the bug itself. If I continue to "play" I do not get disconnected, but if I just wait with no interaction I time out and get kicked by the server.
http://bugs.winehq.org/show_bug.cgi?id=23578
Alfie Day winehq@azelphur.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@azelphur.com
--- Comment #42 from Alfie Day winehq@azelphur.com 2010-07-13 18:27:29 --- (In reply to comment #41)
(In reply to comment #38)
Tested with latest wine and noticed no change. The game can be playable for a long time -- I played for over an hour without hitting the bug. I also was able to leave the application running for several minutes after the bug occurred, I timed out from the server I was on, and after reconnecting I didn't have the bug anymore and I wasn't effected for the rest of the run of wine. I restarted the whole thing in an attempt to trigger the bug again. Still got nothing. Restarted again and got the bug almost immediately. I'm not sure if it's a one-time-per-run thing that most of us just aren't patient enough to power through or not. Has anyone gotten this multiple times after recovering without a restart/relaunch?
I can confirm that after waiting for about 2 minutes the frame rate increases back to normal. The timeouts seem to be related to inactivity from the client not the bug itself. If I continue to "play" I do not get disconnected, but if I just wait with no interaction I time out and get kicked by the server.
I just tried this, I lasted ~3 minutes and then got client timed out anyway. I was still moving around and shooting.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #43 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-13 21:43:19 --- Even if you can wait 2 minutes and continue playing, it's still not very fun to play especially for scrims and competitive matches. :\ In other words, this bug prevents using the application for "normal use".
In my eyes, TF2 deserves a Bronze rating because of this bug.
http://bugs.winehq.org/show_bug.cgi?id=23578
Jeremy Newman jnewman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jnewman@codeweavers.com
--- Comment #44 from Jeremy Newman jnewman@codeweavers.com 2010-07-14 13:17:56 --- I wanted to confirm that this bug also happens for me in Modern Warfare 2 under Steam in Linux. I play MW2 for about 30 minutes and the game comes to a crawl. A quick check of top reports that wineserver is eating up all the CPU.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #45 from Henri Verbeet hverbeet@gmail.com 2010-07-14 14:10:48 --- For what it's worth, my current theory is that the "~4cc3.tmp" process you see in the oprofile log is something like Steam DRM or VAC trying to scan the memory of the game's main process. That would be the read_thread_long() and read_process_memory() calls you see. read_thread_long() uses PTRACE_PEEKDATA, which isn't very efficient, and that would account for the high amount of (Linux) kernel time. (Although you don't see the kernel time in the posted oprofile log.)
http://bugs.winehq.org/show_bug.cgi?id=23578
Bruce Pehl bruce.pehl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bruce.pehl@gmail.com
--- Comment #46 from Bruce Pehl bruce.pehl@gmail.com 2010-07-14 15:26:46 --- I can no longer enjoy TF2 because of this. A fix would be appreciated.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #47 from Jeff Cook cookiecaper@gmail.com 2010-07-14 22:31:25 --- Created an attachment (id=29611) --> (http://bugs.winehq.org/attachment.cgi?id=29611) oprofile log - first 40 lines uncut
You're correct that kernel functions are the next highest on the profile. I've attached the first 40 lines in the log uncut to demonstrate this. Hopefully this is useful.
It does seem like this is a change that affects all Steam games, so something like Steam DRM/VAC is probably a good hunch.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #48 from Professor Sock, of St. Trinians. an.unwashed.stripy.stocking@gmail.com 2010-07-15 19:43:16 --- It looks like Valve might have sorted this.
Played for a number of hours this evening with no problems at all and the intermittent stuttering which used to occur also seems to be completely gone. This is a change from the game becoming unusable after 10-15 mins on average.
This apparent improvement seems to have coincided with a patch which was released today:
------
"Counter-Strike: Source, Team Fortress 2 and Day of Defeat: Source Updates Released Product Update - Valve 14:46 Updates to Counter-Strike: Source, Team Fortress 2 and Day of Defeat: Source have been released. The updates will be applied automatically when your Steam client is restarted. The major changes include:
Engine Tuned thread initialization to improve performance on CPUs with more than four core"
---------
Undocumented fix perhaps? Can anyone confirm or was I just very very lucky? The improvement seems total however.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #49 from Dave acct-winehq@slicer.ca 2010-07-15 19:54:40 --- (In reply to comment #48)
I did as well, played for about an hour with no issues. Then I disconnected from the server for a while but left TF2 running. Later I reconnected and the bug (or at least the same symptoms) appeared after 5 minutes. (ahhh nuts!) Exiting (killing wineserver, etc.) and restarting Steam didn't help at that point.. within 10 mins the symptoms always re-appeared.
If I leave myself connected to try and wait it out I always get disconnected (client timed out).
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #50 from Lukas Niederbremer webmaster@flippeh.de 2010-07-15 22:07:09 --- I can CONFIRM this not being fixed. I just played (restarted steam client to make sure the new update hit me) and it still happened to me.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #51 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-15 22:11:53 --- I only lasted 10 minutes and 49 seconds until the game lagged out. The bug still exists with the new update.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #52 from Jeff Cook cookiecaper@gmail.com 2010-07-15 22:12:50 --- (In reply to comment #50)
I can CONFIRM this not being fixed. I just played (restarted steam client to make sure the new update hit me) and it still happened to me.
Yeah, I don't think it's fixed, people are just saying it's occurring less frequently now.
It'd be nice if someone could get cooperation from Valve and maybe see a diff between the Steam versions before and after the Engie update, I imagine that would help pinpoint the issue. We know that this affects all Steam games, not just TF2.
This issue _did_ exist before, but it would just slow down for three or four seconds at a time and come right back, so it was negligible. Perhaps Valve has greatly increased the aggressiveness of the scan?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #53 from Kfir Itzhak mastertheknife@gmail.com 2010-07-16 06:48:23 --- (In reply to comment #52)
It'd be nice if someone could get cooperation from Valve and maybe see a diff between the Steam versions before and after the Engie update, I imagine that would help pinpoint the issue. We know that this affects all Steam games, not just TF2.
This issue _did_ exist before, but it would just slow down for three or four seconds at a time and come right back, so it was negligible. Perhaps Valve has greatly increased the aggressiveness of the scan?
I doubt we will get any help from Valve, They only support Windows and Mac at this time.
Has anyone confirmed that it really exists on all Source engine games and not just TF2?
I think the solution is to find the slow function(s) and try to optimize those functions to be more efficient, or perhaps make those functions run slower, it seems its like a loop eating CPU, but if we add a small sleep after every loop iteration, TF2 should run better.
Such a patch probably won't be merged into wine, but it should be a nice fix for us TF2 users.
If anyone knows what is the slow function(s) causing the slowdown, please let me know and i will try working around the slowdown.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #54 from Kfir Itzhak mastertheknife@gmail.com 2010-07-16 07:33:19 --- Ok i did read some source code of wine.
Assuming the problem is VAC scanning memory aggressively like people said, i found two potential problems.
ReadProcessMemory() calls NtReadVirtualMemory() which sends a read_process_memory request to wineserver. wineserver dynamically allocates a temporary buffer (of requested size), calls read_process_memory with that buffer and that function is the one actually reading from the process's virtual memory, however, it doesn't seem efficient. To read the memory, it seems like its pausing a thread in the running program, reads the memory and lets the thread continue.
So it can be: 1) read_process_memory in wineserver/ptrace.c being inefficient 2) VAC reads the memory in small chunks, this causes wineserver to allocate memory for every request and believe me, malloc() can be expensive. I did a test year ago, malloc'ing 64,000 linked list nodes took over 10 seconds.
I will do a test and replace the memory allocation in the read_process_memory request with a fixed size buffer, the problem is, i'm not sure whats the maximum allowed read size for ReadProcessMemory() and how much memory VAC is trying to read at each call, i think 1MB might be a safe bet for testing without getting VAC banned.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #55 from Henri Verbeet hverbeet@gmail.com 2010-07-16 08:08:39 --- (In reply to comment #54)
ReadProcessMemory() calls NtReadVirtualMemory() which sends a read_process_memory request to wineserver. wineserver dynamically allocates a temporary buffer (of requested size), calls read_process_memory with that buffer and that function is the one actually reading from the process's virtual memory, however, it doesn't seem efficient. To read the memory, it seems like its pausing a thread in the running program, reads the memory and lets the thread continue.
Yeah, but it's worse than that. Look at the while-loop inside read_process_memory(), and the implementation of read_thread_long().
Another reasonable theory is VAC getting suspicious due to some implementation difference in Wine, and doing more aggressive scans because of that. I.e., that it wouldn't scan so much under normal circumstances. Considering the time it takes to reproduce this that would require prohibitive amounts of logging to track down / verify though.
http://bugs.winehq.org/show_bug.cgi?id=23578
Mr Nobody limited_choice@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |limited_choice@hotmail.com
--- Comment #56 from Mr Nobody limited_choice@hotmail.com 2010-07-17 07:37:26 --- FWIW, using latest crossovergames && the steam gui -beta- seems to alleviate the problem. I'll check with a 1.2-rc a bit later. I know this doesn't <prove> very much, more of an observation....can anyone else confirm using wine ?...
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #57 from Alfie Day winehq@azelphur.com 2010-07-17 10:59:16 --- (In reply to comment #56)
FWIW, using latest crossovergames && the steam gui -beta- seems to alleviate the problem. I'll check with a 1.2-rc a bit later. I know this doesn't <prove> very much, more of an observation....can anyone else confirm using wine ?...
I still get the same issue after opting into the steam beta.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #58 from Mr Nobody limited_choice@hotmail.com 2010-07-18 00:09:33 --- (In reply to comment #57)
(In reply to comment #56)
FWIW, using latest crossovergames && the steam gui -beta- seems to alleviate the problem. I'll check with a 1.2-rc a bit later. I know this doesn't <prove> very much, more of an observation....can anyone else confirm using wine ?...
I still get the same issue after opting into the steam beta.
Yeah, rechecked with 1.2 and it's still there (and in CX)...just seems to take a little longer to manifest itself for me if opted into the steam beta...
http://bugs.winehq.org/show_bug.cgi?id=23578
sh shooter0106@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shooter0106@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #59 from Lukas Niederbremer webmaster@flippeh.de 2010-07-18 17:02:02 --- O opted into the Steam client beta, and ever since I did that, I didn't get this bug even ONCE. The whole day, multiple hours of playing.
I'll observe this some more, but as of now I call it fixed for me!
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #60 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-18 20:01:11 --- I've opted for the beta and the problem still occurs for me. In fact, it's happening either immediately or even sooner than it has before.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #61 from sh shooter0106@gmail.com 2010-07-18 20:47:59 --- I played twice an hour using a virtual desktop wine, and problems with the FPS did not appear. Maybe luck, I'll try today again.
http://bugs.winehq.org/show_bug.cgi?id=23578
peter.maciocia+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter.maciocia+winebugs@gma | |il.com
--- Comment #62 from peter.maciocia+winebugs@gmail.com 2010-07-19 06:30:11 --- Updated from git this morning and tried using the steam beta and i still had this issue.
http://bugs.winehq.org/show_bug.cgi?id=23578
mhdevel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mhdevel@gmail.com
--- Comment #63 from mhdevel@gmail.com 2010-07-20 00:26:51 --- i can confirm that bug. as i played pl_thundermountain on stage 2 / blu, the bug hits me nearly consistent. leaving the respawn point, on the bridge, and the bug was there. i tried two or three times, it was the same all the time.
what about playing on a unsecured server, or isnt that possible? if the bug does not occur, then vac could be the problem.
i had fps drops before the engineer update too, but the game did get back to normal state after some seconds.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #64 from Alexandre Julliard julliard@winehq.org 2010-07-20 07:23:55 --- Created an attachment (id=29724) --> (http://bugs.winehq.org/attachment.cgi?id=29724) Avoid PTRACE_PEEKDATA if possible.
Try if this makes a difference.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #65 from Jeff Cook cookiecaper@gmail.com 2010-07-20 07:28:05 --- I will give that patch a try soon. Has anyone produced a method that can reliably trigger this bug? It'd make testing much easier and faster. We know that this problem is caused by the anti-cheat code; is there something that can trigger a scan specifically?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #66 from peter.maciocia+winebugs@gmail.com 2010-07-20 10:20:56 --- Had a try with the latest git build and that patch, but still had the client time out issue. It did seem to fix the lag spike though.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #67 from Lukas Niederbremer webmaster@flippeh.de 2010-07-20 13:56:59 --- I have been playing every day for many hours now. NOTHING happened. It did NOT lock up. I noticed something new.. instead of the old 2 - 3 minute lags I now get 2 - 3 SECOND lags. Not worth complaining about, my TF2 is 100% playable again.
Using Wine 1.2 (the final release, not RC) and the Steam beta did the trick for me.
http://bugs.winehq.org/show_bug.cgi?id=23578
Tom Hackers tomhackers@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tomhackers@gmail.com
--- Comment #68 from Tom Hackers tomhackers@gmail.com 2010-07-20 14:08:21 --- Lukas Niederbremer said that his game is running ok. I have to confirm that. I use new steam ui with win7 mode. But i had lag spike after engi update, to fix that i just switched hl2.exe to win98 mode. I lost russian chars in game, but game never lag. I expire random fps drop for 2 seconds every 10 minutes of gameplay.
P.s. game is running in windowed mode and minimize all steam windows, coz every steam window give 2-3 fps loss for me.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #69 from Lukas Niederbremer webmaster@flippeh.de 2010-07-20 14:36:28 --- Now that you mention it, I switched Windows 98 on for "hl2.exe", but it wasn't the hl2.exe in Team Fortress 2, it was the one of Garry's Mod. Does WINE check the full path or just the executable file name? If so, this might have been the trick to it.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #70 from Tom Hackers tomhackers@gmail.com 2010-07-20 14:56:46 --- Lukas Niederbremer. Alien Swarm came out 20th July. I expire same lag spike bug in it. It doesn't work on Win98 mod, unlike tf2.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #71 from Tom Hackers tomhackers@gmail.com 2010-07-20 15:48:07 --- Lukas Niederbremer, will test win2000 mode...
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #72 from Jeff Cook cookiecaper@gmail.com 2010-07-20 16:19:34 --- I just played for about 30 minutes with the attached PTRACE_PEEKDATA patch against 1.2 (NOT git) and didn't experience any problems. This playtime is not very long, but that is a pretty good result so far I think. I am not using the Steam beta (and my Settings page now says "None currently available...").
I will try to get wine built with this patch on the computer of someone whom I know will have a lot more playtime and get his report soon. Will report back once I have done that.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #73 from Tom Hackers tomhackers@gmail.com 2010-07-20 20:37:09 --- Played for 1 hour with that patch (compiled 1.2 wine release with that patch) with 8-10 players. No lag and my fps was bigger then usual. :O Will test with more people at morning. (win mode was Windows XP)
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #74 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-20 20:44:54 --- I've played for 2 hours straight. No lag and no problems. Would it be safe to consider this resolved?
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #75 from Immanuel Ortego immanuel.ortego@gmail.com 2010-07-20 20:45:58 --- (In reply to comment #74)
I've played for 2 hours straight. No lag and no problems. Would it be safe to consider this resolved?
Also, this is with the patch and Wine 1.2.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #76 from Jeff Cook cookiecaper@gmail.com 2010-07-21 01:39:27 --- I have just played for about an hour without an issues with the attached patch.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #77 from peter.maciocia+winebugs@gmail.com 2010-07-21 03:47:37 --- After more testing i've had no lag spikes or disconnects. I'd say the issue is resolved.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #78 from Tom Hackers tomhackers@gmail.com 2010-07-21 04:59:00 --- Seems like this patch works for l4d engine (and any source engine) games as well. Played Alien Swarm with this patch, no lag spikes as well (played for ~90 minutes).
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #79 from sh shooter0106@gmail.com 2010-07-21 05:51:52 --- (In reply to comment #78)
Seems like this patch works for l4d engine (and any source engine) games as well. Played Alien Swarm with this patch, no lag spikes as well (played for ~90 minutes).
How do you do it? My FPS in Alien Swarm only about 15. Sorry for Offtopic.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #80 from Tom Hackers tomhackers@gmail.com 2010-07-21 08:20:08 --- (In reply to comment #79)
(In reply to comment #78)
Seems like this patch works for l4d engine (and any source engine) games as well. Played Alien Swarm with this patch, no lag spikes as well (played for ~90 minutes).
How do you do it? My FPS in Alien Swarm only about 15. Sorry for Offtopic.
Again offtopic (but it is still source game). Alien Swarm is 9 fps for me. Lags very rarely on 2-3 players tho, but will almost always lag with 4 players. :( Patch helps tf2 game only. Sadly. (was playing for 5 hours)
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #81 from Jeff Cook cookiecaper@gmail.com 2010-07-21 10:51:33 --- Lag in Alien Swarm is a separate issue, I would assume.
Can one of the guys that experienced this on MW2 chime in? That would be helpful, though this patch does seem to fix this issue completely. Valve updated their anti-cheat code, which triggered more aggressive/frequent scans; apparently there was some incongruency in WINE's implementation of the Windows syscalls. From the patch, it looks like Windows would perform a memory size check and if it was the expected size, not pursue the scan.
I would consider this issue resolved. Many thanks to everyone who helped out with it.
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #82 from Austin English austinenglish@gmail.com 2010-07-21 11:10:05 --- Patch committed: http://source.winehq.org/git/wine.git/?a=commitdiff;h=1a79912a10a6cded54d1f1...
http://bugs.winehq.org/show_bug.cgi?id=23578
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Target Milestone|--- |1.2.x
--- Comment #83 from Alexandre Julliard julliard@winehq.org 2010-07-21 11:44:11 --- Assuming fixed.
http://bugs.winehq.org/show_bug.cgi?id=23578
geek-59600@hotmail.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |geek-59600@hotmail.fr
--- Comment #84 from geek-59600@hotmail.fr 2010-07-24 19:59:15 --- When i try to use steam with wine-1.2-422-ge158bb0 steam tell me it can't load the library "/bin/vgui2.dll" but with wine 1.2 "standart" i haven't this problem anyone can help me ?
Thank you
http://bugs.winehq.org/show_bug.cgi?id=23578
--- Comment #85 from Tom Hackers tomhackers@gmail.com 2010-07-25 10:07:10 --- (In reply to comment #84)
When i try to use steam with wine-1.2-422-ge158bb0 steam tell me it can't load the library "/bin/vgui2.dll" but with wine 1.2 "standart" i haven't this problem anyone can help me ?
Thank you
Uh, just reinstall steam, but don't forget to save your steamapps dir. It has all games.
http://bugs.winehq.org/show_bug.cgi?id=23578
peter.maciocia+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|peter.maciocia+winebugs@gma | |il.com |
http://bugs.winehq.org/show_bug.cgi?id=23578
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #86 from Alexandre Julliard julliard@winehq.org 2010-07-30 12:58:49 --- Closing bugs fixed in 1.3.0.
http://bugs.winehq.org/show_bug.cgi?id=23578
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.2.x |---
--- Comment #87 from Alexandre Julliard julliard@winehq.org 2010-10-08 10:40:50 CDT --- Removing 1.2.x milestone from bugs fixed in 1.2.1.
-
wine-bugs＠winehq.org