☰

解决了 ：）

tag-icon • tag-icon boot memory bios uefi efi
解决了 ：）

这或多或少是

什么硬件设备占用了我的 4GB RAM 中的 1.4GB？

虽然我或多或少接受了那里的解决方案，但出于某些神秘的原因，在 BIOS 升级后，我的图形适配器突然保留了 1.4GB 内存（而不是动态保留），现在（我的笔记本电脑保修期满 2 周后），除了尝试了一些 Linux 实时 CD（其中一些是从 USB 密钥回送启动的）并多次将启动选项从 UEFI 更改为 BIOS CSM 并返回之外，没有做任何特别的事情，突然又保留了 800MB。

需要说明的是，这不是 Windows 的问题 - memtest 和 Linux 都可以看到该数量的内存。只有 Lenovo Diagnostics 仍然可以看到完整的 4GB 内存（并且它对其进行了测试，没有发现任何错误）

以下是图形驱动程序诊断工具和资源监视器的屏幕截图：

新情况

（作为参考，之前为硬件保留了 1435MB，最大图形内存为 1138 MB）。

这显然使问题变得更加紧迫，因为现在我的一半内存“被硬件保留”。

输出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 shell - 并转储了更多信息。我真的不知道这是怎么回事，但也许这对某些人有帮助：

内存映射

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 新手，BS_data 是什么意思？)

dh-d

http://pastebin.com/KH1rFehj

（dh -v 陷入无限循环，无法转储......）

数据存储库（我删除了我的 Windows 8 产品密钥）：

http://pastebin.com/iYPcbpEY

任何想法或其他方法来回收这个内存（有人知道是否有一种可行的方法可以完全重置 UEFI NVRAM 而不会使机器无法启动？）都非常感谢...

编辑1

在 UEFI 模式下启动 Linux 时，大部分内存都是可用的。

/proc/meminfo

/proc/iomem

消息

但是在兼容 BIOS 模式下启动它（通过 CSM）时不是：

/proc/iomem

消息

所以可能是 CSM 中的一个错误？（但它突然出现还是令人惊讶......）

由于我的主要操作系统是 Windows (7)，我想我必须升级到 8(.1) 并在 GPT 分区上执行完全重新安装才能使用 UEFI。考虑到 UEFI 仍然经常导致的问题，我不确定是否要走这条路……

编辑2

我也在联想论坛上发布了有关此问题的帖子，但目前尚无回复： 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-and/td-p/1539272

我还（只是为了排除这个原因）取出了 CMOS 电池，但除了我在“底门”（硬盘和 RAM 隐藏在盖子后面）上发现一些黑色指纹外，并没有发现任何异常。

编辑3

没什么消息，联想的一个人跟进了我在论坛上的帖子，并说会有工程师查看。让我们期待最好的结果。

编辑4

又有 21MB 丢失了，这次是因为尝试通过 UEFI 安全启动来启动 Linux 发行版...更多详细信息请参阅联想论坛中上述主题。

失去更多记忆

答案1

解决了 ：）

原因似乎是 UEFI 实现中的一个奇怪的特性，在开源 TianoCore 实现中也可以看到这一点：

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

在最后一次 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，更改设置等，这些变量从未改变（并且我认为它们存储了一些有关我安装的 RAM 的品牌/型号或类似信息）。

现在我的内存减少了，MemoryTypeInformation 的值被备份为 MemoryTypeInformationBackup（覆盖了旧备份），并且值中只有一个 DWORD 发生了变化 - 在偏移量 0x34 处：旧值为 0x4000，新值为 0x5582。差异是 0x1582 或十进制的 5506，这与我上次内存缩减的页面数（4K 块）完全匹配。

更进一步：MemoryTypeInformation 和 MemoryTypeInformationBackup 的旧值也恰好有一个值不同（但偏移量不同，为 0x44）。再次比较它们的值时，0x2F4C0 或十进制的 193728 恰好又是我上次内存缩减的页面数（当起始地址从 871F2000 更改为 57D32000 时）。

将其与前面提到的 TianoCore 代码进行比较，这突然变得完全合理了：

每当系统即将启动启动选项时，都会触发此代码，它会验证不同的 UEFI 内存区域分配的页面是否少于 MemoryTypeInformation 中存储的页面。如果不是，则内存映射不正确，变量会更新（使用当前分配的 125%）并触发重新启动，以便可以从最新数据重建内存映射。请注意，实现永远不会减少任何内存类型的缓存大小，因此此处的任何更改都将是永久性的。

这里的问题是，如果 UEFI 启动失败，它会将您带回到启动选择菜单（或者如果它是默认启动顺序中的设备，则尝试下一个设备）。由于大多数 UEFI 启动加载程序在启动失败后不会自行清理，因此一旦启动下一个菜单，此代码就会检测到已分配了更多内存，因此决定必须更新内存映射，以便后续操作系统不会出现问题。不幸的是，每次启动失败都会重复此操作，因此最终会有一个“硬限制”，限制您启动失败的次数 :-(

TianoCore 中的代码还提供了回退选项，以防变量丢失或格式错误（如果我理解正确的话，可能需要您额外重启两次），但考虑到联想甚至包含了一个备份变量（TianoCore 中不存在），我决定不相信这个回退选项，而是恢复到我拥有的最旧的备份，减去 LoaderData 类型的 800 MB，这为我提供了有效的 667 MB 硬件保留内存（目前已经足够好了）。而且它有效 :)

已解决的记忆图

得到教训

  • 当 UEFI 启动失败并且您返回到启动菜单时，切勿尝试启动任何其他东西，最好重置系统（我希望这不会触发代码；如果触发，我会更新帖子）

  • EFI Shell 有一个非常实用的十六进制编辑器，可以编辑 EFI 变量并修复这些问题。

  • 即使您的供应商不能或不想帮助您 - 保持固执；最终您会找到解决方案（即使几个月后）

相关内容