Welches Hardwaregerät hat 1,4 GB meines 4-GB-RAM-Speichers aufgebraucht, und jetzt, nachdem keine Hardwareänderungen vorgenommen wurden, sind es plötzlich 2,2 GB?


17

Dies ist mehr oder weniger eine Fortsetzung von

Welches Hardwaregerät verbraucht 1,4 GB meines 4 GB RAM?

Während ich dort die Lösung mehr oder weniger akzeptiert habe, die aus mysteriösen Gründen nach einem BIOS-Upgrade plötzlich 1,4 GB Speicher reservierte (anstatt ihn dynamisch zu reservieren), jetzt (2 Wochen nach Ablauf der Garantie meines Notebooks), nachdem dies geschehen ist nichts Besonderes, außer vielleicht ein paar Linux-Live-CDs auszuprobieren (von denen einige von einem USB-Stick gebootet wurden) und ein paar Mal die Boot-Optionen von UEFI auf BIOS CSM und zurück zu ändern. Plötzlich sind 800 MB mehr reserviert.

Und um es klar zu machen, es handelt sich nicht um ein Windows-Problem. Sowohl memtest als auch Linux sehen diese Speicherkapazität. Nur Lenovo Diagnostics erkennt noch die vollen 4 GB Arbeitsspeicher (und hat diesen getestet und keine Fehler festgestellt).

Hier sind Screenshots vom Grafiktreiber-Diagnosetool und vom Ressourcenmonitor:

Neue Situation

(Zu Referenzzwecken, bevor 1435 MB für Hardware reserviert waren und der maximale Grafikspeicher 1138 MB betrug).

Das macht das Problem natürlich sehr viel dringlicher, da jetzt die Hälfte meines Speichers "durch Hardware reserviert" ist.

Ausgabe von meminfo -ränderte sich nicht viel (der 4. Speicherbereich um fast 800 MB geschrumpft):

MemInfo v2.10 - Show PFN database information
Copyright (C) 2007-2009 Alex Ionescu
www.alex-ionescu.com

Physical Memory Range: 0000000000001000 to 000000000009D000 (156 pages, 624 KB)
Physical Memory Range: 0000000000100000 to 0000000020000000 (130816 pages, 523264 KB)
Physical Memory Range: 0000000020200000 to 0000000040004000 (130564 pages, 522256 KB)
Physical Memory Range: 0000000040005000 to 0000000057D32000 (97581 pages, 390324 KB)
Physical Memory Range: 0000000100000000 to 000000011F600000 (128512 pages, 514048 KB)
MmHighestPhysicalPage: 1177088

Da ich UEFI nach den vorangegangenen Geschichten mit Samsung und Lenovo nicht mehr vertraue, bin ich in die EFI-Shell gegangen - und habe ein paar weitere Informationen veröffentlicht. Ich weiß nicht genau, worum es geht, aber vielleicht hilft das jemandem:

memmap

