Isso é mais ou menos uma continuação de
Qual dispositivo de hardware consome 1,4 GB da minha RAM de 4 GB?
Embora eu tenha aceitado mais ou menos a solução que, por algum motivo misterioso, após uma atualização do BIOS, meu adaptador gráfico repentinamente reservou 1,4 GB de memória (em vez de reservá-lo dinamicamente), agora (2 semanas após a garantia do meu notebook expirar), depois de fazer nada de especial, exceto talvez experimentar alguns live CDs do Linux (alguns deles inicializados a partir de uma chave USB) e algumas vezes alterar as opções de inicialização do UEFI para o BIOS CSM e vice-versa, de repente 800 MB a mais são reservados.
E, para deixar claro, esse não é um problema do Windows - o memtest e o Linux também veem essa quantidade de memória. Apenas o Lenovo Diagnostics ainda vê os 4 GB de memória completos (e o testou e não encontrou erros)
Aqui estão as capturas de tela da ferramenta de diagnóstico do driver gráfico e do monitor de recursos:
(Para referência, antes de 1435 MB eram reservados para hardware e a memória gráfica máxima era de 1138 MB).
O que obviamente torna o problema muito mais urgente, já que agora metade da minha memória é "reservada por hardware".
A saída de meminfo -rnão mudou muito (a quarta faixa de memória encolheu quase 800 MB):
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
Como não confio mais na UEFI após as histórias anteriores com Samsung e Lenovo, entrei no shell da EFI - e coloquei mais algumas informações. Eu realmente não sei do que se trata, mas talvez isso ajude alguém:
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
(como UEFI noob, o que significa BS_data?)
dh -d
(dh -v executa um loop infinito e não pode ser despejado ...)
dmpstore (editei minha chave de produto do Windows 8):
Todas as idéias ou outras maneiras de recuperar essa memória (alguém sabe se existe uma maneira de redefinir completamente a UEFI NVRAM sem tornar a máquina não inicializável?) São muito apreciadas ...
EDIT1
Ao inicializar o Linux no modo UEFI, a maior parte da memória é utilizável.
Mas ao inicializá-lo no modo BIOS de compatibilidade (via CSM), não é:
Então provavelmente um bug no CSM? (Mas ainda é surpreendente que de repente apareça ...)
Como meu sistema operacional principal é o Windows (7), acho que teria que atualizar para 8 (.1) e executar uma reinstalação completa em uma partição GPT para usar o UEFI. E considerando os problemas que a UEFI (ainda) está causando regularmente, não tenho certeza se quero seguir esse caminho ...
EDIT2
Também publiquei um tópico nos Fóruns da Lenovo sobre isso, mas nenhuma resposta até agora: http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 -4 GB de RAM de 4 GB reservados por hardware e / td-p / 1539272
Também removi (apenas para excluir essa causa) a bateria do CMOS, mas, exceto algumas impressões digitais escuras que encontrei na "porta inferior" (tampa atrás da qual o disco rígido e a RAM estão ocultos), isso não me deixou mais sábio.
EDIT3
Não são muitas notícias, um cara da Lenovo acompanhou o meu post no fórum e disse que algum engenheiro vai dar uma olhada nele. Vamos esperar pelo melhor.
EDIT4
Outros 21MB foram demais, desta vez para tentar inicializar uma distribuição Linux via UEFI Secure Boot ... Mais detalhes no tópico acima mencionado nos fóruns da Lenovo.
Respostas:
Resolvido :)
A causa parece ser um recurso estranho na implementação do UEFI, que também pode ser vista na implementação do Open Source TianoCore:
https://github.com/tianocore/edk2/blob/master/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsMisc.c#L1425
Eu finalmente o encontrei depois de diferenciar meus despejos de variáveis EFI após os últimos 21 MB de "perda" e encontrar variáveis interessantes:
Antes de perder os últimos 21 MB de memória
Depois de perdê-los
Por que isso é interessante: Durante todo o tempo em que testei coisas, atualizei e atualizei o BIOS, alterei configurações, etc., essas variáveis nunca foram alteradas (e presumi que elas armazenassem algumas informações sobre a marca / modelo da minha RAM instalada ou similar).
Agora que minha memória diminuiu, o valor de MemoryTypeInformation foi copiado como MemoryTypeInformationBackup (substituindo o backup antigo) e exatamente um DWORD nas alterações de valor - no deslocamento 0x34: o valor antigo era 0x4000, o novo valor é 0x5582. A diferença é 0x1582 ou 5506 em decimal, que corresponde exatamente ao número de páginas (blocos de 4K) em que minha memória diminuiu da última vez.
Indo um passo adiante: o valor antigo de MemoryTypeInformation e MemoryTypeInformationBackup também difere em exatamente um valor (embora em um deslocamento diferente, 0x44). Ao comparar seus valores novamente, 0x2F4C0 ou 193728 em decimal, é exatamente novamente o número de páginas que minha memória diminuiu no tempo anterior (quando o endereço inicial mudou de 871F2000 para 57D32000).
Comparando isso com o código TianoCore mencionado anteriormente, isso repentinamente faz todo sentido:
Esse código é acionado sempre que o sistema está prestes a inicializar uma opção de inicialização e verifica se as diferentes regiões de memória UEFI têm menos páginas alocadas do que armazenadas em MemoryTypeInformation. Caso contrário, o mapa de memória está incorreto e a variável é atualizada (com 125% do que está atualmente alocado) e uma reinicialização é acionada, para que o mapa de memória possa ser reconstruído a partir dos dados mais recentes. Observe que a implementação nunca diminuirá o tamanho do cache de qualquer tipo de memória; portanto, qualquer alteração aqui será permanente.
O problema aqui é que, se a inicialização do UEFI falhar, ele o levará de volta ao menu de seleção de inicialização (ou, caso seja um dispositivo na ordem de inicialização padrão, o próximo dispositivo será tentado). Como a maioria dos carregadores de inicialização UEFI não faz a limpeza após a falha, assim que o próximo menu é inicializado, esse código detecta que mais memória foi alocada e, portanto, decide que precisa atualizar o mapa de memória para que o OS seguintes não terão problemas. Infelizmente, isso se repete para todas as falhas de inicialização, para que eventualmente haja um "limite rígido" de quantas vezes você pode falhar na inicialização :-(
O código no TianoCore também possui opções de fallback, caso a variável esteja ausente ou malformada (o que, se eu entendi o código corretamente, pode custar até duas reinicializações extras), mas considerando o fato de a Lenovo incluir uma variável de backup (que não existe no TianoCore), decidi não confiar nesse fallback e reverti para o backup mais antigo que tinha, menos 800 MB para o tipo LoaderData, o que me proporciona uma memória reservada de hardware efetiva de 667 MB (boa o suficiente por enquanto). E funciona :)
Lições aprendidas
Quando uma inicialização UEFI falha e você retorna ao menu de inicialização, nunca tente inicializar mais nada, redefina melhor o sistema (espero que isso não acione o código; se ocorrer, atualizarei a postagem)
O EFI Shell possui um editor hexadecimal bastante útil para editar variáveis EFI e corrigir esses problemas
Mesmo que seu fornecedor não possa ou não queira ajudá-lo - mantenha-se teimoso; eventualmente, você encontrará uma solução (mesmo meses depois)
fonte