Software > Alternative Betriebssysteme

256MB TT-RAM und MinT streikt

<< < (10/15) > >>

mfro:

--- Zitat von: DonQuichote am Fr 10.08.2018, 07:34:03 ---
--- Zitat von: mfro am Fr 10.08.2018, 06:56:52 ---Schnellschuss: kannst Du das mal bitte (ungezipt, natürlich) in deinen Autoordner stecken und *vor* MiNT starten?

Damit sollte dein TT-RAM um 16 MByte "gekürzt" werden und damit die MMU-Tables gerade noch ausreichen.

--- Ende Zitat ---

Bombt leider immer noch mit MP=on.
CUTMEM.PRG habe ich vor MINT030.PRG im AUTO.

Gegenprobe unter TOS:

CUTMEM inaktiv: 249MB TT-TAM frei
CUTMEM aktiv: 249MB TT-TAM frei - sollten hier 16MB weniger sein, oder?

--- Ende Zitat ---

Ja, sollten. Eigentlich kann man da nicht viel falsch machen, aber ich hab's anscheinend doch geschafft:


--- Code: ---#include <mintbind.h>
 
unsigned long *memtop = (unsigned long *) 0x5a4;

void cutmem(void)
{
    *memtop -= 16 * 1024UL * 1024UL;
}

int main(int argc, char *argv[])
{
    Supexec(cutmem);

    return 0;
}

--- Ende Code ---

Schnellschuss halt. Fällt jemand was dran auf? Ich hab' jetzt grade keine Zeit, aber werde mir das am WE nochmal anschauen.

Entweder ich habe einen Denkfehler oder das gepatchte TOS macht *nach* dem Autoordner noch was mit memtop.

czietz:
Ich vermute, der Denkfehler ist wie folgt: MiNT besorgt sich sein Alt-RAM ja von TOS, via Mxalloc. Wenn Du also aus dem AUTO-Ordner -- und damit, nach der Initialisierung von GEMDOS -- etwas an ramtop änderst, wird MiNT trotzdem von GEMDOS noch den Speicherbereich oberhalb von 256 MB angeboten bekommen. Beim Zugriff darauf kommt's dann zum Absturz.

PS: Außerdem sollte Dein Programm volatile auf die Variable zugreifen, sonst könnte der C-Compiler den Zugriff glatt wegoptimieren. (Geschriebener Wert wird nie gelesen.)

mfro:

--- Zitat von: czietz am Fr 10.08.2018, 08:29:43 ---Ich vermute, der Denkfehler ist wie folgt: MiNT besorgt sich sein Alt-RAM ja von TOS, via Mxalloc. Wenn Du also aus dem AUTO-Ordner -- und damit, nach der Initialisierung von GEMDOS -- etwas an ramtop änderst, wird MiNT trotzdem von GEMDOS noch den Speicherbereich oberhalb von 256 MB angeboten bekommen. Beim Zugriff darauf kommt's dann zum Absturz.

--- Ende Zitat ---
Das ist der Grund. MiNT interessiert sich nur bei der Initialisierung der memory protection-Tabellen für ramtop, übernimmt aber ansonsten den GEMDOS-Speicher. So einfach ist's dann wohl doch nicht.


--- Zitat von: czietz am Fr 10.08.2018, 08:29:43 ---PS: Außerdem sollte Dein Programm volatile auf die Variable zugreifen, sonst könnte der C-Compiler den Zugriff glatt wegoptimieren. (Geschriebener Wert wird nie gelesen.)

--- Ende Zitat ---
Ist mir (nachträglich) auch aufgegangen, ist aber nicht das Problem (habe ich geprüft). Das Programm ist ohne Optimierung übersetzt und macht das Richtige.

Thorsten Otto:

--- Zitat von: czietz am Fr 10.08.2018, 08:29:43 ---wird MiNT trotzdem von GEMDOS noch den Speicherbereich oberhalb von 256 MB angeboten bekommen. Beim Zugriff darauf kommt's dann zum Absturz.
--- Ende Zitat ---

Das wird wohl das Problem sein. Die letzten 16MB werden vermutlich dann noch nicht wirklich benutzt, allerdings wird für einen Programmstart immer die größtmögliche TPA angelegt, und der Stackpointer wird auf das Ende derselben gesetzt. Das führt vertmutlich dazu daß dieser Stachon schon irgendwo benutzt wird bevor das Programm eine Chance hat die TPA zu verkleinern.

Als "Schnellschuss" seh ich im moment 3 Möglichkeiten:


* Das Auto-Ordner-Programm müsste sich durch die Memory-Listen hangeln, und die relevanten Bereiche ausketten, bzw. einfach den letzten Bereich verkleinern. Der Aufbau dieser Listen ist eigentlich dokumentiert, trotzdem vlt. nicht ganz trivial zu implementieren
* Das Auto-Ordner-Programm alloziert allen Speicher in Häppchen von 1MB, gibt dann alles wieder frei was nicht im kritischen Bereich ist, und beendet sich dann über Ptermres(). Der nicht freigegebene Bereich ist damit "weg"
* Man setzt bei allen Programm das "SMALL-TPA" Flag (gibt ein Tool names phbit3.prg dafür, oder man nimmt das "flags" tool aus dem mintbin Paket). Das sollte dafür sorgen daß nur noch der im Programm-Header angegebene Speicher als TPA benutzt wird. Nachteil: man müsste das wieder rückgängig machen, wenn der "richtige" Fix erfolgt ist. Ausserdem könnte es zu Problemen kommen bei Programmen die mit GCC übersetzt wurden, da der Stack bei diesen nicht Teil des BSS ist, und die TPA damit eigentlich zu klein ist. Das wird zwar vom Startup-Code wieder korrigiert, aber bis dahin könnte der für den Stack benötigte Speicher schon anderweitig belegt sein. Als Test könnte man das aber mal bei den Programmen versuchen, die bis einschliesslich des Desktop gestartet werden. Das cutmem Tool würde dann natürlich auch noch benötigt.

Thorsten Otto:
Um mich mal selber zu zitieren:


--- Zitat von: Thorsten Otto am Fr 10.08.2018, 15:12:14 ---Als "Schnellschuss" seh ich im moment 3 Möglichkeiten:

--- Ende Zitat ---

Es gab noch eine viel einfachere Möglichkeit, nämlich direkt in Mint. Ist momentan auch nur ein Workaround (die letzten 16MB sind dann nicht vefügbar)

Don, könntest du das bitte mal testen?

Snapshot-build ist mittlerweile durch, und kann unter https://bintray.com/freemint/freemint/download_file?file_path=snapshots%2Ffreemint-1-19-606-020.zip downgeloadet werden.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete