NEPMD-Startprobleme

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Antworten
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

NEPMD-Startprobleme

Beitrag von MKH »

Hallo zusammen,

ich habe vor kurzem die aktuelle Version von NEPMD installiert. Wenn ich den Editor starte, friert mir ab und zu das System ein. Ich kann das Problem allerdings nicht reproduzieren. Am ehesten tritt das Problem unmittelbar nach dem Systemstart auf. Hier sogar fast immer. Ohne die Erweiterungen lässt sich EPM wie gewohnt starten.

Gibt es vielleicht eine LOG-Datei, in die man reinschauen könnten? POPUPLOG.OS2 gibt leider nichts aus.
Hat jemand ähnliche Probleme?

Hier läuft ArcaOS 5.06

Vielen Dank,
Michael
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Kannst du Mal dein System mit nur einem Kern starten?
Die einfachste Lösung hierzu ist /MAXCPU:1 dem ACPI.PSD hinzuzufügen.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Welche Version ist denn installiert? Aktuell ist 1.23.

Zu mehreren Kernen: Das wäre das EPM-Problem, das hauptsächlich beim Scrollen von Dateien mit langen Zeilen auftritt. Bei NEPMD ist dazu eine .cmd-Datei dabei, die auch bei der Installation ausgeführt wird. Sie markiert \os2\apps\epm.exe (nur diese erforderlich) für Einzelkernbetrieb.

Doch noch 'ne Idee: Benenn mal myepm\bin\NEPMD.INI um. Sie wird dann beim nächsten EPM-Start neu erzeugt. Manchmal steht dort Müll drin. (Die nächsten Schritte wären dann die Debug-Ausgaben zu aktivieren, wobei man vorher den Fehler schon einigermaßen eingegrenzt haben sollte.)
Andreas Schnellbacher
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Danke für eure Antworten.

Mit nur einem Prozessorkern lässt sich NEPMD zuverlässig starten. Das Löschen der INI-Datei hat leider nicht zum Erfolg geführt. Kann es sein, dass die besagte CMD-Datei, zum Markieren für den Einzelkernbetrieb, bei der Installation nicht ausgeführt wurde? Wie kann ich diese nachträglich anwenden?

Installiert ist NEPMD 1.23
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Ich danke Dir für die genauen Angaben. Gut, dass Du schon 1.23 hast. (Nur zur Info: 10 tägliche Kopien der NEPMD.INI werden in %tmp%\nepmd\backup\ini gesichert, seit Version 1.23.)

Was sein kann, das kann ich nicht vorhersehen, hier ist das jedenfalls noch nicht so aufgetreten. ;-) Wie gesagt, ich hatte "nur" die Probleme mit dem Scrollen (Andy Willis wahrscheinlich auch). Das trat nie gleich nach dem Starten auf. Welche Fehler noch alle im Original-EPM stecken, das kann ich nur erahnen (meine Liste ist lang, aber die der Workarounds fast genau so. ;-) )

Die Erkenntnis, dass es mit 1 CPU funktioniert, ist eine gute und das sollten wir dann leicht hinbekommen:

Zunächst wäre es interessant, wie Du schon angedeutet hast, überhaupt abzufragen ob \os2\apps\epm.exe schon bearbeitet wurde. Auch das zeigt die Datei nepmd\netlabs\install\epmsp.cmd an. Starte sie aus einer Befehlszeile heraus. Bei mir sieht das so aus:

Code: Alles auswählen

{0}[F:\APPS\NEPMD\NETLABS\INSTALL] epmsp
Executing: execmode -l -sp C:\OS2\APPS\epm.exe
C:\OS2\APPS\epm.exe runs already in single-processor mode.

