Jest to mniej więcej kontynuacja

Jakie urządzenie zużywa 1,4 GB mojej 4 GB pamięci RAM?

Chociaż mniej więcej zaakceptowałem rozwiązanie, które z jakiegoś tajemniczego powodu, po aktualizacji systemu BIOS moja karta graficzna nagle zarezerwowała 1,4 GB pamięci (zamiast rezerwować ją dynamicznie), teraz (2 tygodnie po wygaśnięciu gwarancji mojego notebooka) po wykonaniu nic specjalnego, może prócz wypróbowania kilku płyt CD z systemem Linux na żywo (niektóre z nich uruchomiono ponownie z klucza USB) i kilka razy zmieniając opcje uruchamiania z UEFI na BIOS CSM iz powrotem, nagle 800 MB więcej jest zarezerwowanych.

Żeby było jasne, nie jest to problem z systemem Windows - zarówno memtest, jak i Linux również widzą taką ilość pamięci. Tylko Lenovo Diagnostics wciąż widzi pełne 4 GB pamięci (przetestowało to i nie wykryło błędów)

Oto zrzuty ekranu z narzędzia diagnostycznego sterownika karty graficznej i monitora zasobów:

(Dla porównania, przed 1435 MB zarezerwowano na sprzęt, a maksymalna pamięć graficzna wynosiła 1138 MB).

Co oczywiście sprawia, że ​​problem jest o wiele pilniejszy, ponieważ teraz połowa mojej pamięci jest „zarezerwowana przez sprzęt”.

Wyjście meminfo -rnie zmieniło się zbytnio (czwarty zakres pamięci zmniejszył się o prawie 800 MB):

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

Ponieważ nie ufam już UEFI po poprzednich historiach z Samsungami i Lenovo, poszedłem do powłoki EFI - i rzuciłem kilka dodatkowych informacji. Naprawdę nie wiem, o co w tym wszystkim chodzi, ale może to komuś pomaga:

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

(jako noob UEFI, co oznacza BS_data?)

dh -d

http://pastebin.com/KH1rFehj

(dh -v działa w nieskończoną pętlę i nie można go zrzucić ...)

dmpstore (wyedytowałem mój klucz produktu Windows 8):

http://pastebin.com/iYPcbpEY

Jakiekolwiek pomysły lub inne sposoby na odzyskanie tej pamięci (czy ktoś wie, czy istnieje skuteczny sposób całkowitego zresetowania pamięci UEFI NVRAM bez powodowania, że ​​maszyna nie nadaje się do rozruchu?) Są bardzo mile widziane ...

EDYCJA 1

Podczas uruchamiania systemu Linux w trybie UEFI można wykorzystać większość pamięci.

/ proc / meminfo

/ proc / iomem

dmesg

Ale podczas uruchamiania w trybie zgodności BIOS (przez CSM) nie jest to:

/ proc / iomem

dmesg

Więc prawdopodobnie błąd w CSM? (Ale wciąż zaskakujące, że nagle się pojawia ...)

Ponieważ moim głównym systemem operacyjnym jest Windows (7), muszę zaktualizować system do wersji 8 (.1) i przeprowadzić pełną ponowną instalację na partycji GPT, aby móc korzystać z UEFI. Biorąc pod uwagę problemy, które UEFI powoduje (wciąż) regularnie, nie jestem pewien, czy chcę pójść tą drogą ...

EDYCJA 2

Opublikowałem także wątek na forach Lenovo na ten temat, ale do tej pory brak odpowiedzi: http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 -4-GB-RAM-of-4-GB-zarezerwowane-przez-sprzęt-i / td-p / 1539272

Ja również (żeby wykluczyć tę przyczynę) wyjąłem baterię CMOS, ale oprócz niektórych ciemnych odcisków palców, które znalazłem na „dolnych drzwiach” (pokrywce, za którą ukryty jest dysk twardy i pamięć RAM), nie uczyniłem mnie mądrzejszym.

EDYCJA 3

Niewiele nowości, jakiś facet z Lenovo śledził mój post na forum i powiedział, że jakiś inżynier go obejrzy. Miejmy nadzieję na najlepsze.

EDYCJA 4

Kolejne 21 MB ugryzło w pył, tym razem za próbę uruchomienia Linuksa za pośrednictwem Bezpiecznego rozruchu UEFI ... Więcej szczegółów w wyżej wspomnianym wątku na forach Lenovo.

Rozwiązany :)

