J'utilise un programme pour tester la RAM. Ce programme tourne sous mac OS
X 10.4. Si j'ai bien compris, il alloue une portion de RAM, la plus grande
qu'il peut. Par exemple, juste apres le boot il arrive a allouer 1600Mo de
mes 2Go. Ensuite il teste cete RAM.
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il
existe une partie de la RAM physique qui sera toujours utilisé par le
systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou
bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe
ou physiquement sur les barrettes? Dans cette seconde eventualite je
pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les
segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Merci de vos lumières.
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Levenez
Le 27/07/07 13:45, dans , « Saïd » a écrit :
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il existe une partie de la RAM physique qui sera toujours utilisé par le systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe ou physiquement sur les barrettes? Dans cette seconde eventualite je pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Au démarrage le CPU démarre sur une adresse physique fixe (parfois configurable par une EEPROM, une flash ou une pin). Le hard a mappé à cette adresse une mémoire non volatile type flash. Cette flash sert à la configuration du CPU et au boot du système. Typiquement c'est à cet endroit que la RAM et la flash sont configurées et mappée dans l'espace d'adressage du noyau.
Ensuite seulement le boot (Open Firmware sur Max) va pouvoir charger le système d'exploitation principal. Je pense que c'est le paramètre load-base de la NVRAM qui donne l'adresse de chargement du système d'exploitation à partir du disque.
Le boot lance alors le système d'exploitation qui a été chargé à cette adresse fixe. Le système d'exploitation va allouer de la mémoire pour sa pile, ses données, il va charger les drivers dynamiques... Entre 2 boots avec le même hard, les adresses de tout ce petit monde devraient être identiques.
Le noyau lance ensuite le père de tous les processus unix (init ou launchd), celui-ci va à son tour lancer tous les autres processus du système. Là entre en scène beaucoup d'interactions qui font que les adresses physiques utilisées seront différentes à chaque reboot. La mémoire libre à ce point ne sera jamais identique physiquement parlant, même si virtuellement elle sera peut-être similaire.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/07/07 13:45, dans <slrnfajmmp.bt.said@dhcp132-209.enst.fr>, « Saïd »
<said@brian.lan> a écrit :
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il
existe une partie de la RAM physique qui sera toujours utilisé par le
systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou
bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe
ou physiquement sur les barrettes? Dans cette seconde eventualite je
pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les
segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Au démarrage le CPU démarre sur une adresse physique fixe (parfois
configurable par une EEPROM, une flash ou une pin). Le hard a mappé à cette
adresse une mémoire non volatile type flash. Cette flash sert à la
configuration du CPU et au boot du système. Typiquement c'est à cet endroit
que la RAM et la flash sont configurées et mappée dans l'espace d'adressage
du noyau.
Ensuite seulement le boot (Open Firmware sur Max) va pouvoir charger le
système d'exploitation principal. Je pense que c'est le paramètre load-base
de la NVRAM qui donne l'adresse de chargement du système d'exploitation à
partir du disque.
Le boot lance alors le système d'exploitation qui a été chargé à cette
adresse fixe. Le système d'exploitation va allouer de la mémoire pour sa
pile, ses données, il va charger les drivers dynamiques... Entre 2 boots
avec le même hard, les adresses de tout ce petit monde devraient être
identiques.
Le noyau lance ensuite le père de tous les processus unix (init ou launchd),
celui-ci va à son tour lancer tous les autres processus du système. Là entre
en scène beaucoup d'interactions qui font que les adresses physiques
utilisées seront différentes à chaque reboot. La mémoire libre à ce point ne
sera jamais identique physiquement parlant, même si virtuellement elle sera
peut-être similaire.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il existe une partie de la RAM physique qui sera toujours utilisé par le systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe ou physiquement sur les barrettes? Dans cette seconde eventualite je pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Au démarrage le CPU démarre sur une adresse physique fixe (parfois configurable par une EEPROM, une flash ou une pin). Le hard a mappé à cette adresse une mémoire non volatile type flash. Cette flash sert à la configuration du CPU et au boot du système. Typiquement c'est à cet endroit que la RAM et la flash sont configurées et mappée dans l'espace d'adressage du noyau.
Ensuite seulement le boot (Open Firmware sur Max) va pouvoir charger le système d'exploitation principal. Je pense que c'est le paramètre load-base de la NVRAM qui donne l'adresse de chargement du système d'exploitation à partir du disque.
Le boot lance alors le système d'exploitation qui a été chargé à cette adresse fixe. Le système d'exploitation va allouer de la mémoire pour sa pile, ses données, il va charger les drivers dynamiques... Entre 2 boots avec le même hard, les adresses de tout ce petit monde devraient être identiques.
Le noyau lance ensuite le père de tous les processus unix (init ou launchd), celui-ci va à son tour lancer tous les autres processus du système. Là entre en scène beaucoup d'interactions qui font que les adresses physiques utilisées seront différentes à chaque reboot. La mémoire libre à ce point ne sera jamais identique physiquement parlant, même si virtuellement elle sera peut-être similaire.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Saïd
Eric Levenez :
Le 27/07/07 13:45, dans , « Saïd » a écrit :
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il existe une partie de la RAM physique qui sera toujours utilisé par le systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe ou physiquement sur les barrettes? Dans cette seconde eventualite je pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Au démarrage le CPU démarre sur une adresse physique fixe (parfois configurable par une EEPROM, une flash ou une pin). Le hard a mappé à cette adresse une mémoire non volatile type flash. Cette flash sert à la configuration du CPU et au boot du système. Typiquement c'est à cet endroit que la RAM et la flash sont configurées et mappée dans l'espace d'adressage du noyau.
Ensuite seulement le boot (Open Firmware sur Max) va pouvoir charger le système d'exploitation principal. Je pense que c'est le paramètre load-base de la NVRAM qui donne l'adresse de chargement du système d'exploitation à partir du disque.
Le boot lance alors le système d'exploitation qui a été chargé à cette adresse fixe. Le système d'exploitation va allouer de la mémoire pour sa pile, ses données, il va charger les drivers dynamiques... Entre 2 boots avec le même hard, les adresses de tout ce petit monde devraient être identiques.
Le noyau lance ensuite le père de tous les processus unix (init ou launchd), celui-ci va à son tour lancer tous les autres processus du système. Là entre en scène beaucoup d'interactions qui font que les adresses physiques utilisées seront différentes à chaque reboot. La mémoire libre à ce point ne sera jamais identique physiquement parlant, même si virtuellement elle sera peut-être similaire.
Et au final, le noyau lui il ne bouge pas (pas les processus)? (sinon on m'a signalé une image iso bootable qui permet de s'affrenchir de ce probleme)
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Eric Levenez :
Le 27/07/07 13:45, dans <slrnfajmmp.bt.said@dhcp132-209.enst.fr>, « Saïd »
<said@brian.lan> a écrit :
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il
existe une partie de la RAM physique qui sera toujours utilisé par le
systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou
bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe
ou physiquement sur les barrettes? Dans cette seconde eventualite je
pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les
segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Au démarrage le CPU démarre sur une adresse physique fixe (parfois
configurable par une EEPROM, une flash ou une pin). Le hard a mappé à cette
adresse une mémoire non volatile type flash. Cette flash sert à la
configuration du CPU et au boot du système. Typiquement c'est à cet endroit
que la RAM et la flash sont configurées et mappée dans l'espace d'adressage
du noyau.
Ensuite seulement le boot (Open Firmware sur Max) va pouvoir charger le
système d'exploitation principal. Je pense que c'est le paramètre load-base
de la NVRAM qui donne l'adresse de chargement du système d'exploitation à
partir du disque.
Le boot lance alors le système d'exploitation qui a été chargé à cette
adresse fixe. Le système d'exploitation va allouer de la mémoire pour sa
pile, ses données, il va charger les drivers dynamiques... Entre 2 boots
avec le même hard, les adresses de tout ce petit monde devraient être
identiques.
Le noyau lance ensuite le père de tous les processus unix (init ou launchd),
celui-ci va à son tour lancer tous les autres processus du système. Là entre
en scène beaucoup d'interactions qui font que les adresses physiques
utilisées seront différentes à chaque reboot. La mémoire libre à ce point ne
sera jamais identique physiquement parlant, même si virtuellement elle sera
peut-être similaire.
Et au final, le noyau lui il ne bouge pas (pas les processus)? (sinon on m'a
signalé une image iso bootable qui permet de s'affrenchir de ce probleme)
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
Ca veut dire que 400Mo ont echappe au test. Ma question est: est-ce qu'il existe une partie de la RAM physique qui sera toujours utilisé par le systeme (noyau) et qui ne pourra jamais etre testé par cette methode, ou bien le noyau utilise des segments de RAm qui peuvent etre situés n'importe ou physiquement sur les barrettes? Dans cette seconde eventualite je pourrais faire une dizaine de tests RAM et etre a peu pres sur que tous les segments physiques ont ete testés. Dans le premier cas, c'est perdu...
Au démarrage le CPU démarre sur une adresse physique fixe (parfois configurable par une EEPROM, une flash ou une pin). Le hard a mappé à cette adresse une mémoire non volatile type flash. Cette flash sert à la configuration du CPU et au boot du système. Typiquement c'est à cet endroit que la RAM et la flash sont configurées et mappée dans l'espace d'adressage du noyau.
Ensuite seulement le boot (Open Firmware sur Max) va pouvoir charger le système d'exploitation principal. Je pense que c'est le paramètre load-base de la NVRAM qui donne l'adresse de chargement du système d'exploitation à partir du disque.
Le boot lance alors le système d'exploitation qui a été chargé à cette adresse fixe. Le système d'exploitation va allouer de la mémoire pour sa pile, ses données, il va charger les drivers dynamiques... Entre 2 boots avec le même hard, les adresses de tout ce petit monde devraient être identiques.
Le noyau lance ensuite le père de tous les processus unix (init ou launchd), celui-ci va à son tour lancer tous les autres processus du système. Là entre en scène beaucoup d'interactions qui font que les adresses physiques utilisées seront différentes à chaque reboot. La mémoire libre à ce point ne sera jamais identique physiquement parlant, même si virtuellement elle sera peut-être similaire.
Et au final, le noyau lui il ne bouge pas (pas les processus)? (sinon on m'a signalé une image iso bootable qui permet de s'affrenchir de ce probleme)
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Eric Levenez
Le 27/07/07 22:27, dans <46aa5525$0$9387$, « Saïd » a écrit :
Et au final, le noyau lui il ne bouge pas (pas les processus)?
Le noyau xnu ne sait pas swappé (pour ses propres pages mémoire), contrairement à des systèmes comme AIX, et donc une fois en mémoire, il ne bouge plus (hors les drivers chargés dynamiquement bien sûr).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 27/07/07 22:27, dans <46aa5525$0$9387$426a74cc@news.free.fr>, « Saïd »
<said@brian.lan> a écrit :
Et au final, le noyau lui il ne bouge pas (pas les processus)?
Le noyau xnu ne sait pas swappé (pour ses propres pages mémoire),
contrairement à des systèmes comme AIX, et donc une fois en mémoire, il ne
bouge plus (hors les drivers chargés dynamiquement bien sûr).
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 27/07/07 22:27, dans <46aa5525$0$9387$, « Saïd » a écrit :
Et au final, le noyau lui il ne bouge pas (pas les processus)?
Le noyau xnu ne sait pas swappé (pour ses propres pages mémoire), contrairement à des systèmes comme AIX, et donc une fois en mémoire, il ne bouge plus (hors les drivers chargés dynamiquement bien sûr).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
