Il y a quelque temps, j'ai installé 16 Go de mémoire sur l'un de mes ordinateurs. Il a la carte mère
Foxconn P55MX avec un Core i5 750. Il serait possible de remplacer cet ancien processeur, mais il fonctionne toujours bien et fait tout ce dont j'ai besoin.
Voici ce qui est intéressant. La carte mère ne prend pas officiellement en charge 16 Go de RAM. Les spécifications de la page ci-dessus indiquent qu'un maximum de 8 Go est pris en charge. Il n'y a que deux emplacements sur la carte, donc je soupçonnais que les bandes de 8 Go n'étaient qu'une rareté au moment de la sortie de la carte mère. J'ai décidé d'essayer quand même. Dans de nombreux cas, les cartes mères prennent en charge plus de RAM que le fabricant ne le prétend officiellement.
Je me suis assuré que la dernière version du BIOS (version 946F1P06) était installée et j'ai inséré deux de mes versions de 8 gigaoctets. Ensuite, j'ai téléchargé Ubuntu 16.04, et tout a parfaitement fonctionné. J'ai décidé que ma théorie selon laquelle la carte prend en charge plus de mémoire que celle indiquée dans la documentation s'est avérée correcte, et j'ai oublié cela. J'ai aimé travailler avec de la RAM supplémentaire et j'étais content que le jeu ait payé.
Mais quelques mois plus tard, j'ai essayé de télécharger Windows 10. Fondamentalement, l'ordinateur fonctionne sous Linux. Parfois seulement, vous devez démarrer Windows pour vérifier quelque chose. C'est alors que le plaisir a commencé.
Lorsque GRUB est apparu, j'ai sélectionné Windows 10 dans le menu et appuyez sur Entrée. L'écran de démarrage de Windows est apparu brièvement, puis j'ai été immédiatement accueilli par l'écran bleu de la mort.
Code d'arrêt: ACPI_BIOS_ERROR. J'ai googlé beaucoup et découvert que l'essentiel est dans une sorte de problème avec les tables ACPI dans le BIOS. Entre autres, les tableaux ACPI indiquent au système d'exploitation comment configurer le matériel. La tentative de démarrage à partir du lecteur USB d'installation de Windows a entraîné la même erreur. Donc, je pense que Foxconn n'a pas menti. Cet ordinateur ne prend vraiment pas en charge 16 Go de RAM. Le retour à 8 Go a entraîné un téléchargement réussi. Les tests RAM étaient également excellents, donc ce n'est pas une mauvaise barre de mémoire.
J'ai essayé de contacter le support Foxconn pour réparer le BIOS, mais je n'ai pas reçu de réponse. L'adresse e-mail est répertoriée sur leur site Web, mais cela ne fonctionne pas. Peut-être que Foxconn ne traite plus de cartes mères. Il semble qu'ils ne fournissent pas non plus de soutien.
À ce stade, une personne ordinaire abandonnerait, résigné à 8 Go de mémoire ou achetant un nouvel ordinateur. Mais je ne voulais pas abandonner si facilement. Je savais que théoriquement un ordinateur pouvait utiliser 16 Go car il fonctionnait parfaitement sous Linux. J'ai donc commencé à apprendre ACPI et à expérimenter les paramètres du BIOS.
J'ai trouvé une section BIOS intéressante où vous pouvez jouer avec certains paramètres de mémoire. Un paramètre était la «fonction de remappage de la mémoire». Elle était incluse. La documentation du BIOS indique que l'option permet de "chevaucher la mémoire PCI" pour le mappage au-dessus de la mémoire physique partagée. Une recherche sur Internet a indiqué qu'il doit être activé lors du démarrage dans un système d'exploitation 64 bits. Juste pour des raisons d'expérience, je l'ai désactivé et Windows a vraiment démarré! Cependant, elle a déclaré qu'elle pouvait utiliser moins de 4 Go de RAM. Mais c'était bien: j'ai eu un moyen d'accéder à Windows sans avoir à retirer physiquement la barre de mémoire.
Ubuntu est le même. Avec la fonction de remappage de la mémoire désactivée, cela m'a limité à moins de 4 Go de RAM. Pour le moment, j'étais sûr qu'il y avait une sorte de problème de mappage de la mémoire. J'ai décidé d'étudier plus en détail l'erreur ACPI_BIOS_ERROR et ses causes - et je suis tombé sur
cet excellent document pour le débogage des pilotes Microsoft, qui explique la vérification des erreurs ACPI_BIOS_ERROR.
Selon le document, il était nécessaire de trouver quatre paramètres d'erreur qui étaient précédemment affichés sur un écran bleu dans les anciennes versions de Windows. Windows 10 masque toutes les informations par défaut, mais vous pouvez réactiver l'affichage d'informations d'erreur supplémentaires en ajoutant une entrée au registre. Voici une
excellente réponse sur superuser.com qui m'a orienté dans la bonne direction .
Après avoir modifié le registre en conséquence, j'ai à nouveau activé la fonction de remappage de la mémoire dans le BIOS et démarré Windows. BSOD affiche maintenant quatre codes supplémentaires dans le coin supérieur gauche:
Super! Ainsi, le paramètre 1 est 0x0000000000000002. La documentation de Microsoft indique que le paramètre 1, égal à 0x02, signifie un problème avec le traitement de la liste des ressources pour les bus racine PCI. Étant donné que les paramètres 2, 3 et 4 ressemblent à des valeurs folles, ce sont probablement des pointeurs. Et s'il n'y a que des pointeurs ici, Microsoft dit que le problème est que la zone de décodage PCI chevauche la liste des zones de mémoire renvoyées par le BIOS E820.
Ok Il y a beaucoup d'informations, mais vous pouvez commencer la recherche avec quelque chose. J'ai trouvé des informations sur la façon dont appeler le BIOS E820 fournit des informations sur les zones de mémoire. Il est ensuite retourné à Linux et a examiné toutes les informations de démarrage du noyau à l'aide de la commande dmesg, en accordant une attention particulière à l'E820 et à l'ACPI. Voici ce qui a été trouvé:
BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] utilisable
BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] réservé
BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] réservé
BIOS-e820: [mem 0x0000000000100000-0x00000000cf77ffff] utilisable
BIOS-e820: [mem 0x00000000cf780000-0x00000000cf78dfff] données ACPI
BIOS-e820: [mem 0x00000000cf78e000-0x00000000cf7cffff] ACPI NVS
BIOS-e820: [mem 0x00000000cf7d0000-0x00000000cf7dffff] réservé
BIOS-e820: [mem 0x00000000cf7ed000-0x00000000cfffffff] réservé
BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] réservé
BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffffffff] réservé
BIOS-e820: [mem 0x0000000100000000-0x000000042fffffff] utilisable
Plus tard, j'ai vu ceci:
acpi PNP0A08: 00: ignorer la fenêtre du pont hôte [mem 0x400000000-0xfffffffff
fenêtre] (conflits avec la RAM système [mem 0x100000000-0x42fffffff])
Pont hôte PCI vers le bus 0000: 00
pci_bus 0000: 00: ressource de bus racine [fenêtre io 0x0000-0x0cf7]
pci_bus 0000: 00: ressource de bus racine [fenêtre io 0x0d00-0xffff]
pci_bus 0000: 00: ressource de bus racine [fenêtre mem 0x000a0000-0x000bffff]
pci_bus 0000: 00: ressource de bus racine [fenêtre mem 0x000d0000-0x000dffff]
pci_bus 0000: 00: ressource de bus racine [fenêtre mem 0xd0000000-0xdfffffff]
pci_bus 0000: 00: ressource de bus racine [fenêtre mem 0xf0000000-0xfed8ffff]
pci_bus 0000: 00: ressource de bus racine [bus 00-ff]
Ouais! Voir un avertissement de conflit? Je ne l'aurais pas remarqué, mais après avoir installé la mémoire, Linux a commencé à afficher ce message à chaque démarrage. J'ai essayé de démarrer sous Linux avec la fonction de remappage de mémoire désactivée dans le BIOS. Dans ce cas, la dernière région e820 a disparu de 0x100000000 à 0x42fffffffff, et donc le message de conflit a également disparu, et une autre «ressource de bus racine» est apparue dans la liste avec la fenêtre de pont principale de 0x400000000 à 0xfffffffff.
Alors qu'est-ce qui se passe. Linux fonctionne avec 16 Go car il remarque un conflit et ignore la plage PCI conflictuelle fournie par ACPI, tandis que Windows lève la main de dégoût et crache un écran bleu: "Votre BIOS a un problème!" Je ne peux pas blâmer Windows. En effet, il y a chevauchement, vous pouvez donc comprendre qu'il est confus.
À ce stade, je ne savais pas s'il fallait continuer. Les 768 derniers Mo de mémoire, de 0x400000000 à 0x42fffffffffff, sont mappés au début de l'énorme zone d'espace mémoire que la carte mère utilise pour PCI. De toute évidence, si la carte mère attend PCI là-bas, quelque chose de vraiment grave peut se produire. Ainsi, la carte mère ne prend en charge que 15,25 Go de RAM, non?
Mais ... sous Linux, tout fonctionne très bien, sans le support de cette zone de mappage PCI supplémentaire! Que se passe-t-il si nous modifions en quelque sorte les tables ACPI de sorte qu'une grande plage PCI commence à partir de 0x430000000 au lieu de 0x400000000, c'est-à-dire immédiatement après la fin de la RAM physique. Ensuite, le conflit disparaîtrait et la majeure partie de la fenêtre de mappage PCI serait toujours disponible.
L'appel est accepté.
J'ai commencé à creuser dans les tables ACPI. Heureusement, Linux facilite le dumping. Il existe des outils spéciaux pour cela, mais les tableaux peuvent être facilement trouvés dans sysfs:
/ sys / firmware / acpi / tables
Les voici. J'ai également été ravi que GRUB ait la possibilité de remplacer vos tables ACPI par de nouvelles versions. Par conséquent, si vous découvrez quelle table est impliquée, vous pouvez installer une nouvelle version de cette table à l'aide de GRUB. Théoriquement, Windows en sera satisfait.
Entre autres outils, j'ai utilisé
iasl pour analyser diverses tables ACPI et trouver la valeur 0x400000000 à remplacer. Très probablement, cette valeur est dans l'ordre des octets inversés (little-endian) et de 64 bits, j'ai donc exécuté
binwalk pour rechercher tous les fichiers de la table:
binwalk -R '\ x00 \ x00 \ x00 \ x00 \ x04 \ x00 \ x00 \ x00' *
Il y avait un résultat dans le tableau OEMB. Le mot 64 bits suivant après il était 0x1000000000, légèrement plus grand que l'adresse de fin dans le message de conflit de la fenêtre de pont principal. Indice très prometteur. La table OEMB est spéciale car ce n'est pas une table standard selon les spécifications ACPI. Linux se plaint d'une somme de contrôle invalide, mais je ne pense pas que cela compte. Je suppose que vous devinez ce que j'ai fait ensuite ...
J'ai fait une copie de la table OEMB, en remplaçant l'octet 0x00 immédiatement avant l'octet 0x04 par 0x30 pour changer la valeur en 0x430000000 (rappelez-vous que c'est l'ordre inverse). J'ai placé cette copie modifiée dans le fichier /boot/oemb.dat. Puis il a utilisé GRUB pour remplacer la table OEMB par ma copie, en collant temporairement la commande suivante dans la liste des commandes de démarrage (en entrant la lettre «e» dans GRUB après avoir sélectionné Ubuntu):
acpi --exclude = OEMB /boot/oemb.dat
L'idée est qu'il indique à GRUB de charger toutes les tables ACPI à l'exception de la table OEMB, puis de charger le contenu de /boot/oemb.dat et de l'ajouter en tant que table supplémentaire. Cela remplacera efficacement l'ancienne table OEMB par la nouvelle table OEMB.
Ok, j'ai démarré Linux et ...
acpi PNP0A08: 00: ignorer la fenêtre du pont hôte [mem 0x400000000-0xfffffffff
fenêtre] (conflits avec la RAM système [mem 0x100000000-0x42fffffff])
. WTF? , PCI - , , . , OEMB , .
iasl DSDT. , DSDT
_CRS, .
iasl -d DSDT
.dsl _CRS, PCI, . DSDT , . _CRS . , _CRS , 0xCF78E064. Linux dmesg :
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x00000000000F9820 000014 (v00 ACPIAM)
ACPI: RSDT 0x00000000CF780000 000044 (v01 012110 RSDT0821 20100121 MSFT 00000097)
ACPI: FACP 0x00000000CF780200 000084 (v01 012110 FACP0821 20100121 MSFT 00000097)
ACPI: DSDT 0x00000000CF780460 006FE7 (v01 946F1 946F1P06 00000000 INTL 20051117)
ACPI: FACS 0x00000000CF78E000 000040
ACPI: APIC 0x00000000CF780390 00008C (v01 012110 APIC0821 20100121 MSFT 00000097)
ACPI: MCFG 0x00000000CF780420 00003C (v01 012110 OEMMCFG 20100121 MSFT 00000097)
ACPI: OEMB 0x00000000CF78E040 000082 (v01 012110 OEMB0821 20100121 MSFT 00000097)
ACPI: HPET 0x00000000CF78A460 000038 (v01 012110 OEMHPET 20100121 MSFT 00000097)
ACPI: GSCI 0x00000000CF78E0D0 002024 (v01 012110 GMCHSCI 20100121 MSFT 00000097)
ACPI: DMAR 0x00000000CF790100 000090 (v01 AMI OEMDMAR 00000001 MSFT 00000097)
ACPI: SSDT 0x00000000CF7917C0 000363 (v01 DpgPmm CpuPm 00000012 INTL 20051117)
! OEMB. . OEMB?
dmesg OEMB. , , , GRUB , OEMB, . , DSDT 0xCF78E064 OEMB. - , - . .
DSDT, OEMB, , , GRUB , OEMB.
. GRUB
write_byte,
write_word,
write_dword read_. GRUB OEMB? BIOS' . , RAM, .
. GRUB:
write_byte 0xCF78E0B5 0x30
0x00 0x04 0x30, 64- PCI 0x0000000430000000. OEMB, Linux , , , , .
Linux dmesg PCI.
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff window]
pci_bus 0000:00: root bus resource [mem 0xd0000000-0xdfffffff window]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfed8ffff window]
pci_bus 0000:00: root bus resource [mem 0x430000000-0xfffffffff window]
pci_bus 0000:00: root bus resource [bus 00-ff]
! 0x430000000-0xfffffffffff , . , Linux , Windows .
! Windows 16 RAM, GRUB write_byte. Windows 10, , . - Windows, , RAM, . !
GRUB, /etc/grub.d/00_patchbios :
# This file patches the BIOS in my Foxconn P55MX motherboard to work
# properly when I have 16 GB of RAM installed. It's a nasty hack.
# Basically, the BIOS is hardcoded in the OEMB ACPI table
# to have a PCI address range from 0x400000000 to 0xfffffffff, but
# that overlaps with 16 GB of RAM being installed, because the RAM
# uses up (among other ranges) 0x100000000 to 0x42fffffff.
# This patch changes the table to actually list a PCI range of:
# 0x430000000 to 0xfffffffff
echo "write_byte 0xCF78E0B5 0x30"
sudo update-grub. GRUB.
, . PCI - . , RAM. Linux 16 RAM, . , PCI/PCIe - , , , , . , , , ACPI BIOS .
, , ! , - . , .