Verträglichkeit der letzten USB-Treiber mit COM.SYS

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Antworten
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Verträglichkeit der letzten USB-Treiber mit COM.SYS

Beitrag von ak120 »

Gibt es irgendwo Informationen, welche Version des Gerätetreibers COM.SYS sich mit den neueren USB-Treibern von Lars verträgt?

Mit dem letzten Stand der IBM Treiber gibt es keine Probleme. Die Hardware ist ziemlich gewöhnlich:
Auf dem FSC Rechner zur Protokollierung ist CP2 für WSEB installiert. Neben der seriellen Schnittstelle, welche sich auf der Systembaugruppe befindet, ist eine zusätzliche PCI-Erweiterungskarte für 2 weitere serielle Anschlüsse verbaut. Diese wird auch erkannt (RMVIEW bzw. Hardware Manager) und ist für die 2 benötigten zusätzlichen Protokolldrucker nutzbar.

Das Problem ist nur, wenn man nun gegen die neueren experimentellen Treiber tauscht, daß der Presentation Manager das Starten der Shell verweigert - in diesem Fall ist SET RUNWORKPLACE=C:\OS2\CMD.EXE. Lediglich der Uhr-Zeiger erscheint.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Verstehe ich nicht. Ich sehe nicht was COM.SYS mit den USB Treibern zu tun haben sollte.
Oder ist USBCOM.SYS (also der USB Treiber für COM - to - USB Adapter) ebenfalls im Einsatz ? Wenn ja, den mal auskommentieren und nur COM.SYS in der config.sys belassen und schauen ob das hilft. USBCOM.SYS legt natürlich auch "COMx" ports an. Vielleicht gibt es dabei Probleme.

Und welcher "letzte Stand der IBM Treiber" ist hier gemeint ? Der COM.SYS oder die USB Treiber ?

Ansonsten lade ich hier COM.SYS sowie alle USB Treiber und kann dieses Problem nicht nachvollziehen. Allerdings habe ich keine COM HW (also UART Schnittstellen) on board. COM.SYS tut also nichts.

Außerdem kommt eCS bzw. ArcaNoae ja mit einem upgedateten "PSCOM.SYS" Treiber als Ersatz zum originalen COM.SYS. Ich meine das hatte was mit PCI zu tun. Oder damit daß der originale COM.SYS nicht multi-core kompatibel war.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

erdmann hat geschrieben:Verstehe ich nicht. Ich sehe nicht was COM.SYS mit den USB Treibern zu tun haben sollte.
Deshalb frage ich ja. COM3 und einer der UHC verwenden Interrupt 11. Könnte dies die Ursache für die Unverträglichkeit sein?
Oder ist USBCOM.SYS (also der USB Treiber für COM - to - USB Adapter) ebenfalls im Einsatz ? Wenn ja, den mal auskommentieren und nur COM.SYS in der config.sys belassen und schauen ob das hilft. USBCOM.SYS legt natürlich auch "COMx" ports an. Vielleicht gibt es dabei Probleme.
Es wird kein USBCOM Treiber genutzt und auch nicht geladen.
Und welcher "letzte Stand der IBM Treiber" ist hier gemeint ? Der COM.SYS oder die USB Treiber ?
USB ist wohl auf dem letzten Stand 10.162, bei COM.SYS müßte ich morgen mal nachsehen.
Ansonsten lade ich hier COM.SYS sowie alle USB Treiber und kann dieses Problem nicht nachvollziehen. Allerdings habe ich keine COM HW (also UART Schnittstellen) on board. COM.SYS tut also nichts.

Außerdem kommt eCS bzw. ArcaNoae ja mit einem upgedateten "PSCOM.SYS" Treiber als Ersatz zum originalen COM.SYS. Ich meine das hatte was mit PCI zu tun. Oder damit daß der originale COM.SYS nicht multi-core kompatibel war.
Ich mußte nichts weiter anpassen und konfigurieren nach Einbau der seriellen PCI-Schnittstellenkarte wurden die beiden zusätzlichen Schnittstellen auch als COM2 und COM3 automatisch erkannt und können genutzt werden. SMP Kernel 14.103 macht keine Probleme. Wie kann ich unter OS/2 zwischen multi-core und Multiprozessor unterscheiden?
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

