WineHQ
Wine Forums

Board index » WineHQ » Wine Help




 Page 1 of 1 [ 17 posts ] 



 
Author Message
 Post Posted: Sun Oct 28, 2018 10:19 am 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
Hello,

ill try to be short, but the topic is big.

1.
Since wine.3.19 we cant play it anymore due to ioctl errors.
Code:
0019mountmgr:harddisk_ioctl Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)
0019mountmgr:harddisk_ioctl Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)


Star Citizen is working under wine-3.18 but after last night release of 3.19 there is this error.
In the wine patch notes we find a lot about changed I/O, so we may need a patch to solve this as its related to wine.
The last good working wine version was 3.18-284 or something, the one before release.

This is a big problem because we can not go on researching the other big problem with Star Citizen as it is this:

2.
The launcher wont install the game.
The launcher is downloading a basepack in .p4k format but does not install anything, download the remaining gamefiles or patch.
We cant identify the error, because there is none. The launcher just said its all ok but its not.
To play it we use a copy of the game from a windows installation.

So the launcher can not install or verify the gamefiles.
My big question is about the xdelta encoder, do we need futher dependencies installed to make it work ?
We think it is something on the wine side.
"We" is the Linux Users Group at Star Citizen, some people have begun the debugging but there is no result yet.

TLDR: Please help us fixing the ioctl errors with wine-3.19 so we can have an "actual" wine to test on.

Cheers, Raw ^^


Top 
 Post Posted: Sun Oct 28, 2018 5:41 pm 
Offline
Level 4
Level 4

Joined: Thu Dec 24, 2009 11:00 am
Posts: 160
It's unlikely that ioctl message means anything, I see mentions of it going back years and I think it's always been safe to ignore.

It would probably be more useful to get at least a basic log from 3.18 and 3.19 if one works and one doesn't: https://wiki.winehq.org/FAQ#How_can_I_g ... tput.29.3F


Top 
 Post Posted: Mon Oct 29, 2018 7:05 am 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
ok, here is the output of 3.19
https://pastebin.com/TEVjs2i4

and here is 3.18
https://pastebin.com/SZq15B6r

Note, its a new prefix with only corefonts, no dx* at all, using wine-staging, but vanilla had similar results.
319 was stuck after the ioctl error (access=0) and i canceled it with strg-c.
318 was loading up to the menu screen, ive cut the paste to match the maximum size but it gets far over that point onto playability.

Obviously you have been right as the ioctl error is in both logs present.

Any suggestions are welcome ^^


Top 
 Post Posted: Mon Oct 29, 2018 1:47 pm 
Offline
Level 12
Level 12
User avatar

Joined: Sat Oct 16, 2010 7:40 pm
Posts: 2325
Location: Cambridge
rawfox wrote:

Any suggestions are welcome ^^


There is nothing leaping out at me in those terminal logs.

You'll probably need to run a Wine Regression Test.

Bob


Top 
 Post Posted: Mon Oct 29, 2018 3:13 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
You are the best Bob i ever saw.
Mentor me a bit, i can get there.
Its not clear to me, where all the commits are ?!
It was from the very last devel patch before release of 3.19, where can i get the SHA1 from that patch to revert my source ?
Is there any database where i can just grab a hash tag for 3.18-284 i.e. ?

Ill read into regressions and report back.

Thanks for your support \m/


Top 
 Post Posted: Mon Oct 29, 2018 3:48 pm 
Offline
Level 12
Level 12
User avatar

Joined: Sat Oct 16, 2010 7:40 pm
Posts: 2325
Location: Cambridge
rawfox wrote:
You are the best Bob i ever saw.
Mentor me a bit, i can get there.
Its not clear to me, where all the commits are ?!
It was from the very last devel patch before release of 3.19, where can i get the SHA1 from that patch to revert my source ?
Is there any database where i can just grab a hash tag for 3.18-284 i.e. ?

Ill read into regressions and report back.

Thanks for your support \m/


In the root of the checkout'd Wine Git source, you can type:
Code:
diff wine-3.19~2 wine-3.19~1 > wine-3.19_revert.patch

which will get the diff from the commit, prior to the actual commit, for the wine-3.19 release.

The tilde traverses parent Git commits by index value.
So wine-3.19~0 is the Wine 3.19 release.

To reverse a patch:
Code:
git diff apply -R wine-3.19_revert.patch


Not sure what you mean by 3.18-284??
Shortened Git hashes are typically 5 characters long (not 3!!)
Standard Git hashes are typically 40 hexadecimal digits long, i.e. a full SHA-1 hash.

You can find the full hash, from a shortened hash, with something like:
Code:
git log --pretty=oneline | egrep '^.....'

Where .... is your 5 character shortened hash value.

Have done the regression test?
That should leave your Git HEAD at the offending / breaking commit.
It should also display the full SHA-1 hash and log message for this Git commit.

Bob


Top 
 Post Posted: Mon Oct 29, 2018 6:24 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
I need to work in there, this is new to me, i can barely handle git.

Quote:
Not sure what you mean by 3.18-284??

