On 27.04.20 15:28, Sven Hartge wrote:
Marco Möller <talby@debianlists.mobilxpress.net> wrote:(Entschuldigt, dass ich doppelt antworte. Die parallele Antwort ist wohl eher ein ausführlicher Kommentar um Svens Fragen zu beantworten, während ich glaube hier tatsächlich auch einen Schritt weiter kommen zu können)On 27.04.20 12:57, Sven Hartge wrote:Sven Hartge <sven@svenhartge.de> wrote:Apr 27 11:19:12 NOTCH kernel: BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usableDie letzte Zeile zeigt, dass 1G (0x3fffffff) in den Bereich jenseits von 4G (0x100000000) gemappt worden ist.Kann man das irgendwie untersagen, damit also auch dieses 1 GB noch innerhalb der tatsächlich physikalisch nur vorhandenen 4 GB gemappt bleibt?Du hast meine Mail nicht komplett gelesen, oder?
Das hatte ich schon gemacht, aber offensichtlich dann eine Aussage nicht verstanden?
Ich erkläre dort deutlich, warum das BIOS zu diesem Remapping-Trick greift: Der Speicher, der remappt wird, wird vom PCI-I/O-Bereich überdeckt. Du hast dort also die Wahl zwischen zwei Dingen: 1) Der Speicherbereich ist verloren und nicht zugreifbar. 2) Der Speicherbereich wird remappt und damit nutzbar. Entweder -- oder.Wenn ich das richtig erahne, dann sollte ich danach allen meinen Speicher verfügbar haben, oder?Nein, weil zwischen den Adressen 3GB und 4GB *immer* der PCI-I/O-Bereich liegt, per definition. Je nach System wird mal mehr und mal weniger Speicher überdeckt, aber *immer* mindestens 256MB. Bei dir sind es, inkl. des Shared-Memory eher mehr, daher verbleiben *unterhalb* der Adresse von 4GB nur noch 2,9GB übrig. 1GB kann das System nach *oberhalb* der Adresse von 4GB remappen, damit verlierst du nur noch ein wenig mehr wie die 128MB Shared Memory für die GPU.
Mal sehen, ob ich es nun besser verstehe, das war nämliche eine mir sehr hilfreiche Erklärung mit Hintergrundinformationen die ich so noch nicht kannte: Der PCI I/O Bereich belegt bei mir aus irgend einem Grund sehr viel Speicher, ich sag mal der Einfachheit halber (das Shared Memory für die Grafikkarte da einfach mal bei gerechnet) knapp 1 GB, und da ich insgesamt nur 4 GB RAM habe bleiben mir in den Befehlen "free -m", "inxi -m", oder auch in "htop" nur die dann noch verbleibenden knapp 3 GB angezeigt und dem OS zum eigenen Schaffen zur Verfügung. Ich kann aber sehen, dass meine 4 GB RAM durchaus vollständig in Benutzung sind wenn ich dazu in das Log-File schaue, weil (nur) dort dieser bei mir mit knapp 1 GB belegter Speicher (wenigstens noch) aufgelistet wird.
Es gäbe dann manchmal noch ein "remapping" dieses für PCI I/O erforderlich zu reservierenden Speichers, damit er zu bestimmten Zwecken nicht im Adressbereich unter 4 GB sondern oberhalb dieser 4 GB Grenze Platz belegt, was bei mir im Speziellen aber keine Rolle spielt, da dieser Laptop kein RAM oberhalb von 4 GB hat wo etwas hin gemappt werden könnte.
Ich interpretiere das alles dann so, daß ich insgesamt also erstmal beruhigt sein kann. Bei mir scheint alles zu funktionieren, die Hardware und auch mein installiertes OS. Ich habe halt nur Pech, dass dieses Modell an Laptop weit mehr RAM für das ordnungsgemäße Funktionieren von PCI I/O abzwackt, als es mein anderer PC tut (in dem sehe ich von den eingebauten 8 GB RAM nämlich immer knapp 7.5 GB durch Befehlen wie "free -m" angezeigt (und hab diesen geringen "Verlust" immer dem Shared Memory zugeschrieben gehabt ohne mal wirklich nachzurechnen ob das auch wirklich stimmig sein könnte - das ist also Shared Memory + PCI I/O was da auch für die knapp 0,5 GB "Verschwinden" verantwortlich ist)). Die beiden Geräte brauchen einfach nur unterschiedlich viel Platz für dieses PCI I/O, und der Samsung P560 Laptop sogar so viel, daß ich zuerst dachte da würde was nicht funktionieren, ich dachte das Linux würde das eingebaute RAM gar nicht vollständig erkennen. Der Punkt ist aber wohl der, dass das RAM schon von der Hardware reserviert wurde und dem Linux daher gar nicht erst weiter zur Verfügung gestellt wird und daher für mich als Benutzer auch gar nicht mehr weiter in den üblichen Anzeigen auftaucht. Hoffentlich bin ich dem richtigen Verständnis nun näher gekommen.
Was passiert, wenn du einaml "mem=5G" als Parameter angibst?
Der Rechner bootet nicht mehr bei mem=5G. Ich hab es systematisch ausprobieren wollen, aber dann doch nur unsystematische Ergebnisse erhalten: Bei einem Wert sehr weit höher als 4G, zum Beispiel mem=4608M bleibt das Gerät mit einer letzten eingefrorenen Fehlermeldung stehen: "Physical KASLR disabled: no suitable memory region". Ein etwas niedrigerer Wert, zum Beispiel mem=4416M, leitet während des Bootens einen reboot ein, wie ich es anfangs berichtet hatte. Das passiert dann bis hinab zu mem=4362M, daß systematisch die Endlosschleife aus boot und reboot erreicht wird. Zwischen mem=4361M und mem=4224M scheint es so als wenn manchmal gebootet werden kann und manchmal nicht, völlig unsystematisch, selbst wenn ich wiederholt den identischen Wert eingebe kann ich nicht mehr vorhersehen was passieren wird, mal wird gebootet, mal erfolgt der reboot. Bei Werten nur knapp über 4096M, zum Beispiel für den Bereich zwischen mem=4096M und sogar mem=4223M scheint der Laptop zu booten, obwohl nur 4096M RAM in 2x 2 GB Riegeln drinnen stecken.