Quel périphérique matériel utilisé pour consommer 1,4 Go de RAM 4 Go, et maintenant soudainement après aucun changement de matériel mange 2,2 Go?

17

C'est plus ou moins une continuation de

Quel périphérique matériel consomme 1,4 Go de RAM 4 Go?

Bien que j'aie plus ou moins accepté la solution, pour une raison mystérieuse, après une mise à niveau du BIOS, mon adaptateur graphique a soudainement réservé 1,4 Go de mémoire (au lieu de le réserver dynamiquement), maintenant (2 semaines après l'expiration de la garantie de mon ordinateur portable), après avoir fait rien de spécial, sauf peut-être essayer quelques CD live Linux (certains d'entre eux démarrés en boucle à partir d'une clé USB) et changer quelques fois les options de démarrage de UEFI en BIOS CSM et vice versa, 800 Mo de plus sont réservés.

Et pour que ce soit clair, ce n'est pas un problème Windows - memtest et Linux voient également cette quantité de mémoire. Seul Lenovo Diagnostics voit toujours les 4 Go de mémoire (et il l'a testé et n'a trouvé aucune erreur)

Voici des captures d'écran de l'outil de diagnostic du pilote graphique et du moniteur de ressources:

Nouvelle situation

(Pour référence, avant 1435 Mo étaient réservés au matériel et la mémoire graphique maximale était de 1138 Mo).

Ce qui rend évidemment le problème beaucoup plus urgent, puisque maintenant la moitié de ma mémoire est "réservée par le matériel".

La sortie de meminfo -rn'a pas beaucoup changé (la 4ème plage de mémoire a diminué de près de 800 Mo):

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

Comme je ne fais plus confiance à UEFI après les histoires précédentes avec Samsung et Lenovo, je suis allé dans le shell EFI - et j'ai vidé quelques informations supplémentaires. Je ne sais pas vraiment de quoi il s'agit, mais peut-être que cela aide quelqu'un:

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

(en tant que noob UEFI, que signifie BS_data?)

dh -d

http://pastebin.com/KH1rFehj

(dh -v s'exécute dans une boucle infinie et ne peut pas être vidé ...)

dmpstore (j'ai édité ma clé de produit Windows 8):

http://pastebin.com/iYPcbpEY

Toutes les idées ou autres moyens de récupérer cette mémoire (est-ce que quelqu'un sait s'il existe un moyen de réinitialiser complètement la NVRAM UEFI sans rendre la machine non amorçable?) Sont très appréciés ...

EDIT1

Lors du démarrage de Linux en mode UEFI, la majeure partie de la mémoire est utilisable.

/ proc / meminfo

/ proc / iomem

dmesg

Mais lors du démarrage en mode BIOS de compatibilité (via CSM), ce n'est pas:

/ proc / iomem

dmesg

Alors probablement un bug dans le CSM? (Mais tout de même surprenant qu'il surgisse soudainement ...)

Comme mon système d'exploitation principal est Windows (7), je suppose que je devrais passer à 8 (.1) et effectuer une réinstallation complète sur une partition GPT pour utiliser UEFI. Et vu les problèmes que l'UEFI cause (toujours) régulièrement, je ne sais pas si je veux emprunter cette voie ...

EDIT2

J'ai également publié un fil sur les forums Lenovo à ce sujet, mais aucune réponse jusqu'à présent: http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 -4 Go de RAM sur 4 Go réservés par matériel et / td-p / 1539272

J'ai également (juste pour exclure cette cause) retiré la batterie CMOS, mais à l'exception de quelques empreintes sombres que j'ai trouvées sur la "porte inférieure" (couvercle derrière lequel le disque dur et la RAM sont cachés), cela ne m'a pas rendu plus sage.

EDIT3

Pas beaucoup de nouvelles, un gars de Lenovo a suivi mon message sur le forum et a dit qu'un ingénieur y jetterait un œil. Esperons le meilleur.

EDIT4

21 Mo supplémentaires ont mordu la poussière, cette fois pour avoir essayé de démarrer une distribution Linux via UEFI Secure Boot ... Plus de détails dans le fil mentionné ci-dessus dans les forums Lenovo.

plus de mémoire perdue

boot  memory  bios  uefi  efi 
— mihi
source
Avez-vous un BIOS en option concernant la mémoire? Particulièrement des options de remappage de la mémoire?
— David Schwartz
Non, à l'exception de la désactivation de la protection de la mémoire (DEP), il n'y a pas de telles options. Et surtout, je suis certain à 100% que je n'ai changé aucune option du BIOS, à l'exception de la priorité de démarrage entre 1,4 Go et 2,2 Go mangé.
— mihi
Je suis un peu perplexe par la question, étant donné que Win7 ne peut utiliser que 3,5 Go ou moins de votre mémoire de toute façon. Avez-vous essayé les suggestions de cet article? support.microsoft.com/kb/978610
— Debra
2
@Debra C'est Win7 64 bits, qui (à coup sûr) peut utiliser> 3,5 Go (au travail, j'ai une machine avec 12 Go exécutant Win7). Et oui, je l'ai fait (il y a 4 mois quand j'ai posté ma dernière question)
— mihi
Quelle version du BIOS utilisez-vous actuellement et quelle était la précédente? Avez-vous déjà essayé de réinitialiser le BIOS à ses paramètres par défaut? Quelle est la quantité de mémoire installée / utilisable affichée dans la boîte de dialogue des propriétés système?
— and31415

Réponses:

19

Résolu :)

