mih*_*ihi 18 bios memory boot efi uefi
这或多或少是一个延续
虽然我或多或少地接受了那里的解决方案,但出于某种神秘的原因,在 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
(dh -v 陷入无限循环,无法转储...)
dmpstore(我编辑了我的 Windows 8 产品密钥):
非常感谢任何想法或任何其他方法来回收此内存(有人知道是否有一种可行的方法可以在不使机器无法启动的情况下完全重置 UEFI NVRAM?)...
编辑1
在 UEFI 模式下启动 Linux 时,大部分内存可用。
但是在兼容 BIOS 模式下(通过 CSM)启动它时,它不是:
所以可能是 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 实现中也可以看到:
在对最后 21MB 的“丢失”之后的 EFI 变量转储进行了比较并找到了有趣的变量后,我最终找到了它:
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 变量并修复这些问题
即使您的供应商不能或不想帮助您 - 保持固执;最终你会找到一个解决方案(即使几个月后)
| 归档时间: |
|
| 查看次数: |
3743 次 |
| 最近记录: |