Przyczyną wydaje się być dziwna funkcja w implementacji UEFI, którą można również zobaczyć w implementacji Open Source TianoCore:

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

Ostatecznie znalazłem to po różnicowaniu zrzutów zmiennych EFI po ostatniej „stracie” 21 MB i znalezieniu interesujących zmiennych:

Przed utratą ostatnich 21 MB pamięci

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...........*

Po ich utracie

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...........*

Dlaczego to takie interesujące: Cały czas testowałem rzeczy, aktualizowałem i obniżałem BIOS, zmieniałem ustawienia itp., Te zmienne nigdy się nie zmieniały (i zakładałem, że przechowują pewne informacje o marce / modelu mojej zainstalowanej pamięci RAM lub podobnej).

Teraz, gdy zmniejszyła się pamięć, utworzono kopię zapasową wartości MemoryTypeInformation jako MemoryTypeInformationBackup (nadpisując starą kopię zapasową) i zmienia się dokładnie jeden DWORD w wartości - przy przesunięciu 0x34: Stara wartość to 0x4000, nowa wartość to 0x5582. Różnica wynosi 0x1582 lub 5506 w systemie dziesiętnym, co dokładnie odpowiada liczbie stron (bloków 4K), które moja pamięć skurczyła się ostatnim razem.

Idąc o krok dalej: stara wartość MemoryTypeInformation i MemoryTypeInformationBackup również różni się dokładnie jedną wartością (choć z innym przesunięciem 0x44). Przy ponownym porównywaniu ich wartości, 0x2F4C0 lub 193728 w systemie dziesiętnym, jest to dokładnie liczba stron, które moja pamięć skurczyła się wcześniej (kiedy adres początkowy zmienił się z 871F2000 na 57D32000).

Porównując to ze wspomnianym kodem TianoCore, nagle ma to sens:

Ten kod jest uruchamiany za każdym razem, gdy system ma zamiar uruchomić opcję rozruchu, i weryfikuje, czy różne regiony pamięci UEFI mają mniej przydzielonych stron niż zapisane w MemoryTypeInformation. Jeśli nie, mapa pamięci jest niepoprawna, a zmienna jest aktualizowana (z 125% tego, co jest obecnie przydzielone) i uruchamiany jest restart, aby mapa pamięci mogła zostać odbudowana z najnowszych danych. Zauważ, że implementacja nigdy nie zmniejszy rozmiaru pamięci podręcznej dla dowolnego typu pamięci, więc każda zmiana tutaj będzie trwała.

Problem polega na tym, że jeśli rozruch UEFI nie powiedzie się, spowoduje to powrót do menu wyboru rozruchu (lub w przypadku, gdy było to urządzenie w domyślnej kolejności rozruchu, próbowane jest następne urządzenie). Ponieważ większość programów ładujących UEFI nie usuwa się po sobie w przypadku niepowodzenia rozruchu, natychmiast po uruchomieniu następnego menu ten kod wykryje, że przydzielono więcej pamięci, i dlatego postanawia zaktualizować mapę pamięci, aby następujący system operacyjny nie będzie miał problemów. Niestety powtarza się to przy każdej awarii rozruchu, więc w końcu istnieje „twardy limit” częstotliwości niepowodzenia uruchamiania :-(

Kod w TianoCore ma również opcje zastępcze na wypadek, gdyby zmienna była zaginiona lub zniekształcona (co, jeśli dobrze rozumiem kod, może kosztować cię nawet do dwóch dodatkowych restartów), ale biorąc pod uwagę fakt, że Lenovo zawiera nawet zmienną zapasową (która nie istnieje w TianoCore), postanowiłem nie ufać tej rezerwie i wróciłem do najstarszej kopii zapasowej, jaką miałem, minus 800 MB dla typu LoaderData, co daje mi efektywną zarezerwowaną pamięć 667 MB (wystarczającą na razie). I to działa :)

Zdobyta wiedza

• Gdy rozruch UEFI nie powiedzie się i wrócisz do menu rozruchu, nigdy nie próbuj uruchamiać niczego innego, lepiej zresetuj system (mam nadzieję, że nie uruchomi to wtedy kodu; jeśli tak, zaktualizuję wiadomość)

• EFI Shell ma całkiem użyteczny edytor szesnastkowy do edycji zmiennych EFI i rozwiązywania tych problemów

• Nawet jeśli twój sprzedawca nie może lub nie chce ci pomóc - pozostań uparty; w końcu znajdziesz rozwiązanie (nawet jeśli miesiące później)