{18}[F:\APPS\NEPMD\NETLABS\INSTALL]
execmode.exe ist seit irgendeiner Warp-Version bei jedem System dabei. Deshalb hab ich das genommen. Die .cmd-Datei könnte den Aufruf nur vereinfachen. Das angenehme ist, dass sie auch außerhalb von NEPMD und der Installation funktioniert und zuverlässig die richtige Datei findet. execmode.exe macht die Arbeit und bearbeitet den Header. Details im Dateiheader der .cmd-Datei.
Andreas Schnellbacher
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Hallo Andreas,

ich habe das Script ausgeführt. Auch meine EMP.EXE war bereits für den Einzelprozessorbetrieb konfiguriert.
Leider, muss ich fast schon sagen.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Dann bleibt ja eigentlich nur die DLLs auch noch zu bearbeiten. (Bei mir musste ich das nicht.) Welche das sind, wird in .NEPMD_INFO (letzter Menüpunkt) angezeigt. Die, die am häufigsten gebraucht wird, ist etke603.dll - auch die richtige nehmen.

Wenn Du "execmode" ohne Parameter aufrufst, erhälst Du eine Beschreibung. Unter "EXAMPLE:" sieht man auch die Syntax. Anscheinend werden auch Wildcards unterstützt.

Ich kann mir nicht vorstellen, dass die NEPMD-Dateien, der Loader \os2\epm.exe und die Bibliothek nepmdlib.dll betroffen sind. Die sind sogar für mehrere Kerne kompiliert. Aber vielleicht verträgt sich der Mix ja nicht bei Dir. Ich würd das also zuerst mit den anderen testen,
die bei .NEPMD_INFO unter "EPM runtime modules" aufgelistet werden.
Andreas Schnellbacher
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Die nächste Frage wäre: welchen Kernel genau benutzt du ?

Diesen ?
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#IBM:14.203#@_SMP IBM OS/2 Kernel
Vendor: IBM
Revision: 14.203
File Version: 14.203
Description: _SMP IBM OS/2 Kernel

Einfach in einer Kommandozeile in das Rootdirectory wechseln und "bldlevel os2krnl" eingeben.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Hallo Lars, ein guter Gedanke. Ich denke ständig darüber nach, was beim EPM alles sein könnte. Es passt aber einfach nichts. Dass sich NEPMD anders als EPM verhält, ist klar, weil da auch viel mehr aufwendige Aktionen (z.T. als Workarounds für EPM-Fehler) ausgeführt werden. Natürlich treten dann auch Fehler im Kernel eher zum Vorschein.

Bei mir ist übrigens 14.202 installiert. (Wusste gar nicht, dass ich nicht den aktuellen hab.)

Beim Scrollen und SMP war es relativ einfach: Nachdem eine Datei gefunden war, mit der die Abstürze (einschließlich Eintrag in POPUPOS2.LOG) reproduzierbar waren, konnte ich das ähnlich mit Standard-EPM auch reproduzieren. Außerdem hatte Andy das auch berichtet. Ich hatte vorher sehr lange noch einen Einkernprozessor.
Zuletzt geändert von aschn am Fr 17. Dez 2021, 17:46, insgesamt 1-mal geändert.
Andreas Schnellbacher
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Bei mir ist auch bereits der aktuellste SMP-Kernel 14.203 installiert.

Das Markieren von DLLs für den Einkernbetrieb scheint nicht zu funktionieren. EXECMODE gibt zwar keine Fehlermeldung aus, meldet aber immer "0 Files modified".

Wenn ich etwas mehr Zeit habe muss ich mal herausfinden, was genau ich machen muss, damit NEPMD startet. Ab einem gewissen Zeitpunkt funktioniert der Editor meistens. Unmittelbar nach dem Systemstart praktisch nie.

Vielen Dank einstweilen,
Michael
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

MKH hat geschrieben: Do 16. Dez 2021, 06:20 Das Markieren von DLLs für den Einkernbetrieb scheint nicht zu funktionieren.
So etwas hab ich mir schon gedacht. (Sonst wär das bei mir ja auch nötig gewesen.) Lars wird dazu Genaueres wissen.
Andreas Schnellbacher
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

Was ja schon mal kalr ist, ist dass es mit /MAXCPU=1 keine Probleme gibt. Wie seht das denn mit Hyper-Threading aus? Hast Du das auch deaktiviert? (Das soll bei einigen unerwünschtes Verhalten hervorrufen.)
Andreas Schnellbacher
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Hallo Andreas,

ja, HyperThreading habe ich deaktiviert.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

aschn hat geschrieben: Do 16. Dez 2021, 09:55
MKH hat geschrieben: Do 16. Dez 2021, 06:20 Das Markieren von DLLs für den Einkernbetrieb scheint nicht zu funktionieren.
So etwas hab ich mir schon gedacht. (Sonst wär das bei mir ja auch nötig gewesen.) Lars wird dazu Genaueres wissen.
Ich müsste mich jetzt durch die Doku graben, aber ich vermute, das "marked for single core" bit ist Teil der PTDA (per task data area) Information, also der Info für einen ausgeführten Prozess (im Volksmund: Programm).

Der OS/2 Thread scheduler wird dann, so glaube ich, diese Info nutzen, wenn ein Prozess einen Thread anlegt: ist das bit in der PTDA gesetzt, wird er den Thread auf genau den Core legen, auf den er auch schon alle anderen Threads dieses Prozesses gelegt hat und ihn auch bei jedem Rescheduling immer wieder auf diesen Core legen.

Und dann ergibt es natürlich nur Sinn, ein Executable so zu markieren und nicht (auch) die DLLs, die von diesem Executable geladen werden.

Das alles bedeutet nun aber nicht, dass generell nur noch ein Core in Betrieb wäre, schließlich kann Prozess A ja exclusiv auf Core 1 laufen und zeitgleich Prozess B exklusiv auf Core 2.

Mit /MAXCPU:1 hingegen legt man alle Cores bis auf einen (den BSP, wird auch schon während des Bootes benutzt) tot. Das ist ein großer Unterschied.

Meine Vermutung: irgendwas in OS/2 SMP Handling ist da noch nicht 100% zuverlässig (und das heißt nicht nur:Kernel). Genauer weiß ich es leider auch nicht. Meine Vermutung wäre allerdings das Graphik Subsystem, schließlich ging es ja ursprünglich um Hänger beim schnellen Scrollen (in EPM).
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

erdmann hat geschrieben: Mo 20. Dez 2021, 11:56 ich vermute, das "marked for single core" bit ist Teil der PTDA (per task data area) Information, also der Info für einen ausgeführten Prozess (im Volksmund: Programm).
Ich hab hier stehen: Im Exe-Header nach "LX" suchen und dann 16 B weiter: 0x00 = MP, 0x08 = SP.
erdmann hat geschrieben: Mo 20. Dez 2021, 11:56 Mit /MAXCPU:1 hingegen legt man alle Cores bis auf einen (den BSP, wird auch schon während des Bootes benutzt) tot. Das ist ein großer Unterschied.
Auch für die Anwendung? Ich denke, das betrifft natürlich das System.

Es geht noch weiter, schönes Beispiel: VPC.EXE (Virtual PC 5.1). Läuft noch brauchbar auf Einkern-CPUs, aber trappt auf Mehrkern-CPUs. Lässt sich nicht mit den beiden Werkzeugen auf SP umstellen, vermutlich kommen die mit dem von Win32 portierten Programm und dessen Header nicht zurecht. Umgestellt auf /MAXCPU=1. Ergebnis: läuft, aber es gibt häufige Aussetzer. Etwas mit der Maus zu ziehen ist ein Geduldsspiel. Kein Vergleich zur Einkern-CPU.
erdmann hat geschrieben: Mo 20. Dez 2021, 11:56 Meine Vermutung: irgendwas in OS/2 SMP Handling ist da noch nicht 100% zuverlässig (und das heißt nicht nur:Kernel). Genauer weiß ich es leider auch nicht. Meine Vermutung wäre allerdings das Graphik Subsystem, schließlich ging es ja ursprünglich um Hänger beim schnellen Scrollen (in EPM).
Interesssant. Klar, beim Problem mit dem Scrollen ist mit großer Sicherheit der Grafiktreiber beteiligt (GRADD.SYS?).

