什么硬件设备曾经消耗了我4GB RAM中的1.4GB，现在突然在没有硬件更改的情况下吞噬了2.2GB？

17

这或多或少是

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

尽管我已经或多或少地接受了出于某种神秘原因的解决方案，但是在BIOS升级后，图形适配器突然保留了1.4GB的内存（而不是动态地保留它），现在（笔记本电脑的保修到期后两周）没什么特别的，除了可以尝试一些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框架-转储了更多信息。我真的不知道这是怎么回事，但这也许对某人有帮助：

记忆图

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陷入无限循环，无法转储...）

dmpstore（我编辑了Windows 8产品密钥）：

http://pastebin.com/iYPcbpEY

非常感谢您有任何想法或其他方式来回收此内存（有人知道是否存在一种在不使机器无法启动的情况下完全重置UEFI NVRAM的有效方法吗？）...

编辑1

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

/ proc / meminfo

/ proc / iomem

dmesg

但是，以兼容BIOS模式（通过CSM）引导它时，它不是：

/ proc / iomem

dmesg

那么可能是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通过硬件和// td-p / 1539272保留的4-GB--4-GB-RAM

我也（只是为了排除这个原因）卸下了CMOS电池，但是除了我在“底门”（位于后盖上隐藏了硬盘和RAM）上发现的一些深色指纹外，它并没有使我更加明智。

编辑3

消息不多，联想的一个家伙在论坛上跟进了我的帖子，并说一些工程师会对此进行关注。让我们期盼最好的结果。

编辑4

另有21MB占用了灰尘，这一次是尝试通过UEFI安全启动来启动Linux发行版。

更多的内存丢失

boot  memory  bios  uefi  efi 
— 三喜
source
您是否有与内存有关的BIOS可选件？特别是任何内存重新映射选项？
— David Schwartz
否，除了禁用内存保护（DEP）之外，没有其他选项。特别是我100％肯定除了在1.4GB和2.2GB之间的启动优先级之外，我没有更改任何BIOS选项。
— mihi 2014年
鉴于Win7可能只使用3.5GB或更少的内存，我对该问题感到有些困惑。您是否尝试过本文中的建议？support.microsoft.com/kb/978610
— Debra 2014年
2
@Debra这是64位Win7，（肯定）可以使用> 3.5GB（在工作中，我有一台运行Win7的计算机具有12GB）。是的，我做到了（4个月前，当我发布我的最后一个问题时）
— mihi 2014年
您当前使用的是哪个BIOS版本，而先前的是哪个版本？您是否已尝试将BIOS重置为其默认设置？系统属性对话框中显示的已安装/可用内存量是多少？
— and31415

Answers:

19

解决了 ：）

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

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

在将我的EFI变量转储与最后21MB的“损失”相比较并找到有趣的变量后，我最终找到了它：

在丢失最后的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中的代码还具有备用选项，以防变量丢失或格式不正确（如果我正确理解代码，则可能会花费多达两次额外的重启时间），但考虑到联想甚至包括Backup变量（在TianoCore中不存在），我决定不信任此后备，而是恢复为我拥有的最旧的备份，对于LoaderData类型，减去了800 MB，这为我提供了有效的667 MB硬件保留内存（目前足够好）。它有效:)

解决的内存映射

得到教训

  • 当UEFI引导失败并返回引导菜单时，切勿尝试引导其他任何东西，最好重设系统（我希望那样的话不会触发代码；如果这样做，我会更新该文章）

  • EFI Shell具有一个非常有用的十六进制编辑器，用于编辑EFI变量并解决这些问题

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

— 三喜
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.