# RAM installée non utilisable complètement, nouvelle approche?

**URL:** <https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581>\
**Category:** Support Debian\
**Tags:** boot\
**Created:** [Novembre 19, 2024, 6:48 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581 "2024-11-19T18:48:09Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 19, 2024, 6:48 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/1 "2024-11-19T18:48:09Z")

</div>

Bonjour,

J’ai moi aussi des problèmes de différence entre la RAM installée et la RAM visible avec ma debian 12. Je précise si cela a un intérêt que pour l’installation j’ai appliqué les options `acpi_osi=Linux pci=nomsi` sinon l’installation ne se lancait pas.

J’ai parcouru un peu tous les messages sur le forum et ailleurs sans trouver de véritable réponse ou alors sans les comprendre (je suis loin d’être informaticien donc désolé d’avance si je suis imprécis dans les termes).

En gros, j’ai deux barrettes de 2 Go sur mon portable Asus et la commande free ne me donne que 2,9 utilisable.  
Avant de chercher à changer les choses, peut-on m’expliquer où est passé ce mega ? Si c’est prévu par la distribution et qu’il est utilisé néanmoins à bon escient, cela ne vaut peut-être pas la peine de chercher à changer les choses si c’est comme cela que ca marchera le mieux (mais quand même, 1Go de RAM sur 4Go, cela peut changer le comportement de mon ordi).

Merci de m’avoir lu et merci d’avance de m’apporter votre science et vos commentaires

Donc pour mes infos :

- portable Asus F70SL
- processeurs : 2 × Intel® Core™2 Duo CPU T5850 @ 2.16GHz
- processeur graphique : NV98
- ma carte mère accepte bien en principe 4Gib
- dans le bios et au démarrage de l’ordi il me dit bien memory installed 4096Mb
- mon Bios est à jour de la dernière version qui est parue en 2009
- debian en 64 bits actuellement, matériel apparament compatible, version de noyau 6.1.0-27-amd64 (64-bit), plateforme graphique : X11
- si je fais le test depuis d’autres debian live, même en 32bit j’ai les mêmes infos sur ma RAM
- J’ai fait les tests alternativement avec une seule barrette de 2Go, sur chacun des ports, à chaque fois la commande free me renvoie 1,9Go de mémoire totale, mais quand je mets les deux la même commande me donne 2,9Go de mémoire totale

PS : aucune donnée à sauvegarder sur cet ordinateur, je peux « prendre des risques », je compte de toute façon repartir sur une installation propre debian 12 LXQt plutôt que KDE que j’ai actuellement un peu gourmand pour ma machine qui manque de fluidité

---

<div class="post-metadata">

**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\
**Post date:** [Novembre 19, 2024, 8:03 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/2 "2024-11-19T20:03:40Z")

</div>

L’option de noyau «&nbsp;pci=nomsi&nbsp;» désactive les interruptions MSI (Message Signaled Interrupts) pour les périphériques PCI, et n’influe donc pas l’allocation mémoire.  
Le différentiel entre quantité de mémoire physique installée et celle disponible pour le système rapportée par la commande «&nbsp;`free`&nbsp;» provient de la mémoire partagée réservée à la carte graphique intégrée (IGPU), qui évolue dynamiquement en fonction du besoin, et probablerment configurable dans le BIOS.

La commande suivante devrait montrer des lignes ‹&nbsp;mémoire&nbsp;›:  
`lspci -v | awk '/3D|VGA/' RS=`

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 19, 2024, 8:30 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/3 "2024-11-19T20:30:41Z")

</div>

Bonsoir Verner,  
Merci pour ta réponse.  
Pour l’option de noyau je préférais juste préciser… histoire de si ça pouvait avoir son importance.  
Pour ces options dans le bios justement il me semble que je n’ai rien pour configurer le comportement de la carte graphique. Faudrait que je mette des images du bios pour illustrer, mais je ne sais pas comment faire cela, je vais me renseigner.  
Voici le résultat de la commande

> `lspci -v | awk '/3D|VGA/' RS=`

