Какое аппаратное устройство раньше потребляло 1,4 ГБ моей 4 ГБ оперативной памяти, а теперь внезапно, после отсутствия аппаратных изменений, расходует 2,2 ГБ?

Question

Это более или менее продолжение

Какое аппаратное устройство съедает 1,4 ГБ моей 4 ГБ оперативной памяти?

В то время как я более или менее принял решение, заключающееся в том, что по какой-то таинственной причине после обновления BIOS мой графический адаптер неожиданно зарезервировал 1,4 ГБ памяти (вместо того, чтобы резервировать ее динамически), но сейчас (через 2 недели после истечения срока гарантии на мой ноутбук), после выполнения Ничего особенного, за исключением, возможно, опробования нескольких живых компакт-дисков Linux (некоторые из них были загружены по шлейфу с USB-ключа) и несколько раз с изменением параметров загрузки с UEFI на BIOS CSM и обратно, внезапно резервируется еще 800 МБ.

И чтобы прояснить это, это не проблема Windows - и memtest, и Linux также видят этот объем памяти. Только Lenovo Diagnostics по-прежнему видит все 4 ГБ памяти (и она проверила и не обнаружила ошибок)

Вот скриншоты из инструмента диагностики графического драйвера и из монитора ресурсов:

(Для справки, до 1435 МБ были зарезервированы для оборудования, а максимальная графическая память была 1138 МБ).

Что, очевидно, делает проблему гораздо более актуальной, поскольку теперь половина моей памяти "зарезервирована аппаратно".

Вывод meminfo -r не сильно изменился (4-й диапазон памяти сократился почти на 800 МБ):

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 после предыдущих историй о Samsung и Lenovo, я пошел в оболочку 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, что означает BS_data?)

дх-д

http://pastebin.com/KH1rFehj

(dh -v работает в бесконечном цикле и не может быть сброшен ...)

dmpstore (я отредактировал мой ключ продукта Windows 8):

http://pastebin.com/iYPcbpEY

Любые идеи или любые другие способы восстановить эту память (кто-нибудь знает, есть ли рабочий способ полностью перезагрузить UEFI NVRAM, не делая машину не загружаемой?) очень ценятся ...

EDIT1

При загрузке Linux в режиме UEFI большая часть памяти используется.

/ Proc / MemInfo

/ Proc / iomem

dmesg

Но при загрузке в режиме совместимости с BIOS (через CSM) это не так:

/ Proc / iomem

dmesg

Так что, вероятно, ошибка в CSM? (Но все же удивительно, что это неожиданно возникает ...)

Поскольку моей основной ОС является Windows (7), я думаю, мне придется обновить ее до 8 (.1) и выполнить полную переустановку раздела GPT, чтобы использовать UEFI. И учитывая проблемы, которые UEFI (все еще) вызывает регулярно, я не уверен, хочу ли я идти этим путем ...

EDIT2

Я также разместил тему на форумах Lenovo по этому поводу, но пока никаких ответов: http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 -4-ГБ-RAM-оф-4-ГБ-зарезервирован-на-аппаратно-и / TD-п / 1539272

Я также (только чтобы исключить эту причину) удалил батарею CMOS, но, кроме некоторых темных отпечатков пальцев, которые я обнаружил на "нижней двери" (крышка, за которой скрыты жесткий диск и оперативная память), это не сделало меня более мудрым.

EDIT3

Не так много новостей, какой-то парень из Lenovo следил за моим постом на форуме и сказал, что какой-нибудь инженер посмотрит на это. Давайте надеяться на лучшее.

EDIT4

Еще 21 МБ укусил пыль, на этот раз за попытку загрузить дистрибутив Linux через UEFI Secure Boot ... Более подробно в вышеупомянутой теме на форумах Lenovo.

Answer 1

Решено :)

Причиной, по-видимому, является странная особенность в реализации UEFI, которую также можно увидеть в реализации TianoCore с открытым исходным кодом:

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

В конечном итоге я нашел его после того, как проанализировал дампы моих переменных EFI после последних 21 МБ "потерь" и нашел интересные переменные:

Прежде чем потерять последние 21 МБ памяти

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, менял настройки и т.д., Эти переменные никогда не менялись (и я предполагал, что они хранят некоторую информацию о марке / модели моего установленного ОЗУ или подобном).

Теперь, когда моя память уменьшилась, значение MemoryTypeInformation было скопировано как MemoryTypeInformationBackup (перезаписывает старую резервную копию), и ровно один DWORD в значении изменяется - по смещению 0x34: старое значение было 0x4000, новое значение 0x5582. Разница составляет 0x1582 или 5506 в десятичном формате, что в точности соответствует количеству страниц (4K блоков), когда моя память сократилась в последний раз.

Идем дальше: старые значения MemoryTypeInformation и MemoryTypeInformationBackup также отличаются ровно одним значением (хотя с другим смещением, 0x44). При повторном сравнении их значений, 0x2F4C0 или 193728 в десятичном виде, это точно снова число страниц, которые моя память сократила по сравнению с предыдущим временем (когда начальный адрес изменился с 871F2000 на 57D32000).

Сравнивая это с вышеупомянутым кодом TianoCore, это внезапно имеет смысл:

Этот код запускается всякий раз, когда система собирается загрузить параметр загрузки, и он проверяет, что в разных областях памяти UEFI выделено меньше страниц, чем в MemoryTypeInformation. Если нет, карта памяти неверна, и переменная обновляется (с 125% от того, что выделено в данный момент), и запускается перезагрузка, так что карту памяти можно восстановить из последних данных. Обратите внимание, что реализация никогда не уменьшит кэшированный размер для любого типа памяти, поэтому любое изменение здесь будет постоянным.

Проблема здесь в том, что если загрузка UEFI завершится неудачно, вы вернетесь обратно в меню выбора загрузки (или, если это было устройство в порядке загрузки по умолчанию, пробуется следующее устройство). Поскольку большинство загрузчиков UEFI не очищаются после сбоя при загрузке, как только загрузится следующее меню, этот код обнаружит, что выделено еще немного памяти, и поэтому решает обновить карту памяти, чтобы Следующая ОС не попадет в неприятности. К сожалению, это повторяется для каждого сбоя загрузки, так что в конечном итоге есть "жесткий предел" того, как часто вы можете потерпеть неудачу при загрузке :-(

В коде TianoCore также есть запасные варианты на случай, если переменная отсутствует или имеет неправильный формат (что, если я правильно понимаю, код может стоить вам до двух дополнительных перезагрузок), но учитывая тот факт, что Lenovo даже включила переменную Backup (которая не существует в TianoCore), я решил не доверять этому запасному варианту и вернулся к самой старой резервной копии, которая была у меня, минус 800 МБ для типа LoaderData, что дает мне эффективную аппаратную зарезервированную память 667 МБ (на данный момент достаточно). И это работает :)

Уроки выучены

• Когда загрузка UEFI завершается неудачно и вы возвращаетесь в меню загрузки, никогда не пытайтесь загружать что-либо еще, лучше перезагрузите систему (надеюсь, что тогда код не сработает; если это произойдет, я обновлю сообщение)

• EFI Shell имеет довольно удобный шестнадцатеричный редактор для редактирования переменных EFI и устранения этих проблем.

• Даже если ваш поставщик не может или не хочет вам помочь - оставайтесь упрямым; в конце концов вы найдете решение (даже если месяцы спустя)