La cause semble être une caractéristique étrange dans l'implémentation UEFI, qui peut également être vue dans l'implémentation Open Source TianoCore:

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

Je l'ai finalement trouvé après avoir différencié mes vidages de variables EFI après la dernière "perte" de 21 Mo et trouvé des variables intéressantes:

Avant de perdre les 21 derniers Mo de mémoire

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...........*

Après les avoir perdus

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...........*

Pourquoi est-ce intéressant: tout le temps, j'ai testé des trucs, mis à niveau et rétrogradé le BIOS, changé les paramètres, etc., ces variables n'ont jamais changé (et j'ai supposé qu'elles stockaient des informations sur la marque / le modèle de ma RAM installée ou similaire).

Maintenant que ma mémoire a diminué, la valeur de MemoryTypeInformation a été sauvegardée en tant que MemoryTypeInformationBackup (écrasant l'ancienne sauvegarde) et exactement un DWORD dans les modifications de valeur - au décalage 0x34: l'ancienne valeur était 0x4000, la nouvelle valeur est 0x5582. La différence est 0x1582 ou 5506 en décimal, ce qui correspond exactement au nombre de pages (blocs 4K) que ma mémoire a rétréci la dernière fois.

Pour aller plus loin: l'ancienne valeur de MemoryTypeInformation et MemoryTypeInformationBackup diffère également en une seule valeur (à un décalage différent cependant, 0x44). Lorsque l'on compare à nouveau leurs valeurs, 0x2F4C0 ou 193728 en décimal, c'est exactement à nouveau le nombre de pages que ma mémoire a rétréci la fois précédente (lorsque l'adresse de début est passée de 871F2000 à 57D32000).

En comparant cela avec le code TianoCore susmentionné, cela est tout à fait logique:

Ce code est déclenché chaque fois que le système est sur le point de démarrer une option de démarrage et il vérifie que les différentes régions de mémoire UEFI ont moins de pages allouées que stockées dans MemoryTypeInformation. Sinon, la carte mémoire est incorrecte et la variable est mise à jour (avec 125% de ce qui est actuellement alloué) et un redémarrage est déclenché, afin que la carte mémoire puisse être reconstruite à partir des dernières données. Notez que l'implémentation ne diminuera jamais aucune taille mise en cache pour n'importe quel type de mémoire, donc tout changement ici sera permanent.

Le problème ici est que si le démarrage UEFI échoue, il vous remettra dans le menu de sélection de démarrage (ou dans le cas où il s'agissait d'un périphérique dans l'ordre de démarrage par défaut, le périphérique suivant est essayé). Comme la plupart des chargeurs de démarrage UEFI ne nettoient pas après eux-mêmes en cas d'échec de démarrage, dès que le menu suivant est démarré, ce code détectera qu'un peu plus de mémoire a été allouée et décide donc qu'il doit mettre à jour la carte mémoire afin que le le système d'exploitation suivant n'entrera pas en difficulté. Malheureusement, cela se répète pour chaque échec de démarrage afin qu'il y ait finalement une "limite stricte" de la fréquence à laquelle vous pouvez échouer au démarrage :-(

Le code dans TianoCore a également des options de secours au cas où la variable serait manquante ou mal formée (ce qui, si je comprends bien, peut vous coûter jusqu'à deux redémarrages supplémentaires), mais compte tenu du fait que Lenovo a même inclus une variable de sauvegarde (qui n'existe pas dans TianoCore), j'ai décidé de ne pas faire confiance à cette solution de repli et suis revenu à la plus ancienne sauvegarde que j'avais, moins 800 Mo pour le type LoaderData, ce qui me donne une mémoire réservée matérielle efficace de 667 Mo (assez bonne pour l'instant). Et il fonctionne :)

carte mémoire résolue

Leçons apprises

  • Quand un démarrage UEFI échoue et que vous revenez au menu de démarrage, n'essayez jamais de démarrer autre chose, mieux réinitialiser le système (j'espère que cela ne déclenchera pas le code alors; si c'est le cas, je mettrai à jour le message)

  • EFI Shell a un éditeur hexadécimal tout à fait utilisable pour éditer les variables EFI et résoudre ces problèmes

  • Même si votre fournisseur ne peut pas ou ne veut pas vous aider - restez têtu; finalement, vous trouverez une solution (même si des mois plus tard)

— mihi
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.