> `01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1) (prog-if 00 [VGA controller])`  
> ` Subsystem: ASUSTeK Computer Inc. U6V laptop`  
> ` Flags: bus master, fast devsel, latency 0, IRQ 16`  
> ` Memory at fc000000 (32-bit, non-prefetchable) [size=16M]`  
> ` Memory at d0000000 (64-bit, prefetchable) [size=256M]`  
> ` Memory at fa000000 (64-bit, non-prefetchable) [size=32M]`  
> ` I/O ports at dc00 [size=128]`  
> ` Expansion ROM at 000c0000 [disabled] [size=128K]`  
> ` Capabilities: <access denied>`  
> ` Kernel driver in use: nouveau`  
> ` Kernel modules: nouveau`

---

<div class="post-metadata">

**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\
**Post date:** [Novembre 19, 2024, 8:39 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/4 "2024-11-19T20:39:56Z")

</div>

J’ai l’impression (aussi dans ma config) que le lspci de l’IGPU rapporte en fait uniquement la mémoire strictement minimum au système pour fonctionner.  
Si je l’augmente dans le BIOS, je ne vois pas de différence rapportée par lspci.  
Cette zone mémoire n’est pas facile à tracer, entre le BIOS et linux.  
Pour comparer, «&nbsp;`free -mh`&nbsp;» permettra de voir une différence au démarrage, avant que le graphique ne soit trop sollicité.  
Voir aussi ce que rapporte glxinfo fourni par mesa-utils:  
`glxinfo | grep -i 'device\|memory'`

Mais le différentiel que tu rapportes entre 1 et 2 barrettes mémoire ne me semble pas cohérent.

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 19, 2024, 9:05 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/5 "2024-11-19T21:05:29Z")

</div>

Je viens de passer la commande au redémarrage de l’ordinateur. Voici le résultat de

> `free -mh`  
> ` total utilisé libre partagé tamp/cache disponible`  
> `Mem: 2,9Gi 750Mi 1,8Gi 10Mi 541Mi 2,2Gi`  
> `Échange: 4,9Gi 0B 4,9Gi`

pour

> `glxinfo | grep -i 'device\|memory'`

j’obtiens :

> ` Device: NV98 (0x6e9)`  
> ` Video memory: 500MB`  
> ` Unified memory: no`  
> `Memory info (GL_ATI_meminfo):`  
> ` VBO free memory - total: 400 MB, largest block: 400 MB`  
> ` VBO free aux. memory - total: 838859 MB, largest block: 838859 MB`  
> ` Texture free memory - total: 400 MB, largest block: 400 MB`  
> ` Texture free aux. memory - total: 838859 MB, largest block: 838859 MB`  
> ` Renderbuffer free memory - total: 400 MB, largest block: 400 MB`  
> ` Renderbuffer free aux. memory - total: 838859 MB, largest block: 838859 MB`  
> `Memory info (GL_NVX_gpu_memory_info):`  
> ` Dedicated video memory: 500 MB`  
> ` Total available memory: 1049075 MB`  
> ` Currently available dedicated video memory: 400 MB`  
> ` GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_copy_image,`  
> ` GL_MESA_window_pos, GL_NVX_gpu_memory_info, GL_NV_ES1_1_compatibility,`

---

<div class="post-metadata">

**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\
**Post date:** [Novembre 19, 2024, 9:16 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/6 "2024-11-19T21:16:02Z")

</div>

> [@SULWC](#):
>
> NV98 Total available memory: 1 049 075 MB

C’est donc bien par là que ça se passe, probablement différent si 1 ou 2 barettes.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Novembre 19, 2024, 10:26 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/7 "2024-11-19T22:26:27Z")

</div>

Sans compter que le pilote nouveau pour NVIDIA n’est pas très bon et ça peut influer sur la mémoire (hors carte GPU).

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 20, 2024, 3:13 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/8 "2024-11-20T15:13:48Z")

</div>

Donc cela veut dire que ma carte graphique se réserve lus de mémoire quand il y en a plus?  
Est-ce que c’est bien que cela fonctionne ainsi ou est-ce que cela nuit au fonctionnement du portable?  
Je l’utilise essentiellement pour lire de la musique en streaming et internet mais j’aimerais aussi pouvoir y lire des vidéos en streaming quand je me déplace

