C'est effectivement pas gagné d'avance ... vu qu'il semble que je soit le seul à qui ça arrive.
Effectivement ça parait bizarre que ça ne marche mal que pour toi. As-tu pu estimer le débit que tu reçois sur ton interface relatif au trafic multicast ?
Peux-tu préciser ton modèle de carte réseau et la configuration de ton noyau ? (particulièrement la partie qui se trouve dans networking options ?). As-tu des infos sur les configurations RedHat qui n'ont pas le problème ?
Le multicast, c'est comme le broadcast: sur un réseau Ethernet, tout le monde va recevoir les trames. Ta carte réseau se prend donc tout dans la figure et c'est logique. Ca ne sert pas à grand chose de filtrer, vu que le mal est déjà fait (ton débit est déjà utilisé).
Pour régler ton problème, c'est à l'administrateur du réseau de faire son boulot correctement et de configurer ses switches pour qu'ils ne balancent pas les trames multicast sur des ports où il n'y a aucun récepteur multicast. Chez Cisco, la fonction à implémenter s'appelle CGMP, ou alors il y a IGMP Snooping qui est normalisé. Encore faut-il avoir des équipements qui supportent ces 2 fonctions (c'est pas gagné d'avance).
Ma question concerne /dev/mem : mémoire physique - Est ce que ça correspond au mapping et donc la possibilité d'accéder à tous les périphériques ?
Je pense que tu fais plutôt référence à /proc/kcore qui est un fichier virtuel permettant d'accéder à l'intégralité de la mémoire physique.
Un mmap() judicieusement utilisé sur ce fichier permet d'accéder à n'importe(s) quelle(s) pages physiques. Mal utilisé, je te promets que tu vas flinguer le système très vite (surtout si tu écris sur des pages du noyau).
Après, pour ton périphérique, il y a 2 possibilités (sur architecture x86):
* Soit il utilise des ports IO spécifiques (voir instructions inb/outb et compagnie) et dans ce cas mapper la mémoire ne sert à rien. On peut voir les ports IO avec le fichier /proc/ioports.
* Soit c'est du "memory-mapped", et dans ce cas, je pense que mapper /proc/kcore fonctionnerait (en ne mappant que la zone qui t'intéresse bien sûr).
Le fichier /proc/iomem montre les zones mémoires et les périphériques qui utilisent ces zones.
Attention, toutes ces manips ne peuvent bien sûr se faire qu'en root.
Il y a aussi quelques petits malloc() qui trainent à droite à gauche.
Si c'est sur le fork, c'est "normal".
Faudrait savoir. En tout cas dans ma logique à moi, c'est incompatible avec une assertion du type "La partie serveur de Postgres ne fait pas de malloc()".
L'argument qui tue... j'ai dit malloc() pour tout ce qui est lié aux demandes mémoires.
Ouais, rattrapage aux branches detected.
De tout manière, tu veux aussi vérifier que PostgreSQL (côté serveur) ne fait pas de malloc(3) avec ltrace.
Oui, là ça marche vu que ltrace(), en plus d'afficher les appels systèmes effectués comme strace, enregistre les appels aux fonctions des librairies chargées dynamiquement.
Quoiqu'il en soit, pour ta gouverne, il est possible d'allouer de la mémoire en utilisant mmap() avec le flag MAP_ANONYMOUS (pour les OS qui le supportent, ça va de soi). malloc() est loin d'être la seule méthode d'allocation.
Un bon SGDB comme PostgreSQL ne fait pas de malloc() côté serveur. Donc il n'a pas ce problème de "OOM killer"). Fais un strace sur postgresql si tu en doutes.
L'argument qui tue. malloc() n'est pas un appel système, strace ne le voit donc pas.
Les appels systèmes qui montrent une activité au niveau de la gestion mémoire, c'est mmap(), brk() et sbrk().
Subversion ne prétend pas être révolutionnaire par rapport à CVS mais il apporte une réponse à tout un ensemble de problématiques qui n'étaient pas ou alors très mal gérés par CVS, notamment le renommage de fichiers ou de répertoire, ou leur déplacement. Je pense que la gestion des verrous est bcp plus "propre" avec subversion que cvs.
Subversion fonctionne aussi avec WebDAV, ce qui est très pratique pour gérer ses "repository".
Peux-tu décrire un peu ton réseau (adressage IP utilisé, configuration du serveur DNS, etc).
Si tu utilises un adressage privé pour numéroter tes machines (rfc1918), et que ton serveur DNS ne gère pas la zone reverse (en in-addr.arpa) mais qu'il fait suivre les requêtes vers Internet, ça risque d'être lent.
En principe c'est le BIOS qui fait une émulation de disquette à partir du CD (qui doit être en format "El Torito"). Globalement, le BIOS intercepte les appels disque concernant la disquette et redirige vers le CD.
Je ne pense pas que LILO offre cette possibilité d'émulation (il faudrait qu'il gère les lecteurs CD matériellement parlant, les CD au format El-Torito, et qu'il émule une disquette suivant le principe décrit avant). Mais je me trompe peut-être.
Lorsque tu utilises la commande "arp", par défaut il y a tentative de résolution de nom (DNS) pour toutes les adresses IP présentes dans la table. Si ton serveur DNS est injoignable, il est donc "normal" que ça prenne bcp de temps.
Pour voir les entrées ARP sans avoir cette résolution DNS, il suffit d'utiliser l'option "-n". Pour toutes les entrées, ça donne donc "arp -na".
Pour le SSH, le serveur essaie de faire une résolution DNS inverse de l'adresse de la machine qui se connecte (pour les logs). Ce qui fait que là encore, s'il n'y a pas de serveur DNS fonctionnel, la connexion met un certain temps à s'établir (30 sec si ma mémoire est bonne).
Ca me parait quand même bizarre un kernel qui crashe à cause d'un filesystem plein.
C'est quelle version de noyau, avec quelle carte réseau utilisée ? Peux-tu recopier le contenu du kernel panic, ça permettra peut-être de voir à quel endroit ça plante.
On dirait que ta clé en passée en lecture-seule. Tu n'aurais pas verrouillé la clé en écriture par inadvertance, ou elle n'aurait pas été remontée en read-only par le système ?
1) est-ce possible que ça soit "mon linux/ma machine" qui soit pas capable d'utiliser un périf "Ultra ata 100" ??? (mon ordi n'est plus tout récent(presque 2 ans), mais si ça passe par usb/firewire, normalement on s'en fout que ça soit en ultra ata, sata ou classique , non ?)
Je pense aussi que la partie UltraATA100 ne doit pas être "vue" du PC. Il y a une conversion USB/Firewire -> interface ATA du disque. C'est marqué UltraATA 100 parce que le disque à l'intérieur est un disque classique avec ce type d'interface.
2) est-ce pk il est gros (250go de fat32) que des problèmes peuvent se poser sous linux, quand je copie des gros fichiers dessus ?
Non, personnellement j'en ai un de 250 Go formaté en FAT32 (Western Digital), et ça marche parfaitement. J'ai parfois eu quelques problèmes avec l'USB (il fallait brancher le disque avant de démarrer le PC) et ça a marché un jour avec le firewire, depuis ça ne fonctionne plus (un changement de noyau je suppose).
Je l'utiliste surtout en USB2.
3) Puis je mettre un disque dur plus petit et pas "ultra ata 100", avec un port ide classique dedans, et esperer des résultats positif ? (j'ai pas démonté encore le boitier, mais est-ce que le disque possède un port IDE classique, pour que je puisse au moins récupéré le hdd dans mon ordi ???)
En principe c'est un disque standard dedans, donc tu devrais pouvoir permuter. Perso, mon boitier est transparent et je vois bien la connectique, c'est un disque standard.
pour information, j'ai d'autres HDD usb2, ou clé usb1 et usb2 qui fonctionne parfaitement, ainsi qu'une cam DV qui se connecte bien via le firewire, donc je pense qu'au niveau config/module du noyau : tout est là ...
Déjà c'est étonnant que le disque ne soit pas vu en USB2 par un W2000-SP4...
C'est vraiment étonnant, gnome lancé et prêt à être utilise utilise moins de 100 Mo de Ram.
C'est pas pour lancer un vieux troll des familles (j'utilise Gnome et j'en suis satisfait), mais 100 Mo pour un environnement graphique tout juste lancé, je trouve ça personnellement énorme.
Quelqu'un sait ce qui prend tant de mémoire dans un environnement graphique récent ? le code (librairies, etc.) ou bien des données genre fontes, bitmap, etc ?
Posté par galactikboulay .
En réponse au message CVS templeet down ?.
Évalué à 1.
Dernière modification le 04 décembre 2021 à 17:42.
Il est possible d'effectuer un transfert de zone sur les serveurs DNS gérant la zone "templeet.org":
$ dig IN NS templeet.org
templeet.org. 86400 IN NS master.victorimage.com.
templeet.org. 86400 IN NS calchas.nouvo.com.
;; ADDITIONAL SECTION:
master.victorimage.com. 172796 IN A 62.212.110.62
calchas.nouvo.com. 172797 IN A 82.127.124.206
$ dig @62.212.110.62 IN AXFR templeet.org
; <<<< DiG 9.2.4rc5 >>>> @62.212.110.62 IN AXFR templeet.org
;; global options: printcmd
templeet.org. 86400 IN SOA master.victorimage.com. courtois.linuxfr.org. 2005022601 21600 3600 6048000 86400
templeet.org. 86400 IN NS master.victorimage.com.
templeet.org. 86400 IN NS calchas.nouvo.com.
templeet.org. 3600 IN MX 10 main.uucpssh.org.
templeet.org. 86400 IN A 212.27.33.226
courtois.templeet.org. 3600 IN CNAME calchas.nouvo.com.
www.courtois.templeet.org. 3600 IN CNAME calchas.nouvo.com.
svn.templeet.org. 3600 IN CNAME calchas.nouvo.com.
wiki.templeet.org. 86400 IN CNAME webother.linuxfr.org.
www.templeet.org. 3600 IN CNAME webother.linuxfr.org.
www2.templeet.org. 3600 IN CNAME master.victorimage.com.
www3.templeet.org. 3600 IN CNAME webother.linuxfr.org.
www4.templeet.org. 3600 IN CNAME master.victorimage.com.
templeet.org. 86400 IN SOA master.victorimage.com. courtois.linuxfr.org. 2005022601 21600 3600 6048000 86400
Je vois qu'il y a un "svn.templeet.org", ils sont peut-être passé sur subversion en remplacement de cvs ?
La dernière fois, nous nous sommes un peu heurté sur un autre thread
Il est vrai que j'avais répondu de manière un peu "brutale" sur une précision que tu avais faite. Je reconnais que c'était pas super diplomate :)
je n'ai malheureusement rien de mieux que dire : "aux armes citoyens!" et d'acquiesser ce que tu dis.
C'est quand même une question à se poser: on vote régulièrement (régionales, présidentielles, européennes, tout ce qu'on veut), en ce qui me concerne je vais voter à chaque fois, mais quand on voit que ces personnes se moquent de l'avis du parlement européen et qu'elles sont quasiment invirables par vote, on fait quoi ?
Le plus ironique dans l'histoire, c'est qu'il me semble que tous les partis (de l'extrême gauche à l'extrême droite) s'étaient prononcés unanimement contre les brevets logiciels. J'irai comme toi manifester mon mécontentement dans les urnes, en ayant bien à l'esprit que J.Chirac est décidément toujours opportuniste, et que Michel Rocard a lui de son côté fait un excellent travail. Beaucoup d'hommes politiques devraient s'en inspirer.
[^] # Re: Ca ne sert à rien de filtrer ce trafic...
Posté par galactikboulay . En réponse au message Flood Multicast. Évalué à 2.
Effectivement ça parait bizarre que ça ne marche mal que pour toi. As-tu pu estimer le débit que tu reçois sur ton interface relatif au trafic multicast ?
Peux-tu préciser ton modèle de carte réseau et la configuration de ton noyau ? (particulièrement la partie qui se trouve dans networking options ?). As-tu des infos sur les configurations RedHat qui n'ont pas le problème ?
# Ca ne sert à rien de filtrer ce trafic...
Posté par galactikboulay . En réponse au message Flood Multicast. Évalué à 4.
Pour régler ton problème, c'est à l'administrateur du réseau de faire son boulot correctement et de configurer ses switches pour qu'ils ne balancent pas les trames multicast sur des ports où il n'y a aucun récepteur multicast. Chez Cisco, la fonction à implémenter s'appelle CGMP, ou alors il y a IGMP Snooping qui est normalisé. Encore faut-il avoir des équipements qui supportent ces 2 fonctions (c'est pas gagné d'avance).
# /dev/kcore et périphériques
Posté par galactikboulay . En réponse au message dev/mem mémoire physique. Évalué à 2.
Je pense que tu fais plutôt référence à /proc/kcore qui est un fichier virtuel permettant d'accéder à l'intégralité de la mémoire physique.
Un mmap() judicieusement utilisé sur ce fichier permet d'accéder à n'importe(s) quelle(s) pages physiques. Mal utilisé, je te promets que tu vas flinguer le système très vite (surtout si tu écris sur des pages du noyau).
Après, pour ton périphérique, il y a 2 possibilités (sur architecture x86):
* Soit il utilise des ports IO spécifiques (voir instructions inb/outb et compagnie) et dans ce cas mapper la mémoire ne sert à rien. On peut voir les ports IO avec le fichier /proc/ioports.
* Soit c'est du "memory-mapped", et dans ce cas, je pense que mapper /proc/kcore fonctionnerait (en ne mappant que la zone qui t'intéresse bien sûr).
Le fichier /proc/iomem montre les zones mémoires et les périphériques qui utilisent ces zones.
Attention, toutes ces manips ne peuvent bien sûr se faire qu'en root.
[^] # Re: Mouai
Posté par galactikboulay . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 7.
Sinon sur le postmaster (donc le process principal), un ltrace me donne:
sigprocmask(2, 0x8256920, NULL) = 0
select(5, 0xbfffeb80, 0xbfffeb00, 0, 0xbfffeae8) = 1
sigprocmask(2, 0x82569c0, NULL) = 0
calloc(1, 620) = 0x826edc8
accept(3, 0x826ee3c, 0xbfffea78, 28127, 0x826edc8) = 8
getsockname(8, 0x826edcc, 0xbfffea78, 28127, 0x826edc8) = 0
setsockopt(8, 6, 1, 0xbfffea74, 4) = 0
setsockopt(8, 1, 9, 0xbfffea74, 4) = 0
Il y a aussi quelques petits malloc() qui trainent à droite à gauche.
Si c'est sur le fork, c'est "normal".
Faudrait savoir. En tout cas dans ma logique à moi, c'est incompatible avec une assertion du type "La partie serveur de Postgres ne fait pas de malloc()".
[^] # Re: Mouai
Posté par galactikboulay . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 5.
Déjà j'avais pas prétendu quoi que ce soit sur le comportement de Postgres, mais si tu y tiens:
Exemple:
[...]
memcpy(0x82eb36c, "", 4) = 0x82eb36c
memcpy(0x82eb370, "", 4) = 0x82eb370
memcpy(0x82eb374, "", 4) = 0x82eb374
memcpy(0x821fa27, "B\377\267\377\377\376", 368) = 0x821fa27
snprintf("FETCH 2", 64, "%s %u", "FETCH", 2) = 7
strlen("DeferredTriggerTupleContext") = 27
strcpy(0x8299748, "DeferredTriggerTupleContext") = 0x8299748
malloc(8192) = 0x82c5f98
free(0x82c5f98) =
strlen("FETCH 2") = 7
memcpy(0x821fb97, "C", 1) = 0x821fb97
memcpy(0x821fb98, "FETCH 2", 8) = 0x821fb98
memcpy(0x821fba0, "Z", 1) = 0x821fba0
sigemptyset(0xbfffe584) = 0
[...]
[^] # Re: Mouai
Posté par galactikboulay . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 1.
Ouais, rattrapage aux branches detected.
Oui, là ça marche vu que ltrace(), en plus d'afficher les appels systèmes effectués comme strace, enregistre les appels aux fonctions des librairies chargées dynamiquement.
Quoiqu'il en soit, pour ta gouverne, il est possible d'allouer de la mémoire en utilisant mmap() avec le flag MAP_ANONYMOUS (pour les OS qui le supportent, ça va de soi). malloc() est loin d'être la seule méthode d'allocation.
[^] # Re: Mouai
Posté par galactikboulay . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 2.
[^] # Re: Mouai
Posté par galactikboulay . En réponse à la dépêche Interview de Marcus Brinkmann, développeur du Hurd. Évalué à 3.
L'argument qui tue. malloc() n'est pas un appel système, strace ne le voit donc pas.
Les appels systèmes qui montrent une activité au niveau de la gestion mémoire, c'est mmap(), brk() et sbrk().
[^] # Re: svn vs cvs
Posté par galactikboulay . En réponse à la dépêche KDE 3.4 officiellement sorti. Évalué à 9.
Subversion fonctionne aussi avec WebDAV, ce qui est très pratique pour gérer ses "repository".
Mes 2 cents.
[^] # Re: whois.sc
Posté par galactikboulay . En réponse au message interrogation DNS inverse. Évalué à 3.
Il est possible d'affecter plusieurs enregistrements "PTR" à une même adresse IP, rien ne s'y oppose.
# Droits d'accès de l'utilisateur MySQL
Posté par galactikboulay . En réponse au message [mysql] plantage sous redhat. Évalué à 2.
Est-ce que le compte "mysql" est bien créé et a bien accès au répertoire où tu as installé la BDD ?
Sous linux, la valeur 13 pour errno correspond à la "EACCES", ce qui signifie "Permission Denied" (voir /usr/include/asm-generic/errno-base.h)
Je pense que tu devrais pouvoir t'en sortir avec du "chown -R mysql:mysql <rep_installation>"
En espérant que ça puisse t'aider.
[^] # Re: Résolution DNS
Posté par galactikboulay . En réponse au message Problème avec la table arp. Évalué à 2.
Si tu utilises un adressage privé pour numéroter tes machines (rfc1918), et que ton serveur DNS ne gère pas la zone reverse (en in-addr.arpa) mais qu'il fait suivre les requêtes vers Internet, ça risque d'être lent.
# BIOS
Posté par galactikboulay . En réponse au message Booter sur cd. Évalué à 3.
Voir les explications de:
http://thelinuxfr.org/howto/Bootdisk-HOWTO/ar01s11.html(...)
Je ne pense pas que LILO offre cette possibilité d'émulation (il faudrait qu'il gère les lecteurs CD matériellement parlant, les CD au format El-Torito, et qu'il émule une disquette suivant le principe décrit avant). Mais je me trompe peut-être.
# Liste des partitions
Posté par galactikboulay . En réponse au message pb de lecture d'une partition EXT3 fedora core 3. Évalué à 2.
# Résolution DNS
Posté par galactikboulay . En réponse au message Problème avec la table arp. Évalué à 3.
Lorsque tu utilises la commande "arp", par défaut il y a tentative de résolution de nom (DNS) pour toutes les adresses IP présentes dans la table. Si ton serveur DNS est injoignable, il est donc "normal" que ça prenne bcp de temps.
Pour voir les entrées ARP sans avoir cette résolution DNS, il suffit d'utiliser l'option "-n". Pour toutes les entrées, ça donne donc "arp -na".
Pour le SSH, le serveur essaie de faire une résolution DNS inverse de l'adresse de la machine qui se connecte (pour les logs). Ce qui fait que là encore, s'il n'y a pas de serveur DNS fonctionnel, la connexion met un certain temps à s'établir (30 sec si ma mémoire est bonne).
En espérant que ça puisse t'aider.
[^] # Re: full disque?
Posté par galactikboulay . En réponse au message kernel panic -promiscous mode. Évalué à 3.
C'est quelle version de noyau, avec quelle carte réseau utilisée ? Peux-tu recopier le contenu du kernel panic, ça permettra peut-être de voir à quel endroit ça plante.
# Un truc tout bête...
Posté par galactikboulay . En réponse au message Problème clé usb avec Mandrake. Évalué à 1.
# Quelques réponses
Posté par galactikboulay . En réponse au message Hdd externe en ultra-ata 100, sous linux, ça marche ?. Évalué à 2.
Je pense aussi que la partie UltraATA100 ne doit pas être "vue" du PC. Il y a une conversion USB/Firewire -> interface ATA du disque. C'est marqué UltraATA 100 parce que le disque à l'intérieur est un disque classique avec ce type d'interface.
Non, personnellement j'en ai un de 250 Go formaté en FAT32 (Western Digital), et ça marche parfaitement. J'ai parfois eu quelques problèmes avec l'USB (il fallait brancher le disque avant de démarrer le PC) et ça a marché un jour avec le firewire, depuis ça ne fonctionne plus (un changement de noyau je suppose).
Je l'utiliste surtout en USB2.
En principe c'est un disque standard dedans, donc tu devrais pouvoir permuter. Perso, mon boitier est transparent et je vois bien la connectique, c'est un disque standard.
Déjà c'est étonnant que le disque ne soit pas vu en USB2 par un W2000-SP4...
[^] # Re: Un bon cru
Posté par galactikboulay . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 3.
http://live.gnome.org/MemoryReduction(...)
[^] # Re: Un bon cru
Posté par galactikboulay . En réponse à la dépêche Sortie de GNOME 2.10. Évalué à 8.
C'est pas pour lancer un vieux troll des familles (j'utilise Gnome et j'en suis satisfait), mais 100 Mo pour un environnement graphique tout juste lancé, je trouve ça personnellement énorme.
Quelqu'un sait ce qui prend tant de mémoire dans un environnement graphique récent ? le code (librairies, etc.) ou bien des données genre fontes, bitmap, etc ?
[^] # Re: DNS
Posté par galactikboulay . En réponse au message CVS templeet down ?. Évalué à 1.
Essaie en installant un client subversion. J'ai trouvé un tutoriel assez sympa pour débuter:
http://toutprogrammer.com/article_19_8.html(...)
# DNS
Posté par galactikboulay . En réponse au message CVS templeet down ?. Évalué à 1. Dernière modification le 04 décembre 2021 à 17:42.
Il est possible d'effectuer un transfert de zone sur les serveurs DNS gérant la zone "templeet.org":
Je vois qu'il y a un "svn.templeet.org", ils sont peut-être passé sur subversion en remplacement de cvs ?
My 2 cents.
[^] # Re: Question conne
Posté par galactikboulay . En réponse à la dépêche La brevetabilité des inventions mises en oeuvre par ordinateur adoptée par le Conseil. Évalué à 2.
Il est vrai que j'avais répondu de manière un peu "brutale" sur une précision que tu avais faite. Je reconnais que c'était pas super diplomate :)
je n'ai malheureusement rien de mieux que dire : "aux armes citoyens!" et d'acquiesser ce que tu dis.
C'est quand même une question à se poser: on vote régulièrement (régionales, présidentielles, européennes, tout ce qu'on veut), en ce qui me concerne je vais voter à chaque fois, mais quand on voit que ces personnes se moquent de l'avis du parlement européen et qu'elles sont quasiment invirables par vote, on fait quoi ?
[^] # Re: Question conne
Posté par galactikboulay . En réponse à la dépêche La brevetabilité des inventions mises en oeuvre par ordinateur adoptée par le Conseil. Évalué à 6.
# SKAS conseillé...
Posté par galactikboulay . En réponse au message UML et 2.6.10. Évalué à 1.
Au niveau du host, je te conseille d'appliquer les patches SKAS (Separate Kernel Address Space), qui font gagner pas mal de performance.
2 URLs utiles:
http://www.user-mode-linux.org/~blaisorblade/(...)
http://user-mode-linux.sourceforge.net/skas.html(...)