AmigaOS 4 mittels Qemu auf einem emulierten Pegasos 2

[Maijestro]

@aros-sg

Das Qemu Build befindet sich in "/Users/qemuDebug/build/qemu-system-ppc" also sollte ich dort auch die Logdatei "logfile.txt" finden aber sie ist einfach nicht dort, so habe ich es meiner Qemu Zeile mit angehangen....

Code: Alles auswählen

/Users/qemuDebug/build/qemu-system-ppc -M pegasos2 -L /Users/reneengel/qemu/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=en0 -netdev user,id=en0 -rtc base=localtime -display cocoa,zoom-to-fit=off,zoom-interpolation=off,full-screen=off -drive format=raw,file=/dev/disk6s2 -drive file=fat:rw:/Users/reneengel/Freigabe,id=ufat,format=raw,if=none -device usb-storage,drive=ufat -drive if=none,id=hd1,file=/Volumes/Games/AmigaOs4.1BackUp/coffin.img,format=raw -device ide-hd,drive=hd1,bus=ide.1 -serial stdio >logfile.txt 2>&1

[aros-sg]

Ist das auf einem Mac? Startest du qemu nicht über Terminal/Shell? Dort ist immer alles relativ zum aktuellen Verzeichnis. Wo sich das Programm (qemu) befindet ist egal. Das aktuelle Verzeichnis im Terminal/Shell sollte "pwd" dort anzeigen. Ist normalerweise aber auch im Shell Prompt sichtbar. Standardmäßig ist man in einem neu geöffneten Terminal/Shell im Heim Verzeichnis des Users.

Wenn Mac und über Icon gestartet, vielleicht zeigt das Icon Infoormations/Eigenschaften Fenster das Verzeichnis an. Und Mac hat ja auch (Datei) Suchfunktionen.

[balaton]

Nein, logfile.txt ist wo du die Commandozeile ausgeführt hast. Wenn im Zweifel benutze >/tmp/logfile.txt dann soll es sich in /tmp befinden. Die alternative mit 2>&1 | tee /tmp/lofgile.txt funktioniert auch und soll die logs auch ins console zeiegen und gleichzeitig in der Datei speichern aber ich habe das ausgelassen um Missverständnis zu vermeiden falls ich es nicht genau erklären kann.

[Maijestro]

@balaton

Ok der log scheint etwas mehr informationen zu geben was genau passiert. Ich habe es mit AmigaOs4.1 RTL8139 Treiber 53.4 und 53.6 getestet, bei letzteres bricht die Internetverbindung bereits beim Download von Dateien zusammen.

Mit Version 53.4 muß das Netzwerk sehr stark belastet werden Upload/Download SMB2 Verbindung zeitgleich....

@aros-sg

Noch etwas der Fehler das ich keine log Datei erstellen konnte lag nicht an mir, sondern wurde mir einfach falsch vermittelt und ja ich führe Qemu über sein Startcript aus was ich schnell editieren kann. Diese Zeile habe ich hinzugefügt und es gab keinerlei Probleme.

Code: Alles auswählen

2>&1 | tee /Volumes/Games/lofgile.txt

Log Daten RTL8139 Version 53.4 und 53.6

[aros-sg]

War das bei den früher geposteten logs ("QemuNetzwerkRTL8139Debug.txt") eine ältere Qemu Version? Denn in diesen neuen logs ist das von mir vermutetet Problem (reentrant/rekursiv aufruf) nicht zu sehen. Nach "in ring" gibts immer entweder "overflow" oder "recevied: bla bla bla", wie es sein soll. Und laut qemu rtl8139.c commit history wurde z. B. "net: Provide MemReentrancyGuard * to qemu_new_nic()" (was vielleicht was damit zu tun hat) erst im Nov 2023 gemacht.

[Maijestro]

@aros-sg

Nein es ist ein und das selbe Build warum ich mir das sicher bin? Weil ich es extra mit Debug Ausgabe kompilieren mußte, alle anderen Builds die ich derzeit verwendet haben diese Eigenschaft nicht und der log würde nichts aufzeichnen.

Wenn man die beiden logs vergleicht sieht man das der AmigaOs4.1 RTL8139 Treiber Version 53.6 viel früher die Verbindung verliert wie die Version 53.4. Aber anscheint sagen auch hier die Protokolle nicht viel darüber aus warum die Verbindung verloren geht

[Cyborg]

Bitte mal die angehängte Testversion vom RTL8139-Treiber probieren.

Edit: Anhang gelöscht, da nicht releasefähig. Neuere Testversion(en) sind weiter hinten im Thema zu finden.

[Maijestro]

Bitte mal die angehängte Testversion vom RTL8139-Treiber probieren.

Ui das kommt jetzt völlig unerwartet Ich teste den Treiber durch mega danke schön

[Maijestro]

@Cyborg

Gestern erst hatte ich das Thema mit Balaton weil ich etwas herausgefunden hatte was ich ihn unbedingt mitteilen wollte und zwar wenn ich etwas über SMB2 Netzwerk freigabe in die RamDisk kopiert habe konnte ich das verlieren der Verbindung des Netzwerks immer reproduzieren auch wenn genug Platz vorhanden war. Habe ich als Speicher Ort aber eine meiner Partition gewählt konnte ich das Testfile 80MB immer komplett übertragen. Das passierte mit dem Treiber 53.4 der ansonsten stabil funktioniert und ich ihn auch für die Qemu installation empfohlen habe. Video von dem test gestern mit Treiber 53.4 bette ich dir in diesen Post mit ein dann siehst du wie der test mit dem Qemu Testtreiber verlaufen ist.

Jetzt wirst du dich wahrscheinlich fragen warum ich dir das schreibe....den Test Treiber 53.6 habe ich unter den selben Bedingungen getestet mit SMB2 und als Speicherort RamDisk, die Verbindung bleibt stabil Netzwerk Übertragung scheint auch etwas schneller geworden zu sein. Downloadrate von Os4Depot liegt bei 1MB/sec bis 1.6MB/sec, SMB2 übertragung etwa schwankend bis 4MB/s, bin mir nicht sicher ob da noch was geht. Um sicher zu sein habe ich das ganze 3 Mal getestet indem ich Qemu komplett beendet/neugestartet habe und dann unter AmigaOs4.1 meinen Testfall wieder holt habe.

Ich bin mega happy, ich bin mir nicht sicher was du geändert hast aber der Treiber bzw. die Netzwerkverbindung ist stabil



Hier noch ein Screenshot mit 8 gleichzeitigen Verbindungen und Qemu AmigaOs4.1/RTL8139 Test Treiber

[Cyborg]

Wenn alle verfügbaren Empfangspuffer vom RTL8139 befüllt wurden, wird ein "Rx Buffer Overflow"-Interrupt ausgelöst. Das ist soweit völlig normal und soll dem Treiber die Möglichkeit geben, Pakete abzuarbeiten, um wieder Platz für neue zu schaffen. Außerdem gibt es einen einem "Rx OK"-Interrupt, wenn Pakete empfangen und vom Chip als valide eingestuft wurden. Bei beiden Interrupts muß der Treiber loslaufen und die empfangenen Pakete abarbeiten. Dabei wird als erster Schritt ein Statusfeld des Pakets gelesen und in drei mögliche Pfade gesprungen:

1) Empfangenes Paket OK -> normale Bearbeitung, Platz wird frei, nächstes Paket.
2) Empfangenes Paket fehlerhaft -> weitere Fehlerbehandlung auf Basis des restlichen Statusfelds, Paket verwerfen, nächstes Paket oder in schweren Fällen zurücksetzen des Netzwerkchips.
3) Empfangenes Paket ist noch nicht vollständig -> überspringen, nächstes Paket behandeln oder Behandlung beenden.

Aus mir unbekannten Gründen löst die RTL8139-Emulation von Qemu einen oder beide der obigen Interrupts aus, ohne das Statusfeld wie erwartet zu setzen. Es ist schlicht leer, womit in Zusammenhang mit "Rx Buffer Overflow" nicht gerechnet wird, da ich dieses Verhalten nicht aus der Dokumentation herauslesen konnte/kann. Durch das leere Statusfeld wurde das Paket zwar als fehlerhaft erkannt, aber die weitere Fehlerbehandlung endete in einem undefinierten Zustand, woraus der Treiber nicht mehr herauskam.

Ich bin mir nicht sicher, ob die Implementierung von Qemu hier falsch ist oder ich einfach nicht die richtige RTL8139-Dokumentation habe, in der der Fall eines komplett leeren Statusfelds beschrieben wird. Aber in keiner meiner Dokumentationsvarianten konnte ich dazu etwas finden. Fakt ist, daß dieser Fall offensichtlich bei echten RTL8139-Karten bisher nicht auftrat, ob zufällig oder nicht.

Ich werde übers Wochenende eine neue 53.7 bauen und in den AmigaOS-Betatest geben. Wenn dabei auch keine Probleme auftauchen, muß ich noch überlegen, wie ich die neue Version dann noch veröffentliche. Vermutlich werde ich sie aber ins OS4Depot hochladen, damit man nicht auf das nächste OS-Update warten (was sonstwann kommt oder auch nicht) oder erst mühselig AmiUpdate zum Laufen bekommen muß, wenn ich es als Einzelupdate bereitstelle(n ließe). Mal sehen.