AmigaOS 4 mittels Qemu auf einem emulierten Pegasos 2

[Cyborg]

Wir werden sehen. Ich bin noch unentschlossen

[Maijestro]

Wir werden sehen. Ich bin noch unentschlossen

Meiner Meinung nach wäre Virtio die bessere Wahl, wie du weist arbeitet Hans ebenso daran. Ich bin mir auch nicht sicher solltest du dich dafür entscheiden einen Treiber zu schreiben wie dieser dann zu verfügung gestellt werden soll. Mit Virtio/KVM Unterstützung können wir vielleicht eines Tages AmigaOs4.1 fast Nativ ausführen. Virtio hat den Vorteil das Nativ auf die Host Geräte zugegriffen werden kann.

Der RTL8139 unter Qemu wird nur emuliert und macht ihn dadurch natürlich langsamer als spezielle Virtio Treiber die auch dem Gast-System zu verfügung stehen. Die Maximal Downloadrate mit emulierten RTl8139 Treiber unter AmigaOs4.1 beträgt derzeit 2MB/s Download was nicht schlecht ist, aber meine Internetverbindung kann 10MB/s was ein Einbruch von 8MB bedeutet.

Natürlich kann ich mir nicht erlauben dir vorzuschreiben was du zu tun hast, ich wollte dich nur darauf hinweisen. Selbst eine kontonuirliche stabile Verbindung mit dem RTL8139 wäre willkommen wenn es für dich der einfachste weg wäre. Es ist natürlich auch möglich das die RTL8139 Emulation innerhalb von Qemu einfach etwas fehlt was dein AmigaOs4.1 Treiber inkompatibel macht, aber ich bin mir nicht sicher was das sein könnte oder wie ich es innerhalb von Qemu Debuggen kann um diesen Fehler den Qemu Developer Team mitteilen zu können.

[Cyborg]

Danke für Deine Hinweise. Mir soweit alles bereits bekannt.

Für die Akten und das Verständnis: "virtio" ist zwar grundsätzlich eine Spezifikation für diverse virtuelle Geräte, um die des Hosts zum Gast durchzusschleifen. Aber dabei hat ein Grafiktreiber (an dem Hans vermutlich bastelt) genauso wenig mit einem Netzwerktreiber zu tun, wie in der realen Hardwarewelt.

Außerdem spielt es keinerlei Rolle, was für eine Netzwerkkarte emuliert wird. Ob eine real Existierende oder eine "erfundene" virtio-Netzwerkarte. Emuliert ist beides, nur die Art und Weise, wie man sie bedient, ist unterschiedlich. Und selbst da ist beides sehr nah beieinander.

Darüberhinaus ist der Datendurchsatz über die Grenzen Deines LANs hinaus in jedem Fall irrelevant, da Roadshow bei allen Transfers ins WAN/Internet *extrem* langsam ist, was viele unterschiedliche (größtenteils bekannte) Gründe hat und nicht an den Treibern liegt. Du mußt nur die Geschwindigkeit im LAN mit der im WAN vergleichen. Eine 100Mbit-Verbindung im LAN wird easy ausgereizt, eine 100Mbit-Internetverbindung (Downstream von einem entsprechend schnellen Server) aber nicht mal ansatzweise.

Der tatsächlich einzige Vorteil der Unterstützung einer virtio-Netzwerk"karte" ist ... daß sie halt unterstützt wird Wirklich, das ist eher ein nice-to-have... ein Vorteil davon wäre vielleicht noch, daß man zumindest in der Theorie auch 2,5 oder sogar 10Gbit/s zur Verfügung hat, je nachdem, was der Host kann. Aber da schlägt dann ganz schnell nicht nur die Beschränkung von Roadshow (was nichtmal 1Gbit im LAN auszureizen erlaubt), sondern auch von der restlichen beteiligten Architektur in AmigaOS.

Grundsätzlich ist es also für Qemu-Nutzer egal, ob ich RTL8139 in der Emulation stabilisiere (was auch für echte Amigas interessant sein könnte) oder einen virtio-net-Treiber schreibe ... vielleicht mache ich auch beides einfach für Spasss mit drei "s"

[Maijestro]

 @Cyborg

Danke für die Erklärung das der TCP/IP Roadshow die Verbindung bremst war mir auch fast klar es gab schon einige Diskussionen darüber in anderen Foren.

Wie dem auch sei, ich wünsche dir viel Glück bei dein vorhaben und egal wie und ob du dich dafür entscheiden tust, mein Segen hast du

[ThorstenS]

Gibt es schon erste Tests, wie sich AmigaOS4 auf einem Raspberry Pi 5 macht?

[Maijestro]

Gibt es schon erste Tests, wie sich AmigaOS4 auf einem Raspberry Pi 5 macht?

Ich wüsste nicht wie das gehen soll AmigaOs4.1 unterstützt kein Raspberry Pi.

