AmigaOS 4 mittels Qemu auf einem emulierten Pegasos 2

[Maijestro]

@Lord

Danke für den Test mit Version 53.7. Noch etwas zum Pingen wie stoppe ich die Ausgabe in der Shell?

@Cyborg

Angeregt von Lord sein test, habe ich es auch noch mal intensiv getestet unter Qemu mit der Maschine AmigaOneXe/Pegasos2 und alle meine üblichen reproduzierbaren Tests durchgeführt, SMB2 Übertragung/TuneNet Musik Streaming/ Odyssey/YT YouTube Stream zeitgleich. Auf beiden Maschinen mit VMNET absolut stabil und es kam zu keinen verlieren der Internetverbindung.

Betriebszeit 20 Minuten indem ich das Netzwerk voll ausgelastet habe. Seltsam ist das mir jetzt auch ein ganz andere IP Adresse zugeordnet wurde. Oben im Verlinkten Screenshot war es 10.0.2.15 mit Version 53.7 ist es 192.168.2.190 achte mal auf den angehängten Screenshot.

Ich kann mir das gerade nicht erklären, aber ein Übeltäter vermute ich, derzeit kommen 2 Qemu Builds zum einsatz, eins ist mit VirGL Unterstützung aus einer nicht offiziellen Qemu Quelle und das andere aus der offiziellen Qemu Master Quelle, dazu kommt noch das Balaton BBoot 0.7 gestern veröffentlicht hat und es einige Änderungen gab "Set interrupts to level trigger on pegasos2 for AmigaOS kernel".

Auch die Bestätigung eines anderen Users habe ich gestern erhalten das Version 53.7 bei ihm mit Qemu/Peg2 funktioniert (MacMini M1) Also scheint der Treiber tatsächlich zu funktionieren wie er sollte.

Qemu Startparameter:

Code: Alles auswählen

 sudo /Users/qemuVirGL/build/qemu-system-ppc -M pegasos2 -L /Users/reneengel/qemuVirGL/pc-bios -accel tcg -kernel /Volumes/Games/AmigaOs4.1BackUp/bboot/bboot -initrd /Volumes/Games/AmigaOs4.1BackUp/bboot/Kickstart.zip -vga none -device sm501 -drive if=none,id=cd -m 2048 -device ide-cd,drive=cd,bus=ide.1 -device rtl8139,netdev=network01 -netdev vmnet-bridged,id=network01,ifname=en0,id=net0 -rtc base=localtime -display cocoa,zoom-to-fit=on,zoom-interpolation=on,full-screen=on,gl=on -drive format=raw,file=/dev/disk6s2 -drive file=fat:rw:/Users/reneengel/Freigabe,id=USB,format=raw,if=none -device usb-storage,drive=USB -drive if=none,id=hd1,file=/Volumes/Games/AmigaOs4.1BackUp/coffin.img,format=raw -device ide-hd,drive=hd1,bus=ide.1

Da dieser Treiber nur VMNET unterstützt bin ich mir nicht sicher wie er sich unter Windows mit Qemu verhält, vielleicht könnte es Probleme geben für Windows User. Das sollte vielleicht noch getestet werden.

Edit: Auch mit mein VirGL Build funktioniert es ohne Probleme, vielleicht war es auch ein Problem mit der Qemu Zeile, ich hab die Zeile von Lord übernommen. "-device rtl8139,netdev=network01 -netdev vmnet-bridged,id=network01,ifname=en0,id=net0" vorher hatte ich "-device rtl8139,netdev=network01 -netdev vmnet-bridged,id=network01,ifname=en0" verwendet.

[Cyborg]

Danke für den Test mit Version 53.7. Noch etwas zum Pingen wie stoppe ich die Ausgabe in der Shell?

CTRL-C

Auf beiden Maschinen mit VMNET absolut stabil und es kam zu keinen verlieren der Internetverbindung.

Das war offenbar ein guter Lauf. Ist das bei Dir verläßlich stabil, auch bei mehreren Reboots von Qemu?

Seltsam ist das mir jetzt auch ein ganz andere IP Adresse zugeordnet wurde. Oben im Verlinkten Screenshot war es 10.0.2.15 mit Version 53.7 ist es 192.168.2.190 achte mal auf den angehängten Screenshot.

Das ist weder seltsam, noch liegt es an meinem Treiber. Wenn Du "netdev user" bei Qemu verwendest, baut Qemu ein eigenes privates Netz (10.0.2.0/24) zwischen dem Gast und dem Host auf und nutzt NAT für die Datenübertragung. Bei "netdev vmnet-bridged" bekommt der Qemu-Gast eine direkte Verbindung zu Deinem restlichen LAN (Netz 192.168.2.0/24) und wird wie ein eigener Rechner behandelt, der auch eine eigene IP bekommt.

Da dieser Treiber nur VMNET unterstützt ...

Diese Aussage impliziert, daß der Treiber da aktiv irgendeine Rolle spielen würde, was aber nicht stimmt. Wie Qemu das Netzwerk aufbaut, ob mit eigenem NAT oder nicht, ist für den Treiber völlig egal. Er schiebt nur Pakete vom TCP-Stack zur Netzwerk"karte" und zurück. Der Rest ist irrelevant.

Daß "netdev user" (mit eigenem NAT) - z.B. bei mir - nicht funktioniert, liegt daran, daß der von Qemu bereitgestellte DNS-Server nicht antwortet. Warum das so ist, weiß ich nicht, kann seine Ursache aber praktisch nicht im Treiber haben.

[Maijestro]

@Cyborg

Das war offenbar ein guter Lauf. Ist das bei Dir verläßlich stabil, auch bei mehreren Reboots von Qemu?

Soweit ich sagen kann ist es wirklich absolut stabil, von unzähligen Sitzungen hatte ich lediglich 1 bei wo überhaupt keine Internetverbindung aufgebaut werden konnte, aber ich konnte es sonst überhaupt nicht reproduzieren. Bei allen sonstigen Sitzungen war alles in Ordnung und es gab auch keine Paket Verluste. Hier noch mal ein weiteres Testergebnis das ich gerade erst durchgeführt habe. Wie immer mit voll ausgelasteten Netzwerk.

Qemu Master (9.0) BBoot 0.7 Pegasos2

--- 192.168.2.190 ping statistics ---
490 packets transmitted, 490 packets received, 0% packet loss
round-trip min/avg/max = 0.138/24.057/203.151 ms
5.Workbench:>

Spielt es eine Rolle welche IP zum Pingen verwendet wird, oder sollte es besser immer die Router IP sein?

Das ist weder seltsam, noch liegt es an meinem Treiber. Wenn Du "netdev user" bei Qemu verwendest, baut Qemu ein eigenes privates Netz (10.0.2.0/24) zwischen dem Gast und dem Host auf und nutzt NAT für die Datenübertragung. Bei "netdev vmnet-bridged" bekommt der Qemu-Gast eine direkte Verbindung zu Deinem restlichen LAN (Netz 192.168.2.0/24) und wird wie ein eigener Rechner behandelt, der auch eine eigene IP bekommt.

Danke das du das noch mal erklärt hast. Vermutlich ist VMNET die beste Option unter MacOs, da VMNET das Apple native Framework verwendet was etwas genauer sein sollte. Ich bin etwas positiv überrascht das es auf einmal so gut funktioniert.

Wie Lord auch berichtet hat Maxmimale Downloadraten von 1.0MB-1.4Mb nicht viel, aber besser wie gar nichts

Hier siehst du noch mal welche Downloadraten erreicht werden...es schwank sehr stark aber wahrscheinlich emulations bedingt. Bessere Ergebnisse werden wir wahrscheinlich nur durch VirtIO Netzwerktreiber erhalten.

[Joerg]

Qemu Master (9.0) BBoot 0.7 Pegasos2
...
Ich bin etwas positiv überrascht das es auf einmal so gut funktioniert.

Der BBoot 0.7 bug fix, Verwendung von level IRQs statt edge in den älteren Versionen, sollte auch zur Stabilität beitragen. AmigaOS kann nur mit level triggered IRQs richtig funktionieren.
Es sei denn rtl8139.device enthält etwas wie einen Watchdog Timer und funktioniert auch problemlos wenn einige Interrupts nicht beim Treiber ankommen?

[Cyborg]

Nein, Interrupts müssen ankommen. Zwar nicht unbedingt jeder, weil nach einem erkannten Interrupt immer der gesamte bereitstehende Puffer eingehend wie ausgehend abgearbeitet wird, aber im ungünstigsten Fall könnten die Puffer natürlich bis zum Deadlock vollaufen (Senderichtung ist da gefährdeter, als die Empfangsrichtung).

Da ich aber das gleiche Verhalten auch mit der Originalfirmware beobachten kann, kann man BBoot in dieser Hinsicht als Problemquelle eigentlich ausschließen.

[Joerg]

Da ich aber das gleiche Verhalten auch mit der Originalfirmware beobachten kann, kann man BBoot in dieser Hinsicht als Problemquelle eigentlich ausschließen.

Laut debug logs auf amigans.net konfiguriert auch die original Pegasos2 SmartFirmware die IRQs auf egde, und da der AmigaOS 4.x kernel üblicherweise überhaupt keine Hardware Konfigurationen durchführt, sondern davon abhängt, dass die Firmware schon alles korrekt konfiguriert hat, dürfte es auf echten Pegasos2 mit AmigaOS 4.x genau die gleichen Interrupt Probleme geben.
Es sei dann man benutzt auch da BBoot 0.7, was auch auf echter Hardware möglich ist, wobei dann BBoot die SmartFirmware nicht komplett ersetzt sondern von dieser gestartet wird. Sollte auf echten Pegasos2 z.B. die Verwendung von PCIe Grafikkarten wie Radeon HD und RX mit 64 Bit BARs hinter einer PCIe Bridge ermöglichen, was alleine mit SmartFirmware unmöglich ist.

Der MorphOS kernel ändert die IRQs dagegen auf level, wodurch es unter MorphOS diese Interrupt Probleme nicht geben sollte, weder auf echter Hardware noch auf QEmu.

[Cyborg]

Oh tatsächlich? Hmm ... mir sind in den letzten 10 Jahren keine Bugreports dahingehend auf echten Pegasos2 mit rtl8139 bekannt. Mag Zufall sein oder Exec rekonfiguriert die Interrupts ebenfalls auf Pegasos, das müßte ich nachsehen. Leider ist es ja wirklich nicht sicher, was ExecSG selbst macht und was nicht.

[Maijestro]

@Joerg @Cyborg

Das ist natürlich interessant, vielleicht sollte ich auch zusätzlich ein paar tests mit dem ursprünglichen RTL8139 Version 53.6 von AmigaOs4.1 update 2 durchführen der immer Probleme bereitete von anfang an.

Auf Amigans wurde auch gesagt das AmigaOs4.1 für Pegasos2 größtenteils ungetestet wurde, vielleicht gibt es auch hier zusammenhänge.

Edit: AmigaOs4.1 Treiber RTL8139 Update 2 Ofiizelle Version 53.6 getestet, Ergebnis...Netzwerk bricht nach kurzer Benutzung zusammen. Wieder gewechselt zu 53.7 test wiederholt alles sauber keine Paketverlust stabiles internet. Mit 53.7 bist du auf dem richtigen Weg....

RTL8139 53.6 AmigaOs4.1 Update 2:

Bildschirmfoto 2024-04-16 um 19.45.52.png

RTL8139 53.7 Testversion:

Bildschirmfoto 2024-04-16 um 19.55.30.png

Getestet mit Qemu 9.0 BBoot 0.7 Pegasos2 VMNET

[balaton]

und da der AmigaOS 4.x kernel üblicherweise überhaupt keine Hardware Konfigurationen durchführt, sondern davon abhängt, dass die Firmware schon alles korrekt konfiguriert hat, dürfte es auf echten Pegasos2 mit AmigaOS 4.x genau die gleichen Interrupt Probleme geben.

Der amigaone Kernel konfiguriert ISA PIC selber ohne es auf Firmware abhängen und schreibt auch das ELCR (Edge/Level Control Register) auf AmigaOne aber die pegasos2 version fehlt das ELCR zu kontigurieren, BBoot 0.7 korrigiert das und soll eine lösung bieten solange es gibt kein Update veröffentlicht das es korrigiert im Kernel. Das heisst dieses Problem soll nicht mit amigaone aufteten, also nur wenn ein Problem auf pegasos2 mit Firmware oder BBoot <=0.6 reproduziert werden kann aber nicht auf amigone oder mit BBoot 0.7 könnte es damit zusammenhängen.

Es sei dann man benutzt auch da BBoot 0.7, was auch auf echter Hardware möglich ist, wobei dann BBoot die SmartFirmware nicht komplett ersetzt sondern von dieser gestartet wird. Sollte auf echten Pegasos2 z.B. die Verwendung von PCIe Grafikkarten wie Radeon HD und RX mit 64 Bit BARs hinter einer PCIe Bridge ermöglichen, was alleine mit SmartFirmware unmöglich ist.

BBoot kann 64bit BARs patchen so der Kernel der nur 32 BARs kennt kann die sehen aber es handelt kein PCIe Bridge noch also kann nur gfx Karten fixen die von der Firmware erkennt sind. Anderen mit Bridge vielleicht benötigen noch ein Kernel Update.

[Cyborg]

Ich glaube nicht, daß es von Trevors "ExecSG Team" unter Führung von Steven Solie jemals sinnvolle Kernelupdates für alte Maschinen geben wird. Dort hat man sich vollkommen auf A-EONKit-Hardware versteift und in IMHO sinnlose Marketingdinge verrannt (SMP! SMP! SMP!)... zumindest, was man so mitbekommt. Ich bin ja kein Teil dieses Teams.