AmigaOS 4 mittels Qemu auf einem emulierten Pegasos 2

[Joerg]

Außer der Kram funktioniert nicht, weil zu alt (oder nur für AmigaOne) oder was auch immer.

Auch wenn das von sg2 ist, einem der kompetentesten AmigaOS 4.x Entwickler, ist es mittlerweile 19 Jahre alt und daher extrem unwahrscheinlich dass es ohne Updates auch noch auf aktuellen AmigaOS 4.x Versionen funktioniert.

[Maijestro]

Wie schon mal geschrieben würde es schon Sinn machen auch mal mit einem alternativen AmigaOS rtl8139 Treiber zu testen. Siehe "openpci" auf os4depot.net. Readme: http://os4depot.net/?function=showfile& ... penpci.zip hat auch Links zum Treiber (man muß wohl die 68k Version nehmen, da die "elf" Variante für MorphOS ist).

Außer der Kram funktioniert nicht, weil zu alt (oder nur für AmigaOne) oder was auch immer.

Das hatte ich bereits ausprobiert, entschuldige ich hab es vergessen zu erwähnen. Der OpenPci RTL8139 lässt sich problemlos mit Roadshow unter AmigaOs 4.1 konfigurieren, führt aber dazu das keine Webseiten mit iBrowse/Odyssey geladen werden.

[Cyborg]

@Maijestro
Wenn Du Dich erinnerst, konnte ich ursprünglich auch nur mittels "vmnet-bridged" mit der Außenwelt kommunizieren, genau aus den Gründen, die balaton schrieb. Das erscheint mir also nicht ungewöhnlich, da der Treiber im Gastsystem auch nicht die Beschränkungen der Emulation umgehen kann. Die Kommunikation mit dem Host verlief allerdings auch bereits damals bei mir einwandfrei.

Qemu verhält sich jedenfalls absolut erratisch beim Netzwerk. Ich habe eben nochmals getestet und tatsächlich passiert es manchmal, daß nach einem Qemu-Start eine dieser Varianten eintritt:

1. alles funktionert wunderbar
2. DHCP funktioniert, danach werden aber mehr oder weniger kaputte Daten an den Treiber geliefert, bis der den (emulierten) 8139 neu startet. Ab diesem Zeitpunkt klappt auch die restliche Kommunikation absolut stabil
3. DHCP funktioniert, danach ist (zumindest für die Dauer meiner Beobachtung) keine Kommunikation mehr möglich
4. gar keine Kommunikation ist möglich

Die erste 53.6-qemutest-Version des Treibers verursacht Probleme auf echter Hardware und kann nicht freigegeben werden. Die 53.7-qemutest-Version läuft auf echter Hardware, wie erwartet, zeigt aber obiges Verhalten unter Qemu.

Es wäre vielleicht hilfreich, zumindet aber interessant, zu wissen, ob es tatsächlich unterschiedliches Verhalten zwischen Qemu-Mac/Linux und Qemu-Windows bei identischer Netzwerkkonfiguration gibt oder ob sich die Konfiguration unterscheidet und damit das Verhalten beeinflußt wird.

[balaton]

Es soll auch mit -netdev user funktionieren. User Netzwerk ist wie ein Firewall der ICMP und einkommende Verbindungen filtriert wie meiste Routern tun, aber ICMP zum Gateway soll gehen. Wichtig ist dass IP Addresse aus DHCP nehmen und nicht andere manuell setzen.
Ich habe keine Ahnung warum soll es untershiedlich verhalten und leider gibt es keine trace Punkte in Netzwerk behandlung. Vielleicht sollte rtl8139_can_receive() geprüft werden und mehr debug in qemu/net/{net|queue|slirp}.c einfügen um es raus zu finden wo die Pakete ferlieren. Gibt es eine einfache Methode es zu reproduzieren?

[Maijestro]

@Cyborg

Ok verstehe ich natürlich das du die erste version des Treibers nicht veröffentlichen kannst wenn er nicht auch auf echter Hardware mit RTL8139 Netzwerkkarte läuft. Für mich funktioniert der Treiber mit am besten, auch heute noch mal getestet. Wie bereits erwähnt Version 53.7 funktioniert nur mit VMNET und die Netzwerk verbindung geht nach 3-5 Minuten komplett verloren egal wie oft ich auch Qemu neustarte und es durch teste.

Um möglichst eigene Fehler bei der Netzwerkkonfiguration auschließen zu können, habe ich alles über DHCP von Roadshow konfigurieren lassen. Da der Treiber Version 1 etwas besser funktioniert, ist es für mich in Ordnung und ich könnte ihn irgendwo hosten und darauf verweisen, besonders für Leute die Qemu mit AmigaOs4.1 auf ein Mac M1/M2 verwenden.

Sollte es mit Version 53.7 nicht auch verbesserungen für echte Hardware geben, gibt es im grunde genommen keinen grund diesen Treiber zu veröffentlichen. Für Qemu ist dieser leider ungeeignet.

Du hast mir bereits geholfen mit Treiber Version 1 und ich erwarte auch nicht das alles innherlab einer Emulation genauso gut oder gar besser funktioniert wie auf echter Hardware. Vielleicht wird es irgendwann noch eine bessere Lösung geben wenn wir mehr Informationen dazu gesammelt haben und es auch verstehen warum es gg. unter Windows funktioniert. Ob dem tatsächlich so ist kann ich leider nicht bestätigen, da ich es unter Windows nicht testen kann.

Vielleicht gibt es auch ein zusammenhang von tests die Hans de Ruiter mit VirtioGPU druchgeführt hat denn er scheint auch Probleme mit der VirtioGPU zu haben "interrupt" Problem.

Für mich ist Version 1 von allen Versionen der stabilste den ich unter Qemu/Pegasos2 AmigaOs4.1 verwenden kann, also danke ich dir dafür

Hier noch mal ein Bildchen, über 3 GB Datenverkehr Betriebszeit über 45 Minuten SMB2/Streaming/Download:

[Maijestro]

Vielleicht sollte rtl8139_can_receive() geprüft werden und mehr debug in qemu/net/{net|queue|slirp}.c einfügen um es raus zu finden wo die Pakete ferlieren. Gibt es eine einfache Methode es zu reproduzieren?

Ich kenne leider keine einfachere Methode außer meine um es reproduzieren zu können

Edit:Das einzige was mir noch einfällt wäre es unter Linux PPC für AmigaOneXe/Pegasos2 zu prüfen ob es dort auch die selben Netzwerk Probleme gibt, so weit ich mich erinnern kann hatten wir das nie getestet ?

Noch etwas wenn die Internet Verbindung bricht bekomme ich folgende Fehlermeldung in die Konsole und auch nur dann:

Code: Alles auswählen

qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1
qemu-system-ppc: Slirp: Failed to send packet, ret: -1

[Lord]

Hi, hab jetzt auch mal den ersten Treiber unter Qemu auf den Mac Mini M1 Qemu 8x (Brew) getestet. Ich habe weiter einen hohen Packet Verlust von 92%. Ermittelt durch einfachen Ping zur FritzBox. Surfen geht soweit und runterladen mit Odyssee z.B das h2_etxramaps Pack 463mb aus OS4Depot, zeigt Werte während des Downloads von 1-1,4MB/s

Ergänzung, der Verlust scheint zu variieren mal mehr mal weniger:
4.Workbench:> ping www.google.de
PING www.google.de (74.125.71.94): 56 data bytes
64 bytes from 74.125.71.94: icmp_seq=0 ttl=255 time=3.99355e+12 ms
wrong data byte #8 should be 0x8 but was 0xc0
69 1 fe a3 4a 7d 47 5e c0 a8 0 82 0 0 f5 b2 a4 a0 0 0 57 a ab aa 0 6 77 ee 8 9 a b
c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b
64 bytes from 74.125.71.94: icmp_seq=0 ttl=255 time=3.99355e+12 ms (DUP!)
wrong data byte #8 should be 0x8 but was 0xc0
69 1 fe a3 4a 7d 47 5e c0 a8 0 82 0 0 f3 97 a4 a0 0 1 57 a ab ab 0 6 7a 7 8 9 a b
c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b
64 bytes from 74.125.71.94: icmp_seq=0 ttl=255 time=3.99355e+12 ms (DUP!)
wrong data byte #8 should be 0x8 but was 0xc0
69 1 fe a3 4a 7d 47 5e c0 a8 0 82 0 0 f0 4d a4 a0 0 2 57 a ab ac 0 6 7d 4f 8 9 a b
c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b
64 bytes from 74.125.71.94: icmp_seq=0 ttl=255 time=3.99355e+12 ms (DUP!)
wrong data byte #8 should be 0x8 but was 0xc0
69 1 fe a3 4a 7d 47 5e c0 a8 0 82 0 0 ee b6 a4 a0 0 3 57 a ab ad 0 6 7e e4 8 9 a b
c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b
64 bytes from 74.125.71.94: icmp_seq=0 ttl=255 time=3.99355e+12 ms (DUP!)
wrong data byte #8 should be 0x8 but was 0xc0
69 1 fe a3 4a 7d 47 5e c0 a8 0 82 0 0 e8 ff a4 a0 0 4 57 a ab ae 0 6 84 99 8 9 a b
c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b

--- www.google.de ping statistics ---
5 packets transmitted, 1 packets received, +4 duplicates, 80% packet loss
round-trip min/avg/max = 1e+09/2.14748e+06/3.99355e+12 ms
4.Workbench:>

Weitere Ergänzung:
Ob DHCP oder feste IP , selbes verhalten

[aros-sg]

In AROS x86 scheint der rtl8139 Treiber (https://github.com/aros-development-tea ... ks/rtl8139) nach einem kleinen Fix (*) mit altem Qemu (6.2.0) und "-netdev user,id=net0 -device rtl8139,netdev=net0" stabil zu funktionieren. Qemu läuft auf Linux x64.

(*) In den Sourcen und Docs sind TODOs, "unfinsihed", "experimental" erwähnt. Der Fix ist für ein TODO wegen ~"wrapped frames" (halbes Paket am Ende des Buffers, der Rest landet am Anfang des Buffers). Patch siehe https://ae.arosworld.org/index.php?topic=540.msg17927. Ohne diesen gab es bei ersten Versuchen mit OWB und Download von Dateien immer wieder mal kurze Pausen wo der Download still stand. Vielleicht sind Dinge wie diese Sachen die auf echter HW selten/garnicht vorkommen, denn sowas müßte eigentlich früher aufgefallen sein.

[balaton]

Noch etwas wenn die Internet Verbindung bricht bekomme ich folgende Fehlermeldung in die Konsole und auch nur dann:

Code: Alles auswählen

qemu-system-ppc: Slirp: Failed to send packet, ret: -1

Das kommt aus libslirp: https://gitlab.freedesktop.org/slirp/li ... eads#L1623 aber es ruft da den Callback von QEMU und letztendlich rtl8139_do_receive() so fern ich es verstehen kann. War das mit #define DEBUG_RTL8139 1 in qemu/net/rtl8139.c? Es sollte loggen warum es -1 "returned" (wie heisst das auf Deutsch?) mit DEBUG_RTL8139. Entweder stopped ===== oder receiver disabled ===== oder wenn size ist -1 aber wie kann das sein?

[balaton]

In AROS x86 scheint der rtl8139 Treiber (https://github.com/aros-development-tea ... ks/rtl8139) nach einem kleinen Fix (*) mit altem Qemu (6.2.0) und "-netdev user,id=net0 -device rtl8139,netdev=net0" stabil zu funktionieren. Qemu läuft auf Linux x64.

Meisten AROS Treibern haben aber endian Probleme also funktionieren nicht mit sam460ex. Das habe ich versucht lange her wenn ich sam460ex erst in QEMU gemacht habe. Momentan bootet aros-sam440-ppc auch nicht wegen etwas fehlende das dieses Patch https://github.com/aros-development-team/AROS/pull/640 erhoben soll aber habe das nicht probiert.