Bei Michael gibt es keine Einträge in POPUPLOG.OS2 und wahscheinlich wird auch kein Eintrag nach EPM.LOG im Arbeitsverzeichnis geschrieben. Das würde sich dann mit Fanfare melden. Das unterscheidet schon mal (leider) diesen Teil von dem einen umschifften SMP-Bug.

Nebenbei: Sicherlich ist EPM mehr schlecht als recht von 16 bit VIO -> 32 bit VIO -> 32 bit PM umgestellt worden. (Sogar für "PowerPC" gab's schon 'ne Version.) Zu der Zeit, als der 32-bit-EPM herausgebracht wurde, konnte C Set 2.1 aber längst mit SMP umgehen. Von daher wäre es eine schöne vorläufige Erklärung, dass da etwas an dem SMP-Verhalten von OS/2 -Systemkomponenten nicht fehlerfrei funktioniert. Nur ohne Quellcode wird das wohl alles nichts. Jedenfalls scheint dieses Problem auch hardware-abhängig zu sein.
Andreas Schnellbacher
MKH
Beiträge: 119
Registriert: So 1. Jul 2018, 08:18

Beitrag von MKH »

Weil Lars das Grafiksubsystem angesprochen hat: Ich habe versuchsweise die Grafik auf VGA umgestellt. Und schon lässt sich NEPMD problemlos starten. Auch mit 2 Kernen.

Ich verwende die aktuellste Version von Panorama 1.17 mit einer Auflösung von 1920x1200 Pixel und 16M Farben. Diesen habe ich nun auch wieder installiert. Ich habe dann an der Auflösung geschraubt und rausgefunden, dass mit 800x600 Pixel und 16M Farben NEPMD ebenfalls auf Anhieb funktioniert.

Alles sehr kurios, weil das Problem nicht durchgehend auftritt - im Gegensatz zu Virtual PC.
Einige Zeit nach dem Systemstart funktioniert der Editor auch mit hoher Auflösung.
Benutzeravatar
aschn
Beiträge: 1363
Registriert: Mi 25. Dez 2013, 22:47

Beitrag von aschn »

MKH hat geschrieben: Mo 20. Dez 2021, 21:01 Ich verwende die aktuellste Version von Panorama 1.17 mit einer Auflösung von 1920x1200 Pixel und 16M Farben.
Hier genau so, aber ohne Probleme. Wenn es mit 800 x 600 geht, dann spricht ja umso mehr für den Grafiktreiber. Der heißt übrigens zunächst GRADD. Panorama ist nur oben drauf gesetzt.
Andreas Schnellbacher
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

aschn hat geschrieben: Mo 20. Dez 2021, 19:21
erdmann hat geschrieben: Mo 20. Dez 2021, 11:56 ich vermute, das "marked for single core" bit ist Teil der PTDA (per task data area) Information, also der Info für einen ausgeführten Prozess (im Volksmund: Programm).
Ich hab hier stehen: Im Exe-Header nach "LX" suchen und dann 16 B weiter: 0x00 = MP, 0x08 = SP.
Du hast mich falsch verstanden. Zunächst einmal ist in der Executable Datei (im Exe-Header) das MP bit gesetzt, so wie von dir angegeben.
Aber beim Laden des Executable binaries in den Speicher und dem Anlegen der PTDA wird diese Information dann in die PTDA übernommen. Wenn das Bit nicht zur Ausführungszeit berücksichtigt werden würde, wäre es ja wertlos.

In der PTDA gibt es ein Feld namens "behav_bit" (2 bytes): "program behavior bits". Das könnte das Feld sein, wo das "MP" bit hineinkopiert wird.
Antworten