PSCOM.SYS statt COM.SYS ?
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

ak120 hat geschrieben:
erdmann hat geschrieben:Verstehe ich nicht. Ich sehe nicht was COM.SYS mit den USB Treibern zu tun haben sollte.
Deshalb frage ich ja. COM3 und einer der UHC verwenden Interrupt 11. Könnte dies die Ursache für die Unverträglichkeit sein?
Oder ist USBCOM.SYS (also der USB Treiber für COM - to - USB Adapter) ebenfalls im Einsatz ? Wenn ja, den mal auskommentieren und nur COM.SYS in der config.sys belassen und schauen ob das hilft. USBCOM.SYS legt natürlich auch "COMx" ports an. Vielleicht gibt es dabei Probleme.
Es wird kein USBCOM Treiber genutzt und auch nicht geladen.
Und welcher "letzte Stand der IBM Treiber" ist hier gemeint ? Der COM.SYS oder die USB Treiber ?
USB ist wohl auf dem letzten Stand 10.162, bei COM.SYS müßte ich morgen mal nachsehen.
Ansonsten lade ich hier COM.SYS sowie alle USB Treiber und kann dieses Problem nicht nachvollziehen. Allerdings habe ich keine COM HW (also UART Schnittstellen) on board. COM.SYS tut also nichts.

Außerdem kommt eCS bzw. ArcaNoae ja mit einem upgedateten "PSCOM.SYS" Treiber als Ersatz zum originalen COM.SYS. Ich meine das hatte was mit PCI zu tun. Oder damit daß der originale COM.SYS nicht multi-core kompatibel war.
Ich mußte nichts weiter anpassen und konfigurieren nach Einbau der seriellen PCI-Schnittstellenkarte wurden die beiden zusätzlichen Schnittstellen auch als COM2 und COM3 automatisch erkannt und können genutzt werden. SMP Kernel 14.103 macht keine Probleme. Wie kann ich unter OS/2 zwischen multi-core und Multiprozessor unterscheiden?
1) Natürlich kann es prinzipiell IRQ Konflikte geben. Nur habe ich an USBUHCD.SYS schon seit 1 Jahr nichts mehr geändert. Es kann also kein Problem sein was nun in den letzten Monaten erst aufgetreten wäre.

2) der COM.SYS der mit OS/2 kommt ist nicht mehr tauglich. Du solltest PSCOM.SYS nehmen (wenn du den irgendwo her bekommst, er ist bei eCS dabei) oder die Treiber von Ray Gwinn:
http://hobbes.nmsu.edu/download/pub/os2 ... 2kv202.zip

2) Es gibt diesbezüglich keinen Unterschied zwischen Multi-core und Multi-Prozessor. Es geht nur um den Unterschied Single-core / Multi-core.
Bei Multi-core / Multi-Prozessor gibt es eben mehrere Cores/Prozessoren die "fast gleichzeitig" (nur HW arbitriert) auf den Speicherbus zugreifen können. Oft muß eben der Zugriff gescheit durch die SW serialisiert werden.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

erdmann hat geschrieben: Außerdem kommt eCS bzw. ArcaNoae ja mit einem upgedateten "PSCOM.SYS" Treiber als Ersatz zum originalen COM.SYS. Ich meine das hatte was mit PCI zu tun. Oder damit daß der originale COM.SYS nicht multi-core kompatibel war.
Es ist der COM.SYS in der Überarbeitungsversion 10.056 installiert, welcher als SMP gekennzeichnet ist. Also würde eine Aktualisierung auf 10.070 (SMP) nichts bringen?
1) Natürlich kann es prinzipiell IRQ Konflikte geben. Nur habe ich an USBUHCD.SYS schon seit 1 Jahr nichts mehr geändert. Es kann also kein Problem sein was nun in den letzten Monaten erst aufgetreten wäre.
Es hätte ja sein können, daß es eine Möglichkeit gibt das Verhalten zu steuern ohne USB im BIOS komplett zu deaktivieren.
2) der COM.SYS der mit OS/2 kommt ist nicht mehr tauglich. Du solltest PSCOM.SYS nehmen (wenn du den irgendwo her bekommst, er ist bei eCS dabei) oder die Treiber von Ray Gwinn:
http://hobbes.nmsu.edu/download/pub/os2 ... 2kv202.zip
War PSCOM nicht ursprünglich für die Verträglichkeit mit OS2ACPI.PSD gedacht? Hier wird jedoch OS2APIC.PSD genutzt.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

ak120 hat geschrieben:
erdmann hat geschrieben: Außerdem kommt eCS bzw. ArcaNoae ja mit einem upgedateten "PSCOM.SYS" Treiber als Ersatz zum originalen COM.SYS. Ich meine das hatte was mit PCI zu tun. Oder damit daß der originale COM.SYS nicht multi-core kompatibel war.
Es ist der COM.SYS in der Überarbeitungsversion 10.056 installiert, welcher als SMP gekennzeichnet ist. Also würde eine Aktualisierung auf 10.070 (SMP) nichts bringen?

Das wäre auf jeden Fall einen Versuch wert.
1) Natürlich kann es prinzipiell IRQ Konflikte geben. Nur habe ich an USBUHCD.SYS schon seit 1 Jahr nichts mehr geändert. Es kann also kein Problem sein was nun in den letzten Monaten erst aufgetreten wäre.
Es hätte ja sein können, daß es eine Möglichkeit gibt das Verhalten zu steuern ohne USB im BIOS komplett zu deaktivieren.
2) der COM.SYS der mit OS/2 kommt ist nicht mehr tauglich. Du solltest PSCOM.SYS nehmen (wenn du den irgendwo her bekommst, er ist bei eCS dabei) oder die Treiber von Ray Gwinn:
http://hobbes.nmsu.edu/download/pub/os2 ... 2kv202.zip
War PSCOM nicht ursprünglich für die Verträglichkeit mit OS2ACPI.PSD gedacht? Hier wird jedoch OS2APIC.PSD genutzt.
1) Ich meine mich zu erinnern daß der originale COM.SYS das Interrupt-Sharing nicht vernünftig beherrscht, also immer den Interrupt für sich alleine will (was bei PCI Systemen im allgemeinen falsch ist). Deshalb wurde meine ich PSCOM.SYS geschrieben und genau den würde ich auch ausprobieren.

2) Ansonsten sieht es so aus daß hier ein Interrupt Konflikt vorliegt. IRQ 11 ist ja kein "Standard" IRQ für COM ports. Das sind ja nur IRQ3 und IRQ4.

Wenn es mit den originalen IBM USB Treibern problemlos geht: die originalen USB HC Treiber versuchen den IRQ zunächst "shared" zu alloziieren und wenn das fehlschlägt dann "exclusive". Ich habe die USB HC Treiber so geändert daß sie nur noch versuchen "shared" zu alloziieren (weil USB devices grundsätzlich am PCI Bus hängen). Könnte ich wieder so ändern wie ursprünglich. Allerdings würde das ja bedeuten daß dann die USB HC Treiber den IRQ "exclusive" alloziieren. Da würde dann ja wiederrum COM.SYS nicht den IRQ zugeteilt bekommen können.

Lars
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