Type       Start            End               # Pages          Attributes
BS_code    0000000000000000-0000000000000FFF  0000000000000001 000000000000000F
available  0000000000001000-000000000005AFFF  000000000000005A 000000000000000F
BS_data    000000000005B000-000000000005BFFF  0000000000000001 000000000000000F
BS_code    000000000005C000-0000000000086FFF  000000000000002B 000000000000000F
BS_data    0000000000087000-0000000000087FFF  0000000000000001 000000000000000F
BS_code    0000000000088000-000000000008FFFF  0000000000000008 000000000000000F
reserved   0000000000090000-000000000009FFFF  0000000000000010 000000000000000F
BS_code    0000000000100000-000000000010FFFF  0000000000000010 000000000000000F
available  0000000000110000-000000001FFFFFFF  000000000001FEF0 000000000000000F
reserved   0000000020000000-00000000201FFFFF  0000000000000200 000000000000000F
available  0000000020200000-0000000040003FFF  000000000001FE04 000000000000000F
reserved   0000000040004000-0000000040004FFF  0000000000000001 000000000000000F
available  0000000040005000-0000000057D31FFF  0000000000017D2D 000000000000000F
BS_data    0000000057D32000-0000000057D51FFF  0000000000000020 000000000000000F
available  0000000057D52000-000000005A34AFFF  00000000000025F9 000000000000000F
BS_data    000000005A34B000-000000005A360FFF  0000000000000016 000000000000000F
reserved   000000005A361000-000000005A562FFF  0000000000000202 000000000000000F
BS_data    000000005A563000-000000005AD21FFF  00000000000007BF 000000000000000F
available  000000005AD22000-0000000096B02FFF  000000000003BDE1 000000000000000F
LoaderData 0000000096B03000-0000000096B04FFF  0000000000000002 000000000000000F
available  0000000096B05000-0000000096B06FFF  0000000000000002 000000000000000F
LoaderData 0000000096B07000-0000000096B14FFF  000000000000000E 000000000000000F
LoaderCode 0000000096B15000-0000000096BD1FFF  00000000000000BD 000000000000000F
LoaderData 0000000096BD2000-00000000C9468FFF  0000000000032897 000000000000000F
available  00000000C9469000-00000000C9474FFF  000000000000000C 000000000000000F
LoaderCode 00000000C9475000-00000000C9668FFF  00000000000001F4 000000000000000F
available  00000000C9669000-00000000CA828FFF  00000000000011C0 000000000000000F
BS_data    00000000CA829000-00000000CAE22FFF  00000000000005FA 000000000000000F
available  00000000CAE23000-00000000CAE31FFF  000000000000000F 000000000000000F
BS_data    00000000CAE32000-00000000CD668FFF  0000000000002837 000000000000000F
available  00000000CD669000-00000000CDCD5FFF  000000000000066D 000000000000000F
BS_code    00000000CDCD6000-00000000D6268FFF  0000000000008593 000000000000000F
RT_code    00000000D6269000-00000000D6344FFF  00000000000000DC 800000000000000F
RT_code    00000000D6345000-00000000D6468FFF  0000000000000124 800000000000000F
RT_data    00000000D6469000-00000000D6FEDFFF  0000000000000B85 800000000000000F
RT_data    00000000D6FEE000-00000000D9E9EFFF  0000000000002EB1 800000000000000F
reserved   00000000D9E9F000-00000000DAC13FFF  0000000000000D75 000000000000000F
reserved   00000000DAC14000-00000000DAE9EFFF  000000000000028B 000000000000000F
ACPI_NVS   00000000DAE9F000-00000000DAF04FFF  0000000000000066 000000000000000F
ACPI_NVS   00000000DAF05000-00000000DAF9EFFF  000000000000009A 000000000000000F
ACPI_recl  00000000DAF9F000-00000000DAFD9FFF  000000000000003B 000000000000000F
ACPI_recl  00000000DAFDA000-00000000DAFFEFFF  0000000000000025 000000000000000F
BS_data    00000000DAFFF000-00000000DAFFFFFF  0000000000000001 000000000000000F
available  0000000100000000-000000011F5FFFFF  000000000001F600 000000000000000F
reserved   00000000000A0000-00000000000BFFFF  0000000000000020 0000000000000000
reserved   00000000DB000000-00000000DF9FFFFF  0000000000004A00 0000000000000000
MemMapIO   00000000F80F8000-00000000F80F8FFF  0000000000000001 8000000000000001
MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000001

  reserved  :  24,115 Pages (98,775,040)
  LoaderCode:     689 Pages (2,822,144)
  LoaderData: 207,015 Pages (847,933,440)
  BS_code   :  34,263 Pages (140,341,248)
  BS_data   :  13,865 Pages (56,791,040)
  RT_code   :     512 Pages (2,097,152)
  RT_data   :  14,902 Pages (61,038,592)
  available : 748,703 Pages (3,066,687,488)
  ACPI_recl :      96 Pages (393,216)
  ACPI_NVS  :     256 Pages (1,048,576)
  MemMapIO  :       5 Pages (20,480)
Total Memory: 3,985 MB (4,179,152,896) Bytes

(Was bedeutet BS_data als UEFI-Noob?)

dh -d

http://pastebin.com/KH1rFehj

(dh -v läuft in eine Endlosschleife und kann nicht ausgegeben werden ...)

dmpstore (Ich habe meinen Windows 8 Product Key bearbeitet):

http://pastebin.com/iYPcbpEY

Jegliche Ideen oder andere Möglichkeiten, diesen Speicher wiederzugewinnen (weiß jemand, ob es eine Möglichkeit gibt, das UEFI-NVRAM vollständig zurückzusetzen, ohne die Maschine zu booten?), Werden sehr geschätzt ...

EDIT1

Beim Booten von Linux im UEFI-Modus kann der größte Teil des Speichers verwendet werden.

/ proc / meminfo

/ proc / iomem

dmesg

Beim Booten im Kompatibilitäts-BIOS-Modus (über CSM) ist dies jedoch nicht der Fall:

/ proc / iomem

dmesg

Also wahrscheinlich ein Fehler im CSM? (Aber immer noch überraschend, dass es plötzlich auftaucht ...)

Da mein primäres Betriebssystem Windows (7) ist, muss ich wahrscheinlich auf 8 (.1) aktualisieren und eine vollständige Neuinstallation auf einer GPT-Partition durchführen, um UEFI nutzen zu können. Und angesichts der Probleme, die UEFI (noch) regelmäßig verursacht, bin ich mir nicht sicher, ob ich diesen Weg einschlagen möchte ...

EDIT2

Ich habe darüber auch einen Thread in den Lenovo-Foren gepostet, aber noch keine Antworten: http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 -4-GB-RAM-von-4-GB-reserviert-durch-Hardware-und / td-p / 1539272

Ich habe auch (nur um diese Ursache auszuschließen) die CMOS-Batterie entfernt, aber mit Ausnahme einiger dunkler Fingerabdrücke, die ich auf der "unteren Tür" (Deckel, hinter dem die Festplatte und der Arbeitsspeicher versteckt sind) gefunden habe, machte es mich nicht klüger.

EDIT3

Es gibt nicht viel Neues, ein Typ von Lenovo hat meinen Beitrag im Forum nachverfolgt und gesagt, ein Ingenieur wird es sich ansehen. Lass uns auf das Beste hoffen.

EDIT4

Weitere 21 MB haben den Staub aufgerissen, diesmal, weil sie versucht haben, eine Linux-Distribution über UEFI Secure Boot zu booten ... Weitere Informationen finden Sie im oben genannten Thread in den Lenovo-Foren.

mehr Speicher verloren


Haben Sie ein optionales BIOS für den Arbeitsspeicher? Vor allem irgendwelche Speicher-Remapping-Optionen?
David Schwartz

Nein, außer dem Deaktivieren des Speicherschutzes (DEP) gibt es keine solchen Optionen. Und vor allem bin ich mir zu 100% sicher, dass ich keine BIOS-Optionen außer der Boot-Priorität zwischen 1,4 GB und 2,2 GB geändert habe.
Mihi

Ich bin ein wenig verwirrt von der Frage, da Win7 ohnehin nur 3,5 GB oder weniger Ihres Speichers verwenden kann. Haben Sie die Vorschläge in diesem Artikel ausprobiert? support.microsoft.com/kb/978610
Debra

2
@Debra Es ist 64-Bit-Win7, das (sicher)> 3,5 GB verwenden kann (bei der Arbeit habe ich einen Computer mit 12 GB, auf dem Win7 ausgeführt wird). Und ja, ich habe (vor 4 Monaten, als ich meine letzte Frage gepostet habe)
mihi

Welche BIOS-Version verwenden Sie derzeit und welche war die vorherige? Haben Sie versucht, das BIOS bereits auf die Standardeinstellungen zurückzusetzen? Wie viel installierter / verwendbarer Speicher wird im Dialogfeld "Systemeigenschaften" angezeigt?
and31415

Antworten:


19

Gelöst :)

Die Ursache scheint ein seltsames Merkmal in der UEFI-Implementierung zu sein, das auch in der Open Source-TianoCore-Implementierung zu sehen ist:

https://github.com/tianocore/edk2/blob/master/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsMisc.c#L1425

Ich habe es letztendlich gefunden, nachdem ich meine EFI-Variablendumps nach dem letzten "Verlust" von 21 MB und dem Auffinden interessanter Variablen differenziert hatte:

Vor dem Verlust der letzten 21 MB Speicher

Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformationBackup' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 00 40 00 00-01 00 00 00 00 02 00 00 *.....@..........*
00000040: 02 00 00 00 78 F2 03 00-0E 00 00 00 00 00 00 00 *....x...........*
Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformation' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 00 40 00 00-01 00 00 00 00 02 00 00 *.....@..........*
00000040: 02 00 00 00 38 E7 06 00-0E 00 00 00 00 00 00 00 *....8...........*

Nachdem ich sie verloren habe

Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformationBackup' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 00 40 00 00-01 00 00 00 00 02 00 00 *.....@..........*
00000040: 02 00 00 00 38 E7 06 00-0E 00 00 00 00 00 00 00 *....8...........*
Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformation' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 82 55 00 00-01 00 00 00 00 02 00 00 *.....U..........*
00000040: 02 00 00 00 38 E7 06 00-0E 00 00 00 00 00 00 00 *....8...........*