When i get the latest build from wine developers git with git pull, it has a new SHA1 with every change, but also a new version number.
Im not sure if the last commit was version 3.18-284 but it was the last commit before 3.19 released.

So i will first try to get the sources back to there and read more into regressions.
No, not done a regression test now as i dont see the whole picture yet, but ill learn it.

Atm its confusing, when 3.19~0 presents 3.19, what is 3.19~1 and 3.19~2 ?!
Dang "The tilde traverses parent Git commits by index value"
So 3.19~1 is the step BEFORE release right ?
~2 is 2 steps back .. k get it, reporting back, thank you ^^



Reading more, learning more, thanks for heads up, im gonna eat it all.


Top 
 Post Posted: Mon Oct 29, 2018 6:35 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
deleted


Top 
 Post Posted: Wed Oct 31, 2018 2:55 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
The patch that broke it was this
https://github.com/wine-mirror/wine/com ... afc81cfc40

its the first commit were Star Citizen wont load.

This commit before was the last one were Star Citizen would run with
https://github.com/wine-mirror/wine/com ... edef2a04aa

What now ?

edit:
Well, now i set those functions stub again, WaitOnAdress, WakeByAddressAll and WakeByAdressSingle.
dlls/kernelbase/kernelbase.spec

While thats working, i dont know exacly what these functions do or if it break something else, but for now, SC is working again with 3.19 .
Ill make a patch for my SC buddies, they are hard nagging the installer problem.

Nontheless, whats the futher way, now that i identified the implementation of the WaitOnAddress functions as a problem for SC running ?


Top 
 Post Posted: Wed Oct 31, 2018 3:43 pm 
Offline
Level 12
Level 12
User avatar

Joined: Sat Oct 16, 2010 7:40 pm
Posts: 2325
Location: Cambridge
rawfox wrote:
...

What now ?



@rawfox

Nice detective work... 8)

The next step is get a Wine terminal log, from Star Citizen, with vanilla Wine 3.19:
Code:
export WINEDEBUG=+timestamp,+tid,+kernelbase

Plus the same log with the offending patch(es) reverted.

Then file a Wine bug report on the WineHQ Bugzilla...
Give your links (or values) for the good and bad commits as well, obviously.
I probably wouldn't select kernelbase as the component, at this time.
At least until your Wine terminal log file is checked over.

Daniel Lehman knows what he's doing...
The problem may be a deadlock, caused by this API call.
This could be because of some other Windows API call, which is now uncovered, that Wine doesn't implement...
Or a bug in the Star Citizen installer / launcher...

Bob


Top 
 Post Posted: Wed Oct 31, 2018 5:27 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
Okay, thanks for your feedback.
Ya, just stub it out again after its implemented is not a wise solution but i know nothing from the wine sources, so that is over my horizon ^^
Life is gonna eating me over the weekend, ill do it next week, get all the shambles together and throw it to Bugzilla.
Im just a nurse, not a codemonkey anymore :)

Thanks a ton, Bob.

Go get StarCitizen, join LUG@SC https://robertsspaceindustries.com/spec ... munity/LUG


Top 
 Post Posted: Sat Nov 03, 2018 7:07 am 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
For later reference, setting the Wake* functions stub results in bad working wine, tasks hang on exit.
Exclusively stubout WaitOnAddress() makes it working good enuff.

Patch is here
https://pastebin.com/9zNBB83T


Top 
 Post Posted: Mon Nov 05, 2018 3:28 am 
Offline
Newbie
Newbie

Joined: Mon Nov 05, 2018 2:57 am
Posts: 1
I have been trying to explore this problem further by attempting to launch star citizen in both 3.18-staging and 3.19-staging with the following WINEDEBUG settings:
Code:
fixme+all,trace+all,trace-heap,+relay

I'll put my relay excludes at the bottom of this post.

Under wine 3.19 staging, a thread that is started and later hangs produces this log snippet:
Code:
1242.417:008a:0091:Call ntdll.RtlWakeAddressAll(4a5b6010) ret=1442ac33b
0091: select( flags=2, cookie=67c8f7cc, timeout=0, prev_apc=0000, result={}, data={KEYED_EVENT_RELEASE,handle=0014,key=4a5b6010} )
0091: select() = 0 { timeout=1d4708c1630f852 (+0.0000000), call={APC_NONE}, apc_handle=0000 }
0091: select( flags=2, cookie=67c8f7cc, timeout=0, prev_apc=0000, result={}, data={KEYED_EVENT_RELEASE,handle=0014,key=4a5b6010} )
0091: select() = TIMEOUT { timeout=1d4708c1630fc8a (+0.0000000), call={APC_NONE}, apc_handle=0000 }
1242.418:008a:0091:Ret  ntdll.RtlWakeAddressAll() retval=00000102 ret=1442ac33b


