geo cherchetout wrote in message <4499b7de$0$914$:
# df Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/sda1 6,9G 4,7G 1,9G 72% / /dev/sda5 87G 4,7G 82G 6% /home (pas trace de /dev/shm)
Alors tu as un problème de config avec ta distrib. Potentiellement assez grave, d'ailleurs, puisqu'il donne accès en écriture dans la partition racine ; sauf qu'en l'occurrence, /tmp y est aussi, donc ça ne change rien.
geo cherchetout wrote in message
<4499b7de$0$914$ba4acef3@news.orange.fr>:
# df
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1 6,9G 4,7G 1,9G 72% /
/dev/sda5 87G 4,7G 82G 6% /home
(pas trace de /dev/shm)
Alors tu as un problème de config avec ta distrib. Potentiellement assez
grave, d'ailleurs, puisqu'il donne accès en écriture dans la partition
racine ; sauf qu'en l'occurrence, /tmp y est aussi, donc ça ne change rien.
geo cherchetout wrote in message <4499b7de$0$914$:
# df Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/sda1 6,9G 4,7G 1,9G 72% / /dev/sda5 87G 4,7G 82G 6% /home (pas trace de /dev/shm)
Alors tu as un problème de config avec ta distrib. Potentiellement assez grave, d'ailleurs, puisqu'il donne accès en écriture dans la partition racine ; sauf qu'en l'occurrence, /tmp y est aussi, donc ça ne change rien.
lhabert
Il a peut-être aussi un tmpfs monté dans /dev. C'est un problème de fusionner les deux? Comment la libc utilise-t-elle le /dev/shm au juste?
Il a peut-être aussi un tmpfs monté dans /dev. C'est un problème de
fusionner les deux? Comment la libc utilise-t-elle le /dev/shm au juste?
Il a peut-être aussi un tmpfs monté dans /dev. C'est un problème de fusionner les deux? Comment la libc utilise-t-elle le /dev/shm au juste?
Nicolas George
Luc Habert wrote in message <e7cnht$a96$:
Il a peut-être aussi un tmpfs monté dans /dev. C'est un problème de fusionner les deux?
Oui, ce serait plutôt mauvais : le tmpfs d'udev est petit, et au contraire, le tmpfs de la mémoire partagée peut être encombré de grosses données. Je pense qu'on a pas intérêt du tout à ce qu'udev se prenne des ENOSPC en créant les devices ou en gérant sa base de données.
Comment la libc utilise-t-elle le /dev/shm au juste?
Des gros fichiers temporaires mmapés, tout simplement.
Luc Habert wrote in message <e7cnht$a96$1@nef.ens.fr>:
Il a peut-être aussi un tmpfs monté dans /dev. C'est un problème de
fusionner les deux?
Oui, ce serait plutôt mauvais : le tmpfs d'udev est petit, et au contraire,
le tmpfs de la mémoire partagée peut être encombré de grosses données. Je
pense qu'on a pas intérêt du tout à ce qu'udev se prenne des ENOSPC en
créant les devices ou en gérant sa base de données.
Comment la libc utilise-t-elle le /dev/shm au juste?
Des gros fichiers temporaires mmapés, tout simplement.
Il a peut-être aussi un tmpfs monté dans /dev. C'est un problème de fusionner les deux?
Oui, ce serait plutôt mauvais : le tmpfs d'udev est petit, et au contraire, le tmpfs de la mémoire partagée peut être encombré de grosses données. Je pense qu'on a pas intérêt du tout à ce qu'udev se prenne des ENOSPC en créant les devices ou en gérant sa base de données.
Comment la libc utilise-t-elle le /dev/shm au juste?
Des gros fichiers temporaires mmapés, tout simplement.
geo cherchetout
Le 21.06.2006 20:51, *Doug713705* a écrit fort à propos :
Une ligne comme celle ci devrait se trouver quelquepart dans ton fstab :
shm /dev/shm tmpfs rw 0 0
C'est ce que suggère d'ajouter la documentation fournie avec le pilote propriétaire, que je viens de découvrir dans /usr/share/doc/ati-xorg-8.25.18/articles/devshm.html Je l'ai fait et le montage est accepté :
# mount | grep "shm" tmpfs on /dev/shm type tmpfs (rw)
Je considère donc le sujet comme épuisé (pour moi) puisque le document conclut :
At this point, POSIX Shared Memory is enabled. Your 3D applications should run properly and the error message above should no longer occur.
Merci à tous.
Le 21.06.2006 20:51, *Doug713705* a écrit fort à propos :
Une ligne comme celle ci devrait se trouver quelquepart dans ton fstab :
shm /dev/shm tmpfs rw 0 0
C'est ce que suggère d'ajouter la documentation fournie avec le pilote
propriétaire, que je viens de découvrir dans
/usr/share/doc/ati-xorg-8.25.18/articles/devshm.html
Je l'ai fait et le montage est accepté :
# mount | grep "shm"
tmpfs on /dev/shm type tmpfs (rw)
Je considère donc le sujet comme épuisé (pour moi) puisque le document
conclut :
At this point, POSIX Shared Memory is enabled. Your 3D applications
should run properly and the error message above should no longer occur.
Le 21.06.2006 20:51, *Doug713705* a écrit fort à propos :
Une ligne comme celle ci devrait se trouver quelquepart dans ton fstab :
shm /dev/shm tmpfs rw 0 0
C'est ce que suggère d'ajouter la documentation fournie avec le pilote propriétaire, que je viens de découvrir dans /usr/share/doc/ati-xorg-8.25.18/articles/devshm.html Je l'ai fait et le montage est accepté :
# mount | grep "shm" tmpfs on /dev/shm type tmpfs (rw)
Je considère donc le sujet comme épuisé (pour moi) puisque le document conclut :
At this point, POSIX Shared Memory is enabled. Your 3D applications should run properly and the error message above should no longer occur.
Merci à tous.
Emmanuel Fleury
Nicolas George wrote:
Non, c'est faux, aucun de ceux-ci n'utilise de mémoire partagée POSIX.
Bof, tu dis des conneries (et sans les vérifier comme d'habitudes). Bon, pour ta culture:
^^^^ Pour ta gouverne, ipcs renvoie des informations sur la mémoire partagée SysV, pas la mémoire partagée POSIX.
Pour ta gouverne, c'est la même chose (et donc, tu t'enfonces, là).
Commence par maîtriser le sujet dont il est question, et on en reparlera.
Je le maîtrise déjà mieux que toi, visiblement... mais bon, de simples excuses suffiront pour cette fois.
-- Emmanuel Fleury | Office: 211 Associate Professor, | Phone: +33 (0)5 40 00 35 24 LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69 351, Cours de la Libération | email: 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury
Nicolas George
Emmanuel Fleury wrote in message <e7ef0p$28v$:
Pour ta gouverne, ipcs renvoie des informations sur la mémoire partagée SysV, pas la mémoire partagée POSIX. Pour ta gouverne, c'est la même chose
Non, pas du tout. La mémoire partagée POSIX se manipule avec les fonctions shm_open, shm_unlink et mmap/munmap, la mémoire partagée SysV avec shmget, shmctl, shmat et shmdt, les deux étant tout à fait indépendants, et non inter-opérables. Techniquement, sous Linux, la mémoire partagée POSIX est implémentée complètement dans la libc, en utilisant des fichiers mmapés dans un tmpfs (le fameux /dev/shm), alors que la mémoire partagée SysV est gérée par des appels système spécifiques.
Je le maîtrise déjà mieux que toi, visiblement...
On voit ça...
Emmanuel Fleury wrote in message <e7ef0p$28v$1@news.u-bordeaux1.fr>:
Pour ta gouverne, ipcs renvoie des informations sur la mémoire partagée
SysV, pas la mémoire partagée POSIX.
Pour ta gouverne, c'est la même chose
Non, pas du tout. La mémoire partagée POSIX se manipule avec les fonctions
shm_open, shm_unlink et mmap/munmap, la mémoire partagée SysV avec shmget,
shmctl, shmat et shmdt, les deux étant tout à fait indépendants, et non
inter-opérables. Techniquement, sous Linux, la mémoire partagée POSIX est
implémentée complètement dans la libc, en utilisant des fichiers mmapés dans
un tmpfs (le fameux /dev/shm), alors que la mémoire partagée SysV est gérée
par des appels système spécifiques.
Pour ta gouverne, ipcs renvoie des informations sur la mémoire partagée SysV, pas la mémoire partagée POSIX. Pour ta gouverne, c'est la même chose
Non, pas du tout. La mémoire partagée POSIX se manipule avec les fonctions shm_open, shm_unlink et mmap/munmap, la mémoire partagée SysV avec shmget, shmctl, shmat et shmdt, les deux étant tout à fait indépendants, et non inter-opérables. Techniquement, sous Linux, la mémoire partagée POSIX est implémentée complètement dans la libc, en utilisant des fichiers mmapés dans un tmpfs (le fameux /dev/shm), alors que la mémoire partagée SysV est gérée par des appels système spécifiques.
Je le maîtrise déjà mieux que toi, visiblement...
On voit ça...
Doug713705
Le mercredi 21 juin 2006 21:53, geo cherchetout s'est exprimé de la sorte sur fr.comp.os.linux.configuration :
Le 21.06.2006 20:51, *Doug713705* a écrit fort à propos :
Une ligne comme celle ci devrait se trouver quelquepart dans ton fstab :
shm /dev/shm tmpfs rw 0 0
Mais il n'y a aucune ligne ressemblant à ça. Si je l'ajoute, à quel effet favorable (ou défavorable) puis-je m'attendre ?
Au temps où je ne montais pas /dev/shm, mon driver fonctionnait et bien que le FPS donné par glxgears soit satisfaisant, j'obtenais des plantages et des bugs d'affichage fréquents.
De plus il était impossible de jouer à des jeux vraiment gourmands en vidéo sans saccade.
Comment le constater ?
Essaie par toi même.
Sans cette shm j'obtiens déjà ce que j'attendais du pilote propriétaire. Extrait de /var/log/Xorg.0.log :
(II) fglrx(0): Acceleration enabled (II) fglrx(0): Direct rendering enabled
Voir plus haut. -- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le mercredi 21 juin 2006 21:53, geo cherchetout s'est exprimé de la sorte
sur fr.comp.os.linux.configuration :
Le 21.06.2006 20:51, *Doug713705* a écrit fort à propos :
Une ligne comme celle ci devrait se trouver quelquepart dans ton fstab :
shm /dev/shm tmpfs rw 0 0
Mais il n'y a aucune ligne ressemblant à ça. Si je l'ajoute, à quel
effet favorable (ou défavorable) puis-je m'attendre ?
Au temps où je ne montais pas /dev/shm, mon driver fonctionnait et bien que
le FPS donné par glxgears soit satisfaisant, j'obtenais des plantages et
des bugs d'affichage fréquents.
De plus il était impossible de jouer à des jeux vraiment gourmands en vidéo
sans saccade.
Comment le constater ?
Essaie par toi même.
Sans cette shm j'obtiens déjà ce que j'attendais du pilote propriétaire.
Extrait de /var/log/Xorg.0.log :
(II) fglrx(0): Acceleration enabled
(II) fglrx(0): Direct rendering enabled
Voir plus haut.
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Au temps où je ne montais pas /dev/shm, mon driver fonctionnait et bien que le FPS donné par glxgears soit satisfaisant, j'obtenais des plantages et des bugs d'affichage fréquents.
De plus il était impossible de jouer à des jeux vraiment gourmands en vidéo sans saccade.
Comment le constater ?
Essaie par toi même.
Sans cette shm j'obtiens déjà ce que j'attendais du pilote propriétaire. Extrait de /var/log/Xorg.0.log :
(II) fglrx(0): Acceleration enabled (II) fglrx(0): Direct rendering enabled
Voir plus haut. -- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
