Ini kurang lebih merupakan kelanjutan dari

Perangkat hardware apa yang memakan 1.4GB RAM 4GB saya?

Sementara saya kurang lebih telah menerima solusi di sana bahwa untuk beberapa alasan misterius, setelah upgrade BIOS adapter grafis saya tiba-tiba mencadangkan memori 1.4GB (alih-alih memesan secara dinamis), sekarang (2 minggu setelah garansi notebook saya kedaluwarsa), setelah melakukan tidak ada yang istimewa kecuali mungkin mencoba beberapa live Linux CD (beberapa di antaranya loopback boot dari kunci USB) dan beberapa kali mengubah opsi boot dari UEFI ke BIOS CSM dan kembali, tiba-tiba 800MB lebih dicadangkan.

Dan hanya untuk memperjelas, ini bukan masalah Windows - memtest dan Linux juga melihat jumlah memori itu. Hanya Lenovo Diagnostics yang masih melihat memori penuh 4GB (dan ia mengujinya dan tidak menemukan kesalahan)

Berikut screenshot dari alat diagnostik driver grafis dan dari monitor sumber:

(Sebagai referensi, sebelum 1435MB dicadangkan untuk perangkat keras, dan memori grafis maks adalah 1138 MB).

Yang jelas membuat masalah jauh lebih mendesak, karena sekarang setengah dari memori saya "dicadangkan oleh perangkat keras".

Output dari meminfo -rtidak banyak berubah (kisaran memori ke-4 menyusut hampir 800MB):

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

Karena saya tidak lagi mempercayai UEFI setelah cerita sebelumnya dengan Samsung dan Lenovo, saya masuk ke shell EFI - dan membuang beberapa info lagi. Saya tidak benar-benar tahu apa ini semua, tapi mungkin ini membantu seseorang:

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

(sebagai noob UEFI, apa maksud BS_data?)

dh -d

http://pastebin.com/KH1rFehj

(dh -v berjalan ke loop tak terbatas dan tidak dapat dibuang ...)

dmpstore (Saya mengedit Kunci Produk Windows 8 saya):

http://pastebin.com/iYPcbpEY

Ada ide atau cara lain untuk mendapatkan kembali memori ini (apakah ada yang tahu jika ada cara yang berfungsi untuk mengatur ulang UEFI NVRAM sepenuhnya tanpa membuat mesin tidak dapat di-boot?) Sangat dihargai ...

EDIT1

Saat mem-boot Linux dalam mode UEFI, sebagian besar memori dapat digunakan.

/ proc / meminfo

/ proc / iomem

dmesg

Tetapi ketika mem-boot-nya dalam mode Compatibility BIOS (via CSM) itu bukan:

/ proc / iomem

dmesg

Jadi mungkin ada bug di CSM? (Tapi masih mengejutkan bahwa tiba-tiba muncul ...)

Karena OS utama saya adalah Windows (7), saya kira saya harus memutakhirkan ke 8 (.1) dan melakukan instal ulang penuh pada partisi GPT untuk menggunakan UEFI. Dan mengingat masalah yang disebabkan UEFI (masih) secara teratur, saya tidak yakin apakah saya ingin pergi ke rute itu ...

EDIT2

Saya juga memposting utas di Forum Lenovo tentang ini, tetapi sejauh ini tidak ada tanggapan: http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 -4-GB-RAM-of-4-GB-reserved-by-hardware-dan / td-p / 1539272

Saya juga (hanya untuk mengecualikan penyebab ini) melepas baterai CMOS, tetapi kecuali beberapa sidik jari gelap yang saya temukan di "pintu bawah" (tutup di mana hard disk dan RAM disembunyikan) itu tidak membuat saya lebih bijak.

EDIT3

Tidak banyak berita, beberapa pria dari Lenovo menindaklanjuti posting saya di forum dan mengatakan beberapa insinyur akan memeriksanya. Mari kita berharap untuk yang terbaik.

EDIT4

21MB lainnya telah menggigit debu, kali ini untuk mencoba mem-boot distro Linux melalui UEFI Secure Boot ... Lebih detail di utas yang disebutkan di atas di forum Lenovo.

Terpecahkan :)

Penyebabnya tampaknya menjadi fitur aneh dalam implementasi UEFI, yang juga dapat dilihat dalam implementasi Open Source TianoCore:

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