Where as under wine 3.18 staging (which works), the same thread, in the same place produces this log snippet:
Code:
5559.096:00b0:00b3:Call ntdll.RtlWakeAllConditionVariable(4a579030) ret=1442d4322
00b3: select( flags=2, cookie=4aa7f7cc, timeout=infinite, prev_apc=0000, result={}, data={KEYED_EVENT_RELEASE,handle=0014,key=4a579030} )
00b3: select() = 0 { timeout=infinite, call={APC_NONE}, apc_handle=0000 }
5559.096:00b0:00b3:Ret  ntdll.RtlWakeAllConditionVariable() retval=00000000 ret=1442d4322


I can not figure out why the 2 versions use different functions. I expected to see a "stub" log in the older version!
While I've been programming primarily in C and also Java, for the last 20+ years, I am new to wine debugging, and have only spent about 1 year of that in Win32 programming.
Ideally, I'm trying to explore the possibility of using the old RtlWakeAllConditionVariable (and friends) instead of the newly implemented counter parts - or at least understand why one works and the other does not.
If someone could point me in the right direction here, I would really appreciate it.
I identified the threads by tracing CreateThread calls after the "StarCitizen.exe" sub process is spawned. I should also admit that I am identifying the location in the thread by the surrounding activity ... an exception, followed by a bunch of SRWLock activity, some Virtual Memory activity the calls logged above followed by a SetThreadPriorityBoost. They also occur at the same function point in the thread relative to the thread start. I think that is a pretty good method, but understand that it is not "bullet-proof" :)

For those who are interested, here are my RelayExcludes:
Quote:
ntdll.RtlEnterCriticalSection;ntdll.RtlTryEnterCriticalSection;ntdll.RtlLeaveCriticalSection;kernel32.48;kernel32.49;kernel32.94;kernel32.95;kernel32.96;kernel32.97;kernel32.98;kernel32.TlsGetValue;kernel32.TlsSetValue;kernel32.FlsGetValue;
kernel32.FlsSetValue;kernel32.SetLastError;KERNEL32.GetWindowsDirectoryW;KERNEL32.SetCurrentDirectoryW;advapi32.RegSetValueExW;advapi32.RegCreateKeyExW;advapi32.RegCloseKey;ucrtbase.memcmp;ucrtbase.malloc;ucrtbase.free;
ntdll.RtlAllocateHeap;ntdll.RtlFreeHeap;KERNEL32.lstrcmpA;KERNEL32.LocalAlloc;ntdll.RtlReAllocateHeap;ucrtbase.memcpy;ucrtbase.memmove;ucrtbase.isspace;ucrtbase.memchr;ucrtbase._dtest;ucrtbase.memset;ucrtbase.realloc;
ucrtbase.memset;KERNEL32.GetLocaleInfoA;KERNEL32.GetLocaleInfoW;ntdll.RtlReleaseSRWLockExclusive;ntdll.RtlAcquireSRWLockExclusive;ntdll.RtlReleaseSRWLockShared;ntdll.RtlAcquireSRWLockShared;ucrtbase.floorf;
user32.GetKeyState;ucrtbase.ceilf;ucrtbase._lrotl;ucrtbase.round;ucrtbase._lrotr


Top 
 Post Posted: Mon Nov 05, 2018 10:09 am 
Offline
Level 12
Level 12
User avatar

Joined: Sat Oct 16, 2010 7:40 pm
Posts: 2325
Location: Cambridge
@Tool,

Nice detective work. 8)
I would speculate that the game is using a fallback path to call RtlWakeAddressAll(), or something similar.
But I haven't dug into this area of the Wine codebase at all...

New Wine code paths that introduce process deadlocks, are not good! :cry:

Wine Developers rarely read these forum threads...
But the WineHQ Bugzilla is pretty active - for "well defined" bugs, like this one!
So someone really needs to file a bug report though!

Bob


Top 
 Post Posted: Mon Nov 05, 2018 5:32 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
@Tool

https://bugs.winehq.org/show_bug.cgi?id=46099

Go add your Spaghetti there, im just a nurse, we need a doc ^^


Top 
 Post Posted: Sun Dec 02, 2018 6:09 pm 
Offline
Level 2
Level 2
User avatar

Joined: Tue Oct 05, 2010 10:59 am
Posts: 30
Thanks for your advise, Bob.

The bug is solved and i hope it gets approved into wine-staging or in best case into wine itself.
Thats out of my hand but im excited about the flow of these things :)

Cheers, raw^^


Top 
 Post Posted: Sun Dec 02, 2018 8:51 pm 
Offline
Level 12
Level 12
User avatar

Joined: Sat Oct 16, 2010 7:40 pm
Posts: 2325
Location: Cambridge
@rawfox

No worries.

OT
Hopefully I'll check out the game (Star Citizen) at some point...
Though I am rather addicted to Fallout 4 at the moment. 8)
So much so, that I plan to cobble in Faudio support to my Gentoo wine builds...
Plus sound effect volume isn't based on distance and the odd machine gun turret can cause sound to totally drop out...
Pulseaudio also tends to introduce latency issues that cause a bit of audio crackling as well... :(

Bob


Top 
Display posts from previous:  Sort by  
 
 Page 1 of 1 [ 17 posts ] 




Board index » WineHQ » Wine Help


Who is online

Users browsing this forum: Google [Bot] and 19 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: