Testbericht unter Linux

Hier kann alles Allgemeine rund um Zusi 3 gefragt und beantwortet werden. Neuigkeiten zum Programm werden hier erscheinen.
Nachricht
Autor
F. Schn.
Beiträge: 4825
Registriert: 24.10.2011 18:58:26

Re: Testbericht unter Linux

#321 Beitrag von F. Schn. »

Normales Zusi-Verhalten, hat nichts mit Wine zu tun: viewtopic.php?p=304319#p304319" target="_blank

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#322 Beitrag von mitropam »

Oha, danke. War mir nicht bewusst, dass ich da mal eine Beta installiert haben soll. Na egal, jetzt funktioniert das Aufgleisen jedenfalls wieder. 8)

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#323 Beitrag von Flo Zille »

Ich kann Proton 4.11-9 wärmstens empfehlen, wenn man eine Vulkan-kompatible Grafikkarte hat. Ich nutze noch die AMD 7870, und unter Ubuntu 19.10, welches Mesa 19.2 mitliefert, kann die Vulkan. Es müssen mesa-vulkan-drivers:amd64 und mesa-vulkan-drivers:i386 installiert sein und man muss vielleicht bei dieser doch recht alten Grafikkarte explizit mit "radeon.si_support=0 amdgpu.si_support=1" (z.B. als Einstellung in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub) booten, um den amdgpu- statt radeonsi-Kerneltreiber zu nutzen. (Vielleicht geht es auch mit dem älteren radeonsi-Treiber? Ich habe schon lange den amdgpu aktiviert, weiß es daher nicht). Testen, ob Vulkan funktioniert, kann man mit den Programmen "vulkaninfo" (zeigt Infos zu unterstützten Vulkan-Features) und "vkcube" (rendert einen sich drehenden Würfel).

Nachdem ich dann in Steam in den Startoptionen von Zusi als Umgebungsvariable festgelegt habe: "PROTON_USE_D9VK=1 %command%", hat das bei mir einen sehr positiven Einfluss auf die Performance gehabt. Vorher (mit dem Standard-Wine-DirectX9-zu-OpenGL-Wrapper) musste ich die Grafikeinstellungen doch ziemlich runterschrauben, um Zusi nutzen zu können, ohne dass die FPS so weit einbrechen, dass praktisch kein Frame mehr ankommt. Jetzt läuft es auf Standard-Grafikeinstellungen außerhalb von Knoten sehr brauchbar, und vielleicht wäre der Genuss auch innerhalb von Knoten wie Köln besser, wenn ich eine halbwegs leistungsstarke CPU hätte oder nicht folgendes "Problem" dazu gekommen wäre:

Nachdem ich mit Proton 4.11-9 per winetricks natives gdiplus, dotnet40 und corefonts installiert hatte (mit mono-wine funktionierte es nicht), habe ich jetzt auch unter Linux die integrierten ZusiDisplays! Die trüben die Performance zwar doch wieder spürbar ein, aber es freut mich. Weil auf Steam schon längere Zeit keine Updates mehr für ZusiDisplay reinkamen, habe ich auch noch die Version 3.3.11.0. Soweit ich es verstehe, wurde ja in einem Update seitdem die Performance verbessert, da bin ich mal gespannt, wie es dann läuft, wenn das Update bei mir eintrudelt. Lustigerweise schlägt der Start von ZusiDisplay.exe (für Standalone-Displays) mittels .NET 4.0 innerhalb von Proton 4.11-9 fehl, weil der Splashscreen eine Exception produziert (System.Threading.ThreadThreadException occured: Parameter is not valid. at System.Drawing.Image.get_FrameDimensionsList() und dann Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object. at MMI.MainForm..ctor(List`1 completeArgs, Authority authority, AuthorityCreationResult result, Boolean isEmbedded)). Mit wine-mono und wine 4.0.2 scheitert es bei dieser Version noch an WPF, aber das dürfte ja durch das ZusiDisplay-Update dann behoben sein.

Edit: Achja, die 2006er Buchfahrpläne funktionieren bei mir unter diesen Umständen nicht, es taucht auch nirgends eine offensichtliche Fehlermeldung auf, aber ich habe auch die .config nicht angepasst, vielleicht liegt es daran. Dafür habe ich ja jetzt Ebula.
Zuletzt geändert von Flo Zille am 29.11.2019 09:07:27, insgesamt 2-mal geändert.

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#324 Beitrag von Flo Zille »

Ich hatte zuletzt noch das Problem, dass gewisse Güterwagen bei mir unter Ubuntu / Proton nicht nur den "üblichen" FPS-Einbruch verursacht haben, sondern Zusi ab einer gewissen Anzahl von Wagen fast zum Erliegen brachten: Es gab dann nur noch alle 30 Sekunden bis mehrere Minuten ein neues Bild (wobei die Spielzeit wohl annähernd in "Realzeit" weitergelaufen ist, mein Zug aber zwischen den Frames nur recht geringe Distanzen zurückgelegt hat, so dass nach 5 oder 10 Minuten der Güterzug und somit das Ruckeln vielleicht vorbei war, mein Zug aber eine entsprechende Verspätung aufgebaut hatte).

Heute habe ich mal "perf record -a -F 500 sleep 5" während eines solchen ausgedehnten Hängers ausgeführt und bemerkt, dass Zusi sehr viel Zeit in dsound.dll verbrachte. Die dsound.dll wurde wohl durch Wine bzw. Proton bereitgestellt. Mittels "winetricks dsound" in meinem Zusi-Proton-Prefix habe ich die originale dsound.dll von Microsoft herunterladen lassen und nun kommt es nicht mehr zum Einfrieren. Da scheint die dsound.dll von Wine wohl etwas mit den vielen Güterwagen-Sounds überfordert gewesen zu sein? Allerdings kommt mir der Sound allgemein jetzt im Vergleich zu vorher doch merklich verzögert vor. In meinen Augen trotzdem eine Verbesserung, da auch Fahrpläne mit ebensolchen Güterwagen fahrbar werden.

Benutzeravatar
Johannes
Beiträge: 2632
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#325 Beitrag von Johannes »

Kannst du die "gewissen Gueterwagen" eingrenzen? Vielleicht kann ich das reproduzieren. (Testfahrplan waere nett.)

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#326 Beitrag von Flo Zille »

Als Testfahrplan nutze ich den Eanos-Testfahrplan von branka, den F. Schn. auf Seite 2 im oben verlinkten Thread geposted hat. Dabei teste ich genau wie von dir beschrieben mit Zug Nr. 12. Genauer auf bestimmte Güterwagen eingrenzen kann ich es momentan nicht, aber ich habe mich anhand einer "dsound-trace"-Logdatei durch den wine-code gewühlt und glaube jetzt zu verstehen, was passiert.

Wine-dsound nutzt wohl einen eigenen "mixthread", der nichts anderes tut, als regelmäßig (bei mir alle 8-12 Millisekunden) die verschiedenen parallel laufenden Soundeffekte zusammenzumixen. Bei mir sieht das dann so aus, wenn es gut läuft (ganz am Anfang die Sekundenangabe jeweils im Abstand von ca. 12ms):
36310.292:0040:trace:dsound:DSOUND_PerformMix (019C46C0)
36310.304:0040:trace:dsound:DSOUND_PerformMix (019C46C0)
36310.316:0040:trace:dsound:DSOUND_PerformMix (019C46C0)
36310.328:0040:trace:dsound:DSOUND_PerformMix (019C46C0)
[..]
Und Zusi erzeugt wohl für alles, was in der Nähe ist und Sounds erzeugt, einen eigenen Soundbuffer, der dann eben durch diesen dsound-mixthread in die Audioausgabe gemixt wird:
36403.845:0033:trace:dsound:DirectSoundDevice_AddBuffer (019C46C0, 01D43FA8)
36403.845:0033:trace:dsound:DirectSoundDevice_AddBuffer buffer count is now 1
36403.852:0033:trace:dsound:DirectSoundDevice_AddBuffer (019C46C0, 01D40398)
36403.852:0033:trace:dsound:DirectSoundDevice_AddBuffer buffer count is now 2
36403.853:0033:trace:dsound:DirectSoundDevice_AddBuffer (019C46C0, 01D40510)
36403.853:0033:trace:dsound:DirectSoundDevice_AddBuffer buffer count is now 3
[..]
Die Zeilen mit (xxx, xxx) bedeuten den Einstieg in die "AddBuffer"-Funktion, die Zeilen mit "buffer count is now x" bedeuten das Ende der Funktion. Das geht dann eine Weile gut, das Hinzufügen dauert wie hier im Log keine Millisekunde, bis ich in die Nähe der vielen Eanos-Güterwagen komme:
36540.957:0033:trace:dsound:DirectSoundDevice_AddBuffer (019C46C0, 02747200)
36541.136:0033:trace:dsound:DirectSoundDevice_AddBuffer buffer count is now 97
36541.428:0033:trace:dsound:DirectSoundDevice_AddBuffer (019C46C0, 02747378)
36551.396:0033:trace:dsound:DirectSoundDevice_AddBuffer buffer count is now 98
[..]
Hier sieht man jetzt, dass das Hinzufügen eines Buffers plötzlich sehr lange dauert, für Buffer 97 mehr als 100ms, und für Buffer 98 sogar 10 Sekunden (= 10-sekündiger Freeze in Zusi).

Die AddBuffer-Funktion fordert ein "buffer_list_lock" im exklusiven Zugriff an (da die buffer-liste verändert werden muss). Das Problem ist jetzt, dass dieses Lock vom ganz oben erwähnten mixthread ebenfalls belegt wird (im "shared"-Zugriff-Modus). Normalerweise ist das kein Problem, da der mixthread nach Beendigung einer Mixrunde das Lock freigibt und wartet, bis die 8-12ms zum Start der nächsten Runde abgelaufen sind, und die AddBuffer-Funktion dann das Lock erhalten kann. Jedoch scheint das Mixen mit ~90 zu behandelnden Buffern mit meiner ollen CPU so lange zu dauern, dass der mixthread nach Beendigung einer Mixrunde sofort die nächste Runde beginnt, also dauert das Mixen wohl um die 12ms oder länger (erste Zeile ist das Ende der vorherigen Mixrunde, zweite Zeile dann Beginn der nächsten):
36551.408:0040:trace:dsound:DSOUND_MixOne total mixed data=441
36551.408:0040:trace:dsound:DSOUND_PerformMix (019C46C0)
[..]
Das Lock wird vom mixthread dazwischen kurz freigegeben und sofort wieder aufgenommen. Und mit der Lockimplementierung gibt es dann wohl eine Race Condition, bei der meistens der mixthread gewinnt, weil wohl der in AddBuffer wartende Thread nicht schnell genug wieder aufgeweckt werden kann, während der mixthread ohne Schlaf durchläuft. So hält der mixthread das Lock dann fast dauerhaft, der neue Buffer kann deshalb nicht bzw. nur mit viel Glück hinzugefügt werden, und Zusi kommt nicht voran. Ein kurzes "Zwangs-Sleep" im mixthread zwischen zwei Runden könnte vielleicht helfen, vielleicht probiere ich das irgendwann mal aus, wenn ich die Kompilierung von dsound.dll hinbekomme. Oder man müsste die Lock-Implementierung ein wenig fairer machen, damit die auf exklusiven Zugriff wartenden Threads nicht wie hier verhungern können (keine neuen "shared"-Zugriffe mehr zulassen, wenn jemand auf exklusiven Zugriff wartet), aber das erscheint mir etwas aufwändig und auch gefährlich.

Es hat sich nämlich gezeigt, dass die originale dsound.dll von Microsoft bei mir ein unschönes Knacksen und auch sonst fehlerhafte Soundeffekte hervorruft.

Edit: Tatsächlich hilft ein simples "Sleep(1);" oben in der while-Schleife von DSOUND_mixthread, um die Freezes zu beseitigen. Der Sound läuft dann meistens problemlos, nur wenn zu viele Soundeffekte gleichzeitig aktiv sind und der mixthread überfordert ist, gibt es hässliche "Soundaussetzer". Das ist aber besser als das Einfrieren. Am besten reporte ich wohl einen wine-Bug für dsound. Das Verhalten ("Soundruckeln in Altenbeken neben einem Güterzug") ist mir sogar noch aus der Zusi-Demo unter wine bekannt, keine Ahnung warum es da auch so funktionierte.

Noch ein Edit: Ich habe versucht, die Situation mit einem einfachen dsound-Testprogramm, das nach und nach immer mehr Soundbuffer anlegt, nachzustellen, um damit einen Bug bei wine melden zu können. Interessanterweise "gewinnt" in diesem Testprogramm der Hauptthread (der gerade die AddBuffer-Funktion ausführt und dort auf den mixthread warten muss) relativ regelmäßig und häufig das Rennen gegen den mixthread, es kommt auch mit Überforderung des mixthreads maximal zu kurzen Verzögerungen im Bereich weniger hundert Millisekunden, das Freeze-Problem tritt also nicht in der Intensität wie mit Zusi auf. Ich bin gerade am grübeln, welche Umstände bestimmen könnten, ob der mixthread schneller ist. Das wäre auch eine mögliche Erklärung, warum die Demo bei mir auch nicht die Freezes hatte, wenn diese Umstände dort nicht gegeben sind. Aber dass es oft schwer nachzuvollziehen ist, wie die Sache ausgeht und woran das liegt, das liegt wohl in der Natur von Race Conditions…
Zuletzt geändert von Flo Zille am 30.12.2019 15:22:10, insgesamt 2-mal geändert.

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#327 Beitrag von Flo Zille »

Jetzt hatte ich das Projekt "Reproducer entwickeln, um einen Wine-Bug zu reporten" schon fast beerdigt gehabt, weil bei meinem Reproducer ständig (scheinbar zufällig und anders als in Zusi) der Thread das Rennen gewonnen hat, durch den es nicht zu Freezes kommt, als ich doch noch einen Gedankenblitz hatte. Und jetzt tritt das Problem tatsächlich auch bei meinem Reproducer auf:
Added buffer No. 1, took 0.009040 sec!
Added buffer No. 2, took 0.017091 sec!
Added buffer No. 3, took 0.012650 sec!
[..]
Added buffer No. 74, took 0.026838 sec!
Added buffer No. 75, took 0.074412 sec!
Added buffer No. 76, took 0.199616 sec!
Added buffer No. 77, took 0.718821 sec!
Added buffer No. 78, took 0.161324 sec!
Added buffer No. 79, took 2.369803 sec!
Added buffer No. 80, took 4.995385 sec!
Added buffer No. 81, took 1.480235 sec!
Added buffer No. 82, took 2.944519 sec!
[Hier passierte jetzt länger nichts, bis ich abgebrochen habe]
Der Trick ist, dass man "esync" aktivieren muss, um das unerwünschte Verhalten zu erzeugen. Esync ist ein von Valve entwickelter Wine-Patch, der so Aufrufe wie "WaitForSingleObject" stark beschleunigt, und der standardmäßig aktiv ist, wenn man Spiele innerhalb von Steam startet. Wenn man Programme in einem Terminal über das von Steam mitgelieferte Wine startet jedoch nicht, und das hatte ich bei meinem Reproducer immer so gemacht. Jetzt habe ich den Reproducer mal mit WINEESYNC=1 aufgerufen, und tatsächlich… er hat dann das gleiche Problem wie Zusi.

Der mixthread nutzt zwischen zwei Mixrunden, während deren er das buffer_list_lock für sich beansprucht, eben genau die WaitForSingleObject-Funktion. Mit aktiviertem esync ist das buffer_list_lock bei mixthread-Überlastung also nur für sehr kurze Zeit freigegeben, weil das WaitForSingleObject so schnell geht. Mit der "klassischen" Wine-Implementierung ohne esync von WaitForSingleObject dauert das auch bei mixthread-Überlastung so lange (es ist wohl Interprozesskommunikation involviert), dass der Haupt-Thread von Zusi oder meinem Reproducer ausreichend Zeit hat, um sich das buffer_list_lock zu schnappen und dann den neuen Soundbuffer in die Liste einzutragen, so dass das Freeze-Problem dann nicht auftritt.

Jetzt habe ich dann wohl die Möglichkeit, einen Bug zu reporten, falls es sich auch mit dem offiziellen wine-staging so nachstellen lässt (nur im Moment keine Zeit dafür). Esync ist nur in Proton und in wine-staging enthalten, nicht im "Haupt-Wine-Zweig". Allerdings ist es ja trotzdem irgendwie auch ein Bug in dsound im Haupt-Wine-Zweig, da das korrekte Funktionieren von dsound davon abhängt, dass WaitForSingleObject "lange" dauert, was ja wohl keine Garantie ist. Mal sehen.

Edit 13. Januar: Zebediah Figura hat sich dankenswerterweise meines Bug-Reports angenommen und einen Patch erstellt, der das Zusi-Dauer-Freeze-Problem mit Valves esync oder fsync behebt. Der Patch wurde bereits in die jüngste Release-Candidate-Version von wine-staging aufgenommen, welches auch einen deutlich schnelleren Soundmixer enthält als das "richtige" wine. Die dsound.dll von wine-staging, kopiert in das ./dist/lib/wine-Verzeichnis von Proton 4.11, und mit aktiviertem d9vk und einem Kernel mit den Valve-fsync-Patches (ich nutze XanMod), ermöglicht jetzt recht gute Zusiperformance unter Linux. gdiplus und diverse dotnet-Versionen habe ich nach wie vor mittels winetricks installiert. Nur damit Zusidisplay auch standalone startet ("GetActiveTcpConnections"-Fehler), habe ich eine kleine Ergänzung für die iphlpapi.dll implementieren müssen, damit sie IPv6 in GetTcpTable (möglicherweise sogar fast korrekt, vermutlich aber eher ziemlich falsch) unterstützt. Mit etwas Glück schaffen es die meisten dieser Sachen von selbst früher oder später in offizielle Wine-, Kernel- oder Proton-Versionen.
Zuletzt geändert von Flo Zille am 13.01.2020 13:31:48, insgesamt 2-mal geändert.

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#328 Beitrag von Flo Zille »

Das Wine-dsound-Problem, das dazu führte, dass sich mit aktiviertem esync (derzeit nur in wine-staging und Proton enthalten) oder fsync (nur in Proton enthalten und erfordert Spezialkernel) Zusi bei zu vielen Güterwagen in der Nähe komplett aufgehängt hat, weil der Mixthread die "lockfreie Phase" denk esync/fsync dann zu schnell durchläuft, ist jetzt offiziell behoben. Der Patch wird dann absehbar in ca. 10 Tagen mit wine 5.2 ausgeliefert. Es kommt dann in Situationen mit sehr vielen gleichzeitigen Soundeffekten zwar je nach CPU-Power noch zu (teils ggf. massiven) Rucklern, aber keinen dauerhaften Hängern. Sobald Valve eine Proton-Version herausbringt, die auf wine 5.2 oder neuer basiert, müsste es dann auch damit klappen.

Einen Bug im radv AMD-Vulkan-Treiber habe ich endlich gefunden und für Mesa 20.0 und die nächste stabile 19.3.x-Version gefixt. Der hat dazu geführt, dass das Laden von Objekten in Situationen, in denen sehr viele Objekte gleichzeitig geladen werden müssen (z.B. beim Kassel-Rbf-Benchmarktest), teilweise fehlgeschlagen ist und dann auch nicht mehr "nachgeholt" wurde, es haben dann einfach zahlreiche Objekte gefehlt.

Leider gab es in den vergangenen Wochen einen Rückschritt bei dxvk. Teile des Führerstands blinken jetzt von Frame zu Frame abwechselnd zwischen der richtigen Ansicht und veralteten Pixeln hin und her, seit dxvk Front- und Backbuffer einsetzt statt wie vorher nur einer Art "einzelner shared Backbuffer". Ich vermute, dass ein Bug in Zusi dahinter steckt. Soweit ich das erkennen kann, wird von Zusi nicht in jedem Frame das gesamte Bild neu gezeichnet, sondern nur die Teile des Bildes, die sich geändert haben. Das ist mit dem genutzten DISCARD SwapEffect eigentlich in DirectX nicht zulässig, scheint aber unter Windows mit fast allen Treibern trotzdem zu funktionieren, jedenfalls solange man kein "echtes" DirectX-Fullscreen nutzt. Es wird hoffentlich einen Zusi-spezifischen Workaround dafür in dxvk geben, was aber noch dauern kann. Bis dahin habe ich bei mir einfach den Buffer-Flipping-Code in dxvk auskommentiert.


Und die Performance im Kassel Rbf Benchmarktest habe ich mal zwischen Windows und Linux im Vollbildmodus verglichen. Ich habe einen Phenom II X4 955, also eine bereits mehr als 10 Jahre alte Vierkerner-CPU. Die Singlecore-Leistung aktueller etwas hochwertiger CPUs dürfte wohl so ungefähr doppelt so hoch sein. Die GPU scheint sich sehr zu langweilen und ist daher wohl weniger relevant, aber es ist eine HD 7870.

Windows: 18 FPS
Linux: 20 FPS (mit Proton 4.11, dxvk, fsync und ein paar anderen Tweaks)

Das Rendering der 3D-Welt scheint also schon ziemlich gut zu laufen, wobei die DirectX9-Treiber von AMD unter Windows eher grottig sein sollen und es daher gar nicht so selten ist, dass ältere D3D9-Spiele unter dxvk mit Vulkan unter Linux besser laufen als unter Windows. Problem bei der Performance ist aber die Zusidisplay-Integration. Zusi und ZusiDisplay kommunizieren über Pipes und es wird auch asynchrones IO genutzt, und das ist unter wine ziemlich uneffizient umgesetzt. Unter anderem wohl, weil asynchrones IO unter Linux bis kürzlich ziemlich grottig bzw. fast nicht existent war. Das läuft daher alles über einen dritten Prozess (wineserver), der zwischen Zusi und ZusiDisplay vermittelt und sich um die asynchronen Vorgänge kümmert, dabei aber natürlich deutlich weniger effizient ist als ein Betriebssystemkern. Ich experimentiere gerade ein wenig mit io_uring und unix domain sockets als Pipe-Transportmittel. Damit könnte man möglicherweise den wineserver stark entlasten und diese Aufgaben durch den Linux-Kernel übernehmen lassen. Falls ich es irgendwann mal ans Laufen bringe, verbessert das die Performance vielleicht. Allerdings dürfte es schwer werden, den Patch auf die für eine offizielle Aufnahme in wine nötige Qualität zu bringen. Vielleicht hilft es auch nichts und die schlechtere Performance mit wine liegt an etwas anderem, was z.B. ZusiDisplay nutzt. Mal sehen.

Benutzeravatar
Johannes
Beiträge: 2632
Registriert: 14.03.2009 22:36:06
Aktuelle Projekte: Zusitools (http://git.io/zusitools)

Re: Testbericht unter Linux

#329 Beitrag von Johannes »

Moin,

vielen Dank fuer dein Engagement fuer Zusi auf Linux!

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#330 Beitrag von mitropam »

Das hört sich ja alles sehr interessant an. Mir ist allerdings noch nicht ganz klar, ob man mit Proton dann die Steam-Version spielt oder das "normale" Zusi.

Schick wäre es, wenn jemand ein kleines HowTo, so ähnlich wie die "Hinweise zur Benutzung von Zusi 3 mit Linux und Wine" (viewtopic.php?f=47&t=10844" target="_blank) erstellen würde.

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#331 Beitrag von Flo Zille »

Ich selbst habe nur die Steam-Version und kann Proton daher auch nur mit der Steam-Version testen. Proton ist letztlich "nur" eine Zusammenstellung von wine mit einigen Valve-Patches (insbesondere esync und fsync) sowie "vorinstallierten" Extras wie dxvk und wine-mono.

Es gibt ein wohl ganz nützliches Programm namens "Lutris". Damit sollte es möglich sein, auch ohne Steam eine Proton-ähnliche Variante von wine auf relativ einfachem Weg zu nutzen. Wenn man dort als "Runner" wine und z.B. "lutris-5.2" als wine-Version auswählt, kann man in den Optionen jedenfalls auch dxvk und esync per Klick aktivieren und deaktivieren. Falls Alwin nichts dagegen hat, könnten wir vielleicht Informationen dazu im ZusiWiki zusammentragen, wobei ich mich wie gesagt auf die Steam-Version beschränken müsste.

Wobei dxvk ab Version 1.5.2 das Problem hat, dass viele Führerstände flackern, da hilft dann auch die höhere Framerate nichts. In den erweiterten Lutris-Runner-Einstellungen kann man die dxvk-Version aber offenbar auf 1.5.1 setzen. d9vk für DirectX9 wird dann nicht benötigt, denn ab dxvk 1.5 ist d9vk bereits mit integriert. Das Flacker-Problem will sich der Autor noch genauer anschauen, er hat aber viel zu tun.

Es gibt auch wieder gute Neuigkeiten:
- In der nächsten wine-Version 5.3, die in einer Woche erscheinen sollte, ist ein Patch von mir enthalten, der in gdiplus.dll die Funktionen GdipSaveAdd und GdipSaveAddImage nachrüstet. Damit werden auch Buchfahrpläne mit mehreren Seiten korrekt erzeugt und es ist hoffentlich künftig nicht mehr nötig, per winetricks die gdiplus von Microsoft zu installieren.
- Ebenfalls in wine 5.3 hat Alex Henrie die Funktion GetTcp6Table ordentlich in iphlpapi.dll implementiert. Damit kann ZusiDisplay nun manuell gestartet werden, ohne dass es mit der "GetActiveTcpConnections"-Fehlermeldung (oder so) gleich wieder abstürzt.

Außerdem habe ich nun auch wine-mono überreden können, die integrierten Displays anzuzeigen. Dafür muss ein Patch von Zebediah Figura angewendet und noch etwas erweitert werden (leider führt das, wie im Kommentar dort angedeutet, zu einem memory leak, da muss wohl eine Lösung gefunden werden bevor es offiziell in wine integriert werden kann), und einen Bug in mono muss man auch noch umschiffen. Außerdem besteht jetzt noch das Problem, dass manche Displays (z.B. das links im 612er) sich nur sehr selten aktualisieren und ich konnte noch nicht herausfinden, wie ich wine dazu überreden kann, etwas weniger schmallippig zu den im ZusiDisplay-Prozess auftretenden Problemen zu sein. Bis auf weiteres ist es also vermutlich sinnvoller, wie bisher mittels winetricks dotnet45 (oder welche Version auch immer nötig war) von Microsoft zu installieren. Bei der Microsoft-Variante wird offenbar ein portabler, in C# implementierter Threadpool für die IO-Callbacks genutzt, statt den Win32 Threadpool zu nutzen, der in wine derzeit noch keine IO-callbacks unterstützt. Daher ist dafür auch kein wine-Patch nötig.


Meine io_uring-Experimente für bessere named pipes und somit bessere ZusiDisplay-Integration in Wine haben gefühlt schon eine Verbesserung gebracht, allerdings haben sie mit Kernel 5.4 auch zu starken memory leaks geführt, die selbst nach Beendigung aller Zusi- und wine-Prozesse nicht verschwanden. Es waren immer noch zahlreiche ring-Kernel-Threads aktiv, was nur durch Neustarts zu beheben war. Daran weiterzubasteln habe ich erstmal verschoben, zumal die Änderungen wohl sowieso wenig Chancen haben dürften, im offiziellen wine zu landen. Ich lade den aktuellen Stand demnächst mal auf github und schaue mir das in ein paar Kernelversionen nochmal an. Nach jedem vierten Test wegen vollem RAM neu starten zu müssen ist etwas nervig.

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#332 Beitrag von mitropam »

Das klingt ja alles sehr spannend und vielversprechend. Danke, dass Du Dich damit so intensiv beschäftigst. Im Moment kann ich allerdings noch nicht erkennen, wie ich das bei mir umsetzen kann.

Flo Zille
Beiträge: 84
Registriert: 15.05.2018 09:06:32

Re: Testbericht unter Linux

#333 Beitrag von Flo Zille »

Ich habe jetzt selbst das Programm "Lutris" aus anderen Gründen ausprobiert und halte es für sehr praktisch, wobei man erstmal herausfinden muss, wofür jeweils die Buttons sind. Da ich die Stick-Version von Zusi nicht habe, kann ich aber nur allgemein sagen: Mit Lutris kann man über die "Runners"-Liste (Zahnradsymbol oben in der Leiste links) eine aktuelle Wine-Version mit einigen Extras, wie sie auch in Proton von Valve enthalten sind, beziehen. Einfach in der "Runners"-Liste auf den grünen Button neben "Wine" klicken und zum Beispiel lutris-5.6.2 (oder welche Version eben gerade aktuell ist) anhaken, dann wird die Version heruntergeladen. Dann kann man über das Plus-Symbol oben im Lutris-Hauptfenster Zusi als neues Spiel hinzufügen und im erscheinenden Dialog die gerade installierte wine-Version wählen. Man muss dort dann noch einstellen, wo man Zusi installiert hat und wo die ZusiSim.exe liegt. Unter "Runner Options" in den Lutris-Spieleinstellungen für Zusi kann man dann esync für eine bessere Performance (und leider möglicherweise auch Freezes bei Nutzung von Standalone-Zusidisplay) aktivieren. Wenn man einen 32-Bit-Vulkantreiber installiert hat, unter Ubuntu z.B. für AMD und Intel das Paket mesa-vulkan-drivers:i386, sollte man dort auch dxvk aktivieren. Das verbessert bei mir die Performance ebenfalls. In den "Runner Options" kann man sogar die dxvk-Version auswählen, die genutzt werden soll, man ist also flexibler und schneller auf dem neuesten Stand als mit Steam und Proton, wo man von Valve fertig geschnürte Gesamtpakete aus älterem wine+dxvk+wine-mono+… vorgesetzt bekommt. Dafür hat man mit Lutris etwas mehr Frickelei.

Es gibt auch weitere gute Neuigkeiten:
  • dxvk ab Version 1.6 enthält jetzt meinen Zusi-Workaround, die Führerstände flackern also mit dieser Version nicht mehr
  • der hauptsächlich an DirectX9 für dxvk arbeitende Entwickler Joshua Ashton hat kürzlich auch einige Optimierungen an der Vulkan-Implementierung in wine für 32-Bit-Anwendungen wie Zusi+dxvk vorgenommen, wodurch die Performance noch geringfügig besser werden sollte
  • wine 5.7, das wahrscheinlich Ende der Woche erscheint, enthält dank Zebediah Figura und Jacek Caban jetzt eine Implementierung von StartThreadpoolIo und verwandten Funktionen. Das ist ein wichtiger Schritt hin zur Zusidisplayintegration mit wine-mono statt dotnet und somit ohne Frickelei, zumindest mit Proton. Allerdings ist in mono noch ein (hoffentlich recht simpler) Bug. Ich schaue mir das nach dem wine-Release mal an. Carsten hat allerdings ja auch angekündigt, dass sich bei der aktuellen Beta etwas mit der Zusidisplayintegration ändern wird.
Hoffentlich wird es also bald möglich sein, das Aerosoft-Zusi unter Linux vollständig und nur durch Aktivierung von Steamplay/Proton mit relativ guter Performance nutzen zu können, wenn man 32-bit-Vulkantreiber installiert hat. Mir sind derzeit keine anderen Probleme außer den hier genannten bekannt. Die Performance von Zusi selbst könnte dann wie schon erwähnt je nach Situation und Hardware sogar besser sein als unter Windows, jedoch wird die Performance der Zusidisplay-Integration wohl auf absehbare Zeit schlechter bleiben, falls die Zusi-Beta da nicht sehr große Änderungen bei der Wahl der ICP mit sich bringt. Die Named Pipes in wine sind einfach vom Prinzip her nicht sehr effizient umgesetzt.
Zuletzt geändert von Flo Zille am 22.04.2020 11:06:14, insgesamt 1-mal geändert.

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#334 Beitrag von mitropam »

Die neue Version von ZusiDisplay lässt sich unter wine nicht mehr starten:

Bild

Der dazugehörige backtrace:

Code: Alles auswählen

Unhandled exception: page fault on read access to 0x00000040 in 32-bit code (0x643c95da).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:643c95da ESP:0032fa88 EBP:0032faf8 EFLAGS:00010202(  R- --  I   - - - )
 EAX:00000000 EBX:015bf0c8 ECX:0032fa28 EDX:0032faf8
 ESI:00000040 EDI:015bf078
Stack dump:
0x0032fa88:  0032fd00 0032faec 643dacb0 643da418
0x0032fa98:  7bd45264 00000043 00000000 00000000
0x0032faa8:  0032fbe0 7bcce5ef 0032fb6c 000000d8
0x0032fab8:  00000000 00110000 00000000 00000000
0x0032fac8:  00000040 7bcf6620 00000002 015b9d98
0x0032fad8:  00000001 00000000 00110064 00110060
Backtrace:
=>0 0x643c95da EntryPoint+0xffffffff() in mscoree (0x0032faf8)
  1 0x7b452109 call_process_entry+0x18() in kernel32 (0x0032ff48)
  2 0x7b4525a4 start_process+0x153() in kernel32 (0x0032ffd8)
  3 0x7b45211a __wine_start_process+0x9() in kernel32 (0x0032ffec)
0x643c95da EntryPoint+0xffffffff in mscoree: movzwl	0x0(%esi),%eax
Modules:
Module	Address			Debug info	Name (90 modules)
PE	  330000-  350000	Deferred        aclui
PE	  400000- 109a000	Deferred        zusidisplay
PE	62800000-628b8000	Deferred        usp10
PE	643c0000-6448f000	Dwarf           mscoree
PE	64b40000-64b77000	Deferred        shcore
PE	65200000-6568d000	Deferred        ole32
PE	65980000-6599a000	Deferred        version
PE	66400000-66603000	Deferred        dbghelp
PE	68c40000-68d3f000	Deferred        shlwapi
PE	6a300000-6a655000	Deferred        oleaut32
PE	6a900000-6aa7e000	Deferred        setupapi
PE	6b4c0000-6b657000	Deferred        wininet
PE	6c0c0000-6c0fa000	Deferred        imm32
PE	6dbc0000-6dc09000	Deferred        mpr
PE	6e8c0000-6ec87000	Deferred        comctl32
PE	6fdc0000-6ff90000	Deferred        rpcrt4
PE	71340000-7158e000	Deferred        urlmon
ELF	79656000-7b000000	Deferred        libicudata.so.60
PE	7b000000-7b276000	Deferred        kernelbase
ELF	7b400000-7b66b000	Dwarf           kernel32<elf>
  \-PE	7b420000-7b66b000	\               kernel32
ELF	7bc00000-7bd7b000	Deferred        ntdll<elf>
  \-PE	7bc30000-7bd7b000	\               ntdll
ELF	7c000000-7c004000	Deferred        <wine-loader>
ELF	7ce28000-7ce6e000	Deferred        libxslt.so.1
ELF	7cea5000-7cee1000	Deferred        ws2_32<elf>
  \-PE	7ceb0000-7cee1000	\               ws2_32
ELF	7cee1000-7ceff000	Deferred        libgcc_s.so.1
ELF	7d085000-7d0b1000	Deferred        liblzma.so.5
ELF	7d0b1000-7d270000	Deferred        libicuuc.so.60
ELF	7d270000-7d45d000	Deferred        libxml2.so.2
ELF	7d476000-7d47b000	Deferred        cp1258.so
ELF	7d47b000-7d47f000	Deferred        cp1257.so
ELF	7d47f000-7d483000	Deferred        cp1256.so
ELF	7d483000-7d488000	Deferred        cp1255.so
ELF	7d488000-7d48c000	Deferred        cp1254.so
ELF	7d48c000-7d490000	Deferred        cp1253.so
ELF	7d490000-7d494000	Deferred        cp1252.so
ELF	7d494000-7d5b0000	Deferred        msxml3<elf>
  \-PE	7d4d0000-7d5b0000	\               msxml3
ELF	7d5d2000-7d61c000	Deferred        uxtheme<elf>
  \-PE	7d5e0000-7d61c000	\               uxtheme
ELF	7d61c000-7d623000	Deferred        libxfixes.so.3
ELF	7d623000-7d62f000	Deferred        libxcursor.so.1
ELF	7d631000-7d635000	Deferred        cp1251.so
ELF	7d635000-7d639000	Deferred        cp1250.so
ELF	7d773000-7d7a5000	Deferred        libexpat.so.1
ELF	7d7a5000-7d7f0000	Deferred        libfontconfig.so.1
ELF	7d7f0000-7d80f000	Deferred        libz.so.1
ELF	7d80f000-7d849000	Deferred        libpng16.so.16
ELF	7d849000-7d906000	Deferred        libfreetype.so.6
ELF	7d906000-7d919000	Deferred        libxi.so.6
ELF	7d919000-7d91d000	Deferred        libxcomposite.so.1
ELF	7d91d000-7d92a000	Deferred        libxrandr.so.2
ELF	7d92a000-7d936000	Deferred        libxrender.so.1
ELF	7da36000-7da51000	Deferred        libbsd.so.0
ELF	7da51000-7da7d000	Deferred        libxcb.so.1
ELF	7da7d000-7dbc7000	Deferred        libx11.so.6
ELF	7dbc7000-7dc81000	Deferred        winex11<elf>
  \-PE	7dbf0000-7dc81000	\               winex11
ELF	7dca3000-7dcaa000	Deferred        libxxf86vm.so.1
ELF	7dcaa000-7dcae000	Deferred        libxinerama.so.1
ELF	7dcae000-7dcb5000	Deferred        libxdmcp.so.6
ELF	7dcb5000-7dcca000	Deferred        libxext.so.6
ELF	7dcca000-7dcf0000	Deferred        libncurses.so.5
ELF	7dd27000-7e75a000	Deferred        shell32<elf>
  \-PE	7dd60000-7e75a000	\               shell32
ELF	7e75a000-7e990000	Deferred        user32<elf>
  \-PE	7e780000-7e990000	\               user32
ELF	7e990000-7eae6000	Deferred        gdi32<elf>
  \-PE	7e9b0000-7eae6000	\               gdi32
ELF	7eae6000-7ebfe000	Deferred        ucrtbase<elf>
  \-PE	7eb20000-7ebfe000	\               ucrtbase
ELF	7ebfe000-7ec80000	Deferred        advapi32<elf>
  \-PE	7ec10000-7ec80000	\               advapi32
ELF	7ee80000-7ee94000	Deferred        libnss_files.so.2
ELF	7ee94000-7eeaf000	Deferred        libnsl.so.1
ELF	7eeaf000-7eebd000	Deferred        libnss_nis.so.2
ELF	7eebd000-7eec7000	Deferred        libnss_compat.so.2
ELF	7eec7000-7efc9000	Deferred        libm.so.6
ELF	7efc9000-7efec000	Deferred        libtinfo.so.5
ELF	7efec000-7f000000	Deferred        wow64cpu<elf>
  \-PE	7eff0000-7f000000	\               wow64cpu
ELF	f7be2000-f7bec000	Deferred        librt.so.1
ELF	f7bee000-f7bf3000	Deferred        libdl.so.2
ELF	f7bf3000-f7dcf000	Deferred        libc.so.6
ELF	f7dcf000-f7dee000	Deferred        libpthread.so.0
ELF	f7e21000-f7e25000	Deferred        libxau.so.6
ELF	f7e25000-f7fbf000	Dwarf           libwine.so.1
ELF	f7fc1000-f7fe9000	Deferred        ld-linux.so.2
Threads:
process  tid      prio (all id:s are in hex)
00000008 ZusiSim.exe
	["Z:\usr\local\Zusi\Zusi3\ZusiSim.exe"]
	0000008f    0
	0000008e    0
	0000008d    0
	0000008c    0
	0000008a    1
	00000089    1
	00000088    1
	00000087    1
	00000086    1
	00000085    1
	00000084    1
	00000083    1
	00000082    1
	00000081    1
	00000073    0
	00000072    0
	00000070    0
	0000006f    0
	0000006e    0
	0000006d    0
	0000006c    0
	0000006b    0
	0000006a    0
	00000069    0
	00000068    0
	00000067    0
	00000066    0
	00000065   -1
	00000064    0
	00000063    0
	00000062    0
	00000061    0
	00000060   -1
	0000005f   -1
	0000005e    0
	0000005d    0
	0000005c    0
	0000005b    0
	0000005a    0
	00000059    0
	00000058    0
	00000057    0
	00000056    0
	00000055    0
	00000054    0
	00000053    0
	00000052    0
	00000051    0
	00000050    0
	0000004f    0
	0000004e    0
	00000034   15
	00000033    0
	00000032   15
	00000031    0
	00000030    0
	0000002d   -1
	0000002c    0
	0000002b    0
	0000002a    0
	00000009    0
0000000e services.exe
	00000046    0
	00000023    0
	0000001c    0
	00000015    0
	00000010    0
	0000000f    0
00000011 plugplay.exe
	00000019    0
	00000018    0
	00000012    0
00000013 explorer.exe
	00000029    0
	00000028    0
	00000027    0
	00000014    0
0000001a winedevice.exe
	00000020    0
	0000001f    0
	0000001e    0
	0000001d    0
	0000001b    0
00000021 winedevice.exe
	00000026    0
	00000025    0
	00000024    0
	00000022    0
00000044 rpcss.exe
	0000004b    0
	0000004a    0
	00000049    0
	00000048    0
	00000047    0
	00000045    0
00000090 (D) Z:\usr\local\Zusi\Zusi3\_Tools\ZusiDisplay\ZusiDisplay.exe
	["Z:\usr\local\Zusi\Zusi3\_Tools\ZusiDisplay\ZusiDisplay.exe"]
	00000094    0
	00000091    0 <==
00000095 explorer.exe
	00000099    0
	00000098    0
	00000097    0
	00000096    0
System information:
    Wine build: wine-5.6 (Staging)
    Platform: i386 (WOW64)
    Version: Windows XP
    Host system: Linux
    Host version: 4.15.0-96-generic
?(

Benutzeravatar
Michael Springer
Beiträge: 2555
Registriert: 24.06.2002 16:22:44
Wohnort: Schwäbisch Gmünd

Re: Testbericht unter Linux

#335 Beitrag von Michael Springer »

Vorletzte Zeile: Windows XP
Ist doch schon die Erklärung warum

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#336 Beitrag von mitropam »

Dachte ich auch erst, aber mit Win7 ists genauso:

Code: Alles auswählen

Unhandled exception: page fault on read access to 0x00000040 in 32-bit code (0x643c95da).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:643c95da ESP:0032fa88 EBP:0032faf8 EFLAGS:00010202(  R- --  I   - - - )
 EAX:00000000 EBX:015b7660 ECX:0032fa28 EDX:0032faf8
 ESI:00000040 EDI:015b75e8
Stack dump:
0x0032fa88:  0032fd00 0032faec 643dacb0 643da418
0x0032fa98:  7bd452be 00000070 00000000 00000000
0x0032faa8:  0032fbe0 7bcce5ef 0032fb6c 000000d8
0x0032fab8:  00000000 00110000 00000000 00000000
0x0032fac8:  00000040 7bcf6620 00000002 015b75e8
0x0032fad8:  00000003 00000000 00110064 00110060
Backtrace:
=>0 0x643c95da EntryPoint+0xffffffff() in mscoree (0x0032faf8)
  1 0x7b452109 call_process_entry+0x18() in kernel32 (0x0032ff48)
  2 0x7b4525a4 start_process+0x153() in kernel32 (0x0032ffd8)
  3 0x7b45211a __wine_start_process+0x9() in kernel32 (0x0032ffec)
0x643c95da EntryPoint+0xffffffff in mscoree: movzwl	0x0(%esi),%eax
Modules:
Module	Address			Debug info	Name (88 modules)
PE	  330000-  350000	Deferred        aclui
PE	  400000- 109a000	Deferred        zusidisplay
PE	62800000-628b8000	Deferred        usp10
PE	643c0000-6448f000	Dwarf           mscoree
PE	64b40000-64b77000	Deferred        shcore
PE	65200000-6568d000	Deferred        ole32
PE	65980000-6599a000	Deferred        version
PE	66400000-66603000	Deferred        dbghelp
PE	68c40000-68d3f000	Deferred        shlwapi
PE	6a300000-6a655000	Deferred        oleaut32
PE	6a900000-6aa7e000	Deferred        setupapi
PE	6b4c0000-6b657000	Deferred        wininet
PE	6c0c0000-6c0fa000	Deferred        imm32
PE	6dbc0000-6dc09000	Deferred        mpr
PE	6e8c0000-6ec87000	Deferred        comctl32
PE	6fdc0000-6ff90000	Deferred        rpcrt4
PE	71340000-7158e000	Deferred        urlmon
ELF	79656000-7b000000	Deferred        libicudata.so.60
PE	7b000000-7b276000	Deferred        kernelbase
ELF	7b400000-7b66b000	Dwarf           kernel32<elf>
  \-PE	7b420000-7b66b000	\               kernel32
ELF	7bc00000-7bd7b000	Deferred        ntdll<elf>
  \-PE	7bc30000-7bd7b000	\               ntdll
ELF	7c000000-7c004000	Deferred        <wine-loader>
ELF	7ce0b000-7ce51000	Deferred        libxslt.so.1
ELF	7d10e000-7d2cd000	Deferred        libicuuc.so.60
ELF	7d2cd000-7d4ba000	Deferred        libxml2.so.2
ELF	7d547000-7d583000	Deferred        ws2_32<elf>
  \-PE	7d550000-7d583000	\               ws2_32
ELF	7d583000-7d5a1000	Deferred        libgcc_s.so.1
ELF	7d5a1000-7d5cd000	Deferred        liblzma.so.5
ELF	7d5e6000-7d5eb000	Deferred        cp1258.so
ELF	7d5eb000-7d5ef000	Deferred        cp1257.so
ELF	7d5ef000-7d5f3000	Deferred        cp1256.so
ELF	7d5f3000-7d5f8000	Deferred        cp1255.so
ELF	7d5f8000-7d5fc000	Deferred        cp1254.so
ELF	7d5fc000-7d600000	Deferred        cp1253.so
ELF	7d600000-7d604000	Deferred        cp1252.so
ELF	7d604000-7d720000	Deferred        msxml3<elf>
  \-PE	7d640000-7d720000	\               msxml3
ELF	7d742000-7d78c000	Deferred        uxtheme<elf>
  \-PE	7d750000-7d78c000	\               uxtheme
ELF	7d78c000-7d793000	Deferred        libxfixes.so.3
ELF	7d793000-7d79f000	Deferred        libxcursor.so.1
ELF	7d7a1000-7d7a5000	Deferred        cp1251.so
ELF	7d7a5000-7d7a9000	Deferred        cp1250.so
ELF	7d8e1000-7d913000	Deferred        libexpat.so.1
ELF	7d913000-7d95e000	Deferred        libfontconfig.so.1
ELF	7d95e000-7d97d000	Deferred        libz.so.1
ELF	7d97d000-7d9b7000	Deferred        libpng16.so.16
ELF	7d9b7000-7da74000	Deferred        libfreetype.so.6
ELF	7da74000-7da87000	Deferred        libxi.so.6
ELF	7da87000-7da8b000	Deferred        libxcomposite.so.1
ELF	7da8b000-7da98000	Deferred        libxrandr.so.2
ELF	7da98000-7daa4000	Deferred        libxrender.so.1
ELF	7daa4000-7daab000	Deferred        libxxf86vm.so.1
ELF	7daab000-7daaf000	Deferred        libxinerama.so.1
ELF	7daaf000-7daca000	Deferred        libbsd.so.0
ELF	7daca000-7daf6000	Deferred        libxcb.so.1
ELF	7daf6000-7dc40000	Deferred        libx11.so.6
ELF	7dc77000-7dd31000	Deferred        winex11<elf>
  \-PE	7dca0000-7dd31000	\               winex11
ELF	7dd31000-7e764000	Deferred        shell32<elf>
  \-PE	7dd60000-7e764000	\               shell32
ELF	7e764000-7e99a000	Deferred        user32<elf>
  \-PE	7e790000-7e99a000	\               user32
ELF	7e99a000-7eaf0000	Deferred        gdi32<elf>
  \-PE	7e9c0000-7eaf0000	\               gdi32
ELF	7eaf0000-7ec08000	Deferred        ucrtbase<elf>
  \-PE	7eb20000-7ec08000	\               ucrtbase
ELF	7ec08000-7ec8a000	Deferred        advapi32<elf>
  \-PE	7ec20000-7ec8a000	\               advapi32
ELF	7ec8a000-7ec9e000	Deferred        libnss_files.so.2
ELF	7ec9e000-7ecb9000	Deferred        libnsl.so.1
ELF	7ecb9000-7ecc7000	Deferred        libnss_nis.so.2
ELF	7eec7000-7efc9000	Deferred        libm.so.6
ELF	7efcc000-7efd3000	Deferred        libxdmcp.so.6
ELF	7efd3000-7efd7000	Deferred        libxau.so.6
ELF	7efd7000-7efec000	Deferred        libxext.so.6
ELF	7efec000-7f000000	Deferred        wow64cpu<elf>
  \-PE	7eff0000-7f000000	\               wow64cpu
ELF	f7bd3000-f7bd8000	Deferred        libdl.so.2
ELF	f7bd8000-f7db4000	Deferred        libc.so.6
ELF	f7db4000-f7dd3000	Deferred        libpthread.so.0
ELF	f7dd6000-f7de0000	Deferred        libnss_compat.so.2
ELF	f7e00000-f7e0a000	Deferred        librt.so.1
ELF	f7e0a000-f7fa4000	Dwarf           libwine.so.1
ELF	f7fa6000-f7fce000	Deferred        ld-linux.so.2
Threads:
process  tid      prio (all id:s are in hex)
00000008 ZusiSim.exe
	["Z:\usr\local\Zusi\Zusi3\ZusiSim.exe"]
	00000036    0
	00000035    0
	00000034   15
	00000033    0
	00000032   15
	00000031    0
	00000030    0
	0000002d   -1
	0000002c    0
	0000002b    0
	0000002a    0
	00000009    0
0000000e services.exe
	00000023    0
	0000001c    0
	00000015    0
	00000010    0
	0000000f    0
00000011 plugplay.exe
	00000019    0
	00000018    0
	00000012    0
00000013 explorer.exe
	00000029    0
	00000028    0
	00000027    0
	00000014    0
0000001a winedevice.exe
	00000020    0
	0000001f    0
	0000001e    0
	0000001d    0
	0000001b    0
00000021 winedevice.exe
	00000026    0
	00000025    0
	00000024    0
	00000022    0
00000037 (D) Z:\usr\local\Zusi\Zusi3\_Tools\ZusiDisplay\ZusiDisplay.exe
	["Z:\usr\local\Zusi\Zusi3\_Tools\ZusiDisplay\ZusiDisplay.exe"  -pipeInfo -pipeName=ZusiDisplayTypen]
	0000003b    0
	00000038    0 <==
0000003c explorer.exe
	00000040    0
	0000003f    0
	0000003e    0
	0000003d    0
System information:
    Wine build: wine-5.6 (Staging)
    Platform: i386 (WOW64)
    Version: Windows 7
    Host system: Linux
    Host version: 4.15.0-96-generic

F. Schn.
Beiträge: 4825
Registriert: 24.10.2011 18:58:26

Re: Testbericht unter Linux

#337 Beitrag von F. Schn. »

Welche "Neue Version"?

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#338 Beitrag von mitropam »

"Neue Version" stimmt nicht ganz, aber beim letzten Update steht
ZusiSim.exe : 3.3.7.2
- Ä Funktion integriertes ZusiDisplay geändert

F. Schn.
Beiträge: 4825
Registriert: 24.10.2011 18:58:26

Re: Testbericht unter Linux

#339 Beitrag von F. Schn. »

Also es geht gar nicht um einen Absturz von ZD sondern von Zusi selbst

mitropam
Beiträge: 120
Registriert: 01.10.2015 21:10:08

Re: Testbericht unter Linux

#340 Beitrag von mitropam »

Nö, die Fehlermeldung lautet doch "Im Programm ZusiDisplay.exe traten schwerwiegende Fehler auf .."
Zusi selbst funktioniert noch. Allerdings kann man kein Display mehr starten.

Antworten