Saya akhirnya menemukannya setelah melakukan diffs variabel EFI saya setelah 21MB "loss" terakhir dan menemukan variabel yang menarik:

Sebelum kehilangan memori 21MB terakhir

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

Setelah kehilangan mereka

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

Mengapa ini menarik: Sepanjang waktu saya menguji hal-hal, meningkatkan dan menurunkan BIOS, mengubah pengaturan, dll, variabel-variabel ini tidak pernah berubah (dan saya berasumsi mereka menyimpan beberapa informasi tentang pembuatan / model RAM yang terpasang atau serupa).

Sekarang memori saya menurun, nilai MemoryTypeInformation mendapat cadangan sebagai MemoryTypeInformationBackup (menimpa cadangan lama) dan tepat satu DWORD dalam perubahan nilai - pada offset 0x34: Nilai lama 0x4000, nilai baru adalah 0x5582. Perbedaannya adalah 0x1582 atau 5506 dalam desimal, yang sama persis dengan jumlah halaman (4K blok) memori saya menyusut terakhir kali.

Melangkah lebih jauh: nilai lama MemoryTypeInformation dan MemoryTypeInformationBackup juga berbeda persis dalam satu nilai (pada offset yang berbeda, 0x44). Ketika membandingkan nilai-nilai mereka lagi, 0x2F4C0 atau 193728 dalam desimal, persis lagi jumlah halaman memori saya menyusut waktu sebelumnya (ketika alamat mulai berubah dari 871F2000 ke 57D32000).

Membandingkan ini dengan kode TianoCore yang disebutkan di atas, tiba-tiba ini masuk akal:

Kode ini dipicu setiap kali sistem akan mem-boot opsi boot, dan memverifikasi bahwa wilayah memori UEFI yang berbeda memiliki lebih sedikit halaman yang dialokasikan daripada disimpan dalam MemoryTypeInformation. Jika tidak, peta memori salah dan variabel diperbarui (dengan 125% dari apa yang saat ini dialokasikan) dan boot ulang dipicu, sehingga peta memori dapat dibangun kembali dari data terbaru. Perhatikan bahwa implementasi tidak akan pernah mengurangi ukuran cache untuk semua jenis memori, jadi setiap perubahan di sini akan permanen.

Masalahnya di sini adalah bahwa jika UEFI boot gagal, itu akan menempatkan Anda kembali ke menu pemilihan boot (atau jika itu adalah perangkat pada urutan boot default, perangkat berikutnya akan dicoba). Karena kebanyakan boot loader UEFI tidak membersihkan sendiri jika terjadi kegagalan boot, segera setelah menu berikutnya di-boot, kode ini akan mendeteksi bahwa ada lebih banyak memori yang telah dialokasikan dan oleh karena itu memutuskan untuk memperbarui peta memori sehingga OS berikut tidak akan mendapat masalah. Sayangnya ini berulang untuk setiap kegagalan boot sehingga pada akhirnya ada "batas keras" seberapa sering Anda bisa gagal boot :-(

Kode di TianoCore juga memiliki opsi mundur jika variabelnya hilang atau cacat (yang, jika saya mengerti kode dengan benar dapat dikenakan biaya hingga dua reboot tambahan), tetapi mengingat fakta bahwa Lenovo bahkan menyertakan variabel Cadangan (yang tidak ada di TianoCore), saya memutuskan untuk tidak mempercayai fallback ini dan kembali ke cadangan terlama yang saya miliki, minus 800 MB untuk tipe LoaderData, yang memberi saya memori cadangan perangkat keras 667 MB yang efektif (cukup baik untuk saat ini). Dan itu bekerja :)

Pelajaran yang dipetik

• Ketika boot UEFI gagal dan Anda kembali ke menu boot, jangan pernah mencoba untuk boot apa pun, lebih baik reset sistem (saya harap itu tidak akan memicu kode itu; jika itu terjadi, saya akan memperbarui posting)

• EFI Shell memiliki hex editor yang cukup dapat digunakan untuk mengedit variabel EFI dan memperbaiki masalah ini

• Bahkan jika vendor Anda tidak dapat atau tidak ingin membantu Anda - tetap keras kepala; akhirnya Anda akan menemukan solusi (bahkan jika berbulan-bulan kemudian)