erdmann hat geschrieben:
ak120 hat geschrieben: Es ist der COM.SYS in der Überarbeitungsversion 10.056 installiert, welcher als SMP gekennzeichnet ist. Also würde eine Aktualisierung auf 10.070 (SMP) nichts bringen?
Das wäre auf jeden Fall einen Versuch wert.
Der Versuch war erfolgreich. Also den COM.SYS 10.070 mit den letzten USB Treibern 10.218 nach Sicherung des vorherigen Standes eingespielt. Jetzt kann der PM die CMD.EXE starten.
1) Ich meine mich zu erinnern daß der originale COM.SYS das Interrupt-Sharing nicht vernünftig beherrscht, also immer den Interrupt für sich alleine will (was bei PCI Systemen im allgemeinen falsch ist). Deshalb wurde meine ich PSCOM.SYS geschrieben und genau den würde ich auch ausprobieren.
Das Drucken funktioniert und den Alarmmodem habe ich an SERIAL_0 COM1 angeschlossen. Falls es im Betrieb Störungen geben sollte, werde ich PSCOM.SYS probieren.
2) Ansonsten sieht es so aus daß hier ein Interrupt Konflikt vorliegt. IRQ 11 ist ja kein "Standard" IRQ für COM ports. Das sind ja nur IRQ3 und IRQ4.
Das war vielleicht beim vom OS/2 nicht unterstützten Ur-PC noch eine übliche Vereinbarung. Spätestens seit dem AT sollte das hoffentlich Geschichte sein.
Wenn es mit den originalen IBM USB Treibern problemlos geht: die originalen USB HC Treiber versuchen den IRQ zunächst "shared" zu alloziieren und wenn das fehlschlägt dann "exclusive". Ich habe die USB HC Treiber so geändert daß sie nur noch versuchen "shared" zu alloziieren (weil USB devices grundsätzlich am PCI Bus hängen). Könnte ich wieder so ändern wie ursprünglich. Allerdings würde das ja bedeuten daß dann die USB HC Treiber den IRQ "exclusive" alloziieren. Da würde dann ja wiederrum COM.SYS nicht den IRQ zugeteilt bekommen können.
Im RMVIEW oder Hardware Manager sind alle USB-Einträge nun als EXC angezeigt. Eine weitere Änderung ergibt sich bei der Erkennung der austauschbaren Datenträger. Ich habe keine Änderungen an den CONFIG.SYS-Parametern vorgenommen, jedoch werden jetzt nur noch 2 dieser Datenträger vom LVM erkannt. Zuvor mit den IBM-Treibern waren es noch sämtliche der 3 probeweise angeschlossenen Einheiten.
Zuletzt geändert von ak120 am Di 20. Jun 2017, 21:54, insgesamt 1-mal geändert.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

Was genau wird bei den USB HC Treibern als EXC angezeigt: der IRQ ? Die I/O Addressen (USBUHCD.SYS) ? Die memory mapped Addressen (USBOHCD.SYS, USBEHCD.SYS) ?
Mit meinen USB HC Treibern wird für IRQ grundsätzlich nie EXC angezeigt weil meine Treiber nur shared alloziieren und das auch entsprechend dem RM so gemeldet wird. Die I/O Addressen bzw. die memory mapped Addressen hingegen werden immer als EXC angezeigt weil diese auch tatsächlich immer exklusiv belegt werden und RM auch so gemeldet werden.

Wenn ein MSD device nicht vernünftig attached müßtest du es mir zuschicken. Dann könnte ich schauen woran das liegt. Oder du stöpselt es ein (und nur das eine !) und aktivierst vorher das Tracing für USBMSD.ADD und schickst mir den Trace (wie Tracing aktiviert wird ist in readusb.txt erklärt).

Übrigens: mag ja sein daß die Vereinbarung "IRQ3" + "IRQ4" für COM ports veraltet ist. Aber die OS/2 device Treiber sind es eben auch.
Und die folgen größtenteils noch diesen längst überholten Regeln und nehmen dann womöglich einfach starr an daß der erste COM port mit IRQ4 verbunden ist und der zweite mit IRQ3. Nennt sich "legacy" Ballast.

Lars
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

Ein kleiner Nachtrag:

Wie es sich herausstellte, funktionieren die neueren USB-Treiber nur in einem Sonderfall:
Es muß zuvor der IBM USB Treiber verwendet worden sein und das System zumindest einmal damit gestartet worden sein. Nach einem anschließenden Warmstart lädt der Presentation Manager die Shell.

Wird hingegen ein Kaltstart durchgeführt scheitern auch die neueren USB-Treiber an dem ursprünglich geschilderten Problem. Einzige Lösung ist der Rückgriff auf die letzten IBM Treiber, welche dann hier auch alle angeschlossenen USB-Speichergeräte erkennen können.
Antworten