Warum ist das so interessant? Ich habe die ganze Zeit über Dinge getestet, das BIOS aktualisiert und heruntergestuft, Einstellungen geändert usw. Diese Variablen haben sich nie geändert (und ich nahm an, dass sie einige Informationen über die Marke / das Modell meines installierten Arbeitsspeichers oder ähnliches speichern).

Nachdem sich mein Arbeitsspeicher verringert hatte, wurde der Wert von MemoryTypeInformation als MemoryTypeInformationBackup (Überschreiben der alten Sicherung) gesichert, und genau ein DWORD im Wert ändert sich - bei Offset 0x34: Alter Wert war 0x4000, neuer Wert ist 0x5582. Der Unterschied ist 0x1582 oder 5506 in Dezimalzahl, was genau der Anzahl der Seiten (4K-Blöcke) entspricht, die mein Speicher beim letzten Mal verkleinert hat.

Einen Schritt weiter gehen: Der alte Wert von MemoryTypeInformation und MemoryTypeInformationBackup unterscheidet sich auch in genau einem Wert (mit einem anderen Offset, 0x44). Beim erneuten Vergleich der Werte ist 0x2F4C0 oder 193728 in Dezimalzahl genau wieder die Anzahl der Seiten, die mein Speicher in der Zeit zuvor verkleinert hat (als sich die Startadresse von 871F2000 auf 57D32000 geändert hat).

Vergleicht man dies mit dem oben genannten TianoCore-Code, ergibt dies plötzlich einen Sinn:

Dieser Code wird ausgelöst, wenn das System im Begriff ist, eine Startoption zu starten, und überprüft, ob den verschiedenen UEFI-Speicherbereichen weniger Seiten zugeordnet sind als in MemoryTypeInformation gespeichert. Wenn nicht, ist die Speicherzuordnung falsch und die Variable wird aktualisiert (mit 125% der aktuell zugewiesenen Werte) und ein Neustart wird ausgelöst, sodass die Speicherzuordnung anhand der neuesten Daten neu erstellt werden kann. Beachten Sie, dass die Implementierung niemals die zwischengespeicherte Größe für einen beliebigen Speichertyp verringert, sodass Änderungen hier dauerhaft sind.

Das Problem hierbei ist, dass beim Fehlschlagen des UEFI-Starts wieder das Startauswahlmenü aufgerufen wird (oder, falls es sich um ein Gerät in der Standardstartreihenfolge handelt, das nächste Gerät ausprobiert wird). Da die meisten UEFI-Bootloader bei einem Startfehler nicht automatisch bereinigen, erkennt dieser Code, sobald das nächste Menü gestartet wird, dass etwas mehr Speicher zugewiesen wurde, und entscheidet daher, dass die Speicherzuordnung aktualisiert werden muss, damit die Das folgende Betriebssystem wird keine Probleme bekommen. Leider wiederholt sich dies bei jedem Startfehler, so dass es irgendwann eine "harte Grenze" dafür gibt, wie oft das Starten fehlschlagen kann :-(

Der Code in TianoCore verfügt auch über Fallback-Optionen für den Fall, dass die Variable fehlt oder fehlerhaft ist (was, wenn ich den Code richtig verstehe, bis zu zwei zusätzliche Neustarts kosten kann), aber unter Berücksichtigung der Tatsache, dass Lenovo sogar eine Backup-Variable enthält (welche existiert nicht in TianoCore), entschied ich mich, diesem Fallback nicht zu vertrauen und kehrte zu der ältesten Sicherung zurück, die ich hatte, minus 800 MB für den LoaderData-Typ, was mir einen effektiven reservierten Hardwarespeicher von 667 MB gibt (für den Moment gut genug). Und es funktioniert :)

Speicherbelegung gelöst

Gewonnene Erkenntnisse

  • Wenn ein UEFI-Start fehlschlägt und Sie zum Startmenü zurückkehren, versuchen Sie niemals, etwas anderes zu starten. Setzen Sie das System besser zurück. (Ich hoffe, dass der Code dann nicht ausgelöst wird. In diesem Fall aktualisiere ich den Beitrag.)

  • EFI Shell verfügt über einen gut verwendbaren Hex-Editor zum Bearbeiten von EFI-Variablen und zum Beheben dieser Probleme

  • Auch wenn Ihr Anbieter Ihnen nicht helfen kann oder will - bleiben Sie hartnäckig; Irgendwann werden Sie eine Lösung finden (auch wenn Monate später)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.