Mon BIOS n’a pas de réglage mémoire graphique.

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 20, 2024, 3:18 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/14 "2024-11-20T15:18:34Z")

</div>

> Citation Sans compter que le pilote nouveau pour NVIDIA n’est pas très bon et ça peut influer sur la mémoire (hors carte GPU).

je crois que le pilote de ma carte n’existe plus dans le debian, je vais essayer de retrouver comment faire pour vérifier cela

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 20, 2024, 3:47 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/15 "2024-11-20T15:47:24Z")

</div>

> `Detected NVIDIA GPUs:`  
> `01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98M [GeForce 9300M GS] [10de:06e9] (rev a1)`

> `Checking card: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1)`  
> `Your card is only supported by the 340 legacy drivers series, which is only available up to buster.`

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Novembre 20, 2024, 4:15 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/16 "2024-11-20T16:15:21Z")

</div>

Le pilote existe dans Debian/SID.  
Pour cela:  
d’abord tu fait une mise à jour de ton système:  
apt update  
apt upgrade  
Pour etre sur qu’aucun paquet ne soit en attente.  
Ensuite il te suffit d’ajouter la ligne SID dans /etc/apt-sources.list.d/nvidia-sid.list  
`deb http://deb.debian.org/debian/ sid main contrib non-free non-free-firmware`

ensuite

```auto
    apt-update
    apt install nvidia-legacy-340xx-driver

```

ensuite tu commente la ligne sid dans le fichier, puis de nouveau  
`apt update`

pour éviter qu’ensuite SID ne soit utilisé.

---

<div class="post-metadata">

**Author:** ![vbreton](https://www.debian-fr.org/user_avatar/www.debian-fr.org/vbreton/32/11400_2.png) [@vbreton](https://www.debian-fr.org/u/vbreton)\
**Post date:** [Novembre 20, 2024, 7:13 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/17 "2024-11-20T19:13:21Z")

</div>

@Zargos, Est-ce que cela signifierait qu’avec ça je n’aurai plus besoin d’aller chercher les drivers sur le site officiel de Nvidia après chaque mise à jour automatique du kernel ?  
A chaque fois qu’il sort un nouveau kernel, je suis contraint de relancer l’installation du driver Nvidia pour ma Geforce 4060 TI.

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 20, 2024, 9:17 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/18 "2024-11-20T21:17:16Z")

</div>

@Zargos

Et bien j’ai suivi cette procédure mais ca ne marche pas.  
Après une longue procédure d’installation, quand je redémarre l’ordinateur reste bloqué sur cet écran

 ![PXL_20241120_190826679.MP](https://www.debian-fr.org/uploads/default/original/2X/2/260282ae8fa911bc79d8e1de1a55d479b6c0df6b.jpeg)

il y a un autre «&nbsp;failed&nbsp;» plus haut :  
Failed to start systemd-modules-load.service - Load Kernel Modules.  
See ‹&nbsp;systemctl status systemd-module-load.service&nbsp;› for details

Puis donc  
Failed to start nvidia-persistence…ervice - NVIDIA Persistence Daemon.  
See ‹&nbsp;systemctl status nvidia-persistenced.service&nbsp;› for details.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Novembre 21, 2024, 12:18 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/19 "2024-11-21T00:18:33Z")

</div>

Il faut aller voir dans les logs pour savoir ce qui se passe. C’est d’ailleurs ce que tu dit le message d’erreur.

---

<div class="post-metadata">

**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\
**Post date:** [Novembre 21, 2024, 8:27 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/21 "2024-11-21T08:27:51Z")

</div>

Si tu fait CTRL+ALT+F2 par exemple, arrives-tu sur la console ?

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Novembre 23, 2024, 3:27 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/24 "2024-11-23T15:27:04Z")

</div>

Bon et bien j’ai du réinstaller.  
Je suis donc avec une nouvelle installation de bookworm, avec les options acpi\_osi=Linux pci=nomsi au noyau, pas de /home séparé. J’ai choisi uniquement l’environnement de bureau LXQt avec les utilitaires usuels du système. J’ai :

- procédé à une mise à jour des paquets
- ajouté mon compte d’utilisateur au groupe sudo
- créé un fichier autologin pour ne pas à avoir à taper mon mdp en début de session (ce qui m’arrange car il y a un bug d’affichage lors de l’ouverture de la session et je dois taper un peu à l’aveugle) car je n’ai pas trouvé comment le faire dans les interfaces graphiques
- installé timeshiht et créer une première sauvegarde (sans exclure root ni le compte utilisateur, avec les fichier cachés)

> `lspci -v | awk '/3D|VGA/' RS=`

donne

> `01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1) (prog-if 00 [VGA controller])`  
> ` Subsystem: ASUSTeK Computer Inc. U6V laptop`  
> ` Flags: bus master, fast devsel, latency 0, IRQ 16`  
> ` Memory at fc000000 (32-bit, non-prefetchable) [size=16M]`  
> ` Memory at d0000000 (64-bit, prefetchable) [size=256M]`  
> ` Memory at fa000000 (64-bit, non-prefetchable) [size=32M]`  
> ` I/O ports at dc00 [size=128]`  
> ` Expansion ROM at 000c0000 [disabled] [size=128K]`  
> ` Capabilities: <access denied>`  
> ` Kernel driver in use: nouveau`  
> ` Kernel modules: nouveau`

La commande

> `free -mh`

donne

> ` total utilisé libre partagé tamp/cache disponible`  
> `Mem: 2,9Gi 1,6Gi 488Mi 31Mi 1,1Gi 1,3Gi`  
> `Échange: 9,3Gi 0B 9,3Gi`

Malgré la RAM physiquement présente de 4Go  
(oui je n’ai pas fait dans le détail pour l’espace swapp, mais j’ai de la place)  
La commande

> `glxinfo | grep -i 'device\|memory'`

donne

> `Device: NV98 (0x6e9) `  
> ` Video memory: 500MB `  
> ` Unified memory: no `  
> `Memory info (GL_ATI_meminfo): `  
> ` VBO free memory - total: 400 MB, largest block: 400 MB `  
> ` VBO free aux. memory - total: 838860 MB, largest block: 838860 MB `  
> ` Texture free memory - total: 400 MB, largest block: 400 MB `  
> ` Texture free aux. memory - total: 838860 MB, largest block: 838860 MB `  
> ` Renderbuffer free memory - total: 400 MB, largest block: 400 MB `  
> ` Renderbuffer free aux. memory - total: 838860 MB, largest block: 838860 MB `  
> `Memory info (GL_NVX_gpu_memory_info): `  
> ` Dedicated video memory: 500 MB `  
> ` Total available memory: 1049076 MB `  
> ` Currently available dedicated video memory: 400 MB `  
> ` GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_copy_image, `  
> ` GL_MESA_window_pos, GL_NVX_gpu_memory_info, GL_NV_ES1_1_compatibility,`

A priori je n’ai pas encore d’installé le driver **nouveau** , en tout cas je ne le vois pas dans Synaptic… pour l’instant j’ai laissé la liste des dépots d’origine avec seulement bookworm main non-free-firmware dans /etc/apt/sources.list  
En faisant une recherche pour **nouveau** je vois ces deux paquets installés **`libdrm-nouveau2`** et **`xserver-xorg-video-nouveau`**  
J’ai par contre le paquet **intel-microcode** installé dans sa dernière version.

---

<div class="post-metadata">

**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\
**Post date:** [Décembre 1, 2024, 8:21 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/25 "2024-12-01T20:21:08Z")

</div>

Une petite conclusion sur ce sujet, et sur le hors-sujet /expérimental (SID dans bookworm).

**Le sujet** : «&nbsp;analyse de la différence de mémoire partagée selon la taille de mémoire RAM installée.&nbsp;»  
Sujet techniquement intéressant, puisque rarement observé.

La mémoire globale utilisable par le système inclus RAM physique + swap éventuellement disponible. Pour un IGPU (_fonction graphique dans le CPU_), ou fonction graphique implantée sur la carte mère, le graphisme utilisera une portion de RAM incrémentée par blocs de 256M. Le graphisme n’utilisera pas le swap.

Au boot, le noyau analyse la configuration en réservant minimum 256M de RAM pour la graphisme, suffisant pour faire fonctionner un environnement bureautique.  
Si le BIOS a un réglage permettant de contraindre une valeur max de RAM pour le graphique, il prendra cette valeur en considération, sinon, estimera la valeur la plus judicieuse à réserver, en s’assurant que ce qui reste de RAM+SWAP permette de faire de faire fonctionner le système.  
Il n’est donc pas ‹&nbsp;_anormal_&nbsp;› que le calcul de RAM graphique pour le noyau soit dépendant de la taille physique RAM, et des propriétés annoncées par la carte graphique. Difficile d’être plus précis dans l’analyse.  
En résumé, le noyau ajustera dynamiquement ce dont il a besoin que le système fonctionne globalement.

Le sujet n’était donc pas un problème de performances graphique, ni même le mot ‹&nbsp;nvidia&nbsp;› prononcé dans le sujet.

Quelques mots concernant la partie expérimentale proposée.  
Avoir un apriori sur le driver nouveau avant même d’avoir analysé la partie graphique plus en détail, pour justifier l’expérience SID n’aurait pas du avoir lieu dans ce sujet.  
La carte ‹&nbsp;GeForce 9300M&nbsp;› est une génération de techno Tesla/200 **8** , et le BIOS date de 200 **9**.  
Le driver nouveau est subdivisé en 15 niveaux de spécification selon l’historique de technologie.  
Si aucun problème de performance n’est signalé, pas la peine de compliquer au risque de casser le système, et encore moins de s’aventurer dans une expérience SID dont le résultat était connu à l’avance (une analyse d’une minute suffit), en laissant imaginer ce qui se passerait lors d’un changement de noyau.

Le module ‹&nbsp;nouveau&nbsp;› provient de l’installation de linux-image, et nécessite le driver `xserver-xorg-video-nouveau` qui fournit `/usr/lib/xorg/modules/drivers/nouveau_drv.so`

```auto
$ /sbin/modinfo nouveau |awk '/filename/{print $2}'
  /lib/modules/6.11.9-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko.xz

```

Le module nouveau mériterait un sujet complet à lui seul, surtout pour aborder la partie firmware un peu plus délicate selon la génération ‹&nbsp;legacy&nbsp;› ou non. Le firmware potentiellement manquant n’est pas nécessairement identifié/réclamé au boot dans les logs, mais peut être demandé **dynamiquement** pour activer l’accélération matérielle potentiellement possible pour la GPU (_déport du calcul graphique du CPU système vers le CPU carte graphique, pour lecture video_). → voir [ce sujet](https://www.debian-fr.org/t/erreurs-pilote-nouveau/90496/13) pour complément.

Conclusion finalement moins petite que prévu.

---

<div class="post-metadata">

**Author:** ![SULWC](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/41988e/32.png) [@SULWC](https://www.debian-fr.org/u/SULWC)\
**Post date:** [Décembre 1, 2024, 9:40 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/26 "2024-12-01T21:40:13Z")

</div>

@Verner merci pour le temps que tu as consacré à cette analyse et pour cette conclusion… qui en éclairera certainement d’autres davantage que moi, mais ça c’est du à mes connaissances sinon cela semble a peu près clair pour moi.  
En tout cas me voilà rassuré 🙂

---

<div class="post-metadata">

**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\
**Post date:** [Décembre 17, 2024, 5:32 UTC](https://www.debian-fr.org/t/ram-installee-non-utilisable-completement-nouvelle-approche/90581/27 "2024-12-17T17:32:57Z")

</div>

En complément l’installation des firmwares nouveau pour `GeForce 9300M ` se poursuit dans ce sujet:  
 → [Nvidia: firmware nouveau manquant [nv98\_fuc084d] ](https://www.debian-fr.org/t/nvidia-firmware-nouveau-manquant-nv98-fuc084d/90698)
