どのハードウェアデバイスが4GBのRAMの1.4GBを消費していましたが、ハードウェアを変更しなかった後、突然2.2GBを消費しましたか？
これは多かれ少なかれの続きです
どのハードウェアデバイスが4GBのRAMの1.4GBを消費しますか？
いくつかの不思議な理由で、私は多かれ少なかれ解決策を受け入れましたが、BIOSのアップグレード後、グラフィックアダプタが突然1.4GBのメモリを予約しました（動的に予約するのではなく）、今（ノートブックの保証が切れてから2週間後）おそらくいくつかのLinuxライブCD（USBキーからループバックブートされたものもあります）を試してみて、ブートオプションをUEFIからBIOS CSMに数回変更したり、元に戻したりする以外は特別なことは何もありません。
そして明確にするために、これはWindowsの問題ではありません-memtestとLinuxの両方がその量のメモリも認識しています。 Lenovo Diagnosticsだけがまだ4GBのメモリ全体を認識しています（そしてそれをテストしてエラーは見つかりませんでした）
グラフィックドライバー診断ツールとリソースモニターのスクリーンショットは次のとおりです。
（参考までに、1435MBがハードウェア用に予約され、最大グラフィックメモリが1138MBになる前）。
私のメモリの半分が「ハードウェアによって予約されている」ので、これは明らかに問題をはるかに緊急にします。
meminfo -rの出力はあまり変化しませんでした（4番目のメモリ範囲はほぼ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
サムスンとレノボとの以前の話の後、UEFIを信頼しなくなったので、EFIシェルに入り、さらにいくつかの情報をダンプしました。私はこれが何であるかを本当に知りませんが、おそらくこれは誰かを助けます：
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
（UEFI noobとして、BS_dataはどういう意味ですか？）
dh -d
（dh -vは無限ループに陥り、ダンプできません...）
dmpstore（Windows 8のプロダクトキーを編集しました）：
このメモリを再利用するためのアイデアやその他の方法（マシンを起動できなくすることなくUEFI NVRAMを完全にリセットする有効な方法があるかどうか誰かが知っていますか？）は非常に高く評価されています...
EDIT1
LinuxをUEFIモードで起動すると、ほとんどのメモリが使用可能になります。
ただし、互換性BIOSモード（CSM経由）で起動する場合は、次のようにはなりません。
では、おそらくCSMのバグですか？ （しかし、それが突然現れるのはまだ驚くべきことです...）
私のプライマリOSはWindows（7）なので、UEFIを利用するには、8(.1)にアップグレードし、GPTパーティションで完全な再インストールを実行する必要があると思います。 UEFIが（まだ）定期的に引き起こしている問題、私はそのルートに行きたいかどうかわかりません...
EDIT2
また、これについてLenovoフォーラムにスレッドを投稿しましたが、これまでのところ応答はありません： http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG -最初-1-4-GB-RAM-of-4-GB-reserved-by-hardware-and/td-p/1539272
私も（この原因を除外するために）CMOSバッテリーを取り外しましたが、「下のドア」（ハードディスクとRAMは隠されています）それは私を賢くしませんでした。
EDIT3
あまりニュースはありませんが、Lenovoの何人かの男がフォーラムへの私の投稿をフォローアップし、エンジニアがそれを調べると言いました。のが最善の結果を期待してみましょう。
EDIT4
別の21MBがほこりをかみましたが、今回はUEFIセキュアブートを介してLinuxディストリビューションを起動しようとしました...詳細については、Lenovoフォーラムの上記のスレッドを参照してください。
解決しました:)
原因は、UEFI実装の奇妙な機能のようです。これは、オープンソースのTianoCore実装でも確認できます。
最後の21MBの「損失」の後で、EFI変数ダンプを比較し、興味深い変数を見つけた後、最終的にそれを見つけました。
最後の21MBのメモリを失う前
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...........*
それらを失った後
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...........*
これが興味深い理由：BIOSのテスト、BIOSのアップグレードとダウングレード、設定の変更などを行うたびに、これらの変数は変更されませんでした（インストールされたRAMまたは同様のもの）。
メモリが減少したので、MemoryTypeInformationの値はMemoryTypeInformationBackup（古いバックアップを上書き）としてバックアップされ、値の1つのDWORDが変更されます-オフセット0x34：古い値は0x4000、新しい値は0x5582です。違いは10進数で0x1582または5506であり、これは前回メモリが縮小したページ数（4Kブロック）と正確に一致します。
さらに一歩進んで、MemoryTypeInformationとMemoryTypeInformationBackupの古い値も、正確に1つの値が異なります（ただし、オフセットは異なりますが、0x44です）。それらの値を再度比較すると、10進数で0x2F4C0または193728は、以前（開始アドレスが871F2000から57D32000に変更されたとき）にメモリが縮小したページ数とまったく同じです。
これを前述のTianoCoreコードと比較すると、これは突然完全に理にかなっています。
このコードは、システムがブートオプションを起動しようとするたびにトリガーされ、異なるUEFIメモリ領域にMemoryTypeInformationに格納されているよりも少ないページが割り当てられていることを確認します。そうでない場合は、メモリマップが正しくなく、変数が更新され（現在割り当てられているものの125％で）、再起動がトリガーされるため、メモリマップを最新のデータから再構築できます。実装によってメモリタイプのキャッシュサイズが減少することはないため、ここでの変更は永続的であることに注意してください。
ここでの問題は、UEFIブートが失敗した場合、ブート選択メニューに戻ることです（または、デフォルトのブート順序のデバイスであった場合は、次のデバイスが試行されます）。ほとんどのUEFIブートローダーは起動に失敗した場合にクリーンアップしないため、次のメニューが起動されるとすぐに、このコードはさらにメモリが割り当てられていることを検出し、メモリマップを更新する必要があると判断します。以下のOSはトラブルになりません。残念ながら、これは起動に失敗するたびに繰り返されるため、最終的には起動に失敗する頻度に「厳しい制限」があります:-(
TianoCoreのコードには、変数が欠落しているか不正な形式である場合のフォールバックオプションもあります（ただし、コードを正しく理解している場合は、最大2回の追加の再起動が必要になる可能性があります）が、Lenovoにはバックアップ変数も含まれているという事実を考慮しています（ TianoCoreには存在しません）、私はこのフォールバックを信頼しないことに決め、私が持っていた最も古いバックアップに戻しました。LoaderDataタイプの800 MBを引いたもので、有効な667 MBのハードウェア予約メモリが得られます（今のところ十分です）。そしてそれは動作します:)
学んだ教訓
UEFIブートが失敗し、ブートメニューに戻った場合は、他のブートを試みないでください。システムをリセットすることをお勧めします（コードがトリガーされないことを願っています。トリガーされる場合は、投稿を更新します）
EFI Shellには、EFI変数を編集し、これらの問題を修正するための非常に便利な16進エディターがあります。
ベンダーがあなたを助けることができない、またはしたくない場合でも、頑固なままです。最終的には解決策が見つかります（数か月後であっても）