[ThorstenS]

Ich wüsste nicht wie das gehen soll und AmigaOs4.1 unterstützt kein Raspberry Pi

Na so wie unter Windows und MacOS, mittels QEMU...

[Maijestro]

@Cyborg

Ich weis nicht inwiefern du dich mit dem Netzwerktreiber schon beschäftigt hast, aber solltest du an der Debug Ausgabe des RTL8139 Treibers unter Qemu Interesse haben, so könnte ich dir ein paar Debug Protokolle zu verfügung stellen. Es zeigt den start von Qemu mit virtuellen RTL8139-Treiber bis hin zum gesamten Netzwerk Zusammenbruch unter AmigaOs4.1. Vielleicht tut der Virtuelle RTL8139 Treiber etwas was dein Treiber unter AmigaOs4.1 nicht erwartet was dann zum Verbindungsabruch führt.

Wenn die Verbindung verloren geht reicht es nicht AmigaOs4.1 zu rebooten um wieder eine Netzwerkverbindung zu bekommen, sondern Qemu muß komplett beendet und neugestartet werden. Auf echter Hardware sollte doch ein Reboot völlig ausreichen um den Treiber bzw. die Netzwerkkarte wieder neu initialisieren zu können oder?

Darum vermuten wir das es innerhalb von Qemu Probleme gibt, oder etwas was der Virtuelle Treiber RTL8139 anders macht.

[Cyborg]

Danke. Du kannst es gerne mal hier anhängen, wenn Du möchtest. Allerdings hab ich wenig Hoffnung, darin wirklich Hinweise zu finden, denn die Releaseversion der Netzwerktreiber hat natürlich kaum Debugausgaben, weil die extrem viel Zeit kosten. Wenn es nicht gerade ein Crash oder zumindest ein vom Treiber erkennbarer (!) fataler Fehler ist.

Nach den bisherigen Beschreibungen vermute ich, daß irgendwie das Ringpuffermanagement durcheinandergekommen ist und die Hardwareregister im emulierten RTL8139 von der letzten Treiberversion nicht 100% passend initialisiert werden. Das Problem ist, daß es unzählige Varianten von RTL8139 gibt (A, B, C, D, E, C+, ohne Buchstaben,...), alle unterschiedlich initialisiert und bespielt werden müssen und ich (aus Zeitgründen) noch nicht eruiert habe, welche davon eigentlich genau von Qemu emuliert werden soll. In der letzten Treiberversion habe ich den Variantensupport erweitert, daher scheint es, daß Qemu damit eine andere Variante als in der Vorversion des Treibers anspricht, mit der es Schwierigkeiten gibt.

[balaton]

Ich denke QEMU emuliert C+ aber der AmigaOS Treiber benutzt das nicht. Maijestro meinte Debug Protokolle von QEMU nich von der Treiber. Ich verstehe diese logs nicht weil ich weiss nicht wie RTL8139 functioniert. Ich denke es geht schief ungefähr hier:

Code: Alles auswählen

RTL8139:  CAPR write: rx buffer length 32768 head 0x2e88 read 0x289c
RTL8139: receiver buffer data available 0x05ec
RTL8139: ChipCmd read val=0x000c
RTL8139: RxBufPtr write val=0x2e78
RTL8139:  CAPR write: rx buffer length 32768 head 0x2e88 read 0x2e88
RTL8139: receiver buffer is empty
RTL8139: ChipCmd read val=0x000d
RTL8139: >>> received len=1506
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: received: rx buffer length 32768 head 0x3474 read 0x2e88
RTL8139: Set IRQ to 1 (0001 807f)
RTL8139: >>> received len=1506
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: received: rx buffer length 32768 head 0x3a60 read 0x2e88
RTL8139: Set IRQ to 1 (0001 807f)
RTL8139: >>> received len=1506
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: received: rx buffer length 32768 head 0x404c read 0x2e88
RTL8139: Set IRQ to 1 (0001 807f)
RTL8139: >>> received len=1506
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: received: rx buffer length 32768 head 0x4638 read 0x2e88
RTL8139: Set IRQ to 1 (0001 807f)
RTL8139: >>> received len=1506
RTL8139: >>> physical address matching packet received
RTL8RTL8139: entered rtl8139_set_next_tctr_time
RTL8139: receiver buffer is empty
RTL8139: entered rtl8139_set_next_tctr_time
RTL8139: entered rtl8139_set_next_tctr_time
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: entered rtl8139_set_next_tctr_time
RTL8139: receiver buffer is empty
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================
RTL8139: >>> physical address matching packet received
RTL8139: in ring Rx mode ================

Die logs kommen aus qemu/hw/net/rtl8139.c::rtl8139_do_receive() aber ich verstehe nicht wie es ein "in ring Rx mode" log geben kann ohne es entweder mit "received: rx buffer" oder "rx overflow:" zeile verfolgt zu werden.