[Bug 29168] New: Star Wars: The Old Republic game client hangs at
http://bugs.winehq.org/show_bug.cgi?id=29168 Bug #: 29168 Summary: Star Wars: The Old Republic game client hangs at Product: Wine Version: 1.3.33 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: erik.weatherwax(a)gmail.com Classification: Unclassified Created attachment 37628 --> http://bugs.winehq.org/attachment.cgi?id=37628 Console output Upon successful launching of the game client after logging in via the game launcher, no progress is made towards loading the game after the initial splash screen: it merely sits at the initial splash with a sort of "Working" icon spinning in the lower right indefinitely. Console output is attached but doesn't seem to be much help; it is mostly just spam of: fixme:win:GetWindowPlacement not supported on other process window 0xa0026 fixme:d3d:query_init Unhandled query type 0xc. Originally suspected this was a server-side or game client problem since some Windows users were reporting similar issues at the beginning of this beta test weekend; however, any of numerous purported workarounds fail to work in Wine, and it seems the problem pretty uniformly affects Wine users, at least in Linux. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Erik Weatherwax <erik.weatherwax(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Star Wars: The Old Republic |Star Wars: The Old Republic |game client hangs at |game client hangs at intro | |splash -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 wiggmpk(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wiggmpk(a)gmail.com --- Comment #1 from wiggmpk(a)gmail.com 2011-11-26 01:23:18 CST --- If you take a look inside the install direction, navigate to ../betatest/retailclient/LoadingScreens/ and rename both files, I use *.old. Takes care of this issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #2 from Erik Weatherwax <erik.weatherwax(a)gmail.com> 2011-11-26 01:56:09 CST --- Tried that, but now I'm just looking at an eternal black screen instead of an eternal load screen. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Florian Traverse <florian.traverse(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |florian.traverse(a)gmail.com --- Comment #3 from Florian Traverse <florian.traverse(a)gmail.com> 2011-11-26 03:04:32 CST --- Same issue. Tried the workaround. The launcher tries to download a new file but has an error (I don't have the stack :() and pops up a small alert with comething like biteset or bitefield error. So I tried to rename back the .jpg from .jpg.old , but it did not work, it doesn't try anymore to download something, but I haven't the "play" button either -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #4 from wiggmpk(a)gmail.com 2011-11-26 04:39:47 CST --- Confirm you are renamed BOTH files in this folder, like mentioned. It should contain: LoadingIconAnim.dds LoadingScreen.jpg @Erik Weatherwax your symptom implies you didnt rename BOTH files. If you remove the .jpg its still loading the animation, but you can't see it now, because the image is gone (at least that sounds logical) @Florian Traverse again, you only mention renaming the .jpg so try BOTH files like mentioned. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Jack <niniendowarrior(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |niniendowarrior(a)gmail.com --- Comment #5 from Jack <niniendowarrior(a)gmail.com> 2011-11-26 05:06:41 CST --- I would also like to point out that during the intro splash screen, the bottom left corner menu works. These buttons are visible if you get the server listing screen to appear. If you click the bottom left area of the screen, you will here a confirmation sound then press ESC to quit the game while the splash screen is running. I suspect that the splash screen is displayed over the server listing display while the game waits for the list of servers which will never arrive. I was burnt out trying different dll combinations hoping it was a network related deficiency but I have come up with nothing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #6 from Jack <niniendowarrior(a)gmail.com> 2011-11-26 06:02:09 CST --- @wiggmpk I just tried your workaround. Basically this will not work when BioWare is pushing out a patch. There will be an error during installation on bitfield.c or something. So if there's an update, be sure to rename the files back to what they were. I added .old on each of them to get rid of them. With the workaround applied (after the new patch I got from BioWare), the server is now listed (there's quite a lot of them). Clicking one server and select shows a tiny blue window. Not sure what it is but so far, that's where things stopped. I will let this run a bit further to see if there are any progress. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #7 from wiggmpk(a)gmail.com 2011-11-26 06:29:40 CST --- (In reply to comment #6)
@wiggmpk I just tried your workaround. Basically this will not work when BioWare is pushing out a patch. There will be an error during installation on bitfield.c or something. So if there's an update, be sure to rename the files back to what they were. I added .old on each of them to get rid of them.
With the workaround applied (after the new patch I got from BioWare), the server is now listed (there's quite a lot of them). Clicking one server and select shows a tiny blue window. Not sure what it is but so far, that's where things stopped. I will let this run a bit further to see if there are any progress.
This seems to be an issue with Windows users as well right now. I am literally loosing sleep to try and work around this. I have tried many different servers (including North America & Europe) with the same blue dialog box (after clicking select) with no information being displayed. The client looks like its getting stuck and I think the loading screen might be related to this issue. It's a good point your bring up, every patch will nerf the workaround to get to server select (but its a small baby step of progress) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #8 from Jack <niniendowarrior(a)gmail.com> 2011-11-26 07:59:56 CST --- I'm not ready to sign this off as a server side issue. For one thing, the knowledge base isn't getting updated and I saw several servers that are full with "Calculating" written but it doesn't ever update. I also remember that on the Official Forum, the splash screen with the blue cogs should be making a return after selecting servers (which with your workaround means a blackscreen). This is basically what most of the complaints on the loading screen seems to be. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #9 from Erik Weatherwax <erik.weatherwax(a)gmail.com> 2011-11-26 10:19:08 CST --- (In reply to comment #4)
Confirm you are renamed BOTH files in this folder, like mentioned.
It should contain: LoadingIconAnim.dds LoadingScreen.jpg
@Erik Weatherwax your symptom implies you didnt rename BOTH files. If you remove the .jpg its still loading the animation, but you can't see it now, because the image is gone (at least that sounds logical)
@Florian Traverse again, you only mention renaming the .jpg so try BOTH files like mentioned.
$ ls betatest/retailclient/LoadingScreens/ LoadingIconAnim.dds.bak LoadingScreen.jpg.bak Still no good. There is some speculation that the effectiveness of this workaround depends on whether or not one has prior characters in the game. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 TJ <johansen.priv(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johansen.priv(a)gmail.com --- Comment #10 from TJ <johansen.priv(a)gmail.com> 2011-11-26 10:32:27 CST --- I've been able to load the serverlist by: a) Renaming both files in folder LoadingScreens b) Renaming only LoadingScreen.jpg After renaming one or both of the files I've not been asked to download anything new by the launcher. I did however patch the game before trying to rename anything. I have NOT chosen server/made any characters previously. After selecting server I end up with a tiny empty window which was previously mentioned, could be a another problem though. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Stefan <stefan(a)wilsky.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)wilsky.de --- Comment #11 from Stefan <stefan(a)wilsky.de> 2011-11-26 11:46:55 CST --- (In reply to comment #9)
Still no good. There is some speculation that the effectiveness of this workaround depends on whether or not one has prior characters in the game.
I can also confirm that renaming or deleting both files isn't a general solution for everyone. Now I just have a black screen and the game's mouse cursor. I thought it's a problem with directx now, for I have tried everything like reinstalling wine or d3dx9 and different options in the "Libraries" tab, but other games like LotRo work fine. I have already selected a server and created a character on my girlfriend's windows pc, perhaps it has something to do with the problem. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 sxe <sxxe(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sxxe(a)gmx.de -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 sxe <sxxe(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sxxe(a)gmx.de | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 sxe <sxxe(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sxxe(a)gmx.de --- Comment #12 from sxe <sxxe(a)gmx.de> 2011-11-26 13:08:35 CST --- (In reply to comment #10)
I've been able to load the serverlist by: a) Renaming both files in folder LoadingScreens b) Renaming only LoadingScreen.jpg
After renaming one or both of the files I've not been asked to download anything new by the launcher. I did however patch the game before trying to rename anything.
I have NOT chosen server/made any characters previously.
After selecting server I end up with a tiny empty window which was previously mentioned, could be a another problem though.
I can confirm this. I get exactly the same behavior after renaming the files. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #13 from Jack <niniendowarrior(a)gmail.com> 2011-11-26 16:36:02 CST --- With the recent run, I no longer think it's a networking issue as the server list updated with the current load. Every server is full. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Justin Gray <justinanthonygray(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |justinanthonygray(a)gmail.com --- Comment #14 from Justin Gray <justinanthonygray(a)gmail.com> 2011-11-26 21:11:52 CST --- I attempted each workaround listed. I am using CrossOver to handle most of the activities. I have two accounts. One blank and one has 8 characters on it. 1: I renamed both LoadingIconAnim.dds LoadingScreen.jpg to LoadingIconAnim.dds.old LoadingScreen.jpg.old 2: I forced the library to use dxd9_36.dll 3: Turned off WiFi after pushing play button 4: Tried using a fresh account without any characters I tried variations on each of these workarounds to no success. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #15 from Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> 2011-11-26 21:18:05 CST --- (In reply to comment #14)
I am using CrossOver This bugzilla is for plain Wine only. Please install regular Wine, or contact Code Weavers for support.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #16 from Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> 2011-11-26 21:18:42 CST --- Also confirming - multiple users having issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #17 from Stefan <stefan(a)wilsky.de> 2011-11-27 08:11:30 CST --- Perhaps having a black screen is not a wine only problem? http://www.swtor.com/community/showthread.php?t=664073 already 40+ pages, the problem sounds very similar. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #18 from Erik Weatherwax <erik.weatherwax(a)gmail.com> 2011-11-27 15:41:32 CST --- (In reply to comment #17)
Perhaps having a black screen is not a wine only problem?
I can't discount that possibility. However, for each Windows user having problems with the beta, hundreds are not. On the other hand, I don't know of *any* Wine users who aren't experiencing issues. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #19 from Jack <niniendowarrior(a)gmail.com> 2011-11-27 16:24:57 CST --- I also think the black screen has more to do with the Loading screens being removed. Just my two cents. I've been looking into netstat and I don't think I've seen anything different when SWTOR attempts to connect to a server. I find that a little strange. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Kristian Robertsen <kristian.robertsen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kristian.robertsen(a)gmail.co | |m --- Comment #20 from Kristian Robertsen <kristian.robertsen(a)gmail.com> 2011-11-27 19:50:52 CST --- I've had the same issue myself during the weekend testing. I only got around to working on it tonight, and I finally managed to get to the server screen... The forum thread answers about updating drivers held true for me, as did the workaround suggested here; renaming LoadingIconAnim.dds LoadingScreen.jpg I was using the ubuntu-supplied nvidia 280.xx drivers, updating to the closed source 290.xx drivers from Nvidia got me past the white/black screen (alternating depending on whether I had TwinView enabled or not) I would get after renaming the loading screen files. Renaming the loading screen files back got me stuck again. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Benh <ixfrom(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ixfrom(a)gmail.com --- Comment #21 from Benh <ixfrom(a)gmail.com> 2011-11-28 16:23:05 CST --- (In reply to comment #9)
(In reply to comment #4)
Confirm you are renamed BOTH files in this folder, like mentioned.
It should contain: LoadingIconAnim.dds LoadingScreen.jpg
@Erik Weatherwax your symptom implies you didnt rename BOTH files. If you remove the .jpg its still loading the animation, but you can't see it now, because the image is gone (at least that sounds logical)
@Florian Traverse again, you only mention renaming the .jpg so try BOTH files like mentioned.
$ ls betatest/retailclient/LoadingScreens/ LoadingIconAnim.dds.bak LoadingScreen.jpg.bak
Still no good. There is some speculation that the effectiveness of this workaround depends on whether or not one has prior characters in the game.
Your speculation is right, i made the test with two accounts. Account 1 has prior characters, Account 2 has no character. Account 1 shows the splash screen permanently (or a white screen if the files above are renamed). Account 2 shows the server list when the two files are renamed. I'm able to choose a server but when i click select, i hear a sound and then nothing happens. When the files are not renamed i only see the splash screen but i can hear the server list is behind when i do a mouseover where it's supposed to be -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Luke Bratch <l_bratch(a)yahoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch(a)yahoo.co.uk -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #22 from Stefan <stefan(a)wilsky.de> 2011-12-13 11:37:35 CST --- (In reply to comment #21)
Your speculation is right, i made the test with two accounts. Account 1 has prior characters, Account 2 has no character.
Account 1 shows the splash screen permanently (or a white screen if the files above are renamed).
Account 2 shows the server list when the two files are renamed. I'm able to choose a server but when i click select, i hear a sound and then nothing happens. When the files are not renamed i only see the splash screen but i can hear the server list is behind when i do a mouseover where it's supposed to be
I can confirm this. I made my character with a windows pc before, on wine I could only see the splash or black screen. Now at release (preorder) and without any characters I can see the server list, too (renamed the files). After server selection nothing happens. So the problem with splash screen has a good workaround, but here we have a new bug? With a premade character or after server selection we should see the character creation/selection screen. Here nothing happens. I also noticed that behind the server selection i could not see anything. I could be wrong, but shouldn't there be any 3d ship models or something? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Ahmed W. <oneofone(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oneofone(a)gmail.com --- Comment #23 from Ahmed W. <oneofone(a)gmail.com> 2011-12-14 03:01:58 CST --- I can confirm this as well. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 MrJake <mrjake(a)kacknet.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrjake(a)kacknet.com --- Comment #24 from MrJake <mrjake(a)kacknet.com> 2011-12-15 07:21:50 CST --- Game is running official release now. its no more a beta. anyone has a work around for this. I got it installed and the mouse issue has been fixed since. I just hang at that screen with that mechanical wheel spinning randomly almost laughing at me :P Would be nice to get this working -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #25 from Ahmed W. <oneofone(a)gmail.com> 2011-12-15 10:42:52 CST --- I narrowed it down to a networking issue with winsock, but I have no idea what since there are absolutely no FIXMEs/warnings related to networking. Using wireshark I can tell that the game connects to the server for 30-60 seconds then disconnects and leaves that loading screen on. On windows 7 (using vmware) it connects fine and I was able to play for 6 hours without any problems, the only problem was having 10 fps on lowest settings but that's expected from vmware I suppose. So it *is* in wine's networking code, I just have no idea how to pinpoint it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #26 from Erik Weatherwax <erik.weatherwax(a)gmail.com> 2011-12-15 10:49:24 CST --- (In reply to comment #25)
I narrowed it down to a networking issue with winsock, but I have no idea what since there are absolutely no FIXMEs/warnings related to networking.
Using wireshark I can tell that the game connects to the server for 30-60 seconds then disconnects and leaves that loading screen on.
On windows 7 (using vmware) it connects fine and I was able to play for 6 hours without any problems, the only problem was having 10 fps on lowest settings but that's expected from vmware I suppose.
So it *is* in wine's networking code, I just have no idea how to pinpoint it.
Thanks for the confirmation, Ahmed. I just noticed the same thing (well, noticed an outbound TCP connection to an EA server in netstat) whereas in the past betas I never saw any outbound connection attempt to EA -- so that's an improvement, I guess? Might I ask what version of vmware you're using? I use VirtualBox for my virtualization at home, but it usually chokes on any attempt to play modern games, even with the "experimental" 3d support. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 talkingodlor(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |talkingodlor(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #27 from Ahmed W. <oneofone(a)gmail.com> 2011-12-16 02:28:54 CST --- In the 11/11 beta, it worked perfectly fine, in the following ones it did exactly the same thing, connect to last-server and disconnect 30s later and never try again I'm running VMWare 8.0.1 with Windows 7 Enterprise (32bit), I've been playing on it for the past 12 hours or so, getting 10-20 fps at 1920x1080 with lowest settings and shadows off. I *really* want this to run on wine, since the last working beta I ran the game on max settings and it had 30+ fps :( Stupid bioware, why did they break it :( -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com --- Comment #28 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-16 04:50:19 CST --- (In reply to comment #25)
I narrowed it down to a networking issue with winsock, but I have no idea what since there are absolutely no FIXMEs/warnings related to networking.
Using wireshark I can tell that the game connects to the server for 30-60 seconds then disconnects and leaves that loading screen on.
....
So it *is* in wine's networking code, I just have no idea how to pinpoint it.
Please, attach a +winsock debug log until the game disconnects. You can gzip it if it's too big. What do you think it's causing the disconnection? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #29 from Erik Weatherwax <erik.weatherwax(a)gmail.com> 2011-12-16 10:58:53 CST --- Created attachment 37992 --> http://bugs.winehq.org/attachment.cgi?id=37992 Compressed +winsock log WINEDEBUG=+winsock log attached. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #30 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-16 21:56:52 CST --- Created attachment 37997 --> http://bugs.winehq.org/attachment.cgi?id=37997 short winsock debug log Here's a short log containing just the connection to the server after selecting from the list. I verified this by correlating to the IP address and port from netstat: xoloki(a)xocotl:~$ sudo netstat -t -n -p 2>&1 | grep win tcp 0 0 192.168.10.101:39305 159.153.124.223:8995 ESTABLISHED 3496/wineserver -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #31 from Ahmed W. <oneofone(a)gmail.com> 2011-12-16 21:58:11 CST --- Created attachment 37998 --> http://bugs.winehq.org/attachment.cgi?id=37998 cleaned up +winsock,-d3d,-win,-oss I cleaned up the log a bit, this is the relevant part, all the other spam is before the actual client tries to connect. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 jordi.davis_11(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jordi.davis_11(a)yahoo.com --- Comment #32 from jordi.davis_11(a)yahoo.com 2011-12-17 03:52:54 CST --- I am having trouble on my Mac using Wine for SWTOR. I have downloaded the client using Wine, I have uploaded the launcher using Wine, I sign in. but then whenever I press play, it comes up with something saying it needs to change my graphics resolution or something to fit the screen or something like that. I press that and then it either goes to a black screen or a smaller blank white screen. I can Command/alt A out of it but its just a blank screen for the application. Is there any way I can fix this???! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #33 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-17 10:05:43 CST --- It seems like the game can't find the server: trace:winsock:WS_gethostbyname "skynet01.aus.bwa" ret (nil) I can't resolve that name either. There are several results in google about that address name problem. Maybe something is wrong before that and it then tries a default server that does not exist anymore. It's also weird that it sends and receives 1 byte messages. But I guess that's planned. Is there a demo available for this game that triggers the problem? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Dan <rohleder18(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rohleder18(a)gmail.com --- Comment #34 from Dan <rohleder18(a)gmail.com> 2011-12-17 10:34:48 CST --- (In reply to comment #33)
It seems like the game can't find the server: trace:winsock:WS_gethostbyname "skynet01.aus.bwa" ret (nil)
I can't resolve that name either. There are several results in google about that address name problem. Maybe something is wrong before that and it then tries a default server that does not exist anymore.
It's also weird that it sends and receives 1 byte messages. But I guess that's planned. Is there a demo available for this game that triggers the problem?
Check out my comment half-way down at http://appdb.winehq.org/commentview.php?iAppId=13553&iVersionId=24528&iThrea... This appears to be used for internal debugging at Bioware when connections go wrong. Immediately following the skynet DNS query, it tries to send some data to a private subnet. Based on the beta info, I verified I could receive the JSON objects for the server lists, it just never displays it to the user. It then proceeds to the skynet and private network comms attempts. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Andrew Resch <andrewresch(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewresch(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Nicklas Larsson <nicklas.larsson(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nicklas.larsson(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #35 from Nicklas Larsson <nicklas.larsson(a)gmail.com> 2011-12-17 15:24:33 CST --- Created attachment 38006 --> http://bugs.winehq.org/attachment.cgi?id=38006 Compressed +winsock,-d3d,-win,-oss,-alsa -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #36 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-17 17:12:35 CST --- Why the application sends and receives 1 byte packets? Does that happen in windows (one can tell using wireshark). If you telnet to 159.153.75.94 port 8995 you will receive a 22 byte package, I can't see that in your log. There are several read requests (near to log end) but they are probably over -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #37 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-17 17:14:59 CST --- If you telnet to 159.153.75.94 port 8995 you will receive a 22 byte package, I can't see that in your log. There are several read requests (near to log end) but they are probably overlapped because they are not followed by "WS2_recv_base -> xxx bytes" nor 10035 (no data to read) error. Can you rerun with wireshark in gnu/linux and check that it receives the 22 bytes before quitting? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #38 from Nicklas Larsson <nicklas.larsson(a)gmail.com> 2011-12-17 17:26:55 CST --- Created attachment 38008 --> http://bugs.winehq.org/attachment.cgi?id=38008 Wireshark(1.6.2)/tcpdump/libpcap -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #39 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-17 17:37:15 CST --- Please, give it a new try. Using wireshark add a "port 8995" filter. After the packets are captured use the File->Export->Plain text. It will dump in a readable format that's easier to see. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Nicklas Larsson <nicklas.larsson(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #38008|0 |1 is obsolete| | --- Comment #40 from Nicklas Larsson <nicklas.larsson(a)gmail.com> 2011-12-17 17:48:24 CST --- Created attachment 38009 --> http://bugs.winehq.org/attachment.cgi?id=38009 text export -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Nicklas Larsson <nicklas.larsson(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #38009|text export |wireshark text export description| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #41 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-17 19:03:17 CST --- Here they are: Data: 03160000001511000000080000006e2d0b19469c9db9 [Length: 22] My theory is that wine is not receiving this data because I can't see it in the winsock log. Do you have strace installed? We need to check if the application received the bytes. If you have strace you can run: strace wine <app.exe> 2>&1 | grep 'socket\|connect\|recv\|poll\|close' > /tmp/reallylong.txt I'm looking for a recv() call that returns that 22 bytes. If it's not there wine is really not receiving the data and the app is timing out and quitting. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #42 from Nicklas Larsson <nicklas.larsson(a)gmail.com> 2011-12-17 20:17:02 CST --- (In reply to comment #41)
If you have strace you can run: strace wine <app.exe> 2>&1 | grep 'socket\|connect\|recv\|poll\|close' > /tmp/reallylong.txt
with strace i can't get pass the first "login"(20min gave up/log pushes halv a gig) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #43 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-17 20:23:52 CST --- Possibly because of the 'poll' word in grep. Retry without it, please. If it's still too big try: strace -e read wine <app.exe> 2>&1 | grep '= 22' > /tmp/read22only.txt It will fetch only the read which receives 22 bytes, if it's not there in the end of the process we can be sure wine didn't receive it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #44 from Nicklas Larsson <nicklas.larsson(a)gmail.com> 2011-12-17 21:15:42 CST --- (In reply to comment #43)
Possibly because of the 'poll' word in grep. Retry without it, please.
even with "-e read" i just can't get pass the initial "login"(im not pegging io nor cpu), think of something else to try for tomorrow. i need some sleep.. good night. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xoloki(a)gmail.com --- Comment #45 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-18 04:34:13 CST --- I also tried to run through strace, and failed to complete login while doing so. So I looked over WS2_recv_base, and noticed something. The function has standard exit point labels (exit and error), but those are NOT the only exit points; there are two places where naked return is called, one each for success and error cases. So I added some extra TRACE logging; I'll attach the diff to the bug. I log the return value of WS2_recv, and all the exit points. I also encode the socket value to make sure I can correlate successive log lines properly. Here's the relavant bits: trace:winsock:WS_connect socket 0164, ptr 0xa1cdffc { family AF_INET, address 159.153.69.80, port 8995 }, length 16 trace:winsock:WS2_recv_base socket 0164, wsabuf 0xa1cdfcc, nbufs 1, flags 0, from (nil), fromlen -1, ovl 0x57122e70, func (nil) trace:winsock:WS2_recv_base fd=223, options=0 trace:winsock:WS2_recv_base socket 0164 -> WS2_recv returned -1 bytes, errno 11 trace:winsock:WS2_recv_base socket 0164 -> returning SOCKET_ERROR, wsaErrno 259 trace:winsock:WS_shutdown socket 0164, how 2 0 trace:winsock:WS2_register_async_shutdown s 356 type 1 trace:winsock:WS_closesocket socket 0164 So when we try to connect to the server, we call WS2_recv which returns EAGAIN. We then go into the if ((lpOverlapped || lpCompletionRoutine) && !(options & (FILE_SYNCHRONOUS_IO_ALERT | FILE_SYNCHRONOUS_IO_NONALERT))) branch, which always returns SOCKET_ERROR if WS2_recv returned -1. Is this correct behavior? I don't understand enough of the context to tell. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #46 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-18 04:37:57 CST --- Created attachment 38016 --> http://bugs.winehq.org/attachment.cgi?id=38016 additional trace lines -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #47 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-18 06:02:17 CST --- Great! If possible do further tracing in function WS2_async_recv because it's the target function for overlapped operations. It may be important to find out who is calling WS2_recv_base, possibly WSARecv or WSARecvFrom beacuse of the overlapped structure. We need to isolate the operation so we can build a simple example that demonstrates the problem, it will be easier if more people can test it =) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Tyler Nielsen <tyler.nielsen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tyler.nielsen(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #37997|0 |1 is obsolete| | Attachment #38016|0 |1 is obsolete| | --- Comment #48 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-18 19:16:12 CST --- Created attachment 38023 --> http://bugs.winehq.org/attachment.cgi?id=38023 WINEDEBUG=+winsock log with extra tracing on WS2_async_recv Here I added some tracing in the async recv function. It looks like we are getting the 22 byte packet, and returning that result properly asynchronously. But the next recv call also goes async, and the callback gets a result of 0. Next we close the socket. Next I'll trace the entry points to WS2_recv_base, and see from where we're coming. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #38023|0 |1 is obsolete| | --- Comment #49 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-18 19:34:50 CST --- Created attachment 38024 --> http://bugs.winehq.org/attachment.cgi?id=38024 WINEDEBUG=+winsock log with extra tracing Here we have the entry points mapped as well. So it appears what happens is: 1. the game calls WSARecv 2. WS2_recv_base goes async 3. WS2_async_recv is alerted, so it reads data 4. WS2_async_recv reads 22 bytes, returns them via completion function which is good. Then: 5. the game calls WSARecv 6. WS2_recv_base goes async 7. WS2_async_recv is called with a status of 0, so it doesn't read from the net 8. WS2_async_recv returns the default result of 0 via the completion function I'm not sure step #8 is correct. Usually returning 0 from an async read function means the socket has shut down, which would likely trigger the calling code to initiate a shutdown itself. What does it mean when WS2_async_recv is called with a status of 0? Should this propagate to the async caller as a 0 result? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 talchas(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |talchas(a)gmail.com --- Comment #50 from talchas(a)gmail.com 2011-12-19 21:55:25 CST --- (In reply to comment #49)
Created attachment 38024 [details]
I see the same thing, but theres (at least for me) a long delay between the second recv being posted and the async response, because the 0 response is the server timing out. I see the probably-error-indicating skynet01.aus.bwa lookup well before then (about immediately after the second Recv call) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #51 from talchas(a)gmail.com 2011-12-21 10:58:12 CST --- Created attachment 38061 --> http://bugs.winehq.org/attachment.cgi?id=38061 WINEDEBUG=+winsock,+tid,+timestamp,-d3d,-win Log with timestamps/tids added. Hmm, apparently the skynet lookup was a bit later than I thought, although still way before the server timeout. It's possible that they have a manual ~5s timeout due to receiving no new data, but I wouldn't bet on it (especially since the socket seems to be handled by a different thread, although that could just be offloading it). I'm going to do a run with +relay this evening and see if 003d was doing anything detectably interesting in those 5s. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #52 from talchas(a)gmail.com 2011-12-21 20:48:23 CST --- Well, I got 5GB of +relay log without ever hitting even the first winsock messages after d3d startup before my machine crashed, so yeah. I'll keep looking into this at times, although I should note that I'm not entirely convinced this is likely to be a winsock issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Morning Hangover <panickiss(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |panickiss(a)gmail.com --- Comment #53 from Morning Hangover <panickiss(a)gmail.com> 2011-12-22 02:35:43 CST --- I tried today to login when servers were offline for maintenance and I got to the server list. The issue imo it's when the game tries to open the specific server that you have your character on. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #54 from Ahmed W. <oneofone(a)gmail.com> 2011-12-22 05:17:29 CST --- Yes, it is a problem with connecting to the game server, the server list uses HTTP as far as I can tell. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 tonedef <wine(a)causal.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine(a)causal.ca -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #55 from talchas(a)gmail.com 2011-12-22 20:26:34 CST --- OK, I finally actually ran a wireshark session when connecting under windows. A few notes: the server should only send those 22 bytes before the client replies, and they look similar on windows - 0316000000151100000008000000xxxxxxxx. The client should then respond with what looks like a header followed by a whole bunch of upper case ascii hex digits and then a bunch of dunno-what binary data. the skynet lookup occurs _normally on windows_, again about 5-6s after connecting to the 8995 server, so it doesn't mean things have failed, although it occurs at least in my run after replies to the server. There is I suppose a remote possibility that wine is just too slow to reply, but despite the initial load time before seeing a window being ridiculously slower for me (it is reading the last meg or so of all of the .tor files 34 bytes at a time, and poorly at that), I doubt that is the case as I don't see the same disk traffic. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Mikaël Cluseau <nwrk-public(a)altern.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nwrk-public(a)altern.org -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #56 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-23 18:53:42 CST --- Created attachment 38095 --> http://bugs.winehq.org/attachment.cgi?id=38095 wireshark log of traffic on port 8995 when running under wine -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #57 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-23 18:54:20 CST --- Created attachment 38096 --> http://bugs.winehq.org/attachment.cgi?id=38096 wireshark log of traffic on port 8995 when running under windows -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #38024|0 |1 is obsolete| | --- Comment #58 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-23 19:00:04 CST --- Created attachment 38097 --> http://bugs.winehq.org/attachment.cgi?id=38097 WINEDEBUG=+winsock log with extra tracing on send and recv I've attached wireshark logs filtered for port 8995, both running under wine and windows. When running under wine, the 22 byte packet comes in, then we see two keep-alive TCP packets, then a disconnect. Under windows, though, the client responds to the 22 byte packet in 0.04 seconds with 2 data packets (1034 and 38 bytes). Since wine was not sending the response, I added tracing to the send functions in socket.c. However, *none* of the send functions were called. Does anyone know how I could trace the win32 calls under windows? I'm curious as to what should be called, so I can trace more. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #59 from Xolotl Loki <xoloki(a)gmail.com> 2011-12-23 20:40:45 CST --- Created attachment 38098 --> http://bugs.winehq.org/attachment.cgi?id=38098 patch with extra tracing on send and recv functions, with timestamps on the recv functions Here's my current tracing diff. Unfortunately, current master branch no longer brings up the UI, so I'm stuck for now. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Agifem <agifem(a)free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |agifem(a)free.fr -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #60 from Ahmed W. <oneofone(a)gmail.com> 2011-12-27 08:36:53 CST --- I just got an idea, what if this bug is caused somehow by fixme:win:GetWindowPlacement not supported on other process window? SWTOR uses 2 processes, what if wine returns the server data to the wrong process? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #61 from Ahmed W. <oneofone(a)gmail.com> 2011-12-27 08:49:05 CST --- @Xolotl can you try http://www.apimonitor.com/? It's too slow on vmware for me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Alan Luth <alanluth(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alanluth(a)gmail.com --- Comment #62 from Alan Luth <alanluth(a)gmail.com> 2011-12-27 10:02:18 CST --- Some possible interesting lines i get using the degub=all option: fixme:iphlpapi:NotifyAddrChange (Handle 0x33e5a4, overlapped 0xd49428): stub fixme:winsock:WSALookupServiceBeginW (0x33e5c8 0x00000ff0 0x33e5c4) Stub! [1227/165828:ERROR:network_change_notifier_win.cc(111)] WSALookupServiceBegin failed with: 8 fixme:advapi:RegisterTraceGuidsW (0x1047c680, 0x111ac364, {3dada31d-19ef-4dc1-b345-037927193422}, 1, 0x1117ca$ fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented Exception: resolve: Unknown error -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Jeremy White <jwhite(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwhite(a)codeweavers.com --- Comment #63 from Jeremy White <jwhite(a)codeweavers.com> 2011-12-27 16:09:36 CST --- One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death. One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently. If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Reece Dunn <msclrhd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msclrhd(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |spetreolle(a)yahoo.fr -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastiaan.blommers(a)gmail.c | |om -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Andrew Eikum <aeikum(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aeikum(a)codeweavers.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #64 from Dorek Biglari <dbiglari(a)gmail.com> 2011-12-30 18:18:23 CST --- Created attachment 38190 --> http://bugs.winehq.org/attachment.cgi?id=38190 a list of all the ws2_32 calls in the swtor.exe process This file was generated using a proxy ws2_32.dll that passes calls into ws2_32 on to the real ws2_32 in c:\windows\system32, and logs the calls and the returns and return types. I added *'s around the function name which can be ignored. Running this file through cat, and grepping out the unique function names, I generated a list of all the functions used in swtor.exe: cat ws2_32_pid_6024.calls | gawk ' { print $3 } ' | sort | uniq *__WSAFDIsSet* *accept* *bind* *closesocket* *connect* *freeaddrinfo* *getaddrinfo* *gethostbyname* *gethostname* *getpeername* *getsockname* *getsockopt* *htonl* *htons* *inet_addr* *ioctlsocket* *listen* *ntohl* *ntohs* *select* *setsockopt* *shutdown* *WSAAddressToStringA* *WSAGetLastError* *WSARecv* *WSASend* *WSASetLastError* *WSASocketA* *WSASocketW* *WSAStartup* -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Dorek Biglari <dbiglari(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dbiglari(a)gmail.com --- Comment #65 from Dorek Biglari <dbiglari(a)gmail.com> 2011-12-30 18:19:53 CST --- I noticed some people have mentioned a possible problem with multiple processes of swtor.exe. In the swtor/retailclient directory, ,f you rename swtor_dual.icb to swtor_dual.icb.bak and copy swtor.icb to swtor_dual.icb the game will run in a single process. I've tested this in Windows and it works fine. I've also tried this in wine and the same hanging occurs. I think we can eliminate multiple processes as the potential issue here. Also, I have a way to trace the winsock calls in Windows that should be fast enough to run even in a virtual machine environment, I wrote a dll proxy stub for ws2_32.dll. This method will work in Windows XP, I'll post a link to my code and the call traces that I generated. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #66 from Dorek Biglari <dbiglari(a)gmail.com> 2011-12-30 18:29:51 CST --- Created attachment 38191 --> http://bugs.winehq.org/attachment.cgi?id=38191 This is the source code for a ws2_32 proxy dll that I created to monitor application calls to ws2_32. This is the source code for a ws2_32 proxy dll that I created to monitor application calls to ws2_32. Build using cygwin: gcc -shared -enable-stdcall-fixup -o ws2_32.dll ws2_32.c ws2_32.def and place in the directory with launcher.exe and swtor.exe. Output files will be written to c:\ws2_32_pid_xxxx.calls. This works in Windows XP, however it may not work in Windows 7. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #67 from Dorek Biglari <dbiglari(a)gmail.com> 2011-12-30 18:31:49 CST --- Created attachment 38192 --> http://bugs.winehq.org/attachment.cgi?id=38192 This is the compiled dll from the ws2_32.c above. Compiled using: gcc -shared -enable-stdcall-fixup -o ws2_32.dll ws2_32.c ws2_32.def Place in the directory with launcher.exe and swtor.exe (Or any other .exe you want to log ws2_32 calls in). Note: works in Windows XP, but may not work in Windows 7. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #68 from Dorek Biglari <dbiglari(a)gmail.com> 2011-12-30 18:36:25 CST --- (In reply to comment #63)
One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
I notice that GetThreadPreferredUILanguages is only on Vista platforms and above, since the game runs in Windows XP, this method shouldn't be required to run. It seems to me that setting wine to run as Windows XP would make the most sense to keep the API as minimal as possible, am I incorrect in thinking this? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Ian <ian(a)ianlevesque.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian(a)ianlevesque.org -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 mbisme(a)burke-works.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mbisme(a)burke-works.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 mbokman(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mbokman(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #69 from Austin English <austinenglish(a)gmail.com> 2012-01-02 12:17:35 CST --- (In reply to comment #68)
(In reply to comment #63)
One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
I notice that GetThreadPreferredUILanguages is only on Vista platforms and above, since the game runs in Windows XP, this method shouldn't be required to run. It seems to me that setting wine to run as Windows XP would make the most sense to keep the API as minimal as possible, am I incorrect in thinking this?
Wine supports more applications than just SWTOR. In particular, that stub was needed for bug 28648. Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Stephen Smith <stephenmsmith(a)blueyonder.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephenmsmith(a)blueyonder.co | |.uk --- Comment #70 from Stephen Smith <stephenmsmith(a)blueyonder.co.uk> 2012-01-02 20:44:11 CST --- (In reply to comment #69)
(In reply to comment #68)
(In reply to comment #63)
One note that may be of interest. If you add +seh to a trace, you'll see that you get a thread spinning down into death.
One of those threads will do so after invoking GetThreadPreferredUILanguages. That's interesting, because that stub was added fairly recently.
If you remove that stub (effectively revert commit e24438c1d1f68ae84f7570b53b8d5e7c24680fc6), that thread no longer spins down to death, but a different thread now does :-(.
I notice that GetThreadPreferredUILanguages is only on Vista platforms and above, since the game runs in Windows XP, this method shouldn't be required to run. It seems to me that setting wine to run as Windows XP would make the most sense to keep the API as minimal as possible, am I incorrect in thinking this?
Wine supports more applications than just SWTOR. In particular, that stub was needed for bug 28648.
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version). It was being disabled as a work around to try and get back the bug on connecting to the game server. Currently that bug appears to be blocked by stuck loader screen see comment 1 for issue and workaround, the issue you mention with GetThreadPreferredUILanguages and its mentioned even on thats funcs absence another thread fails. So for one or more reasons this bug seems currently blocked until the launcher can be loaded and people can test connecting again. Should the bugs be split or are there more logs you want?
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #71 from Dorek Biglari <dbiglari(a)gmail.com> 2012-01-02 21:21:32 CST ---
Wine supports more applications than just SWTOR. In particular, that stub was needed for bug 28648.
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version).
Yes that is what I meant, that the function is unlikely the root cause of the hanging since it isn't present in Windows XP. I agree it is likely dynamically loaded based on OS version. I have the OS set to Windows XP in winecfg, since it does run on XP. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #72 from Dorek Biglari <dbiglari(a)gmail.com> 2012-01-03 00:54:32 CST ---
Unless you mean the game shouldn't be using it since it's told it's on XP. The game may be dynamically loading it, seeing it as available and attempts to use it (rather than hardcoding based on Windows version).
I misread your comment previously, and I think you are correct, it does dynamically load it *not* based on the OS. Even though my wine is set to Windows XP, it does call GetThreadPreferredUILanguages: 003d:Call KERNEL32.GetProcAddress(7ed30000,189ed558 "GetThreadPreferredUILanguages") ret=188d50bb 003d:Call KERNEL32.GetThreadPreferredUILanguages(00000034,0a2bdff8,0a2be068,0a2be000) ret=188d510c 003d:fixme:thread:GetThreadPreferredUILanguages 52, 0xa2bdff8, 0xa2be068 0xa2be000 003d:Ret KERNEL32.GetThreadPreferredUILanguages() retval=00000001 ret=188d510c It calls it a second time further below as well. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #73 from Jeremy White <jwhite(a)codeweavers.com> 2012-01-03 09:10:49 CST --- Sorry to spur a red herring chase; while it is true that it calls this stub, an stubbing it does seem to change behavior, it does not seem to affect the fundamental behavior. I think it's just a red herring. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #74 from Agifem <agifem(a)free.fr> 2012-01-04 02:58:58 CST --- I've been looking at it more and more closely for the past few days, and I still think the problem is, like was observed earlier, in the socket. More precisely, in the WS2_async_recv function. In Xolotl's trace from 23rd december, we can see how Wine interprets differently two calls to WS2_async_recv : The first one, called with a status of 257, Wine reads 22 bytes of data, and returns. The second one, called with a status of 0, Wine doesn't seem to even try reading, and returns. Although both return with the same status, I can't help thinking the second case is doing something wrong, for example failing to initialize a data buffer, one that the game would be puzzled to find as a return value. Also, but it's probably my lack of knowledge of the inner workings of Wine, why is the WS2_async_recv called with a status as a parameter ? It doesn't make much sense to me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #75 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-04 05:32:42 CST --- Hi, I just looked at the code in latest git (socket.c). I don't know if it helps but the code is pretty clear about what it does with the status codes (found in ntstatus.h). The code switches on STATUS_ALERTED (0x00000101)) and STATUS_PENDING (0x00000103) else it would just return itself. My conclusion is that the first connection try is false. The socket just won't connect and pops up with wrong statusses (at least, cannot be processed by async logically).
From the log from Xolotl: trace:winsock:WS2_recv_base socket 03e8 -> WS2_recv returned -1 bytes, errno 11 trace:winsock:WS2_recv_base socket 03e8 -> returning SOCKET_ERROR, wsaErrno 259 trace:winsock:WS2_async_recv socket 03e8, status 257
SOCKET_ERROR pops status 257 which is: #define STATUS_PATH_NOT_COVERED ((NTSTATUS) 0xC0000257). Maybe a path/link/port or credential is missing/incomplete/incorrect? My question: is STATUS_PATH_NOT_COVERED == code 257 (because of 0xC0000257) Sebastiaan -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #76 from Agifem <agifem(a)free.fr> 2012-01-04 05:49:08 CST --- This is hexadecimal. 257 in decimal stands for STATUS_ALERTED (0x00000101). The calls to WS2_recv_base always fail/terminate/abort, because it's an asynchronous socket/connexion. After aborting, it calls WS2_async_recv, the real function that does the data reception. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #77 from talchas(a)gmail.com 2012-01-04 09:46:42 CST --- It is called with status 0 because the socket has closed and if you read the wineserver socket code, it calls with 0 in the case of POLLERR/POLLHUP. If you watch the log or turn on timestamps, (and particularly if you correlate them with a wireshark log running at the same time) you'll see that this happens a while after the 22 read, and at the same time as wireshark reports the socket being closed by the server. So for whatever reason it is not replying to the message sent by the server (_maybe_ just not fast enough) and/or not realizing the message was sent (although the behavior looks right). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #78 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-05 08:42:57 CST --- I found something in the wireshark logs that might be of help. If you take a look at the communication going on windows and wine you can see that the first 5 lines are exactly the same. Now comes the strange part. On windows line 6 0.078365 192.168.10.101 159.153.124.223 TCP 1100 39283 > 8995 [PSH, ACK] Seq=1 Ack=23 Win=5888 Len=1034 TSval=138362322 TSecr=1355350512 This line is missing in the wine log of wireshark, [PSH, ACK] is missing. Wine does not do the final acknowledgement of the connection and therefore times out after 30 seconds and sends a TCP keep alive ACK. 30.060985 159.153.124.223 192.168.10.101 TCP 66 [TCP Keep-Alive] 8995 > 51450 [ACK] Seq=22 Ack=1 Win=5888 Len=0 TSval=1353896825 TSecr=138213923 There must be something wrong in the winsock2 implementation on wine preventing sending the last data to the server. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #79 from Agifem <agifem(a)free.fr> 2012-01-05 08:52:23 CST --- It's not just an aknowledgment. It also sends a little over 1Kbyte of data. It's not the socket answering, it's the application talking back to the server. I didn't have the time on the winedebug trace, so I hadn't noticed the status 0 call was happening so late. Now that I think about it, there's nothing suggesting it's a socket anomaly. The WSARecv is called correctly, and responds correctly (it seems), then the game doesn't send more data. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #80 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-05 09:20:28 CST --- @Agifem: yes thank you for pointing that out. Maybe some sort of hook that's not being called? (Thinking of it after reading socket.c code: */ The actual definition of WSASendTo, wrapped in a different function name * so that internal calls from ws2_32 itself will not trigger programs like * Garena, which hooks WSASendTo/WSARecvFrom calls. */ static int WS2_sendto .............. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Jason <r6express(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |r6express(a)yahoo.com --- Comment #81 from Jason <r6express(a)yahoo.com> 2012-01-05 13:44:41 CST --- I don't see a valid completion function (arg is nil) or an event handler (arg is 0000) specified to the WSA recieve func, so I'm not sure how the caller is supposed to know that the async read has finished. Regardless, I forced a 10 second delay prior to the first read on the login port 8995 and this allowed it to read the first 22 bytes without going into the async operation. WS2_recv_base then correctly returns 0 and err is set to 0 as well. But the login data (1k chunk) still is not sent by the swtor process. It's possible that there is some subtle difference between the wine and windows WSA implementations, but it's still just as possible that the swtor process is getting the full 22 bytes back into it's hands correctly and a follow-up error (without log) is occuring, such as a routine to compress or encrypt the 1k block that it is supposed to send back over the socket. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #82 from Jeremy White <jwhite(a)codeweavers.com> 2012-01-05 14:56:28 CST --- (In reply to comment #81)
I don't see a valid completion function (arg is nil) or an event handler (arg is 0000) specified to the WSA recieve func, so I'm not sure how the caller is supposed to know that the async read has finished.
If you look a bit before the connect() call, you'll see a CreateIoCompletionPort call that associates the socket with an Io completion port. That is sufficient, on Windows, to provide a way to find those 22 bytes after they come in. I do see an indication that a GetQueuedCompletionStatus is called, and returns those 22 bytes, so we do seem to be correctly reporting that the 22 bytes arrive. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #83 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-09 15:36:53 CST --- (In reply to comment #82) Thanks for looking at this Jeremy; it's good to have skilled eyes in addition to the internet hordes. I sacrificed my swap partition to install windows a couple of weeks ago, and I've been playing in XP since. I noticed that I often see aborts when running under XP; windows pulls me back to the desktop, with an error dialog saying something like "ABORT: NULL pointer at socket.c/385". So it's entirely possible that TOR itself has bugs in its network code path, and it's subtle differences in error paths that's causing the troubles. I'm going to try testing with Jeremy's +seh debug flag. I suspect that the thread which is reading the socket on port 8995 dies after recving the 22 byte packet, before it can send the login data. Hopefully this death will be related to some wine function. Does anyone have any other suggestions? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #84 from Jason <r6express(a)yahoo.com> 2012-01-09 15:59:49 CST --- (In reply to comment #83) I have ran the swtor process with trace+winsock,trace+relay, along with my custom socket.c that forces a delay to make sure the 22 byte read occurs synchronously. I found that the same thread doing the read (and the long pause/sleep I coded in) continues on after the read and starts opening up the swtor .ini settings files located in c:\users\...\Local Settings\Application Data\SWTOR\swtor\settings. It also opens up the disk cache files also in that dir tree. Eventually the thread ceases to do anything interesting (based on relay output). The next test I planned to do is to block socket.c from responding back with those 22 bytes to determine if the behavior changed. If it did then that would tell me the swtor process is in fact getting the bytes. I haven't had a chance to run that test. I also wanted to force that socket read thread to crash/break during the read so I could see what else was happening up the stack. But I am new to Wine and haven't figured out how to make the debugger stop breaking every time it encounters a floating point exception (of which there a boatload when running with winedbg). All those apparently harmless (I say apparently since the program doesn't seem to complain when running with just wine) exceptions make it a hassle to use the debugger. FYI, the wine output/log file ends up around 5-6GB by the time it gets to messing around with the socket on port 8995. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #85 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-10 03:35:28 CST --- Ok, that's very informative! .. I noticed this difference between the client_settings.ini files. No idea of it brings us anything. Original on WinXP and Win7 [Renderer] D3DFullScreen = true Height = 900 NativeHeight = 1080 NativeWidth = 1920 TextureAnisotropy = 16 Width = 1600 WindowX = 0 WindowY = 0 MeshLODQuality = 1 SpeedTreeDistanceScale = 1. doShadows = false FullScreen = true FarClipScale = 25. VerticalSyncState = false EnableBloom = true TextureQuality = 0 UseMinSpecShaders = false PlantDensity = 100 doBlobShadows = true [Game] MoviesFolder = ..\..\Movies SwtorRegKey = SOFTWARE\BioWare\Star Wars - The Old Republic Now the one that is created using Wine (it's limited compared to): [Renderer] D3DFullScreen = true EnableBloom = false Height = 768 NativeHeight = 720 NativeWidth = 1280 RefreshRate = 120 TextureQuality = 1 UseMinSpecShaders = true VerticalSyncState = true Width = 1024 WindowX = 0 WindowY = 0 My tought: could it be that the swtor.exe process is trying to read the last known configuration (the character/account ini files are also there) but cannot complete the initial phase of the client_setting therefore canceling the other routines? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #86 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-10 05:07:49 CST --- I played around a bit with the settings ini files. No change. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #87 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-10 08:21:21 CST --- I installed the test version. The difference I have now with latest from git is that the normal version gives me a black screen (because I renamed the LoaderScreens to .old) but with the latest test version I go straight to the server selection screen. Also I see that the live version goes to 99% cpu and does not communicate at all with the server (no packets through wireshark) but the test version does (normal communication except ACK FIN at the end) and returns an empty list. Anyone else can confirm this? (maybe it's just my build). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #88 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-11 03:38:02 CST --- Ok I can confirm that the latest test version (1.1) works on latest git for me. I receive the server list on the first tab, after selecting it nothing happens but at least I get a server listing again. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #89 from Jeremy White <jwhite(a)codeweavers.com> 2012-01-11 09:18:28 CST --- (In reply to comment #88)
Ok I can confirm that the latest test version (1.1) works on latest git for me. I receive the server list on the first tab, after selecting it nothing happens but at least I get a server listing again.
That's very interesting; I'm having trouble getting the test version down to try that myself, but hope to do so shortly. Have you tried the test versions previously? If so, how did they behave? I'm wondering if there is something fundamentally different about all test versions such that they don't show the bug, or if we can hope that the swtor guys have fixed something on their end and as soon as 1.1 hits the streets we'll be past this issue. Cheers, Jeremy -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #90 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-01-11 09:26:18 CST --- As far as i can remember the older test versions didn't work but that was on another version of wine i tested on. Maybe authentication is different on live vs. test -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Michael Bond <mikejbond(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikejbond(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #91 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-12 16:56:10 CST ---
Ok I can confirm that the latest test version (1.1) works on latest git for me. I receive the server list on the first tab, after selecting it nothing happens but at least I get a server listing again.
How does this constitute "working"? We've been able to get to the server listing by move the loading screen files for pretty much the duration of this bug. Are you saying that you got to the server list without having to move the loading screen files? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #92 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-12 16:57:22 CST --- (In reply to comment #91)
Are you saying that you got to the server list without having to move the loading screen files?
Sorry, just read your earlier comment. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #93 from Jeremy White <jwhite(a)codeweavers.com> 2012-01-13 09:44:33 CST --- Yes, we have found that renaming the screens makes no difference. We also haven't gotten joy with the test server, although it's been hard to test. It seems to us that if the servers are down, then you get through to the blank server screen, otherwise you don't. I wonder if renaming the images just happened to coincide with some server down time for you, Xolotl Loki. This is proving to be a hard one; it's hard to figure out why an app *doesn't* do something; it's much easier when it does something and something bad happens. We just need that one glimmer of insight... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Marco D <moonbane(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |moonbane(a)gmx.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 orlando.cruz(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |orlando.cruz(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #94 from Alan Luth <alanluth(a)gmail.com> 2012-01-19 15:31:43 CST --- update 1.1 doesn't change the behavior, still looking at the eternal loading screen. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 fermadas(a)hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fermadas(a)hotmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 b <bdkelsey(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdkelsey(a)hotmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 hash <HASH.DuOrden(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #95 from Night and Day <nightrise22-daylight23(a)yahoo.com> 2012-01-25 02:20:24 CST --- Created attachment 38543 --> http://bugs.winehq.org/attachment.cgi?id=38543 New console output after 1/24/2012 patch -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #96 from Night and Day <nightrise22-daylight23(a)yahoo.com> 2012-01-25 02:21:58 CST --- Comment on attachment 38543 --> http://bugs.winehq.org/attachment.cgi?id=38543 New console output after 1/24/2012 patch New behavior with today's patch, instead of hanging on the loading screen it seems to start to connect and then the game crashes completely. It appears to be related to the "RemoteRendererServer.icb" component. I've attached the console output, is anyone else seeing anything like this? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #97 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-25 16:44:18 CST --- No change for me with the 1/24 patch. wine-1.3.37 gets stuck on the loading screen if the files are present, and a black screen if they are not. wine git master freezes when I click Play on the launcher login screen. With WINEDEBUG='+seh' on wine-1.3.37, I see the following repeating endlessly on the console while the loading screen spins: trace:seh:raise_exception code=80000003 flags=0 addr=0x6fc310 ip=006fc311 tid=000b trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000035 edx=00000001 esi=ffffffff edi=02530910 trace:seh:raise_exception ebp=0a19e888 esp=0a19e864 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00000286 trace:seh:call_stack_handlers calling handler at 0xe363cc code=80000003 flags=0 trace:seh:__regs_RtlUnwind code=c0000027 flags=2 trace:seh:__regs_RtlUnwind calling handler at 0x7bc71fe0 code=c0000027 flags=2 trace:seh:__regs_RtlUnwind handler at 0x7bc71fe0 returned 1 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Michael Flowers <mikesflowers(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikesflowers(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Johan Gill <johan.gill(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gill(a)gmail.com --- Comment #98 from Johan Gill <johan.gill(a)gmail.com> 2012-01-26 07:47:21 CST --- Trying to grasp the variety of behaviours: I see the image in the right corner, but it's not spinning. Is it spinning for someone else? My only dll overrides are for the d3dx9 dlls, what are yours? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #99 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-26 20:21:06 CST --- The lower right hand image is spinning for me, and always has (when the loading screen files are present). I'm not currently using any DLL overrides. At this point, I'm really at an impasse. I'm happy to spend gobs of time working on this, but I'm not overly familiar with wine source or runtime. For example, when I run under winedbg, I see various threads being created and renamed: Thread ID=0027 renamed using MS VC6 extension (name=="BrowserDB") Thread ID=002a renamed using MS VC6 extension (name=="Cef_FileT") Thread ID=002b renamed using MS VC6 extension (name=="Cef_IOThr") Thread ID=002c renamed using MS VC6 extension (name=="AppCacheD") Thread ID=0037 renamed using MS VC6 extension (name=="PipelineT") Thread ID=0038 renamed using MS VC6 extension (name=="AudioDeco") Thread ID=0039 renamed using MS VC6 extension (name=="VideoDeco") Thread ID=003b renamed using MS VC6 extension (name=="AudioThre") However, I can't see any way to associate them with the thread that's constantly crashing: Unhandled exception: page fault on read access to 0x064f742c in 32-bit code (0x064f742c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:064f742c ESP:04d1ea3c EBP:04d1ea48 EFLAGS:00010216( R- -- I -A-P- ) EAX:00000000 EBX:7bca5ff4 ECX:00000000 EDX:00000000 ESI:7ff6cf10 EDI:064f7410 Stack dump: 0x04d1ea3c: 00000000 00002710 00000000 04d1ea58 0x04d1ea4c: 7bc71f60 05477b88 7ff6cf10 04d1eb28 0x04d1ea5c: 7bc7219d 064f7410 05477b88 00000000 0x04d1ea6c: 00000000 ffffffff 7bc88f40 7b83ab40 0x04d1ea7c: 7bca5ff4 7ff6cf10 064f7410 04d1eb28 0x04d1ea8c: db6edaa8 f6f8fe56 00000000 00000000 Backtrace: =>0 0x064f742c (0x04d1ea48) 1 0x7bc71f60 call_thread_func_wrapper+0xb() in ntdll (0x04d1ea58) 2 0x7bc7219d call_thread_func+0x7c(entry=0x64f7410, arg=0x5477b88, frame=0x4d1eb48) [/build/buildd/wine1.3-1.3.37/dlls/ntdll/signal_i386.c:2532] in ntdll (0x04d1eb28) 3 0x7bc71f3e RtlRaiseException+0x21() in ntdll (0x04d1eb48) 4 0x7bc7bf45 start_thread+0xf4(info=0x7ff6cfb8) [/build/buildd/wine1.3-1.3.37/dlls/ntdll/thread.c:405] in ntdll (0x04d1f398) 5 0xf757e96e start_thread+0xbd(arg=0x4d1fb70) [/build/buildd/eglibc-2.11.1/nptl/pthread_create.c:300] in libpthread.so.0 (0x04d1f498) 0x064f742c: addb %al,0x0(%eax) Do the SS/DS/ES registers hold the thread ID? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #100 from Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> 2012-01-26 21:41:56 CST --- Use WINEDEBUG=+tid to tell where messages are coming from. Segment registers point to a segment descriptors and have nothing to do with thread IDs. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #101 from Johan Gill <johan.gill(a)gmail.com> 2012-01-27 00:37:43 CST --- (In reply to comment #99)
The lower right hand image is spinning for me, and always has (when the loading screen files are present).
I'm not currently using any DLL overrides.
Are you really sure about this? It looks like D3DX is reading the animation from a DDS format, and the builtin D3DX can't handle that. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #102 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-27 19:52:19 CST ---
I'm not currently using any DLL overrides.
Are you really sure about this? It looks like D3DX is reading the animation from a DDS format, and the builtin D3DX can't handle that.
I'm looking at the 'Libraries' tab of winecfg, there is nothing in the 'Existing overrides:' box. Should I look in a config file somewhere to be sure? This is with wine-1.3.37, but I've used everything from 1.3.33 on, including many random git builds. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #103 from Xolotl Loki <xoloki(a)gmail.com> 2012-01-27 19:52:49 CST --- (In reply to comment #100)
Use WINEDEBUG=+tid to tell where messages are coming from.
Thanks, that should help immensely correlating messages to threads. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 webgeek1234(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |webgeek1234(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 sporth(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sporth(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Jason J <jason.james(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason.james(a)gmail.com --- Comment #104 from Jason J <jason.james(a)gmail.com> 2012-02-01 22:16:54 CST --- Any progress being made on this? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Scott <scott(a)chaos-dragon.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scott(a)chaos-dragon.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 h.v.bruinehsen(a)fu-berlin.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |h.v.bruinehsen(a)fu-berlin.de -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Marco Di Fresco <marco.difresco(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marco.difresco(a)gmail.com --- Comment #105 from Marco Di Fresco <marco.difresco(a)gmail.com> 2012-02-20 12:31:04 CST --- Any news? :-/ I am not an expert in debugging, but if you want just tell me what do you need I and I will do any test necessary. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #106 from Xolotl Loki <xoloki(a)gmail.com> 2012-02-20 23:47:06 CST --- I keep looking at this from time to time, but still no real progress. I'm still focusing on the server handshake on port 8995. I had previously determined that TOR calls WSARecv, and is returned the 22 byte server header asynchronously. TOR immediately calls WSARecv again, and after a minute the connection times out, and is closed. Debugging with +tid, I discovered something new today: the thread that does the second WSARecv call on the 8995 socket is *not* the same as the thread which is delivered the 22 byte header. I then added +seh, and discovered: 0045:trace:winsock:WS2_async_recv socket 0178 not PENDING so return ws2_async_apc as *apc and pass status 0 and result 22 through iosb 0045:trace:winsock:WS2_async_recv socket 0178 returning status 0 000d:trace:winsock:WSARecv socket 0178, calling WS2_recv_base 000d:trace:winsock:WS2_recv_base socket 0178, wsabuf 0xa4ce630, nbufs 1, flags 0, from (nil), fromlen -1, ovl 0x526a0f50, func (nil) [2012-02-20 18:54:57] 0045:trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000000 edx=01784065 esi=00000400 edi=7b8351f0 0045:trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000000 edx=01789457 esi=00000400 edi=7b8351f0 0045:trace:seh:raise_exception eax=000000ff ebx=00000000 ecx=00000000 edx=0178d980 esi=00000400 edi=7b8351f0 Basically, the thread that receives the data crashes, and another thread tries to read again. However, the data is already gone, so the new IO thread gets nothing, and we never progress. I was lucky to see this, because it was only the value of edx happening to match the socket handle I was grepping. So I ran again with +relay, and after sifting through 11GB of data, I found nothing particularly useful: 000d:Ret KERNEL32.GetCurrentThreadId() retval=0000000d ret=10004837 000d:Call KERNEL32.GetCurrentThreadId() ret=1000033:Ret KERNEL32.GetLastError() retval=00000000 ret=78543849 000d:Call KERNEL32.SetEvent(00000328) ret=00365655 000d:Ret KERNEL32.SetEvent() retval=00000001 ret=00365655 000d:Call user32.GetClientRect(000a0052,0a2ce950) ret=006fa5f6 000d:Ret user32.GetClientRect() retval=00000001 ret=006fa5f6 000d:Call KERNEL32.QueryPerformanceCounter(0a2ce8f8) ret=006f9a14 000d:Ret KERNEL32.QueryPerformanceCounter() retval=00000001 ret=006f9a14 000d:trace:seh:raise_exception code=80000004 flags=0 addr=0x70a9c1 ip=0070a9c1 tid=000d So I'm at an impasse again. I think I know what's going on; the IO thread crashes after getting the server header, never sending the reply, and another thread times out waiting for more data. But I don't see anything suspicious going on right before the crash, which means the trail is cold again. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #107 from Xolotl Loki <xoloki(a)gmail.com> 2012-02-20 23:52:30 CST --- I also tried something completely different; I tried using winecfg to do DLL overrides of various combinations of the networking DLLs. Often overriding one DLL would require additional overrides. But after many hours of trying ws2_32 and others, I was never able to get past the auth windows, much less server login. So this seems like anothe3r dead end. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #108 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2012-02-21 01:26:39 CST --- (In reply to comment #106)
000d:trace:seh:raise_exception code=80000004 flags=0 addr=0x70a9c1 ip=0070a9c1 tid=000d
So I'm at an impasse again. I think I know what's going on; the IO thread crashes after getting the server header, never sending the reply, and another thread times out waiting for more data. But I don't see anything suspicious going on right before the crash, which means the trail is cold again.
This is not a crash, 80000004 is EXCEPTION_SINGLE_STEP, somebody is playing with CPU context flags? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral(a)gmail.com --- Comment #109 from Matteo Bruni <matteo.mystral(a)gmail.com> 2012-02-21 07:30:33 CST --- (In reply to comment #108)
(In reply to comment #106)
000d:trace:seh:raise_exception code=80000004 flags=0 addr=0x70a9c1 ip=0070a9c1 tid=000d
So I'm at an impasse again. I think I know what's going on; the IO thread crashes after getting the server header, never sending the reply, and another thread times out waiting for more data. But I don't see anything suspicious going on right before the crash, which means the trail is cold again.
This is not a crash, 80000004 is EXCEPTION_SINGLE_STEP, somebody is playing with CPU context flags?
Yeah, the thread initially doing the WSArecv actually generates those single step exceptions. Those happen on Windows too, AFAICT, and they don't seem to be a problem anyway (except making debugging more annoying, of course...) Xolotl, you're right that the thread which calls WSArecv is not the same as the thread receiving the completion notification. But then this second thread posts an application-generated completion message to the first thread, which gets it. But nothing happens. The first thread also waits (non blocking) on a mutex which is never waited/signaled by other threads. That may play a role here, but it could also be completely unrelated. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Carsten Juttner <carjay(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carjay(a)gmx.net --- Comment #110 from Carsten Juttner <carjay(a)gmx.net> 2012-03-05 15:42:42 CST --- Hi, I've been looking for the cause for some weeks now, too, and found the answer. SWTOR seemingly reads part of its timing information directly from the KUSER_SHARED_DATA mapping. This is a special virtual address mapping which is present in all processes and used internally by Windows user space libraries. Basically a system stat page exported by the NT kernel to user space. It can be found at virtual address 0x7ffe0000. In Wine this page is initialized once (it holds a lot more information than just timing) but after that there do not seem to be any more updates. Also the InterruptTime field (time since boot) is never set up at all. SWTOR seems to base its send timers on exactly this source. Now, obviously a timing source that never progresses leads to timers never elapsing which is a good explanation why things do not work properly. For demonstration purposes I've attached a small proof of concept which makes things work by simply updating the fields whenever the process enters an "EnterCriticalSection"-API call. Before you get all excited, this is of course not a proper way to do things. On Windows this information is set from within the kernel which cannot be done for wine in a similar way. Hopefully someone more familiar with Wine internals has an idea where and how to set this up properly. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #111 from Carsten Juttner <carjay(a)gmx.net> 2012-03-05 15:46:19 CST --- Created attachment 39208 --> http://bugs.winehq.org/attachment.cgi?id=39208 Proof of concept for KUSER_SHARED_DATA updates simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #112 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-05 16:43:41 CST --- Thanks Carsten, I'm patching and rebuilding wine as we speak, and I'll let you know if it works for me. I'm trying 1.4-rc4; is that the branch you were working on? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #113 from Carsten Juttner <carjay(a)gmx.net> 2012-03-05 17:33:13 CST --- (In reply to comment #112)
Thanks Carsten, I'm patching and rebuilding wine as we speak, and I'll let you know if it works for me.
I'm trying 1.4-rc4; is that the branch you were working on?
I usually work directly on the git repository and was testing against the current master at c991d115b but before that I had a version from a month ago. It should not make much of a difference. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #114 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-05 17:42:49 CST --- I made it past server selection, was able to choose a character, and now I have successfully logged in. Thanks Carsten! If you would like, I'll happily PayPal you $100 for figuring this out. Wine devs: any chance of fixing this for 1.4, or Crossover XI? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #115 from Jeremy White <jwhite(a)codeweavers.com> 2012-03-05 17:51:37 CST --- Well done indeed, Carsten! This doesn't look surgical enough to make it into either of those releases, although I think only Alexandre can answer that for certain. We may try to provide a hack for customers to experiment with CrossOver XI. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #116 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2012-03-05 21:08:05 CST --- (In reply to comment #111)
Created attachment 39208 [details] Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
May be adding the updating timers functionality to server.c,wine_server_call() would be more correct. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #117 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-05 21:47:04 CST --- Does wine implement KUSER_SHARED_DATA as shared memory? If so, then it should be updated by wineserver, not client wine threads. The memory is allocated by the following call in thread.c: addr = (void *)0x7ffe0000; size = 0x10000; NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE ); I see no mention of shared memory in NtAllocateVirtualMemory, so I'm guessing no. Accoding to the docs I found, these fields are supposed to be updated every *100ns*. If we try to do that in every thread, it's just not going to work. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #118 from hash <HASH.DuOrden(a)gmail.com> 2012-03-06 10:37:42 CST --- Well, I also tested this "Proof of concept for KUSER_SHARED_DATA updates" patch and I wasn't able to get any further than before. So it do not work for me, sadly. If there is something wrong with the way I compile Wine just tell me. I'll gladly apologize and be actually happy been mistaken. git clean -fd git checkout -f && git fetch && git rebase origin git reset --hard origin/master git apply ../KUSER_SHARED_DATA.patch export CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" ./configure --prefix=/opt/wine --with-xinput2 --without-openal --with-opengl --with-oss --with-mpg123 && make depend && make && make install I also tried to issue ./tools/make_requests after git apply, it didn't changed anything. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #119 from Morning Hangover <panickiss(a)gmail.com> 2012-03-06 11:33:02 CST --- (In reply to comment #111)
Created attachment 39208 [details] Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
Patched latest wine git, working as intended. Played around 1h framerate is not much worse than the windows version. Thanks Carsten. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #120 from Carsten Juttner <carjay(a)gmx.net> 2012-03-06 12:08:40 CST --- (In reply to comment #114)
I made it past server selection, was able to choose a character, and now I have successfully logged in.
Thanks Carsten! If you would like, I'll happily PayPal you $100 for figuring this out.
Thanks for the offer but please rather donate it to a charity of your own choosing. My day job pays well so I don't have a need. Besides it was a great learning experience. :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #121 from Carsten Juttner <carjay(a)gmx.net> 2012-03-06 12:58:23 CST --- (In reply to comment #118)
Well, I also tested this "Proof of concept for KUSER_SHARED_DATA updates" patch and I wasn't able to get any further than before. So it do not work for me, sadly.
If there is something wrong with the way I compile Wine just tell me. I'll gladly apologize and be actually happy been mistaken.
git clean -fd git checkout -f && git fetch && git rebase origin git reset --hard origin/master git apply ../KUSER_SHARED_DATA.patch export CFLAGS="-march=native -O2 -pipe -fomit-frame-pointer" ./configure --prefix=/opt/wine --with-xinput2 --without-openal --with-opengl --with-oss --with-mpg123 && make depend && make && make install
I also tried to issue ./tools/make_requests after git apply, it didn't changed anything.
For a release build I don't set any CFLAGS, I just run the ./configure-script (I have a 64 bit Linux box but it seems to detect things just fine). I also used winetricks to install all kinds of DirectX and Microsoft runtime related libs. Maybe something shows up in your wine log that may give a clue what is happening? Note that the window placement and directx query warnings are ok. One thought, since I already have a character on a server I didn't test if the original server selection (when you do not have a character) is visible (which was an issue before, I had to rename the jpg to get to the selection screen). Using the proof of concept patch at least once having a character on a server I do not require this trick anymore though. Also logging out and going back to the server selection works ok. I didn't do anything special to make it run apart from what was already suggested (e.g. running the launcher in a desktop). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #122 from Carsten Juttner <carjay(a)gmx.net> 2012-03-06 13:44:26 CST --- (In reply to comment #116)
(In reply to comment #111)
Created attachment 39208 [details] Proof of concept for KUSER_SHARED_DATA updates
simple proof of concept showing that the initial server connect is working successful once the timer fields in KUSER_SHARED_DATA are updated properly.
May be adding the updating timers functionality to server.c,wine_server_call() would be more correct.
I had a similar idea but I'm still trying to get a better understanding of how the wine server works. For now I'd just want to share the results of my research. So just to state the obvious before Alexandre hits me with a haversack :) the patch cannot be merged like that, using EnterCriticalSection this way is completely wrong. Further notes: Windows of course does not update the times at 10 MHz granularity. I wrote a little test application that confirms (on Vista) what http://www.dcl.hpi.uni-potsdam.de/research/WRK/2007/08/getting-os-informatio... says: the values are updated at a 15.625ms interval which is 64 Hz. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 dan <toreador(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |toreador(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #123 from hash <HASH.DuOrden(a)gmail.com> 2012-03-07 07:59:41 CST --- (In reply to comment #121)
(In reply to comment #118)
Well, I also tested this "Proof of concept for KUSER_SHARED_DATA updates" patch..... For a release build I don't set any CFLAGS, I just run the ./configure-script (I have a 64 bit Linux box but it seems to detect things just fine).
I also used winetricks to install all kinds of DirectX and Microsoft runtime related libs.
Maybe something shows up in your wine log that may give a clue what is happening? Note that the window placement and directx query warnings are ok.
One thought, since I already have a character on a server I didn't test if the original server selection (when you do not have a character) is visible (which was an issue before, I had to rename the jpg to get to the selection screen).
Using the proof of concept patch at least once having a character on a server I do not require this trick anymore though. Also logging out and going back to the server selection works ok.
I didn't do anything special to make it run apart from what was already suggested (e.g. running the launcher in a desktop).
I have 32 bit Gentoo install and I use OSS4, I've removed CFLAGS declaration, this haven't changed anything. Could you please specify what you installed aside from SWTOR? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #124 from hash <HASH.DuOrden(a)gmail.com> 2012-03-07 08:22:38 CST --- Created attachment 39227 --> http://bugs.winehq.org/attachment.cgi?id=39227 A log starting SWTOR and not connecting to server with wine compiled with "Proof of concept for KUSER_SHARED_DATA updates" patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #125 from Carsten Juttner <carjay(a)gmx.net> 2012-03-07 13:21:11 CST --- Just rebuilt against the 1.4 release tag and used a fresh winedir. I then used winetricks to add the Microsoft runtimes "vcrun2008" and "d3dx9". That's it. Your log looks like the expected output but seems to only contain the STDOUT parts but not what goes to STDERR. To get the full output you can redirect it to log.txt similar to this: wine explorer /desktop=launcher.exe,1280x1024 launcher.exe >log.txt 2>&1 BTW: if that's your real username in the log you should remove both username and password entries. That's debug output from swtor, not wine and may identify you! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #126 from hash <HASH.DuOrden(a)gmail.com> 2012-03-07 15:35:49 CST --- Comment on attachment 39227 --> http://bugs.winehq.org/attachment.cgi?id=39227 A log starting SWTOR and not connecting to server with wine compiled with "Proof of concept for KUSER_SHARED_DATA updates" patch.
wine: cannot find L"C:\\windows\\system32\\winemenubuilder.exe" err:wineboot:ProcessRunKeys Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (2) [0307/141243:ERROR:network_change_notifier_win.cc(111)] WSALookupServiceBegin failed with: 8 err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded Exception: resolve: Unknown error Exception: resolve: Unknown error | Variable USERNAME set to '****' | Variable PASSWORD set to '****' | Variable PLATFORM set to 'gamepad.swtor.com:443' | Variable ENVIRONMENT set to 'swtor' | Variable LANG set to 'en-us' | Variable TORSETS set to 'main,en-us' | Executing batch file 'swtor_dual.icb':
|> set shardaddress @${server}:${port}:${instance} | Variable SHARDADDRESS set to '@::' |> server install HeroEngine | Successfully installed server application: HeroEngine
|> server start HeroEngine://test1(a)null::IpcConsole:1 dual=true username=${username} password=${password} shardaddress=${shardaddress} environment=${environment} platform=${platform} lang=${lang} torsets=${torsets} | Successfully started server: HeroEngine://test1(a)null::IpcConsole:1
|> autotick | Beginning auto-tick. Use <Ctrl-shift-x> to break. | Executing batch file 'RemoteRendererServer.icb':
|> server install RemoteRenderer | Successfully installed server application: RemoteRenderer
|> server start RemoteRenderer://test1(a)shared::IpcConsole:1 | Successfully started server: RemoteRenderer://test1(a)shared::IpcConsole:1
|> autotick | Beginning auto-tick. Use <Ctrl-shift-x> to break. Connection 0 to RemoteRenderer accepted! Connecting process name is: swtor.exe Creating interfaces... bwa::RemoteMetricsCallbacksHandler::IID bwa::RemoteRendererInterface::IID err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #127 from hash <HASH.DuOrden(a)gmail.com> 2012-03-07 15:40:28 CST --- Idiotic bugzilla mechanic, nothing can't be deleted... No that out put is made this way: &>./SWTOR.log it's shorter version of:
log.txt 2>&1
But thanks for info about runtimes, will try to do that with clean prefix. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #128 from Dorek Biglari <dbiglari(a)gmail.com> 2012-03-08 00:11:16 CST --- I can also confirm latest working wine with Carsten's patch works great. For me the game framerate is more than acceptable. The only changes made to get the game to run after patching were creating a Virtual Desktop the same size as my screen size and adding d3dx9_38.dll as a native dll. Thanks Carsten! I hope Bioware doesn't break it again with a future patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #129 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-08 09:38:21 CST --- It is working for me also. FPS is reasonable, might be 90% of what i'm getting on Windows 7. I use Ironhide to optirun start wine. After touching Antialiasing the graphics went a bit crazy with artifacts but other then that it is running pretty smooth. Starting up the game takes a while but after hitting the character screen everything seems ok. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 hash <HASH.DuOrden(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39227|0 |1 is obsolete| | --- Comment #130 from hash <HASH.DuOrden(a)gmail.com> 2012-03-08 11:19:34 CST --- Created attachment 39245 --> http://bugs.winehq.org/attachment.cgi?id=39245 Another log starting SWTOR with wine compiled with "Proof of concept for KUSER_SHARED_DATA updates" patch. This log is produced without WINEDEBUG set. By the way, is every one of you for who this works happen to run 64 bit linux? I'm actually don't know what to think and how to diagnose why this doesn't work for me. :( -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #131 from Johan Gill <johan.gill(a)gmail.com> 2012-03-08 11:33:36 CST --- (In reply to comment #130)
By the way, is every one of you for who this works happen to run 64 bit linux? I'm actually don't know what to think and how to diagnose why this doesn't work for me. :(
Are you running in a virtual desktop? That seems to work best. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #132 from hash <HASH.DuOrden(a)gmail.com> 2012-03-08 11:54:57 CST --- yes -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Jonathan Marchand <jonathlela(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathlela(a)gmail.com --- Comment #133 from Jonathan Marchand <jonathlela(a)gmail.com> 2012-03-08 12:23:58 CST --- It works fine with me with this patch in debian amd64. I have a recent git wine compiled with some ia32 libs, I have installed dxd9 with winetricks. I don't use a virtual desktop. I launch the game with : wine ~/.wine/Program\ Files/Electronic\ Arts/BioWare/Star\ Wars\ - \The\ Old\ Republic/launcher.exe It runs without any glitches and about as the same speed as in windows (slightly slower). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #134 from Erik Weatherwax <erik.weatherwax(a)gmail.com> 2012-03-08 12:43:44 CST --- Add me to the list of people for whom Carsten's proof of concept patch has the game working successfully. Steps I followed: (1) Remove old SWTOR wineprefix with pathetic attempts at DLL overrides to get game to work. (2) Create and configure clean wineprefix: turning on virtual desktop is the only config change I made here. (3) Override d3dx9_36 via winetricks -- this is the only DLL override I needed. (4) Run SWTOR_setup.exe available on SWTOR website in the new prefix. (5) Copy Program Files/Electronic Arts/BioWare/ folder from Win7 partition I was (regrettably) forced to use to Program Files/Electronic Arts/BioWare/ folder in new wineprefix, because I'm too impatient to download the game assets again or patch from initial retail. (6) Apply Carsten's patch against a copy of wine 1.4 source and perform straight ./configure && make, no special CFLAGS or installation, because I'm told by far more knowledgeable people that the patch isn't suitable for mainline Wine. (7) cd to the SWTOR install directory, run: $PATCHED_WINE_PATH/wine launcher.exe (8) Hit "play" very quickly to avoid bug 29169 (reported fixed but I'm still running into it, need to open another bug report). (9) Enjoy. For the record, this is a Gentoo x86_64 system. I did notice the same graphical artifacts Sebastiaan mentioned on first launching the game with AA at high: turning off AA corrected it, and I was later able to set AA to low without the artifacting resuming. This is on an nVidia GT240 with the 295.20 proprietary driver. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #135 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-08 12:50:50 CST --- Running on 64 bit Ubuntu yes. Maybe start over with clean git Steps: 1) git clone 2) git apply KUSERPATCH 3) ./configure 4) sudo make install 5) wget http://winetricks.org/winetricks 6) chmod +x winetricks 7) start winetricks and remove all application stuff -> cleans up .wine or just delete the .wine folder. 7) winetricks vcrun2008 d3dx9 8) winetricks -> config set virtual desktop and set to xp That's all i did. *Ironhide/Bumblebee users: I run using optirun32 so I installed virtualgl-libs:i386 because optirun64 didn't work for me. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #136 from Mikaël Cluseau <nwrk-public(a)altern.org> 2012-03-08 13:21:48 CST --- This patch works for me too under gentoo gnu/linux 64 bits. Applied on git commit ecc2fae44bc337bf4f07e24572dc4b4776fe269a. Login, character selection, playing (well, at least 10 minutes, I had to go after ;)). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #137 from hash <HASH.DuOrden(a)gmail.com> 2012-03-08 14:15:08 CST --- Only difference with me is I am using 32 bit Gentoo, beyond that I'm lost. :( -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #138 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-08 22:27:10 CST --- I've been playing with Carsten's patch all week, but I keep seeing a random UI freeze that lasts anywhere from 1 to 60 seconds. The game plays normally for a while (sometimes hours), but once it starts freezing it does so too often to continue playing. Has anyone else seen, and/or worked around this issue? I thought it might be because Carsten's patch doesn't appear to set the time fields in the proper order; from what I read, it should be done like user_shared_data->SystemTime.High2Time = now.HighPart; user_shared_data->SystemTime.LowPart = now.LowPart; user_shared_data->SystemTime.High1Time = now.HighPart; rather than user_shared_data->SystemTime.LowPart = now.LowPart; user_shared_data->SystemTime.High1Time = user_shared_data->SystemTime.High2Time = now.HighPart; But that didn't solve the freezing. So I've been working on an alternate patch using NtSetTimer to set the times at a regular interval. However, I can't get past the 8995 server handshake. I'll post the patch if I get it working. In the meantime, a question: does anyone know what the scope is of the user_shared_data memory area? Is it local to the thread/process, or is it shared? Every thread reserves it then writes to it in thread_init. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 talchas(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|talchas(a)gmail.com | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #139 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-09 02:25:37 CST --- (In reply to comment #138)
Every thread reserves it then writes to it in thread_init.
Just realized that only the initial thread reserves and writes the virtual memory address. I also realized what's different between my NtSetTimer and Carsten's patch: Carsten's ends up calling update_shared_data_time every couple of microsecs: 0045:fixme:ntdll:update_shared_data_time 129757528561624540 0045:fixme:ntdll:update_shared_data_time 129757528561624570 0045:fixme:ntdll:update_shared_data_time 129757528561624640 0045:fixme:ntdll:update_shared_data_time 129757528561624670 My NtTimer code, when set to fire every 100 nanosecs: NtQuerySystemTime( &when ); when.QuadPart += 1; status = NtSetTimer(handle, &when, (PTIMER_APC_ROUTINE)shared_data_timer_apc, handle, 0, 0, NULL); only fires every 150 microsecs: 000f:fixme:ntdll:update_shared_data_time 129757541427830810 000f:fixme:ntdll:update_shared_data_time 129757541427832270 000f:fixme:ntdll:update_shared_data_time 129757541427833710 000f:fixme:ntdll:update_shared_data_time 129757541427835170 If I set it to fire every 10 microsecs it actually does better: 000f:fixme:ntdll:update_shared_data_time 129757548414991300 000f:fixme:ntdll:update_shared_data_time 129757548414992020 000f:fixme:ntdll:update_shared_data_time 129757548414992820 000f:fixme:ntdll:update_shared_data_time 129757548414993800 Next I'll try a dedicated thread which just sets the times and does a nanosleep... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #140 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-09 04:16:28 CST --- Very good idea, that might fix the delay and the issues it introduces. Thank you for keeping us posted about the progress. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Skuzzie <skuzzie(a)internode.on.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |skuzzie(a)internode.on.net --- Comment #141 from Skuzzie <skuzzie(a)internode.on.net> 2012-03-09 04:21:51 CST --- (In reply to comment #138)
I've been playing with Carsten's patch all week, but I keep seeing a random UI freeze that lasts anywhere from 1 to 60 seconds. The game plays normally for a while (sometimes hours), but once it starts freezing it does so too often to continue playing.
Yeah, been playing a few hours now...I have noticed it runs fine until I get into a fight, then it starts freezing up, the longer the fight goes the more it freezes up, seems to increase in occurrance and duration very quickly. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 xoffox(a)softhome.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xoffox(a)softhome.net --- Comment #142 from xoffox(a)softhome.net 2012-03-09 10:51:26 CST --- (In reply to comment #141)
(In reply to comment #138)
I've been playing with Carsten's patch all week, but I keep seeing a random UI freeze that lasts anywhere from 1 to 60 seconds. The game plays normally for a while (sometimes hours), but once it starts freezing it does so too often to continue playing.
Yeah, been playing a few hours now...I have noticed it runs fine until I get into a fight, then it starts freezing up, the longer the fight goes the more it freezes up, seems to increase in occurrance and duration very quickly.
The patch works well with stock wine 1.4 on my Debian-amd64 testing system. I was playing for hours, I did not notice more freeze than when I play under Windows 7. The freeze are probably related to the game, not to the patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #143 from tonedef <wine(a)causal.ca> 2012-03-09 11:35:27 CST --- I'm in the same boat as hash. I can login fine but, I get a plain desktop and a cursor after logging in. After waiting ~10mins the screen goes black and nothing further happens. Any ideas on what could be going wrong? When I log in from Windows it goes straight to my character selection screen (not the server selection screen). Could this be the problem? I'm using NVidia 290.10 drivers in Arch 64bit to drive an NVidia 9600 GSO. Any ideas? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 julusp(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julusp(a)gmail.com --- Comment #144 from julusp(a)gmail.com 2012-03-10 02:56:54 CST --- No problem with the patch on Mac OS X 10.7.3 with Radeon 6750, game plays well, excellent framerates. Only issue i found is *insane* loading times. the bigger location, the longer it will takes, (Nar Shadaa - 15 minutes, and sometimes disconnect). I dont think that te texture is related to this patch. only things i see in logs are: fixme:win:GetWindowPlacement not supported on other process window 0x90060 fixme:d3d:query_init Unhandled query type 0xc. warn:d3d:wined3d_query_create Failed to initialize query, hr 0x8876086a. warn:d3d9:query_init Failed to create wined3d query, hr 0x8876086a. warn:d3d9:IDirect3DDevice9Impl_CreateQuery Failed to initialize query, hr 0x8876086a. fixme:d3d:resource_check_usage Unhandled usage flags 0x8. warn:d3d9:IDirect3DDevice9Impl_SetFVF 0 is not a valid FVF which spawns like crazy trough the loading screen. Personally i think this is another bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #145 from Carsten Juttner <carjay(a)gmx.net> 2012-03-10 07:43:28 CST --- (In reply to comment #138)
order; from what I read, it should be done like
user_shared_data->SystemTime.High2Time = now.HighPart; user_shared_data->SystemTime.LowPart = now.LowPart; user_shared_data->SystemTime.High1Time = now.HighPart;
You are right, I remember I wanted to scrutinize this a bit more but obviously failed to do so and ended up copying and pasting the original wine source code from the initial initialisation. So let's do this now. We have L, H1 and H2. Obviously on the "kernel" side this is coherent (since the now-structure is not changing). Writing L, H1, H2 (as in the patch) concurrently with the expected H1, L, H2 read sequence (in a different thread) leads to 4 cases: 4 relevant points in time: - H1 old, L old, H2 old: ok - H1 old, L new, H2 old: nok, but will not(!) be detected - H1 new, L new, H2 old: nok - H1 new, L new, H2 new: ok So indeed this code is obviously wrong and whoever wrote this probably thought that it would not matter because it was intended as a one time initial write. Shows that copying and paste code without reviewing is a bad practice. :) For the intended write order H2, L, H1 and read order H1, L, H2 this cannot happen (but see below): - H1 old, L old, H2 old: ok - H1 old, L old, H2 new: nok - H1 old, L new, H2 new: nok - H2 new, L new, H2 new: ok Since this only becomes an issue at the moment the HighTime-Part actually changes this could in theory happen every (1<<32)/10e6 = 429 seconds which is roughly every 7 minutes. So for a reader application this will appear like the system jumps in time by about 7 minutes. Sadly, even if the order is corrected in the patch I think this will not be enough since due to the hackish nature several updates could happen concurrently. Because, if several threads enter a critical section and thus update the page at the same time this may invalidate the strict order guarantee (since a second thread may overwrite H2 with an old value after another thread set it to a new one). So there is still a chance that H and L do not fit. For a final implementation this also needs to take memory reference reordering and cache coherence issues into account. IIRC x86 is safe here as long as the compiler does not reorder the assembler instructions but for other platforms this may differ. Some memory fences should help. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #146 from Carsten Juttner <carjay(a)gmx.net> 2012-03-10 08:21:28 CST --- (In reply to comment #143)
I'm in the same boat as hash. I can login fine but, I get a plain desktop and a cursor after logging in. After waiting ~10mins the screen goes black and nothing further happens. Any ideas on what could be going wrong? When I log in from Windows it goes straight to my character selection screen (not the server selection screen). Could this be the problem? I'm using NVidia 290.10 drivers in Arch 64bit to drive an NVidia 9600 GSO. Any ideas?
As a guideline, what happens after hitting "Play" here is: - 15-20 seconds: plain desktop background (blue) - ~1 second: black screen - 20-25 second: initial game loading screen After that the character selection is visible. Where "here" is a quad core i7-2630QM CPU with an Nvidia GeForce GTX460M and 270.41.06 drivers. It's an older Ubuntu 11.04 system with a custom kernel. Hashs log appeared to be similar to my own so no ideas here. :-| You could try to activate some debug flags concerning directx (e.g. d3d9) and try to gather from the logs if something goes wrong during initialization that might tell why things go wrong. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Andy <darkdelusions(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |darkdelusions(a)gmail.com --- Comment #147 from Andy <darkdelusions(a)gmail.com> 2012-03-10 14:07:49 CST --- The patch worked successfully for me on fedora 16 64 bit. The only issue I have is if the game is not launched in a virtual desktop the launcher does not draw correctly. So I just run the game using the following command env WINEPREFIX=$HOME/.wine-swtor wine explorer /desktop=SWTOR,1920x1080 "C:\Program Files\Electronic Arts\BioWare\Star Wars - The Old Republic\launcher.exe" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Balsha <balsha-gajin(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |balsha-gajin(a)hotmail.com --- Comment #148 from Balsha <balsha-gajin(a)hotmail.com> 2012-03-10 14:11:20 CST --- I'm a complete noob in both Ubuntu and Wine. So if anyone could explain how to install this KUSER patch step-by-step, I would greatly apreciate it. I'm using Ubuntu 11.10 and wine 1.4rc6. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #149 from Balsha <balsha-gajin(a)hotmail.com> 2012-03-10 14:13:53 CST --- I'm a complete noob in both Ubuntu and Wine. So if anyone could explain how to install this KUSER patch step-by-step, I would greatly apreciate it. I'm using Ubuntu 11.10 and wine 1.4rc6. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Fernando Martins <fernando(a)cmartins.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fernando(a)cmartins.nl --- Comment #150 from Fernando Martins <fernando(a)cmartins.nl> 2012-03-10 17:17:03 CST --- @Balsha: please do not use the bug comments to ask for help. Use the wine forum: http://forum.winehq.org/viewforum.php?f=2&sid=c5b6e78ac4b901da88fa3a770c3a01... But first read http://wiki.winehq.org/Patching for help on applying patches. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #151 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-10 17:37:39 CST --- Created attachment 39300 --> http://bugs.winehq.org/attachment.cgi?id=39300 KUSER_SHARED_DATA updates using a dedicated thread per swtor process Here's my current patch. It updates KUSER_SHARED_DATA with a dedicated thread per swtor process. It works better for me than Carsten's patch, but it still suffers from freezing, though the frequency varies: a starter character on Tython can play for hours, but a Sith Assassin on Hoth starts freezing almost immediately. The thread's priority can be controller via the env variable WINE_USER_DATA_THREAD_PRIORITY Default is 20. The sleep time in nanosecond can be controlled via WINE_USER_DATA_THREAD_NSLEEP Default is 15625000 (15.625 ms). I've included my NtTimer code, commented out. I'm not sure why it didn't work, since apparently the updates really don't need to be very fast. The update thread is only spawned for the swtor processes. To determine this, I had to look in the CommandLine process variable. I had to manually convert the UNICODE_STRING to ANSI; when I tried to use RtlUnicodeToMultiByteN it segfaulted. I think this is a more general fix than Carsten's, since there will be no overlapping writes (single writer thread per process). But it still doesn't solve the freezing issue, which I'm no longer sure is related. I've noticed that during the freezing, the RemoteRenderer process stops consuming CPU, so it seems like something is deadlocked in the renderer. Can people please try my patch and report your results? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #152 from julusp(a)gmail.com 2012-03-10 17:48:49 CST --- Compiling it now, will let you know with the result, anyway the freezing can be theoreticaly caused by 256MB GPU cards, friend confirmed that on his Nvidia 320M 256MB recieves spam when freezed (the VideoSizeRam is set correctly): fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #153 from julusp(a)gmail.com 2012-03-10 18:20:50 CST --- (In reply to comment #151)
Created attachment 39300 [details] KUSER_SHARED_DATA updates using a dedicated thread per swtor process .... Can people please try my patch and report your results?
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #154 from julusp(a)gmail.com 2012-03-10 19:34:27 CST --- Created attachment 39303 --> http://bugs.winehq.org/attachment.cgi?id=39303 wine log for KUSER_SHARED_DATA updates using a dedicated thread per swtor ... As you can see, it tryies two times to register thread and then nothing more happens and launcher will show "unable to launch the game" error, i can run it with aditional debug, just please tell me which one you want. (And no, i am not concerned about showing the password, as i use security key auth, it is always different :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 julusp(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39303|application/octet-stream |text/plain mime type| | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #155 from tonedef <wine(a)causal.ca> 2012-03-10 20:07:41 CST --- I managed to solve my issues of "black screen after login" so I thought I'd come back and let people know what worked for me. Hopefully this works for hash. Aside from recompiling with KUSER_SHARED_DATA patch I had to also drop my gcc version from 4.6.3 to 4.5.2 before compilation. This is actually a known bug in gcc. I think the relevant log line is: fixme:dbghelp:elf_search_auxv can't find symbol in module For more information see http://appdb.winehq.org/objectManager.php?sClass=version&iId=19444. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39300|0 |1 is obsolete| | --- Comment #156 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-11 04:08:13 CDT --- Created attachment 39308 --> http://bugs.winehq.org/attachment.cgi?id=39308 KUSER_SHARED_DATA updates using a dedicated thread for all processes Removed the CommandLine parsing, spawn a thread for all processes. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #157 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-11 04:12:19 CDT ---
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #158 from Carsten Juttner <carjay(a)gmx.net> 2012-03-11 05:57:27 CDT --- (In reply to comment #155)
I managed to solve my issues of "black screen after login" so I thought I'd come back and let people know what worked for me. Hopefully this works for hash. Aside from recompiling with KUSER_SHARED_DATA patch I had to also drop my gcc version from 4.6.3 to 4.5.2 before compilation.
Yes, since I was using an older Ubuntu installation my gcc was by default the mentioned version 4.5.2. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #159 from Carsten Juttner <carjay(a)gmx.net> 2012-03-11 07:55:14 CDT --- (In reply to comment #157)
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
This patch won't work as is on my Ubuntu system since it tries to set the scheduling policy to SCHED_FIFO which isn't allowed by the process limits (it will return "no permission" when calling pthread_create). If I remove the scheduling setup, the login to character selection works (didn't test more). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #160 from julusp(a)gmail.com 2012-03-11 09:09:27 CDT --- (In reply to comment #157)
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
Now it wont even launch anything, producing nothing but empty log. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #161 from julusp(a)gmail.com 2012-03-11 09:21:21 CDT --- (In reply to comment #160)
(In reply to comment #157)
With your patch applied on vanilla wine1.4 source code, i cant get past launcher - i get Unable to launch game when i hit play.
I updated the patch, can you try again? Hopefully you were just having trouble with the CommandLine parsing, so I removed that piece. Not sure what else could have caused a crash anyway :)
Now it wont even launch anything, producing nothing but empty log.
Even if i remove the schedpolicy as Carsten did i will get only fixme:thread:thread_init unable to spawn thread: Undefined error: 0 (0) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #162 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-11 19:13:44 CDT --- Created attachment 39316 --> http://bugs.winehq.org/attachment.cgi?id=39316 KUSER_SHARED_DATA updates using a dedicated thread for all processes with no attributes I removed all the pthread attribute code, and all the commented out NtTimer code. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #163 from hash <HASH.DuOrden(a)gmail.com> 2012-03-11 19:41:56 CDT --- (In reply to comment #155)
I managed to solve my issues of "black screen after login" so I thought I'd come back and let people know what worked for me. Hopefully this works for hash. Aside from recompiling with KUSER_SHARED_DATA patch I had to also drop my gcc version from 4.6.3 to 4.5.2 before compilation. This is actually a known bug in gcc. I think the relevant log line is:
fixme:dbghelp:elf_search_auxv can't find symbol in module
For more information see http://appdb.winehq.org/objectManager.php?sClass=version&iId=19444.
Thank you! That solved it, in my system I've had gcc-4.5.3. so I've compiled 4.5.2 in /opt/gcc/4.5.2 and then compiled wine this way: CFLAGS="-march=native -O2 -pipe --enable-frame-pointer" CXXFLAGS="${CFLAGS}" ./configure --prefix=/opt/wine${WINE_BUILD_TYPE} \ --with-xinput2 --without-openal --with-opengl --with-oss --with-mpg123 \ CC=/opt/gcc-4.5.2/bin/gcc CXX=/opt/gcc-4.5.2/bin/c++ CPP=/opt/gcc-4.5.2/bin/cpp && \ make depend && make Now I can login with WINE! Finally I can dish-out VMWare! All thanks to tonedef who found tiny piece of gold in wine-bugzilla! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #164 from julusp(a)gmail.com 2012-03-11 19:49:22 CDT --- (In reply to comment #162)
Created attachment 39316 [details] KUSER_SHARED_DATA updates using a dedicated thread for all processes with no attributes
I removed all the pthread attribute code, and all the commented out NtTimer code.
Argh, you will kill me. The code works, the code before works too. I am using Mac OSX 10.7, gcc-4.2 and wineskin, i was running your code in DEBUG and that is why it wont work, i accidently launched the game without debug and i was surprised it works!? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #165 from julusp(a)gmail.com 2012-03-11 19:52:12 CDT --- Created attachment 39317 --> http://bugs.winehq.org/attachment.cgi?id=39317 OSX Debug trace If you want to look on this issue, why your code breaks debug, i attached the +all log (it generates just few lines). Anyway, the insane loading times for big locations remains. Maybe another bug? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 silentz0r <d.misdanitis(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |d.misdanitis(a)gmail.com --- Comment #166 from silentz0r <d.misdanitis(a)gmail.com> 2012-03-11 19:59:58 CDT --- (In reply to comment #165)
Created attachment 39317 [details] OSX Debug trace
If you want to look on this issue, why your code breaks debug, i attached the +all log (it generates just few lines).
Anyway, the insane loading times for big locations remains. Maybe another bug?
The insane loading times might be from wine producing too much output. Try disabling ALL output from wine, and run swtor. Please let us know if this resolves your issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #167 from julusp(a)gmail.com 2012-03-11 20:13:10 CDT --- (In reply to comment #166)
(In reply to comment #165)
Created attachment 39317 [details] OSX Debug trace
If you want to look on this issue, why your code breaks debug, i attached the +all log (it generates just few lines).
Anyway, the insane loading times for big locations remains. Maybe another bug?
The insane loading times might be from wine producing too much output. Try disabling ALL output from wine, and run swtor. Please let us know if this resolves your issue.
I tryied WINEDEBUG=-all and the load time is still taking long time (more than 5 minute to load Nar Shaddaa) swtor.exe @swtor_dual.icb is taking 100% of cpu core, and swtor.exe @RemoteRendererServer.icb is almost idle -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #168 from Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> 2012-03-11 23:04:46 CDT --- (In reply to comment #166)
Anyway, the insane loading times for big locations remains. Maybe another bug? Yes, please open a new bug.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Panama Craig <Panama.Craig00(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Panama.Craig00(a)gmail.com --- Comment #169 from Panama Craig <Panama.Craig00(a)gmail.com> 2012-03-12 03:42:28 CDT --- Ok, so I decided recently that I would go ahead and change back over to Ubuntu from Win7 once SWTOR was found to be working. I did a fresh install of Ubuntu 10.04 Lucid Lucy. I started out getting wine 1.4 and making sure to get the build dependencies, and then updated my nvidia drivers to the most current version. I then compiled a version of wine-git with the proof of concept patch and performed an override on the dlls with wine for the d3dx9_36 dll and the vcrun2008 dll. After all that and of course, much more customization of Ubuntu's look for me. I decided to go ahead and install SWTOR. The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen. I would continue to troubleshoot whats going on here, but I am getting extremely tired and have taken every possible step that I can take. Carefully and slowly... I don't know how to run debug logging, but I don't mind doing it. With the drivers, the git build, the renamed files, and the ability to get all the way in game... I suspect I should be able to get to the server list at least and get turned away because I didn't compile my git build properly or something, but I should be getting past where I am right now at the very least. Thank you for any assistance! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #170 from julusp(a)gmail.com 2012-03-12 07:06:21 CDT --- (In reply to comment #169)
The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen.
Don't rename that files, it is not needed anymore, and you will not know if you have render problems (like hash and tonedef) or something else, also try take look at comment #155 and #163 maybe it is related to your issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 dlzerocool <dl.zerocool(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dl.zerocool(a)gmail.com --- Comment #171 from dlzerocool <dl.zerocool(a)gmail.com> 2012-03-12 08:15:04 CDT --- I would like to know more about why GCC 4.6 exactly broke things up, and why this flag help : CFLAGS="--enable-frame-pointer" As far as I remember enabling frame-pointer resulted in a broken wine, not the opposite. But I might be wrong. Also, as someone already reported this to FSF ? And if yes, where, because I am desperately looking for it, and eventually give some help to solve this annoying bug. (Having to revert to any other GCC version just to compile wine is not a solution, since a GNU/Linux distribution would have build all other packages with the newer version.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30148 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #172 from Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> 2012-03-12 08:24:49 CDT --- (In reply to comment #171) For example see bug 22053. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #173 from dlzerocool <dl.zerocool(a)gmail.com> 2012-03-12 08:30:25 CDT --- (In reply to comment #172)
(In reply to comment #171) For example see bug 22053.
Thank you, I did already found that bug, but look at the http://bugs.winehq.org/show_bug.cgi?id=22053#c27 (comment 27) you'll see that he is using "-fomit-frame-pointer". It a really weird bug, and apparently none is speaking about what code lines are exactly broken or not interpreted like they should by gcc 4.6 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #174 from dlzerocool <dl.zerocool(a)gmail.com> 2012-03-12 09:08:44 CDT --- (In reply to comment #169) I haven't been able to pass the loading screen either. I am using an ArchlinuxX64. Compiled with GCC 1.5.0 and tried every patch available here. Including the last one from "Xoloti Loki". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #175 from dlzerocool <dl.zerocool(a)gmail.com> 2012-03-12 09:20:45 CDT --- (In reply to comment #174)
(In reply to comment #169)
I haven't been able to pass the loading screen either. I am using an ArchlinuxX64. Compiled with GCC 1.5.0 and tried every patch available here. Including the last one from "Xoloti Loki".
My bad, I might have been a bit tired yesterday, I just revert all my changes, cleaned wine (make clean) and apply the patch again, compiled the wine with GCC 4.5.0 and it's working. But it's generating a HUGE amount of logs : Which are mainly generated by this fixme, fixme:win:GetWindowPlacement not supported on other process window 0x60086 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #176 from hash <HASH.DuOrden(a)gmail.com> 2012-03-12 09:22:38 CDT --- Well, for me it dosn't matter which gcc to use 4.5.2 or 4.5.3 as long as I use CFLAGS="--enable-frame-pointer", I haven't yet tested with 4.6 simply because in Gentoo 4.6 hard masked as unstable and unsuitable for production use. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #177 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-12 09:58:10 CDT --- (In reply to comment #176)
Well, for me it dosn't matter which gcc to use 4.5.2 or 4.5.3 as long as I use CFLAGS="--enable-frame-pointer", I haven't yet tested with 4.6 simply because in Gentoo 4.6 hard masked as unstable and unsuitable for production use.
32 or 64 bit? @dlzerocool: WindowPlacement = known other issue -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #178 from hash <HASH.DuOrden(a)gmail.com> 2012-03-12 10:12:02 CDT --- 32bit -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 mbisme(a)burke-works.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mbisme(a)burke-works.com | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #179 from Panama Craig <Panama.Craig00(a)gmail.com> 2012-03-12 21:46:44 CDT --- (In reply to comment #170)
(In reply to comment #169)
The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen.
Don't rename that files, it is not needed anymore, and you will not know if you have render problems (like hash and tonedef) or something else, also try take look at comment #155 and #163 maybe it is related to your issue.
I know what my problem is... It is that I compiled wine and git under gcc 4.6 instead of 4.5.2 or .3 ... I need to recompile them both, but I don't know how to do that. Here is where I left off at last night before giving up completely. I just downloaded and extracted gcc 4.5.2 into my /home/*username*/gcc-4.5.2/ then cd'd to that folder in the terminal and performed the commands to compile gcc-4.5.2 into the system. Also did a sudo make and sudo make install on gcc-4.5.2... So now when I recompile wine-git I should be able to use 4.5.2 instead of 4.6, but where I am stuck at is finding out how to just recompile wine-git... Do I need to remove wine-git before I recompile it? Or do I just recompile over it? Do I need to specify that wine-git be compiled with 4.5.2 instead of 4.6 since I now have both? What are the commands to do all this? Do I need to compile wine all over again as well, not just git? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #180 from hash <HASH.DuOrden(a)gmail.com> 2012-03-13 00:37:52 CDT --- (In reply to comment #179)
(In reply to comment #170)
(In reply to comment #169)
The install went through and I renamed the LoadingScreenIcon.dds and the LoadingScreen.jpg files to be preceded with the extension ".bak". From here I loaded the game and am now stuck at a black screen.
Don't rename that files, it is not needed anymore, and you will not know if you have render problems (like hash and tonedef) or something else, also try take look at comment #155 and #163 maybe it is related to your issue.
I know what my problem is... It is that I compiled wine and git under gcc 4.6 instead of 4.5.2 or .3 ... I need to recompile them both, but I don't know how to do that. Here is where I left off at last night before giving up completely.
I just downloaded and extracted gcc 4.5.2 into my /home/*username*/gcc-4.5.2/ then cd'd to that folder in the terminal and performed the commands to compile gcc-4.5.2 into the system. Also did a sudo make and sudo make install on gcc-4.5.2... So now when I recompile wine-git I should be able to use 4.5.2 instead of 4.6, but where I am stuck at is finding out how to just recompile wine-git... Do I need to remove wine-git before I recompile it? Or do I just recompile over it? Do I need to specify that wine-git be compiled with 4.5.2 instead of 4.6 since I now have both? What are the commands to do all this? Do I need to compile wine all over again as well, not just git?
I cannot say that replacing your system gcc with older version just to compile single program is good idea, if in distribution of your choice gcc-4.6 is default then there is a reason for that and by performing sudo make install you playing with fire there! Instead you should've used --prefix when you run configure, you did run ./configure script before make in gcc-4.5.2, did you? Here how I run configure when I thought needed gcc-4.5.2: ./configure --prefix=/opt/gcc-4.5.2 --enable-languages=c,c++,fortran and thanks to --prefix when you sudo make install it will install it in /opt/gcc-4.5.2 consecutively to compile wine you will need to point it's configure to where to look for gcc: ./configure --prefix=/opt/wine CC=/opt/gcc-4.5.2/bin/gcc CXX=/opt/gcc-4.5.2/bin/c++ CPP=/opt/gcc-4.5.2/bin/cpp -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #181 from h.v.bruinehsen(a)fu-berlin.de 2012-03-13 05:17:26 CDT --- I'm not sure, if the lockups are really wine related. In the beginning I had them, too (Gameplay on Korriban grew sluggish over time, Dromund Kaas was nearly unplayable from the beginning on). Without changing anything directly wine related (still using Carstes patch) the problem disappeared after some system updates (kernel from 3.0.4 to 3.2.6, both with Con Kolivas patchset, new glibc, gcc from 4.5.2 to 4.6.3 with graphite and some other). Now everythings runs fine (sometimes minor stuttering, but that is most likely hardware related). Therefore I believe that the problem is not wine-related or some kind of race-condition (which will make it much harder to debug, I fear)... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #182 from hash <HASH.DuOrden(a)gmail.com> 2012-03-13 07:46:41 CDT --- (In reply to comment #181)
I'm not sure, if the lockups are really wine related. In the beginning I had ... with Con Kolivas patchset, new glibc, gcc from 4.5.2 to 4.6.3 with graphite and ...
I'm sorry to ask not about what your post is, but have you tried compile wine with gcc-4.6.3 and Carstes patch? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Justin Gray <justinanthonygray(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|justinanthonygray(a)gmail.com | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #183 from Panama Craig <Panama.Craig00(a)gmail.com> 2012-03-13 10:40:04 CDT --- Honestly, at this point... I am going to reinstall Ubuntu and start over clean. I am running 10.04 right now, but it seems that most people are having success with 11.04 or 11.10 more than I am having success with Lucid Lucy. I may also just go with 12.04 and see how that works out as well. Not sure though to be honest. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #184 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-13 11:55:03 CDT --- Post your results. Testing 12.04 also, no problems thus far. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #185 from h.v.bruinehsen(a)fu-berlin.de 2012-03-13 12:52:43 CDT --- The git-checkout from today compiled fine with gcc-4.6.2 and Carstens patch. I'm using Gentoo and only patched the ebuild - there are two Gentoo-specific patches applied also: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f... and http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f... If it's not one of them, it's maybe the Gentoo-spec file for gcc. Otherwise my point wasn't the ability to compile wine with newer ggc-versions, but the fix for the slowdown-problem without touching wine... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #186 from julusp(a)gmail.com 2012-03-13 13:22:33 CDT --- (In reply to comment #185)
Otherwise my point wasn't the ability to compile wine with newer ggc-versions, but the fix for the slowdown-problem without touching wine...
That is not good solution. This may works with linux distributions, but with othet os like BSD or MAC OS X where you are stuck with gcc-4.2 this will not work. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #187 from h.v.bruinehsen(a)fu-berlin.de 2012-03-13 13:53:10 CDT ---
That is not good solution. This may works with linux distributions, but with othet os like BSD or MAC OS X where you are stuck with gcc-4.2 this will not work.
And searching for a fix in Wine for a problem that may be not caused by Wine is a good solution? I'm not saying that the problem may not be caused by Wine - but if it can be fixed by other means, it seems to be at least some kind of race condition or a problem with one of the used libraries. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #188 from julusp(a)gmail.com 2012-03-13 13:57:59 CDT --- (In reply to comment #187)
And searching for a fix in Wine for a problem that may be not caused by Wine is a good solution? I'm not saying that the problem may not be caused by Wine - but if it can be fixed by other means, it seems to be at least some kind of race condition or a problem with one of the used libraries.
I dont know what issues you see, on mac the only issue is with loading times, but when loaded the performance is nearly windows like. No slowdowns only minor stuttering ( major when taxi moving but that does not affect gameplay) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #189 from hash <HASH.DuOrden(a)gmail.com> 2012-03-13 14:42:36 CDT --- (In reply to comment #185)
The git-checkout from today compiled fine with gcc-4.6.2 and Carstens patch. I'm using Gentoo and only patched the ebuild - there are two Gentoo-specific patches applied also: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f... and http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-emulation/wine/f...
If it's not one of them, it's maybe the Gentoo-spec file for gcc.
Otherwise my point wasn't the ability to compile wine with newer ggc-versions, but the fix for the slowdown-problem without touching wine...
So you saying that you compiled otherwise stock, from Gentoo perspective view, WINE with gcc-4.6.2 and all works? Could you provide emerge --info please? PS: And by the way, if you just want to add one patch to any packet in Gentoo you do not have to copy in to /usr/local/portage and alter it's .ebuild file, all you need to do is create directory in etc like this for wine: /etc/portage/patches/app-emulation/wine/ and place in it your patch, and next time emerge will compile it with your patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #190 from Panama Craig <Panama.Craig00(a)gmail.com> 2012-03-13 19:02:37 CDT --- Created attachment 39344 --> http://bugs.winehq.org/attachment.cgi?id=39344 Terminal Log Ok, so here I am again... I freshly installed Ubuntu desktop 11.10 and have updated my nvidia drivers to 295.20 again, and then installed git, and then applied the patch, compiled wine through git, then installed wine. Installed SWTOR, then did the d3dx9 override and launch the game via cd'ing to the game directory then ~/wine-git/wine explorer /desktop=4,1360x768 launcher.exe. From there, I log into the game, and it takes a moment, but the game will finally open and it gets to the loading screen and begins to load, then just stops and the game will crash... The terminal leaves behind the message in the attachment I logged. Is this because I did the steps for ./configure and make on git for wine before I ever even installed wine? I did apply the patch before performing either of those steps too btw. Whats going on? I just want to play mah gamez! LoL -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #191 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-14 04:18:22 CDT --- Strange, might be driver/hardware related then. Did you try to use Crossover XI? (there is a trial that supports swtor from these patches). Also try another driver version, I use the exact same one but it might just be that in your case. http://www.codeweavers.com/compatibility/browse/name/?forum=1;app_id=7626;mh... Best regards, Sebastiaan -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #192 from h.v.bruinehsen(a)fu-berlin.de 2012-03-14 10:11:57 CDT --- Created attachment 39360 --> http://bugs.winehq.org/attachment.cgi?id=39360 Emerge --info output from working Gentoo 64~ (In reply to comment #189)
Could you provide emerge --info please?
I attached the output. Otherwise I think we should discuss Gentoo specific things (except it's related to this bug) privately or via gentoo lists/forums/irc.
PS: And by the way, if you just want to add one patch to any packet in Gentoo you do not have to copy in to /usr/local/portage and alter it's .ebuild file, all you need to do is create directory in etc like this for wine: /etc/portage/patches/app-emulation/wine/ and place in it your patch, and next time emerge will compile it with your patch.
This only works, when the ebuild calls 'epatch_user' (which wine-9999.ebuild acually does). Old habits are also hard to put down.. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #193 from hash <HASH.DuOrden(a)gmail.com> 2012-03-14 10:45:15 CDT --- (In reply to comment #192)
Created attachment 39360 [details] Emerge --info output from working Gentoo 64~ .... This only works, when the ebuild calls 'epatch_user' (which wine-9999.ebuild acually does). Old habits are also hard to put down..
I asked about emerge --info just to look in your CFLAGS since I didn't know your level of Linux understanding I thought it'll easer way of looking in that. So as you use gcc-4.6 and you don't use --enable-frame-pointer it is mean one of three options: 1. gcc-4.6 can compile WINE without braking it. :) 2. some default CFLAGS from Gentoo profile insert --enable-frame-pointer by default. 3. Some of your CFLAGS or combination of them made gcc compile WINE without braking it. :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 André Fettouhi <A.Fettouhi(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |A.Fettouhi(a)gmail.com --- Comment #194 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-03-16 12:51:18 CDT --- I'm trying to build wine version 1.4 against the patch from Carsten but I keep getting this error: can't find file to patch at input line 7 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/critsection.c b/dlls/ntdll/critsection.c |index fb69b31..5d7783b 100644 |--- a/dlls/ntdll/critsection.c |+++ b/dlls/ntdll/critsection.c -------------------------- File to patch: I'm just using this command to patch with: cat proof_of_concept.patch |patch -p1 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #195 from Sebastiaan Blommers <sebastiaan.blommers(a)gmail.com> 2012-03-16 12:53:23 CDT --- (In reply to comment #194)
I'm trying to build wine version 1.4 against the patch from Carsten but I keep getting this error:
can't find file to patch at input line 7 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/dlls/ntdll/critsection.c b/dlls/ntdll/critsection.c |index fb69b31..5d7783b 100644 |--- a/dlls/ntdll/critsection.c |+++ b/dlls/ntdll/critsection.c -------------------------- File to patch:
I'm just using this command to patch with:
cat proof_of_concept.patch |patch -p1
http://wiki.winehq.org/Patching -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #196 from Henri Verbeet <hverbeet(a)gmail.com> 2012-03-16 13:00:07 CDT --- (In reply to comment #195)
cat proof_of_concept.patch |patch -p1
http://wiki.winehq.org/Patching Actually, you almost always want to use "git apply" instead of "patch" for applying patches to a git tree.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #197 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-03-16 13:02:12 CDT --- But I'm not patching against the latest git? I'm patching against wine 1.4. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #198 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-03-16 14:37:14 CDT --- I just build Carstens patch against wine 1.4 and tried to launch swtor. I can't get to the server selection screen at all plus I am experiencing very very long load times as mentioned in another wine bug. I am running Arch Linux 64 bit with gcc 4.6.3. The output from the terminal gives me an infinite loop of... fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #199 from julusp(a)gmail.com 2012-03-16 18:03:26 CDT --- (In reply to comment #198)
I just build Carstens patch against wine 1.4 and tried to launch swtor. I can't get to the server selection screen at all plus I am experiencing very very long load times as mentioned in another wine bug. I am running Arch Linux 64 bit with gcc 4.6.3. The output from the terminal gives me an infinite loop of...
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory
Obviously out of gpu memory (some 256MB cards are not working), or try to set correct VideoMemorySize in registry. For others: Discuss only things related to this issue, please don't ask for steps how to build wine, this is not help forum. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #200 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-16 21:48:23 CDT --- I think the current patches do a reasonable job of fixing the initial server handshake, so we should apply some version of them and close this bug. At this point it's degenerating into a forum session on patching and video cards. Wine devs: is there anything you find unacceptable about my last patch? The only concern I have is that clock_nanosleep on an absolute timer might be a better choice than the current nanosleep call, since the update time will drift. But I don't know if there is drift when windows updates the values either. Carsten, did your test program exhibit such drift? I.e. did they do 64 full updates every second, so the values would fall on every second boundary? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #201 from silentz0r <d.misdanitis(a)gmail.com> 2012-03-17 07:42:51 CDT --- (In reply to comment #198)
I just build Carstens patch against wine 1.4 and tried to launch swtor. I can't get to the server selection screen at all plus I am experiencing very very long load times as mentioned in another wine bug. I am running Arch Linux 64 bit with gcc 4.6.3. The output from the terminal gives me an infinite loop of...
fixme:d3d:resource_check_usage Unhandled usage flags 0x8. err:d3d:resource_init Out of adapter memory
I have made a package called gcc45-multilib. Build it using yaourt -G gcc45-multilib, then cd into that dir and makepkg -si After cd into ~/wine-git and run ./configure CC=gcc-4.5.2 CXX=c++-4.5.2 CPP=cpp-4.5.2 and you're done. If you want a more detailed explanation I wrote a guide on my blog, which I won't post here. Google my nick along with " swtor linux". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #202 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-03-17 12:09:24 CDT --- I just tried rebuild wine 1.5.0 with Xolotl Loki patch (39316) using gcc 4.6.3 on Arch Linux 64 bit and the game actually works now :-). Have only played very little of the game but load times seem to be ok. Loading the game after login takes quite a whole though +5 minutes at least. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #203 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-03-17 12:14:47 CDT --- I forgot to add that exiting/logging out the game hangs, e.g. swtor.exe, launcher.exe and winserver.exe keep on running... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #204 from Carsten Juttner <carjay(a)gmx.net> 2012-03-17 19:18:20 CDT --- (In reply to comment #200)
But I don't know if there is drift when windows updates the values either. Carsten, did your test program exhibit such drift? I.e. did they do 64 full updates every second, so the values would fall on every second boundary?
A quick test shows that on my Vista system each update seems to add a value of either 156000 or 156001 to InterruptTime and always 156000 for SystemTime. This would hint that the "real" update is not occurring at 64Hz but rather around 64.102564Hz. Anyway, the values are quite consistent. I guess there is not a lot of drift because the timer interrupt is hardware generated. But I do not think it matters much since these timers are not documented officially so as long as they get updated around 64 Hz things should work ok. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #205 from Bruno Jesus <00cpxxx(a)gmail.com> 2012-03-19 06:24:42 CDT --- (In reply to comment #200)
Wine devs: is there anything you find unacceptable about my last patch? The only concern I have is that clock_nanosleep on an absolute timer might be a better choice than the current nanosleep call, since the update time will drift.
You can follow the guidelines from http://wiki.winehq.org/SubmittingPatches and send it to wine-patches. Or send first to wine-devel with RFC in the beggining of the subject so others can take a look on it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Trograin <boban.alempijevic(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |boban.alempijevic(a)gmail.com --- Comment #206 from Trograin <boban.alempijevic(a)gmail.com> 2012-03-20 07:09:04 CDT --- Been trying this patch added to 1.4 source and used with Wineskin in OSX 10.7 with an ATI HD 5770 1024Mb GPU. Now the game starts good ( if using Virtual window and a set resolution doesn't matter what size as long as there is one), login, character creation the whole thin goes real nice. I can start the game as well . Now the problem I have and that a lot of other people most likely have as well is the stuttering. I have been trying to read through this thread and I am wiling to try to help out even though my skills are on an amateur level ( Though I have sys admin skills in background, these type of coding /hacking/software stuff is NOT my strong side :D ). I ran a debug in wineskin while running the game but it spat out a 22Mb large file. If I knew what areas in the Debug file would be of interest to this community I would gladly post it somewhere on the net and link it here. TI have been using the Wineskin as I said and the one that seems to be working nicely ( WITH stuttering) is this one: http://portingteam.com/index.php/files/file/7187-star-wars-the-old-republic/.... Now the stuttering is in starting areas okey, happens for a second or two once a minute, but go off to a main world and we talk MAIN stuttering ala Headache! Yes the stuttering part seems to be less in Linux, My bro did the patching and got the game to run under the patched wine on his Kubuntu 11 what ever the latest version now a days is:D. His stuttering is almost non existing compared to mine. It seems to have a larger impact on the OSX wine community though. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #207 from julusp(a)gmail.com 2012-03-20 07:22:12 CDT --- (In reply to comment #206)
Been trying this patch added to 1.4 source and used with Wineskin in OSX 10.7 with an ATI HD 5770 1024Mb GPU. Now the game starts good ( if using Virtual window and a set resolution doesn't matter what size as long as there is one), login, character creation the whole thin goes real nice. I can start the game as well . Now the problem I have and that a lot of other people most likely have as well is the stuttering. I have been trying to read through this thread and I am wiling to try to help out even though my skills are on an amateur level ( Though I have sys admin skills in background, these type of coding /hacking/software stuff is NOT my strong side :D ). I ran a debug in wineskin while running the game but it spat out a 22Mb large file. If I knew what areas in the Debug file would be of interest to this community I would gladly post it somewhere on the net and link it here.
TI have been using the Wineskin as I said and the one that seems to be working nicely ( WITH stuttering) is this one: http://portingteam.com/index.php/files/file/7187-star-wars-the-old-republic/....
Now the stuttering is in starting areas okey, happens for a second or two once a minute, but go off to a main world and we talk MAIN stuttering ala Headache!
Yes the stuttering part seems to be less in Linux, My bro did the patching and got the game to run under the patched wine on his Kubuntu 11 what ever the latest version now a days is:D. His stuttering is almost non existing compared to mine. It seems to have a larger impact on the OSX wine community though.
The wineskin port is made by me. The uploaded version uses the first patch as other ones breaks winedebug and does not bring any perfomance boost nor solve any issues. The other patches break vanilla wine as well (wine available trough macports). So this problem is not related to custom wineskin build process -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #208 from Trograin <boban.alempijevic(a)gmail.com> 2012-03-20 07:35:06 CDT --- Julus, I did not say that this problem is related to custom wineskin build process :) Iam still eager to try to help out though in any way I can. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #209 from julusp(a)gmail.com 2012-03-20 08:01:01 CDT --- (In reply to comment #208)
Julus, I did not say that this problem is related to custom wineskin build process :) Iam still eager to try to help out though in any way I can.
Anyway the stuttering and performance problems does not belong to this thread as that is separate bug. The current problem is that all patches except the proof of concept breaks winedebug on osx (wine exits with dbus error) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 julusp(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39317|0 |1 is obsolete| | --- Comment #210 from julusp(a)gmail.com 2012-03-20 11:30:50 CDT --- Created attachment 39477 --> http://bugs.winehq.org/attachment.cgi?id=39477 failing debug on OSX All patches from Xolotl Loki breaks wine on OSX with following error: /opt/local/bin/wine: line 5: 85970 Bus error: 10 DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:/usr/lib" "/opt/local/libexec/wine/wine" "$@" if the wine is run with WINEDEBUG="-all" then wine will start correctly. Proof of concept from Carsten Juttner work ok though. Attached more complete debug log when run WINEDEBUG="+all" winecfg can somebody look what is causing problem ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #211 from Carsten Juttner <carjay(a)gmx.net> 2012-03-20 18:10:41 CDT --- (In reply to comment #210)
Created attachment 39477 [details] failing debug on OSX
All patches from Xolotl Loki breaks wine on OSX with following error:
/opt/local/bin/wine: line 5: 85970 Bus error: 10 DYLD_FALLBACK_LIBRARY_PATH="/opt/local/lib:/usr/lib" "/opt/local/libexec/wine/wine" "$@"
if the wine is run with WINEDEBUG="-all" then wine will start correctly.
Proof of concept from Carsten Juttner work ok though.
Attached more complete debug log when run WINEDEBUG="+all" winecfg
can somebody look what is causing problem ?
If it only works with debugging messages turned off I'd suspect one of the added FIXME messages. An easy test would be to comment out all FIXME-lines from the patch and see if it works now. Then try to add them back one by one (actually only the FIXMEs that contain format specifiers like "%s" have a high probability to cause a Bus Error so one should try to add these back first). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #212 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-20 18:41:52 CDT --- Created attachment 39481 --> http://bugs.winehq.org/attachment.cgi?id=39481 KUSER_SHARED_DATA updates using a dedicated thread with no debugging I removed all the FIXME and getenv calls, hopefully this will work for OSX. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39481|0 |1 is obsolete| | --- Comment #213 from Xolotl Loki <xoloki(a)gmail.com> 2012-03-20 18:50:27 CDT --- Created attachment 39482 --> http://bugs.winehq.org/attachment.cgi?id=39482 KUSER_SHARED_DATA updates using a dedicated thread with no debugging Correct diff between my code and wine-1.4-rc6. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #214 from julusp(a)gmail.com 2012-03-22 10:03:59 CDT --- (In reply to comment #213)
Created attachment 39482 [details] KUSER_SHARED_DATA updates using a dedicated thread with no debugging
Correct diff between my code and wine-1.4-rc6.
Confirming fixed WINEDEBUG on OSX (against wine-1.5.0) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh(a)gmail.com --- Comment #215 from Jerome Leclanche <adys.wh(a)gmail.com> 2012-04-18 22:07:46 CDT --- (In reply to comment #214) Huh? was this fixed? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #216 from Xolotl Loki <xoloki(a)gmail.com> 2012-04-18 22:14:55 CDT --- The latest patch attached to this bug appears to fix the intro hang for Linux and OSX. It cannot be applied to wine though, since it uses a pthread in the wine process. I'm working with wine-dev to push a wineserver shared memory patch which fixes this for good. Though I got sign-off on the design, I have been unable to get NtMapViewOfSection to cooperate, so the patch has been languishing. Any wine devs looking at this bug who grok NtMapViewOfSection please check out my latest patch on wine-dev. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #217 from Johan Gill <johan.gill(a)gmail.com> 2012-05-15 08:16:38 CDT --- Any news? I see on the patch list for wine that there is a patch to "Separate image relocation from NtMapViewOfSection" pending. Does that have anything to do with this? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #218 from Xolotl Loki <xoloki(a)gmail.com> 2012-05-16 15:28:41 CDT --- No, none of the wine devs has helped me with my NtMapViewOfSection problems, and I haven't had any time to look at it myself lately. The current patch (and my improved version which does clock_nanosleep) does an adequate job of playing SWTOR post the 1.2 patch; the extended freezing appears to be gone. Framerate in PvP can drop very low though (4 fps, with a GTX 680!). Has anyone experimented with DLL overrides to get PvP performance to an acceptable level? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #219 from Marco D <moonbane(a)gmx.net> 2012-05-18 01:36:32 CDT --- (In reply to comment #218)
No, none of the wine devs has helped me with my NtMapViewOfSection problems, and I haven't had any time to look at it myself lately.
The current patch (and my improved version which does clock_nanosleep) does an adequate job of playing SWTOR post the 1.2 patch; the extended freezing appears to be gone. Framerate in PvP can drop very low though (4 fps, with a GTX 680!).
Has anyone experimented with DLL overrides to get PvP performance to an acceptable level?
I think it's a CPU-scaling/multithread issue. In Ops I can usually get better Performance, if I set each swtor-process per "taskset ..." to its own CPU-core. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #220 from hash <HASH.DuOrden(a)gmail.com> 2012-06-07 11:59:41 CDT --- As of wine-1.5.5-214-g876f0f2 patch from comment #213 isn't applicable: error: patch failed: server/async.c:256 error: server/async.c: patch does not apply include/wine/server_protocol.h updated -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 sporth(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sporth(a)gmail.com | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #221 from Xolotl Loki <xoloki(a)gmail.com> 2012-06-07 13:17:06 CDT --- (In reply to comment #220)
As of wine-1.5.5-214-g876f0f2 patch from comment #213 isn't applicable: error: patch failed: server/async.c:256 error: server/async.c: patch does not apply include/wine/server_protocol.h updated
The patch from comment #213 did not patch those files, so I'm not sure what the problem is. I'm attaching my current clock_nanosleep patch against 1.5.5 just in case. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Xolotl Loki <xoloki(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #39308|0 |1 is obsolete| | Attachment #39316|0 |1 is obsolete| | --- Comment #222 from Xolotl Loki <xoloki(a)gmail.com> 2012-06-07 13:18:20 CDT --- Created attachment 40435 --> http://bugs.winehq.org/attachment.cgi?id=40435 KUSER_SHARED_DATA updates using a clock_nanosleep against wine-1.5.5 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #223 from Xolotl Loki <xoloki(a)gmail.com> 2012-06-07 20:07:32 CDT --- (In reply to comment #219)
Has anyone experimented with DLL overrides to get PvP performance to an acceptable level?
I think it's a CPU-scaling/multithread issue. In Ops I can usually get better Performance, if I set each swtor-process per "taskset ..." to its own CPU-core.
When booted into Windows XP, I get minimum 20 fps in warzones. On the same computer, this drops to around 5 fps in Ubuntu under Wine (minimum). Trying taskset like such: xoloki(a)xocotl:~/src/mrx/build$ ps auwx | grep swtor xoloki 8935 0.0 0.0 8704 900 pts/1 R+ 17:44 0:00 grep swtor xoloki 29822 50.4 8.4 1916864 1389392 pts/5 RLl 15:20 72:26 C:\Program Files\Electronic Arts\BioWare\Star Wars - The Old Republic\swtor\RetailClient\swtor.exe @swtor_dual.icb xoloki 29839 74.1 4.5 2188764 756428 pts/5 SLl 15:20 106:20 swtor.exe @RemoteRendererServer.icb xoloki(a)xocotl:~/src/mrx/build$ taskset -pc 2 29822 pid 29822's current affinity list: 3 pid 29822's new affinity list: 2 xoloki(a)xocotl:~/src/mrx/build$ taskset -pc 3 29839 pid 29839's current affinity list: 3 pid 29839's new affinity list: 3 I didn't see any noticeable difference in framerate in warzones (still dropped to around 5 during large fights). I have 4 CPUs, so I chose 3 and 4. Does anyone get good (i.e. comparable to Windows on same hardware) framerates in PvP? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #224 from Marco D <moonbane(a)gmx.net> 2012-06-08 09:31:54 CDT --- Well I have an Vista on the same machine and have severe improvements in operations when I use taskset. I dislike the SWTOR-PvP so I cannot really compare but in operations (EV,KP) I get about 30 frames in Vista and around 25 in Wine. Without taskset I stay at ~15 frames. Debian Sid, vanilla 3.4, Q6600 GF 8800 Ultra with 302.11 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #225 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-07-10 10:51:44 CDT --- Can anyone get the launcher working after todays patch in swtor (1.3.2)? I just get a black screen with gold ornaments at the edge. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #226 from Xolotl Loki <xoloki(a)gmail.com> 2012-07-10 11:17:07 CDT --- I just tried with wine-1.5.7 and my clock_nanosleep patch, and after the launcher updated it became blacked out as described. Completely unusable. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #227 from julusp(a)gmail.com 2012-07-10 12:19:52 CDT --- (In reply to comment #226)
I just tried with wine-1.5.7 and my clock_nanosleep patch, and after the launcher updated it became blacked out as described. Completely unusable.
Can be workarounded by setting virtual desktop resolution to 800x600. Otherwise the window content will be moved or rendered black. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #228 from Xolotl Loki <xoloki(a)gmail.com> 2012-07-10 12:38:50 CDT --- (In reply to comment #227)
Can be workarounded by setting virtual desktop resolution to 800x600. Otherwise the window content will be moved or rendered black.
Confirmed workaround works on ubuntu-12.04. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #229 from julusp(a)gmail.com 2012-07-10 13:28:14 CDT --- (In reply to comment #222)
Created attachment 40435 [details] KUSER_SHARED_DATA updates using a clock_nanosleep against wine-1.5.5
Does not compile on MacOSX against wine 1.5.8: thread.c: In function ‘shared_data_thread’: thread.c:117: warning: implicit declaration of function ‘clock_gettime’ thread.c:117: error: ‘CLOCK_MONOTONIC’ undeclared (first use in this function) thread.c:117: error: (Each undeclared identifier is reported only once thread.c:117: error: for each function it appears in.) thread.c:129: warning: implicit declaration of function ‘clock_nanosleep’ thread.c:129: error: ‘TIMER_ABSTIME’ undeclared (first use in this function) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #230 from Xolotl Loki <xoloki(a)gmail.com> 2012-07-10 18:10:24 CDT ---
KUSER_SHARED_DATA updates using a clock_nanosleep against wine-1.5.5
Does not compile on MacOSX against wine 1.5.8:
clock_nanosleep is part of POSIX.1-2001 (IEEE Std 1003.1-2001). It looks like OS X only supports POSIX.1 (IEEE Std 1003.1-1988). So the clock_nanosleep patch will not work on OS X. Does the previous patch (KUSER_SHARED_DATA updates using a dedicated thread with no debugging) no longer work? I can regenerate it against a new wine version if needed. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #231 from julusp(a)gmail.com 2012-07-10 18:15:51 CDT --- (In reply to comment #230)
Does the previous patch (KUSER_SHARED_DATA updates using a dedicated thread with no debugging) no longer work? I can regenerate it against a new wine version if needed.
The previous patch still works. No need for regenerating it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #232 from Xolotl Loki <xoloki(a)gmail.com> 2012-07-10 19:31:43 CDT --- (In reply to comment #223)
Does anyone get good (i.e. comparable to Windows on same hardware) framerates in PvP?
I fixed this today, and it had nothing to do with wine. The culprit was an interaction between swtor.exe, my CPU, and Linux. My CPU allows the OS to scale down the CPU frequency during low loads. For some reason, swtor.exe convinced the OS it didn't need full power, so the OS left all cores idling at 800 MHz (3GHz CPU). This didn't happen with WoW, though I do remember occasional slowdowns that might have been freq scaling. The solution was to turn off "Cool and Quiet" in the BIOS, and lock all cores at 3 GHz. Hopefully this will not burn out my CPU, but the system is 3 years old so whatever. Not sure if XP did a better job of scaling the CPU, or if it just didn't bother trying. But I really don't care, because now I can PvP without booting into XP :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #233 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-07-11 00:37:31 CDT --- (In reply to comment #227)
(In reply to comment #226)
I just tried with wine-1.5.7 and my clock_nanosleep patch, and after the launcher updated it became blacked out as described. Completely unusable.
Can be workarounded by setting virtual desktop resolution to 800x600. Otherwise the window content will be moved or rendered black.
How do you then change the resolution of the virtual desktop once the game has launched? I play the game at my native resolution 1680x1050 in fullscreen mode with a 1680x1050 virtual desktop. How do I get that back after login? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #234 from Xolotl Loki <xoloki(a)gmail.com> 2012-07-11 00:53:07 CDT ---
How do you then change the resolution of the virtual desktop once the game has launched? I play the game at my native resolution 1680x1050 in fullscreen mode with a 1680x1050 virtual desktop. How do I get that back after login?
I was able to invoke my window manager's fullscreen command via Alt-F11, which then gave me a fullscreen toplevel window with no borders. This is Xfce on xubuntu-10.04. Other desktop/window managers may have different accels. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #235 from André Fettouhi <A.Fettouhi(a)gmail.com> 2012-07-11 01:01:50 CDT --- (In reply to comment #234)
How do you then change the resolution of the virtual desktop once the game has launched? I play the game at my native resolution 1680x1050 in fullscreen mode with a 1680x1050 virtual desktop. How do I get that back after login?
I was able to invoke my window manager's fullscreen command via Alt-F11, which then gave me a fullscreen toplevel window with no borders.
This is Xfce on xubuntu-10.04. Other desktop/window managers may have different accels.
Using KDE, so I did a similar thing. So works for now as well. Would be nice if this issue could be fixed permanently. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #236 from rawfox <rawfox(a)freenet.de> 2012-12-04 17:25:02 CST --- Created attachment 42706 --> http://bugs.winehq.org/attachment.cgi?id=42706 KUSER_SHARED_DATA_18 against -> wine-1.5.18 Due to improvements in wine-1.5.18 the /dlls/ntdll/thread.c was touched and the KUSER_SHARED_DATA patch wont apply anymore. The KUSER_SHARED_DATA patch is still needed due to http://bugs.winehq.org/show_bug.cgi?id=29168 what is still present in wine-1.5.18 . KUSER_SHARED_DATA_18 is tested and applies correctly here for wine-1.5.18 Pre-requisits are unchanged, needs vcrun2008 and d3dx9 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 eroen(a)eroen.eu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eroen(a)eroen.eu --- Comment #237 from eroen(a)eroen.eu 2012-12-07 16:05:03 CST --- (In reply to comment #236)
Created attachment 42706 [details] KUSER_SHARED_DATA_18 against -> wine-1.5.18
I can confirm this (unsettlingly heavily) modified patch applies cleanly to wine-1.5.19 (with the patches Gentoo shipped for 1.5.18). Cursory testing shows swtor starting and running similar to under 1.5.8 with previous patch. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 gregor <gregor.binder(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gregor.binder(a)gmx.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Andy Wilkinson <andy(a)wtribe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andy(a)wtribe.com --- Comment #238 from Andy Wilkinson <andy(a)wtribe.com> 2013-01-30 21:30:00 CST --- (In reply to comment #236)
Created attachment 42706 [details] KUSER_SHARED_DATA_18 against -> wine-1.5.18
This patch applies to wine-1.5.22, but SWTOR appears to hang at the loading screen nonetheless. Here's some pretty vanilla wine output. Let me know if you want it run differently: http://pastebin.com/0hfBj0gC -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Alex <alexzk(a)mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexzk(a)mail.ru --- Comment #239 from Alex <alexzk(a)mail.ru> 2013-03-15 14:26:54 CDT --- Game still suffers from pereodic lags. If you will open CPU graph over time on 2nd monitor, you will see that there are "downpeaks" when lagg happens. CPU usage drops from 80% on my machine to 20% and inside game fps drops from 40 to 0-5. Looks like game takes sleep() somewhere atm. So I decided to try 1st patch from here (proof of conecept). It gave me downpeaks like each couple seconds. Dedicated thread (last patch) gives downpeaks each 45 seconds about. So I combined them: dedicated thread + critical section: thread.c: static void update_shared_data_time(void) ->>> void update_shared_data_time(void) and critsection.c extern struct _KUSER_SHARED_DATA *user_shared_data; extern void update_shared_data_time(void); ....... NTSTATUS WINAPI RtlEnterCriticalSection( RTL_CRITICAL_SECTION *crit ) { update_shared_data_time(); That looks much better. I don't see downpeaks last 30 minutes at all. May be somebody smarter can improve idea and put more calls to function somewhere else ? Also it works with 1.5.20 couldn't run with 1.5.25. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 JR <zorael(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zorael(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Forrest Loomis <cybercyst(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cybercyst(a)gmail.com --- Comment #240 from Forrest Loomis <cybercyst(a)gmail.com> 2013-04-09 16:40:08 CDT --- Since wine 1.5.25 I was getting "fixme:dbghelp:elf_search_auxv can't find symbol in module" in the console after I logged in with my username and password and when the loading spinner would lock on the loading screen. With 1.5.24 I could use swtor_fix.exe from this thread http://ubuntuforums.org/showthread.php?t=2097068 along with stock wine to get SW:TOR running up to the character selection screen. After performing a git bisect, I found the change was in this commit: cfec148b8baeb86ee9d775f9cf527b80e043f5a4 by Piotr Caban <piotr(a)codeweavers.com>. Also, reverting the latest git revision with the following command: "git show cfec148b8baeb86ee9d775f9cf527b80e043f5a4 | patch -p1 -R" yields a working wine installation. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #241 from julusp(a)gmail.com 2013-04-10 08:49:58 CDT --- (In reply to comment #240)
Also, reverting the latest git revision with the following command: "git show cfec148b8baeb86ee9d775f9cf527b80e043f5a4 | patch -p1 -R" yields a working wine installation.
If I am reading it correctly, setting msvcp90 to native in winecfg would do after that commit. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #242 from Forrest Loomis <cybercyst(a)gmail.com> 2013-04-10 09:04:19 CDT --- Yeah, I had msvcp90 set to native and it was crashing as well. I have that dll override deleted now and it seems to launch without vcrun2008 from winetricks as well. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #243 from Alex <alexzk(a)mail.ru> 2013-04-10 11:21:12 CDT --- Btw, game is going smoother with that exe as for me than using wine patch. I suggest to run fix as next: wine swtor_fix.exe > /dev/null 2> /dev/null < /dev/null & disown so you don't need to open 2nd console. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 StewVed <stewved(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stewved(a)gmail.com --- Comment #244 from StewVed <stewved(a)gmail.com> 2013-07-18 13:33:06 CDT --- This bug is still here for everyone playing Star Wars: The Old Republic even using the latest Wine (1.6 RC5) Ubuntu 13.04 64-bit using env WINEARCH=win32 because the game needs it, along with: winetricks vcrun2008 d3dx9 msls31 Also the swtor_fix.exe 'patch' thing for this Bug (#29168) my launcher to run the game - to workaround Bug #31186 and also put the password directly into the clipboard on loading the launcher :D (Needs xsel installed) --------------------------- #!/bin/bash cd ~/wines && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine "swtor_fix.exe" & echo -n 'YourPasswordHere' | xsel -i -b & xrandr -s 800x600 cd 'Where You installed the game' && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine launcher.exe xrandr -s 1280x1024 wait killall swtor_fix.exe ----------------------------- Download the game for free from http://www.swtor.com/ - so anyone can test this. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #245 from hash <HASH.DuOrden(a)gmail.com> 2013-07-18 15:29:18 CDT --- (In reply to comment #244)
This bug is still here for everyone playing Star Wars: The Old Republic even using the latest Wine (1.6 RC5)
Ubuntu 13.04 64-bit using env WINEARCH=win32 because the game needs it, along with: winetricks vcrun2008 d3dx9 msls31 Also the swtor_fix.exe 'patch' thing for this Bug (#29168)
Sadly but swtor_fix.exe isn't working for me, it just hangs with "Waiting for tread to end." for eternity not doing anything. Still have to use last wine build with which patches from here still working. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #246 from StewVed <stewved(a)gmail.com> 2013-07-18 15:45:38 CDT --- (In reply to comment #245)
Sadly but swtor_fix.exe isn't working for me, it just hangs with "Waiting for tread to end." for eternity not doing anything. Still have to use last wine build with which patches from here still working.
swtor_fix.exe has to be on a completely seperate thread to the game, and does nothing until SWTOR.exe has been called by the Launcher when you press 'Play'. Methods to try: # Use the single ampersand & at the end of it to make the command on a seperate 'thread'. my all-in-one launcher does that :) # Just use a completely seperate terminal and kick it up in there: Open a new terminal and put in: cd [where it is saved] && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine "swtor_fix.exe" it will then say waiting for threads... then open a NEW terminal and start the launcher in that one. Once logged in and you press play, the launcher closes and calls swtor.exe (with a load of parameters). If you check back with the terminal that has swtor_fix.exe, it should now say a PID found or somert. Please also be aware to run swtor_fix.exe in 32-bit along with the game if you are using a 64-bit OS :D Hope this helps! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #247 from hash <HASH.DuOrden(a)gmail.com> 2013-07-18 16:46:10 CDT --- (In reply to comment #246)
(In reply to comment #245)
swtor_fix.exe has to be on a completely seperate thread to the game, and does nothing until SWTOR.exe has been called by the Launcher when you press 'Play'.
With my script, I made to run games with WINE, swtor_fix.exe is runned at the same time as launcher.exe as a separate process. It echoes in terminal, in my case in log file: Waiting for swtor...
Methods to try: # Use the single ampersand & at the end of it to make the command on a seperate 'thread'. my all-in-one launcher does that :)
# Just use a completely seperate terminal and kick it up in there: Open a new terminal and put in: cd [where it is saved] && env WINEARCH=win32 WINEPREFIX=~/wines/swtor wine "swtor_fix.exe" I don't need that: env WINEARCH=win32 as my linux is 32 bit. it will then say waiting for threads... then open a NEW terminal and start the launcher in that one. Once logged in and you press play, the launcher closes and calls swtor.exe (with a load of parameters). If you check back with the terminal that has swtor_fix.exe, it should now say a PID found or somert. Yes, as swtor.exe starts swtor_fix.exe logs:
Found, PID: 114 Waiting for threads to end.. ^^^^^^^^^^^^^^^^ And thats all it dose. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #248 from StewVed <stewved(a)gmail.com> 2013-07-18 16:55:08 CDT --- (In reply to comment #247)
Yes, as swtor.exe starts swtor_fix.exe logs: ---------------- Found, PID: 114 Waiting for threads to end.. ^^^^^^^^^^^^^^^^ And thats all it dose.
yeah... that is all swtor_fix.exe does in the Terminal until you exit the game. It should allow you to get to the Character selection screen once the game loads up - which can take a few minutes: After pressing 'play' on the Launcher, the game itself takes some 40+ seconds before the game's loading screen appears on my computer; before that, it seems as if nothing is happening at all. After that, it takes about another minute to load up the Character screen. If you see that, swtor_fix.exe has done it's job :) The game should run fine from then on - until you hover your mouse over something that has a popup :D -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #249 from hash <HASH.DuOrden(a)gmail.com> 2013-07-18 17:19:06 CDT --- (In reply to comment #248)
(In reply to comment #247)
Yes, as swtor.exe starts swtor_fix.exe logs: ..... yeah... that is all swtor_fix.exe does in the Terminal until you exit the game. ..... No char selection screen here, I can wait forever and nothing gonna happen.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #250 from StewVed <stewved(a)gmail.com> 2013-07-18 17:39:22 CDT --- (In reply to comment #249)
No char selection screen here, I can wait forever and nothing gonna happen.
Are you using the latest Wine (1.6 RC5 at time of writing) with no extra patches built in it, and a dedicated wineprefix just for SWTOR where you have put in DirectX 9 and VCrun2008? not sure if it works with 1.4.1 for instance... also maybe try the Repair Installation in the Launcher's settings - maybe a file is corrupt. Once, I was fooling with my launcher and didn't have the fix running. it did just as you'd expect - only the loading screen with the little spinning icon spinning so you know it hasn't crashed. Luckily my terminal history had the swtor_fix.exe command in it, so I pressed ctrl+alt+t and pressed the up arrow, then enter (I couldn't see, but that brought up a new terminal, then the up arrow rewrote the last command, then enter executed it) It worked and within a couple of seconds the character screen came up :D If your loading screen icon (Botton-Right) is not spinning, I think I had that when I forgot to put DX9 and vcrun2008 into the SWTOR wineprefix .. maybe that was where I put in msls31 thinking about it - no idea where that came from otherwise... lol. That is the end of my knowledge on SW:TOR, and I sincerely hope you get the game up and running... and the Wine Dev geniuses fix our issues in the future :D -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #251 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-20 18:03:36 CDT --- Hi, I have Gentoo 64 bits and swtor_fix.exe stopped working (meaning it doesn't help - technically it keep being executed without errors) since Wine >= 1.5.25 and the following emul-linux-x86-* (I don't remember which one are required by Wine): app-emulation/emul-linux-x86-baselibs-20130224 app-emulation/emul-linux-x86-soundlibs-20130224 app-emulation/emul-linux-x86-gtklibs-20130224 app-emulation/emul-linux-x86-qtlibs-20130224 app-emulation/emul-linux-x86-sdl-20130224 app-emulation/emul-linux-x86-xlibs-20130224 app-emulation/emul-linux-x86-db-20130224 app-emulation/emul-linux-x86-medialibs-20130224 app-emulation/emul-linux-x86-opengl-20130224 I don't know if it is a regression with Wine itself or with those emul-linux-x86-* since such 20130224 version is required by Wine >= 1.5.25. Wine <= 1.5.24 required the version 20121202 of those libs and in this case swtor_fix.exe worked correctly. For sometime I have been able to stay with Wine 1.5.24 and those lib at 20121202 version by masking the updates, but since few weeks ago other programs on my system started to require the 20130224 version to be updated so it wasn't feasible to keep the old version. Of course since then I couldn't play SWTOR (it wasn't a problem until this evening since I was on temporary break from the game). I am no expert in debugging, but if I can help just tell me what test I have to do. P.S.: I don't know if it helps but Wine >= 1.5.25 and those libs on version 20130224 give me problems also with Lord of the Rings Online: it get frequently terminated without errors. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #252 from Alex <alexzk(a)mail.ru> 2013-07-21 02:38:09 CDT --- Just install PlayOnLinux, it can keep couple wines, for example I have like 10 versions for different games. And yes, last good for swtor is 1.5.25, laters I tried randomly do not work. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #253 from joaopa <jeremielapuree(a)yahoo.fr> 2013-07-21 05:53:51 CDT --- If it is a regression, regression testing would be more profitable than adding more reports. http://wiki.winehq.org/RegressionTesting -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #254 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-21 07:24:50 CDT --- Tried with PlayOnLinux and Wine 1.5.24 and still I can't get to the characters screen. I may assume then that it is not a regression with Wine itself, but it is those app-emulation/emul-linux-x86-*-20130224 that nullify the benefits of swtor_fix.exe. Unfortunately, as I said, other programs beside Wine started to require the 20130224 version of those libs so I cannot stay with the previous version. I have no idea how to debug those app-emulation/emul-linux-x86-* to find the root of the problem. Any idea? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #255 from Alex <alexzk(a)mail.ru> 2013-07-21 09:19:42 CDT --- Maybe try to apply patch directly to wine (see all those above). If it works - than wine has somewhere data protection, so internal exe can't modify shared memory (maybe it creates new memory block for each exe now), if patch doesn't go too - then need search for regression. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #256 from Alex <alexzk(a)mail.ru> 2013-07-21 09:23:58 CDT --- Also did you try 32 bit wine? I had to use chroot 32 to apply patches and compile it, so I assume game won't run using pure 64 bit wine :/ -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #257 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-22 05:16:16 CDT --- I'll try to compile it manually. Still, on PlayOnLinux I did tried to use the pre-compiled 32 bit version of Wine 1.5.24, but it didn't work and the system (meaning out of Gentoo's package manager) Wine 1.5.24 at the time was actually the 64 bit version with 32 bit support (in fact when I originally created the Wine prefix for TOR I had to use export WINEARCH=win32 first, otherwise Wine would have created a 64 prefix like the others I have on my system). I'll let you know when I have finished the compiling test. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #258 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-22 08:35:41 CDT --- I'll try to compile it manually. Still, on PlayOnLinux I did tried to use the pre-compiled 32 bit version of Wine 1.5.24, but it didn't work and the system (meaning out of Gentoo's package manager) Wine 1.5.24 at the time was actually the 64 bit version with 32 bit support (in fact when I originally created the Wine prefix for TOR I had to use export WINEARCH=win32 first, otherwise Wine would have created a 64 prefix like the others I have on my system). I'll let you know when I have finished the compiling test. UPDATE: When I try to apply the patch, I get the following error: patching file dlls/ntdll/Makefile.in Hunk #1 FAILED at 2. 1 out of 1 hunk FAILED -- saving rejects to file dlls/ntdll/Makefile.in.rej patching file dlls/ntdll/thread.c Hunk #3 FAILED at 265. Hunk #4 succeeded at 364 (offset 7 lines). 1 out of 4 hunks FAILED -- saving rejects to file dlls/ntdll/thread.c.rej I tried with both the latest version and 1.5.24 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #259 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-22 08:40:23 CDT --- Sorry for the repeated block of text. When I tried to post a new comment with the patch error, the previous text was already included in the writing area and I thought that the website was making me editing the previous comment by default. P.S.: just for the sake of curriosity, why the patch isn't already included on the Wine source code itself? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #260 from Alex <alexzk(a)mail.ru> 2013-07-22 08:47:40 CDT --- I think latest patch file itself was for 1.5.18 or even below (so it failes with latest changes), you can open it to compare, you will need add 1 static function to thread.c which updates timings into KUSER_SHARED_DATA, add custom thread which will call this function and add creation of this thread to initialization. Not too hard to make it manually if you want for latest wines. Just copy-paste it from tracker to ur sources. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #261 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-23 14:12:16 CDT --- Tried directly with 1.5.18 and I correctly applied the patch and compiled. Tor now correctly launch. I kept the modified 1.5.18 on its own source folder so I can use it for Tor and on the same time still have the latest wine system-wide automatically managed by the package manager for any other program; ergo the best of both worlds. Thanks Alex for your support. The curiosity still remain on why the patch isn't already integrated on Wine; anyone knows? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #262 from Alex <alexzk(a)mail.ru> 2013-07-23 14:52:00 CDT --- I think because patch itself is dumb :/ Nobody wants to update timer's counter using separated thread. Idea must be revised by someone with deep wine's knowledge and he must to proper update when all timings are done (my opinion). My guess was to make exe-debugger, which puts HW breakpoints at this address on access and updates it when SWTOR tries to read it. But well, i'm lazy too :D ----------- Also you can try now just exe with NOT patched 1.5.18 - it should go. And if it is, this means latest wines changed something related to shared memory: 1. No shares - each exe gets own copy. 2. Enchanced Security - exe can't modify "kernel" memory. 3. Most unlikelly - address of the share is changed. As usually while it goes on 1.5.18 - who cares :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #263 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-24 06:41:18 CDT --- I did some test: 1.5.18 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is spinning). - Both KUSER_SHARED_DATA and swtor_fix.exe (used alternatively to each other) solve the problem. 1.5.19 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe solve the problem. 1.5.24 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe solve the problem. 1.5.25 - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is NOT spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe is loaded without errors, but no longer solve the issue. 1.6 (LATEST) - Unpatched and without swtor_fix.exe it cannot run the game as it stay stuck to the loading screen (the cog on the bottom right corner is NOT spinning). - KUSER_SHARED_DATA cannot longer be applied; - swtor_fix.exe is loaded without errors, but no longer solve the issue. As the problems in 1.5.25 and 1.6 appear to be identical, I may guess that no version in between offer any difference; unless of course some official Wine developer come out pointing a specific version that was supposed to work differently, so in that case we can do a regression test. Until the bug is officially fixed, or at least until there is a positive change toward it, to play the game and still keep the latest Wine version system-wide, I suggest to: - Download the source code for Wine <= 1.5.24 (or <= 1.5.18 if you want to use KUSER_SHARED_DATA patch instead of swtor_fix.exe); - Apply the KUSER_SHARED_DATA patch (only if you have chosen the version <= 1.5.18 and you don't want to use swtor_fix.exe); - Either leave the compiled version on its own source code (by NOT issuing 'make install') or go back to the ./configure and add '--prefix=/opt/[whatever directory that doesn't conflict with system-wide wine]') - Make a script (or modify if you already use one) that call the custom Wine version by absolute path (and eventually execute swtor_fix.exe of you opted for that fix). P.S.: as I was posting this it came to my mind that a regression test can be done between 1.5.25 and 1.5.24 to see what is breaking swtor_fix.exe; since it would take a lot of time and since swtor_fix.exe is an unofficial fix anyway, is it worth doing it? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #264 from Alex <alexzk(a)mail.ru> 2013-07-24 09:25:55 CDT --- Well, for the start you could add "printf" to each 2nd line into swtor_fix source and print out everything, every value, every line executed (like debugger). And check/compare where is error coming. It is also possible it will not though. This will mean exe is "sandboxed" against other exes. It will be a start to find changings. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #265 from Dan Kegel <dank(a)kegel.com> 2013-07-24 10:58:24 CDT --- Yes, finding the commit that broke things would probably be illuminating. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #266 from Forrest Loomis <cybercyst(a)gmail.com> 2013-07-24 11:29:00 CDT --- (In reply to comment #265)
Yes, finding the commit that broke things would probably be illuminating.
Guys, please look at comment #240. I did the git bisect and found the commit that was breaking loading for me. Reverting that commit also leads to a SWTOR that will work. Can anyone confirm that? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #267 from Forrest Loomis <cybercyst(a)gmail.com> 2013-07-24 12:18:10 CDT --- (In reply to comment #265)
Yes, finding the commit that broke things would probably be illuminating.
Guys, please look at comment #240. I did the git bisect and found the commit that was breaking loading for me. Reverting that commit also leads to a SWTOR that will work. Can anyone confirm that? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #268 from Alex <alexzk(a)mail.ru> 2013-07-24 12:25:54 CDT --- SWTOR uses vc runtimes, it is possible that it will not work with "built-in" as that commit sets to use. Intresting, maybe this KSHARED_USER_DATA should be done inside those runtimes? :/ Here is that commit: commit cfec148b8baeb86ee9d775f9cf527b80e043f5a4 Author: Piotr Caban <piotr(a)codeweavers.com> Date: Mon Feb 18 10:26:17 2013 +0100 msvcp90: Prefer builtin version. diff --git a/dlls/msvcp90/msvcp90_main.c b/dlls/msvcp90/msvcp90_main.c index cb6377f..7a7aafe 100644 --- a/dlls/msvcp90/msvcp90_main.c +++ b/dlls/msvcp90/msvcp90_main.c @@ -84,8 +84,6 @@ BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) switch (fdwReason) { - case DLL_WINE_PREATTACH: - return FALSE; /* prefer native version */ case DLL_PROCESS_ATTACH: init_cxx_funcs(); init_lockit(); -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #269 from Dan Kegel <dank(a)kegel.com> 2013-07-24 12:26:54 CDT --- Oh, thanks. The commit was http://www.winehq.org/pipermail/wine-cvs/2013-February/093779.html Marco, does setting msvcp90.dll to native (e.g. 'winetricks msvcp90=native') help? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 tonedef <wine(a)causal.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|wine(a)causal.ca | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #270 from Marco Di Fresco <marco.difresco(a)gmail.com> 2013-07-24 16:57:19 CDT --- (In reply to comment #269)
Oh, thanks. The commit was http://www.winehq.org/pipermail/wine-cvs/2013-February/093779.html
Marco, does setting msvcp90.dll to native (e.g. 'winetricks msvcp90=native') help?
Yes it does. I am trying with the latest Wine 1.6 (without KUSER_SHARED_DATA patch, but with swtor_fix.exe) and I can correctly get to the characters screen and login into the game. Thanks. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #271 from Alex <alexzk(a)mail.ru> 2013-07-24 17:29:46 CDT --- wow, wine 1.6.rc5 gives like 3x FPS on fleet compairing to older...cool :) So to recup: swtor_fix.exe AND winetricks msvcp90=native to make it run -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #272 from Alex <alexzk(a)mail.ru> 2013-07-24 17:45:25 CDT --- Okey ...just got BAD sound using 1.6.rc5 ...it's like "shaking" and drop to 5 fps on voidstar wz, possibly it is problem of WZ/game itself. It was such long ago even on windows. I must say with older wine I had to restart game after VS WZ time-to-time because it became too laggy. Can you guys pay attention on it? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #273 from Alex <alexzk(a)mail.ru> 2013-07-24 18:23:23 CDT --- Looks like it is bug in: winealsa+pulseaudio+kmix+usb headset.. even "test sound" button keeps draining memory, switched device from "analog" to "digital" output and works for now :/ So nvm above comment for this one :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 b <bdkelsey(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|bdkelsey(a)hotmail.com | -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Bjoern Bidar <theodorstormgrade(a)googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |theodorstormgrade(a)googlemai | |l.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Alan Jackson <ajackson1972(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson1972(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #274 from eroen <eroen(a)faith.eroen.eu> --- Created attachment 47704 --> http://bugs.winehq.org/attachment.cgi?id=47704 KUSER_SHARED_DATA_18 for >=wine-1.7.1 This issue is still present in current SWTOR with wine-1.7.13. Find attached the earlier patch merged with and regenerated from wine-1.7.13, should apply since wine-1.7.1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 Michael Bond <mikejbond(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mikejbond(a)gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29168 chad.g9(a)hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chad.g9(a)hotmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 roger(a)mailinator.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roger(a)mailinator.com --- Comment #275 from roger(a)mailinator.com --- Is this basically duplicate? https://bugs.winehq.org/show_bug.cgi?id=13398 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #276 from silentz0r <d.misdanitis(a)gmail.com> --- (In reply to roger from comment #275)
Is this basically duplicate?
SWTOR and SWKOTOR are two different games. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 michal <harustiak.michal(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |harustiak.michal(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Summary|Star Wars: The Old Republic |Multiple games and |game client hangs at intro |applications need realtime |splash |updates to KSYSTEM_TIME | |members in | |KUSER_SHARED_DATA (Star | |Wars: The Old Republic game | |client, GO 1.4+ runtime) --- Comment #277 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, I'm refining the summary here since there exist multiple games/applications relying on this "feature" (= collect dupes here). Obviously still present as of Wine 1.7.43 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leonbogaert+winehq(a)gmail.co | |m --- Comment #278 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 38272 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Joe Terwilliger <jolyon(a)nixbox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jolyon(a)nixbox.com --- Comment #279 from Joe Terwilliger <jolyon(a)nixbox.com> --- Created attachment 51589 --> https://bugs.winehq.org/attachment.cgi?id=51589 1.7.44 thread.c patch, OS X compatible Possibly why the preexisting patches have not been accepted is clock_gettime and clock_nanosleep are not directly supported in OS X. I am not sure why the clock_gettime nor the update_time_spec routine since it doesn't seem to be used at all. I've trimmed the fat and converted the sleep / update loop back to nanosleep and this patch is working fine for me on 1.7.31 and 1.7.44 on OS X 10.9.5 and 10.10.3 Patch was tested running Star Wars: The Old Republic latest versions (without swtorfix.exe running, of course.) Could someone test on Linux? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #280 from leonbogaert+winehq(a)gmail.com --- When Ubuntu fixes it's package conflict (https://bugs.launchpad.net/ubuntu/+source/mesa-lts-utopic/+bug/1424059) needed for building wine I'll test it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Qian Hong <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Adam Bolte <abolte(a)systemsaviour.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte(a)systemsaviour.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 EoD <EoD(a)xmw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |EoD(a)xmw.de --- Comment #281 from EoD <EoD(a)xmw.de> --- (In reply to Joe Terwilliger from comment #279)
Created attachment 51589 [details] 1.7.44 thread.c patch, OS X compatible
Possibly why the preexisting patches have not been accepted is clock_gettime and clock_nanosleep are not directly supported in OS X. I am not sure why the clock_gettime nor the update_time_spec routine since it doesn't seem to be used at all.
I've trimmed the fat and converted the sleep / update loop back to nanosleep and this patch is working fine for me on 1.7.31 and 1.7.44 on OS X 10.9.5 and 10.10.3
Patch was tested running Star Wars: The Old Republic latest versions (without swtorfix.exe running, of course.)
Could someone test on Linux?
I tested it on Gentoo with kernel 4.2.5 and wine 1.7.45: It fixes the problem with launching swtor (without swtor_fix.exe)! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #282 from EoD <EoD(a)xmw.de> --- Also the GO test program from bug 38272 does work with the new patch. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #283 from leonbogaert+winehq(a)gmail.com --- I used the patch on HEAD on Ubuntu 14.04 and the Go test program outputs the correct information now. Is there something that can be done to get the patch accepted? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #284 from Andrew Eikum <aeikum(a)codeweavers.com> --- I haven't been following this issue closely. There's a great thread about this here: https://www.winehq.org/pipermail/wine-devel/2012-March/094788.html It sounds like there was no solution found that wouldn't potentially break other applications. wine-staging has some patches in this area that take a different approach. They don't appear to have been submitted upstream. https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-Use... It's not clear to me if those patches are intended fix this issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael(a)fds-team.de --- Comment #285 from Michael Müller <michael(a)fds-team.de> --- The reason no suitable approach was found so far is not that it could break other applications, but instead that it introduces overhead for all apps. This could cause some slowdown. The Staging patch is unrelated to this bug report. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #286 from EoD <EoD(a)xmw.de> --- If it causes only overhead, can't it be possible to enable this feature "on demand" as a fallback? Something like: If the error message has been hit several time, enable the feature. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #287 from Joe Terwilliger <jolyon(a)nixbox.com> --- I can attest that the wine-staging team has implemented some of the kshared data routine, but it is incomplete and does not solve the problem the latest patch here fixed. I have patched it successfully a few times in the wine-staging releases, but it has fallen out of date due to some other extreme restructuring of that source file by the wine-staging team. I fail to see how the latest patch here would significantly impact performance as the Windows subsystem already is apparently performing this same operation at some level, possibly in the network layer? I did experiment in raising the refresh interval wondering if that could improve performance, but it breaks the fix which leads me to believe the original code for this patch is somehow derived directly from the Windows source or compiled code. The only thing I can think of this not being accepted is this is perhaps not the right location for this particular patch. At any rate, I agree that this could be an opt-in performance patch only enabled if specified via winecfg settings or some other switch on wine startup. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #288 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to EoD from comment #286)
If it causes only overhead, can't it be possible to enable this feature "on demand" as a fallback?
Something like: If the error message has been hit several time, enable the feature.
Imho that is the only way to do it "properly", but its much more complicated. There is no error message or specific code path to know if an application depends on it. Its just a memory access, and installing exception handlers and/or write watches seems a bit ugly. (In reply to Joe Terwilliger from comment #287)
I can attest that the wine-staging team has implemented some of the kshared data routine, but it is incomplete and does not solve the problem the latest patch here fixed.
As already mentioned, the couple of Wine Staging patches in the same area are unrelated, and for a different issue.
I have patched it successfully a few times in the wine-staging releases, but it has fallen out of date due to some other extreme restructuring of that source file by the wine-staging team.
Not sure which "extreme restructuring" you mean, but rebasing any of the proposed patches on top of Wine Staging is absolutely no problem. Ask me privately (email or IRC) if you need help with that.
I fail to see how the latest patch here would significantly impact performance as the Windows subsystem already is apparently performing this same operation at some level, possibly in the network layer?
The difference is that Windows doesn't need a separate thread for it, its updated by the kernel directly. On Wine, such a refresh timer would run in each process. Also in those where its absolutely unnecessary, like Wine internal processes (explorer.exe, ... and so on).
I did experiment in raising the refresh interval wondering if that could improve performance, but it breaks the fix which leads me to believe the original code for this patch is somehow derived directly from the Windows source or compiled code.
It works totally different on Windows, there is nothing to "copy" from Windows sources. Please note that the Wine patch submission rules also don't allow to look at Windows sources, so if anybody did that, it would mean that the patch can no longer be accepted.
The only thing I can think of this not being accepted is this is perhaps not the right location for this particular patch.
At any rate, I agree that this could be an opt-in performance patch only enabled if specified via winecfg settings or some other switch on wine startup.
If possible, extra winecfg settings or registry keys should usually avoided. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #289 from Joe Terwilliger <jolyon(a)nixbox.com> --- Thanks Sebastian for clearing that up! The situation regarding this fix has been puzzling many of us for some ~~time~~ years. I honestly have no idea how the source patch for this was derived, I merely cleaned it up and made it workable on OSX. My comment was based on probably incorrect assumptions I came to whilst adjusting the parameters in final tests. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Jellemoisson(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Jellemoisson(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Thomas Kowaliczek <linuxdonald(a)posteo.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linuxdonald(a)posteo.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #290 from Bjoern Bidar <theodorstormgrade(a)googlemail.com> --- Created attachment 54531 --> https://bugs.winehq.org/attachment.cgi?id=54531 updated patch on top of latest wine-staging I updated the patch on top of the latest wine staging patches. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Robert Walker <bob.mt.wya(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya(a)gmail.com --- Comment #291 from Robert Walker <bob.mt.wya(a)gmail.com> --- Created attachment 55748 --> https://bugs.winehq.org/attachment.cgi?id=55748 wine-1.9.19-ntdll_thread_update_shared_data_time.patch I've updated the original patch for Wine 1.9.19 (Staging). Re-factored and tidied up the code a bit to conform to Wine coding conventions. Now has a shift and multiply implementation of the divide by 10000 computation. Well it might be more efficient than gcc - who knows? Using Gentoo with Wine-Staging 1.9.19. I tested the latest build of SWTOR - appears to do the job - as well as swtor_fix.exe anyway ... Gameplay doesn't appear to be too affected by the constant (15ms) thread wakeups!! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 juju96(a)mac.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |juju96(a)mac.com --- Comment #292 from juju96(a)mac.com --- Created attachment 56054 --> https://bugs.winehq.org/attachment.cgi?id=56054 Install Application This is the install application for Star Wars - The Old Republic. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Paul Gofman <gofmanp(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry(a)baikal.ru, | |erich.e.hoover(a)wine-staging | |.com Status|NEW |STAGED Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/ntdll-User_Sha | |red_Data -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #293 from Joe Terwilliger <jolyon(a)nixbox.com> --- Latest Staging 2.8 build fixes the SWTOR client login bug for me on MacOS; SWTORFIX is no longer needed !! Thanks Christian Lackner for the effort! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Sylvain Petreolle <spetreolle(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|spetreolle(a)yahoo.fr | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/ntdll-User_Sha |er/patches/ntdll-User_Share |red_Data |d_Data Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, GO 1.4+ runtime) |client, Blizzard games: | |Diablo III, StarCraft II, | |WoW, Overwatch, GO 1.4+ | |runtime) Keywords| |obfuscation --- Comment #294 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, obviously still present. Updating some fields: * corrected link to Wine-Staging patchset * added more games affected by this to summary Staging has some patch dependencies on https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-User_... * Depends: ntdll-Hide_Wine_Exports * Depends: ntdll-x86_64_ExceptionInformation These are not needed for the apps/games listed here. I've tested/debugged with minimal patchsets from existing tickets and this one against vanilla Wine 3.4 I think the current maintainers of Wine-Staging, Alistair and Zebediah should talk with Alexandre about a feasible solution. A number of major games, especially from Blizzard require this feature to work. People will stick to Wine-Staging to be able to play their games with result that they run all their other stuff (apps) with Wine-Staging too. $ wine --version wine-3.4 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #295 from Bjoern Bidar <theodorstormgrade(a)googlemail.com> --- Since when is this needed for wow? This about the KUSER_SHARED_DATA feature needed by games like swtor. Wow needs the exception fixes that this patch depends on it's current ( older patches didn't depend on this). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #296 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Anastasius Focht from comment #294)
Hello folks,
obviously still present. Updating some fields:
* corrected link to Wine-Staging patchset * added more games affected by this to summary
Staging has some patch dependencies on https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll- User_Shared_Data/definition
* Depends: ntdll-Hide_Wine_Exports * Depends: ntdll-x86_64_ExceptionInformation
These are not needed for the apps/games listed here.
The dependencies are basically to make sure that all patches can be applied/compiled at once, so sometimes patchsets have 'dependencies' that aren't actually necessary.
I've tested/debugged with minimal patchsets from existing tickets and this one against vanilla Wine 3.4
I think the current maintainers of Wine-Staging, Alistair and Zebediah should talk with Alexandre about a feasible solution. A number of major games, especially from Blizzard require this feature to work. People will stick to Wine-Staging to be able to play their games with result that they run all their other stuff (apps) with Wine-Staging too.
It would indeed be nice if someone could come up with a feasible solution to this problem. I doubt that person will be me, however. Besides which there are many other widely-used staging patches that will be much easier to upstream. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, Blizzard games: |client, Blizzard games: |Diablo III, StarCraft II, |32-bit Diablo III, 32-bit |WoW, Overwatch, GO 1.4+ |WoW, Overwatch, GO 1.4+ |runtime) |runtime) --- Comment #297 from Anastasius Focht <focht(a)gmx.net> --- Hello Bjoern, --- quote --- Since when is this needed for wow? This about the KUSER_SHARED_DATA feature needed by games like swtor. Wow needs the exception fixes that this patch depends on it's current ( older patches didn't depend on this). --- quote --- I downloaded multiple Blizzard games: the 64-bit and 32-bit variants if available. For testing I used a 64-bit WINEPREFIX with full install and a helper 32-bit WINEPREFIX with has symlinks to allow testing both versions (32-bit and 64-bit) if present. I should have been more explicit though, the are some differences when 32-bit or 64-bit version is used. Some of Blizzard's major titles/games seem to share parts of the anti-cheat/debugging code. === Overwatch (64-bit): === --- snip --- ./drive_c/Program Files (x86)/Overwatch/Overwatch Launcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/Overwatch/Overwatch.exe: PE32+ executable (GUI) x86-64, for MS Windows --- snip --- NOTE: requires additional patches === StarCraft II (32-bit and 64-bit): === --- snip --- ./drive_c/Program Files (x86)/StarCraft II/Support64/SC2Switcher_x64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/StarCraft II.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/Versions/Base62848/SC2_x64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/Versions/Base62848/SC2.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/StarCraft II/Support/SC2Switcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows --- snip --- --- snip --- $ wine ./StarCraft\ II.exe OnlineService.SSO=true -launch -uid --- snip --- --- snip --- $ wine64 ./Support64/SC2Switcher_x64.exe --- snip --- Correction: SC II seems to work without KUSER_SHARED_DATA patch (runs at least until login screen) -> sorry about that. === Diablo III (32-bit and 64-bit): === --- snip --- ./drive_c/Program Files (x86)/Diablo III/x64/Diablo III64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/Diablo III/Diablo III Launcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/Diablo III/Diablo III.exe: PE32 executable (GUI) Intel 80386, for MS Windows --- snip --- NOTE: requires additional patches --- snip --- $ wine ./Diablo\ III.exe OnlineService.SSO=true -launch -uid diablo3_enus ... 00ff:err:seh:setup_exception_record stack overflow 1188 bytes in thread 00ff eip 7bc9219a esp 00240e8c stack 0x240000-0x241000-0x340000 --- snip --- 32-bit version started working when KUSER_SHARED_DATA patch was applied on top. --- snip --- $ wine64 ./Diablo\ III64.exe OnlineService.SSO=true -launch -uid diablo3_enus ... 0009:err:seh:setup_exception stack overflow 2032 bytes in thread 0009 eip 00007f2e9158fa76 esp 0000000000140e20 stack 0x140000-0x141000-0x240000 --- snip --- === World of Warcraft (32-bit and 64-bit): === --- snip --- ./drive_c/Program Files (x86)/World of Warcraft/Wow-64.exe: PE32+ executable (GUI) x86-64, for MS Windows ./drive_c/Program Files (x86)/World of Warcraft/World of Warcraft Launcher.exe: PE32 executable (GUI) Intel 80386, for MS Windows ./drive_c/Program Files (x86)/World of Warcraft/Wow.exe: PE32 executable (GUI) Intel 80386, for MS Windows --- snip --- NOTE: requires additional patches --- snip --- $ wine ./Wow.exe # hangs in live-loop (most recent update 2018-03-26T18:35:44Z|7.3.5.26124 ) or stack-overflow (before weekend) --- snip --- 32-bit version started working when KUSER_SHARED_DATA patch was applied on top. --- snip --- $ wine64 ./Wow-64.exe ... 0009:err:seh:setup_exception stack overflow 1920 bytes in thread 0009 eip 00007f6e1b5e5a76 esp 0000000000140e90 stack 0x140000-0x141000-0x240000 --- snip --- I cherry-picked single patches from Wine-Staging without dependencies to figure out the minimum set and drop unneeded dependencies. The 64-bit exception code patch alone which is listed as dependency didn't resolve the issue for the 64-bit versions. I'm correcting the summary to explicitly refer to 32-bit Diablo III, 32-bit WoW and Overwatch until further results. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fincer89(a)hotmail.com --- Comment #298 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 44849 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fabienmoal(a)wanadoo.fr --- Comment #299 from Matteo Bruni <matteo.mystral(a)gmail.com> --- *** Bug 44861 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 zzzzzyzz(a)hacari.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz(a)hacari.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lmnet89(a)gmail.com --- Comment #300 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 45905 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Andrey <andrey.gursky(a)e-mail.ua> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.gursky(a)e-mail.ua -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #301 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Sniper Elite 4 is affected. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 pattietreutel <katyaberezyaka(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 auxsvr(a)yahoo.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |auxsvr(a)yahoo.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |diego.lazcanoarcos(a)gmail.co | |m --- Comment #302 from Matteo Bruni <matteo.mystral(a)gmail.com> --- *** Bug 47132 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |protel02(a)gmail.com --- Comment #303 from Matteo Bruni <matteo.mystral(a)gmail.com> --- *** Bug 46586 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, Blizzard games: |client, Blizzard games, GO |32-bit Diablo III, 32-bit |1.4+ runtime) |WoW, Overwatch, GO 1.4+ | |runtime) | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 silentz0r <d.misdanitis(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|d.misdanitis(a)gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #304 from Andrey Gusev <andrey.goosev(a)gmail.com> --- Far Cry Primal requires this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 --- Comment #305 from Anastasius Focht <focht(a)gmx.net> --- *** Bug 44438 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple games and |Multiple games and |applications need realtime |applications need realtime |updates to KSYSTEM_TIME |updates to KSYSTEM_TIME |members in |members in |KUSER_SHARED_DATA (Star |KUSER_SHARED_DATA (Star |Wars: The Old Republic game |Wars: The Old Republic game |client, Blizzard games, GO |client, Blizzard games, GO |1.4+ runtime) |1.4+ runtime, Denuvo | |Anti-Tamper x64 #2) --- Comment #306 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, let's keep fingers crossed. Recently, there have been multiple attempts by Rémi Bernon from CodeWeavers to get support for user shared data updates into mainline Wine. It's currently at "v4": https://www.winehq.org/pipermail/wine-devel/2020-April/thread.html#165600 It would make a number of apps/games/protection schemes work that don't depend on fake dlls/syscall thunk patches. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 sxe <sxxe(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|sxxe(a)gmx.de | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a1c46c3806a054c16fab9fd9d83 | |88e55eb473536 Status|STAGED |RESOLVED Component|ntdll |wineserver Resolution|--- |FIXED --- Comment #307 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, this should be fixed by commit https://source.winehq.org/git/wine.git/commitdiff/a1c46c3806a054c16fab9fd9d8... ("server: Add USD support with timestamp updates.") Thanks Rémi. Let's not forget the initial contribution/groundwork by Sebastian, Michael and Andrew from Wine-Staging team. I've tested with Denuvo protected games, such as DOOM 2016 Steam demo that don't require other Wine-Staging patches. They run further now with mainline. $ wine --version wine-5.8-63-g26b26a2e0e Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=29168 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #308 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 5.9. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla