AmigaOS 4 mittels Qemu auf einem emulierten Pegasos 2

[aros-sg]

Was passiert mit nem alternativem rtl8139 Treiber, wie dem 68k Treiber von Benjamin Vernoux der laut docs vom AOS4 openpci wrapper auf os4depot.net unter AOS4 funktionieren soll (http://os4depot.net/?function=showfile& ... penpci.zip).

[Maijestro]

@Cyborg

Ja Balaton hat recht es geht im Moment um die reine Qemu RTL8139 Emulation was ich Debuggt habe, innerhalb von AmigaOs4.1 kann ich das nicht tun da du wie bereits erwähnt hast dein Treiber nicht mit Debug Unterstützung gebaut wurde, was auch sinn macht.

Ich hänge dir den gesamten Log mit an was innerhalb von Qemu und schließlich zum Ausfall der RTL8139 Emulation führt. Zusätzlich hänge ich dir den QEMU RTL8139 emulations Treiber mit an bevor Qemu gebaut wird wo du entnehmen kannst welche Funktionen der Virtuelle RTL8139 Treiber unterstützt. Vielleicht fehlt hier einfach auch etwas was für eine stabile Verwendung in Zusammenspiel mit den echten RTL8139 Treiber unter AmigaOs4.1 von Nöten ist. Wenn es dir deine Zeit zu lässt wirf doch mal ein blick drauf vielleicht wirst du daraus schlau. Ich hingegen hab von den dingen absolut keine Ahnung kann dir aber zu mindestens ein paar Protokolle oder dich mit informationen füttern was es dir vielleicht etwas einfacher machen könnten als das du alles irgendwie selber herausfinden mußt.

Unter Qemu AmigaOs4.1 funktioniert das internet wie bereits erwähnt, Download/Upload bzw. Netzwerk Verbindungen sind möglich, auch das kopieren einzelner großer Dateien sind möglich z.B. kann ich mit Odyssey mehrere Dateien von Os4Depot runterladen und vom Netzwerk Freigabe Verzeichnis SMB2 eine einzelne Datei (800MB) vom Host zum Gast über SMB2 AmigaOs4.1 übertragen, was dann im selben Moment stattfindet. Sobald ich aber beim aktiven Download mehrere kleinere Dateien über SMB2 kopiere bricht das gesamte Netzwerk zusammen bzw. die Verbindung geht verloren.

[aros-sg]

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.

Überprüfen ob nicht evtl. do_receive() reentrant aufgerufen wird (wegen bug oder was auch immer?), oder gar von 2 (qemu) threads gleichzeitig. VIelleicht so:

Code: Alles auswählen

static ssize_t rtl8139_receive(NetClientState *nc, const uint8_t *buf, size_t size)
{
    ssize_t ret;

   DPRINTF("reveive() ENTER: %p\n", &nc);    
    ret = rtl8139_do_receive(nc, buf, size, 1);
   DPRINTF("reveive() EXIT: %p\n", &nc);

   return ret;
}

Folgendes wäre dann okay:

Code: Alles auswählen

ENTER 0x12345678
EXIT 0x12345678
ENTER 0xABCDABCD
EXIT 0xABCDABCD

Folgendes wäre dann nicht okay:

Code: Alles auswählen

ENTER 0x12345678
ENTER 0xABCDABCD
EXIT 0xABCDABCD
EXIT 0x12345678

[aros-sg]

Falls das "nicht okay" ausfällt: schnelles googeln:

"Fix DMA MMIO reentrancy issues":
https://gitlab.com/qemu-project/qemu/-/issues/556

Vielleicht ist Problem irgendwas in der Richtung.

[Maijestro]

@aros-sg

Vielleicht könntest du dir auch zusätzlich die Protokolle die ich weiter oben im thread hochgeladen habe angucken. Wie gesagt der Debug Log zeigt den gesamten start von Qemu mit Virtuellen RTL8139 bis hin zum abbrechen der Netzerkverbindung unter AmigaOs4.1.

[aros-sg]

Vielleicht könntest du dir auch zusätzlich die Protokolle die ich weiter oben im thread hochgeladen habe angucken.

Ich kenn' mich mit Netzwerk Kram nicht aus, aber der erwähnte ~"Logik Fehler" im debug output kann man unabhängig davon sehen. Es ist ja so:

Code: Alles auswählen

rtl8139_do_receive()
{
   ...
   debug("in ring rx mode")
   if (something)
   {
     debug("overflow");
     return;
   }
   
   ...
   
   rtl_8139_write_buffer();
   rtl_8139_write_buffer();

   ...
   
   debug("recevied: bla bla bla");   
}

Wenn dann im Debug Output "in ring rx mode" mehrmals aufscheint, ohne daß dazwischen auch "overflow" oder "received" erscheint, dann kann da das nur sein wenn mehrere qemu threads da gleichzeitig do_receive() aufrufen würden (= unwahrscheinlich), oder wenn (= wahrscheinlich) rtl_8139_write_buffer() indirekt (DMA Kram) reentrant wieder in rtl_8139_do_receive() springt, was zu 99 % nicht so vorgesehen sein wird.

[balaton]

Das macht immer noch kein sinn für mich. Auch wenn do_receive ist mehrmals aufgeruft, sollte es später eine der exit log zeilen aufscheinen aber ich sehe keine in die Protokolle danach wo es shiefgegangen ist. rtl8139_write_buffer kann nicht wieder in do_receive rufen so es scheint aufhängen in rtl8139_write_buffer, aber do_receive ist danach trotzdem erneut afgeruft wird and hängt auch. rtl8139_write_buffer am ende ruft qemu/system/physmem.c::address_space_rw() wo gibt es ein RCU_READ_LOCK_GUARD(). Vielleicht es ist ein deadlock dort? Aber kann ich nicht aus diese Protokolle feststellen was könnte das lock halten weil es sieht aus so zeilen fehlen oder sind übergeschrieben in der Protokolle.

Könntest du bitte es noch mal versuchen eine Protokolle aufzeichnen mit >logfile.txt 2>&1 am ende der qemu-system-ppc aufruf anhängen falls es war nicht so aufgezeichnet? Und auch eine Protokolle mit letztem AmigaOS Treiber version von Update 2 machen so wir es sehen kann was das macht. Es könnte sein das andere OS Treibern die C+ mode beutzen also nie dieses Problem treffen. Vielleicht solllte AmigaOS Treiber auch C+ mode benutzen.

Ich hoffe was ich schreibe kann man verstehen. Ich kann Deutsch gut lesen aber weniger scheiben.

[aros-sg]

Sollte es endlos reentern/recursen (oder evtl. ab irgendeiner Tiefe hängen) gäbe es auch keine exit log zeilen. Aber eigentlich (falls es nicht hängt, wo dann auch der debug output aufhören müßte) sollte QEmu dann früher oder später wegen stack overflow crashen. Ich weiß ja nicht wie schnell die debug outputs kommen. Was passiert wenn man nach Netzwerk-Versagen QEmu noch länger unberührt laufen läßt?

Und wie schnell kommen diese debug outputs vor und nach Netzwerk versagen? QEmu mal so starten

Code: Alles auswählen

qemu <args> | grep "in ring" -A 1 | nl

Damit werden nur debug zeilen angezeigt die "in ring" beinhalten und jeweils die Zeile danach. Und "nl" fügt Zeilennummern Counter voran, damit man sieht wie schnell der Output kommt.

[Maijestro]

@balaton

Könntest du bitte es noch mal versuchen eine Protokolle aufzeichnen mit >logfile.txt 2>&1 am ende der qemu-system-ppc aufruf anhängen falls es war nicht so aufgezeichnet? Und auch eine Protokolle mit letztem AmigaOS Treiber version von Update 2 machen so wir es sehen kann was das macht. Es könnte sein das andere OS Treibern die C+ mode beutzen also nie dieses Problem treffen. Vielleicht solllte AmigaOS Treiber auch C+ mode benutzen.

Wo wird das logfile gespeichert?

[aros-sg]

@balaton

Könntest du bitte es noch mal versuchen eine Protokolle aufzeichnen mit >logfile.txt 2>&1 am ende der qemu-system-ppc aufruf anhängen falls es war nicht so aufgezeichnet? Und auch eine Protokolle mit letztem AmigaOS Treiber version von Update 2 machen so wir es sehen kann was das macht. Es könnte sein das andere OS Treibern die C+ mode beutzen also nie dieses Problem treffen. Vielleicht solllte AmigaOS Treiber auch C+ mode benutzen.

Wo wird das logfile gespeichert?

Das bestimmst du ja selbst: "programm >logfile.txt 2>&1" würde den normalen ("stdout") output eines Programms (qemu) in logfile.txt speichern und "2> &1" bedeutet der Fehler ("stderr") output soll auch dahin.

Wenn man den output sowohl in der Shell (also in Echtzeit sichtbar) als auch in nem File haben will, dann kann kann "programm | tee logfile.txt" bzw. "programm 2>&1 | tee logfile.txt" benutzen. "tee" liest hier über stdin den output von "programm" und schreibt ihn nochmal raus sowohl nach stdout (in diesem Beispiel Shell), also auch in das angegebene File (in diesem Beispiel "logfile.txt").