什么硬件设备以前吃掉了我 4GB RAM 的 1.4GB,现在突然在没有硬件更改后吃掉了 2.2GB?

mih*_*ihi 18 bios memory boot efi uefi

这或多或少是一个延续

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

虽然我或多或少地接受了那里的解决方案,但出于某种神秘的原因,在 BIOS 升级后,我的图形适配器突然保留了 1.4GB 的内存(而不是动态保留),现在(我的笔记本保修到期后 2 周),在执行以下操作后除了尝试一些 Linux live CD(其中一些从 U 盘启动环回)和几次将启动选项从 UEFI 更改为 BIOS CSM 并返回之外,没有什么特别的,突然间又保留了 800MB。

并且明确地说,这不是 Windows 问题 - memtest 和 Linux 也看到了该数量的内存。只有联想诊断仍然可以看到完整的 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
Run Code Online (Sandbox Code Playgroud)

由于在三星和联想之前的故事之后我不再相信 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
Run Code Online (Sandbox Code Playgroud)

(作为 UEFI 菜鸟,BS_data 是什么意思?)

dh -d

http://pastebin.com/KH1rFehj

(dh -v 陷入无限循环,无法转储...)

dmpstore(我编辑了我的 Windows 8 产品密钥):

http://pastebin.com/iYPcbpEY

非常感谢任何想法或任何其他方法来回收此内存(有人知道是否有一种可行的方法可以在不使机器无法启动的情况下完全重置 UEFI NVRAM?)...

编辑1

在 UEFI 模式下启动 Linux 时,大部分内存可用。

/proc/内存信息

/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 发行版……有关联想论坛上述主题的更多详细信息。

更多的记忆丢失

mih*_*ihi 19

解决了 :)

原因似乎是 UEFI 实现中的一个奇怪的特性,在 Open Source 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...........*
Run Code Online (Sandbox Code Playgroud)

失去他们之后

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...........*
Run Code Online (Sandbox Code Playgroud)

为什么这很有趣:我一直在测试东西、升级和降级 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 变量并修复这些问题

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