Re: Santé des SSD et SSD plus généralement

[Thibaut Chèze]

Bonjour,

Encore merci pour vos réponses.
Une dernière relance.

> Et donc je vous pose la question, d'après vous dois-je apporter credit à
> ces indicateurs ou simplement au fait que le test SMART passe ?
> Quelqu'un a t'il de l'expérience en particulier avec le SMART et les SSD
> ? les SSD OCZ ?
>

Thibaut



signature.asc
Description: OpenPGP digital signature

Re: Santé des SSD et SSD plus généralement

[Thibaut Chèze]

Bonjour,

Merci pour les réponses.

Je me permet d'essayer de recentrer le débat. Pour les questions
d'hibernation, j'ai lu que la plupart des info avaient été traitée dans
un autre fil. En ce qui me concerne, la swap est surtout pour une
gestion "correct" des processus qui consomment trop de ram, pour que
l'oomkiller puisse s'exécuter en toute quiétude... (j'ai déjà vu des
kernel oops de l'oomkiller qui ne pouvais allouer les ressources
nécessaires à la mort d'un processus...

Mais bref, avec vos réponses je pense qu'on a fait le tour sur le
système de fichier ext4 en ce qui concerne les optimisations pour les
SSD. En revanche, personne n'a abordé le sujet du SMART...

Petites nouvelles de ce coté-ci, après mise à jour des firmwares et
"secure erase" la plupart des attributs SMART ont été réinitialisés...
Et donc je vous pose la question, d'après vous dois-je apporter credit à
ces indicateurs ou simplement au fait que le test SMART passe ?
Quelqu'un a t'il de l'expérience en particulier avec le SMART et les SSD
? les SSD OCZ ?
Je vous joins le fichier SMART d'après le reset.

Merci encore pour vos réponses,

Thibaut


Le 27/10/2011 11:58, Thibaut Chèze a écrit :
> Bonjour,
>
> Je viens vers vous car comme certains je me lance dans le monde du SSD
> et comme tous j'ai quelques difficultés...
> J'ai quelques interrogations qui restent sans réponses, mais j'y
> reviendrais par la suite.
>
> Tout d'abord, le SMART. Je sais qu'il y a moins d'indicateurs sur les
> SSD, que certains sont même très mal renseignés (comme pour les disques
> durs au début) mais voila, j'ai des SSD, je surveille le SMART et
> j'aimerai bien avoir d'autres avis sur la santé de ces "disques".
> Je joins quelques fichiers contenant le SMART:
>  - Les "sd[bc].ref.smart" sont les fichiers d'origine, juste après le
> branchement des disques
>  - Les "sd[bc].test.smart" sont ceux recueillit après deux "badblocks"
> sur les "disques" (pas de partitions encore, directement le device)
>  - Les "sd[bc].test2.smart" sont ceux recueillit après deux autres
> "badblocks" sur les "disques" et tests "court" et "long" de SMART
>
> J'ai trouver sur le net une référence de certaines des valeurs mais
> cette source n'indiquait pas les valeurs normales et/ou unités
> (http://www.ocztechnologyforum.com/staff/ryderocz/misc/Sandforce.jpg par
> exemple). N'hésitez pas si vous pouvez éclairer ma lanterne.
> Je suis quelques peut intrigué par la valeur "Power_On_Hours" (9), qui
> diminue avec le temps :-$, peut-être le MTBF (temps moyen entre deux
> pannes), mais à ce moment la, je crois que je devrais m'inquiéter.
> Il y a aussi les valeurs des "Raw_Read_Error_Rate" (1),
> "Hardware_ECC_Recovered" (195), "Soft_Read_Error_Rate" (201),
> "Soft_ECC_Correction" (204), qui sont parfaitement identiques et qui
> augmente avec le temps, sur un disque dur, je le remplacerait
> immédiatement...
> Et finalement la valeur du "Temperature_Celsius" (231), qui si l'on en
> croit le lien donné plus haut signifierait "SSD_Life_Left" et qui si la
> valeur est exacte, indiquerait que les disques sont en fin de vie...
>
> Qu'en pensez-vous ?
>
>
> Mes autres interrogations portent principalement sur le TRIM et le
> système de fichier ext4.
> J'ai lu dans une autre conversation qu'il était conseillé de mettre la
> swap dans un fichier sur une partition formatée en ext4 et montée avec
> l'option "discard".
>
> Ok pour l'ext4 avec l'option "discard" pour "activer" le TRIM, mais la
> swap, le fichier est créer, quand la machine swap, est remplit, mais en
> aucun cas supprimer quand la machine "déswap",  et donc le TRIM n'est
> jamais utilisé dessus ? je me trompe ? Du coup aucun interrêt à ce que
> se soit un fichier sur une partition...
>
> Autrement, il me semblait qu'il existait une option sur le système de
> fichier ext4 pour faire une sorte de "round-robin" des blocs et ainsi
> allongé la durée de vie des SSD, mais je n'arrive pas a en trouver la
> moindre trace, aurais-je rêvé ? Quelqu'un à t'il déjà entendu parler
> d'une telle option, en projet peut-être ? Automatique ?
>
> Y'a t'il d'autres options que "relatime", "noatime" et "discard" qui
> seraient intéressantes pour un SSD ?
>
> Pour revenir sur le TRIM, comment indiqué manuellement au SSD que les
> secteurs sont disponibles ? D'une part car j&#x

Re: Santé des SSD et SSD plus généralement

[Thibaut Chèze]

Le 27/10/2011 12:37, Anthony Bourguignon a écrit :
> Le jeudi 27 octobre 2011 à 11:58 +0200, Thibaut Chèze a écrit :
>> Mes autres interrogations portent principalement sur le TRIM et le
>> système de fichier ext4.
>> J'ai lu dans une autre conversation qu'il était conseillé de mettre la
>> swap dans un fichier sur une partition formatée en ext4 et montée avec
>> l'option "discard".
>>
>> Ok pour l'ext4 avec l'option "discard" pour "activer" le TRIM, mais la
>> swap, le fichier est créer, quand la machine swap, est remplit, mais en
>> aucun cas supprimer quand la machine "déswap",  et donc le TRIM n'est
>> jamais utilisé dessus ? je me trompe ? Du coup aucun interrêt à ce que
>> se soit un fichier sur une partition...
> La première question que tu devrais te poser c'est si tu as réellement
> besoin d'un partition de swap. Perso, même avec des machines avec
> "seulement" 2Go de ram, je n'ai jamais besoin de la swap. Et vu que
> j'utilise des ssd, bah j'en met pas. Comme ça, je me prend pas la tête.
Je m'étais posé la question mais malheureusement, j'ai des problèmes
d'oomkiller s'il n'y a pas de swap... et je préfère qu'il tourne
correctement ;-). Mais après oui, je ferais en sorte que la swap soit la
moins utilisée possible (swappiness, ...)
>> Pour revenir sur le TRIM, comment indiqué manuellement au SSD que les
>> secteurs sont disponibles ? D'une part car j'ai fais mes "badblocks"
>> dessus et que du coup normalement tout est occupé, mais aussi pour la
>> partition swap, lors d'un arrêt ou démarrage (avant le swapon) histoire
>> de... Autrement, j'envisageais de mettre un ext4 sur une partition qui
>> fait tout le SSD, la remplir avec un fichier, et supprimer se fichier...
> Si tu es prêt à réinstaller ton système, le plus simple est de faire un
> secure erase. Ça va permettre de repartir de zéro (je te le conseille).
> Une doc est dispo :
> https://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing . Sinon,
> tu lances l'utilitaire "fstrim" qui va s'occuper de faire l'opération
> manuellement en conservant ton système de fichiers.
>
J'étais manifestement passé à côté du "secure erase" dans mes
recherches, merci pour le lien, je vais me pencher dessus.
> En espérant que ça t'aid
C'est le cas, merci beaucoup.

Thibaut



signature.asc
Description: OpenPGP digital signature

Santé des SSD et SSD plus généralement

[Thibaut Chèze]

Bonjour,

Je viens vers vous car comme certains je me lance dans le monde du SSD
et comme tous j'ai quelques difficultés...
J'ai quelques interrogations qui restent sans réponses, mais j'y
reviendrais par la suite.

Tout d'abord, le SMART. Je sais qu'il y a moins d'indicateurs sur les
SSD, que certains sont même très mal renseignés (comme pour les disques
durs au début) mais voila, j'ai des SSD, je surveille le SMART et
j'aimerai bien avoir d'autres avis sur la santé de ces "disques".
Je joins quelques fichiers contenant le SMART:
 - Les "sd[bc].ref.smart" sont les fichiers d'origine, juste après le
branchement des disques
 - Les "sd[bc].test.smart" sont ceux recueillit après deux "badblocks"
sur les "disques" (pas de partitions encore, directement le device)
 - Les "sd[bc].test2.smart" sont ceux recueillit après deux autres
"badblocks" sur les "disques" et tests "court" et "long" de SMART

J'ai trouver sur le net une référence de certaines des valeurs mais
cette source n'indiquait pas les valeurs normales et/ou unités
(http://www.ocztechnologyforum.com/staff/ryderocz/misc/Sandforce.jpg par
exemple). N'hésitez pas si vous pouvez éclairer ma lanterne.
Je suis quelques peut intrigué par la valeur "Power_On_Hours" (9), qui
diminue avec le temps :-$, peut-être le MTBF (temps moyen entre deux
pannes), mais à ce moment la, je crois que je devrais m'inquiéter.
Il y a aussi les valeurs des "Raw_Read_Error_Rate" (1),
"Hardware_ECC_Recovered" (195), "Soft_Read_Error_Rate" (201),
"Soft_ECC_Correction" (204), qui sont parfaitement identiques et qui
augmente avec le temps, sur un disque dur, je le remplacerait
immédiatement...
Et finalement la valeur du "Temperature_Celsius" (231), qui si l'on en
croit le lien donné plus haut signifierait "SSD_Life_Left" et qui si la
valeur est exacte, indiquerait que les disques sont en fin de vie...

Qu'en pensez-vous ?


Mes autres interrogations portent principalement sur le TRIM et le
système de fichier ext4.
J'ai lu dans une autre conversation qu'il était conseillé de mettre la
swap dans un fichier sur une partition formatée en ext4 et montée avec
l'option "discard".

Ok pour l'ext4 avec l'option "discard" pour "activer" le TRIM, mais la
swap, le fichier est créer, quand la machine swap, est remplit, mais en
aucun cas supprimer quand la machine "déswap",  et donc le TRIM n'est
jamais utilisé dessus ? je me trompe ? Du coup aucun interrêt à ce que
se soit un fichier sur une partition...

Autrement, il me semblait qu'il existait une option sur le système de
fichier ext4 pour faire une sorte de "round-robin" des blocs et ainsi
allongé la durée de vie des SSD, mais je n'arrive pas a en trouver la
moindre trace, aurais-je rêvé ? Quelqu'un à t'il déjà entendu parler
d'une telle option, en projet peut-être ? Automatique ?

Y'a t'il d'autres options que "relatime", "noatime" et "discard" qui
seraient intéressantes pour un SSD ?

Pour revenir sur le TRIM, comment indiqué manuellement au SSD que les
secteurs sont disponibles ? D'une part car j'ai fais mes "badblocks"
dessus et que du coup normalement tout est occupé, mais aussi pour la
partition swap, lors d'un arrêt ou démarrage (avant le swapon) histoire
de... Autrement, j'envisageais de mettre un ext4 sur une partition qui
fait tout le SSD, la remplir avec un fichier, et supprimer se fichier...

Merci d'avoir pris le temps de me lire, et d'avance merci, pour toute
l'aide que vous apporterez, à moi-même, mais aussi aux autres qui
lierons ceci par la suite.

Thibaut

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.0.0-1-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model: OCZ-AGILITY3
Serial Number:OCZ-TQ89VYH86KE61BRD
LU WWN Device Id: 5 e83a97 e7462bf01
Firmware Version: 2.13
User Capacity:60 022 480 896 bytes [60,0 GB]
Sector Size:  512 bytes logical/physical
Device is:Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ACS-2 revision 3
Local Time is:Wed Oct 26 22:40:07 2011 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status:  (   0) The previous self-test routine completed
without error or no self-test has ever 
been run.
Total time to complete Offline 
data collection:( 2097) seconds.
Offline data collection
capabilities:(0x7f) SMART execute Offline immediate.
Auto Offline data collection on/off 
support.
   

Re: Reverse proxy avec apache

[Thibaut Chèze]

Bonjour,

Regarde le message exact du 404 et les log de http://192.168.1.40/ (mais
aussi ceux de la machine proxy), notamment le path.
Là à froid, j'ai l'impression que ton problème vient que tu mandate une
page exacte et non un 'site'.

Essai plutot quelque chose du genre :
ProxyPass /test/ http://192.168.1.40/
ProxyPassReverse /test/ http://192.168.1.40/

Et de faire comme requête :
http://chezmoi.org/test/page.html

Autrement, rien de problématique ne me saute au yeux dans ton montage,
je crois vraiment que les log de ton proxy t'en apprendrons plus.

Bon courage,

Thibaut Chèze

Le 31/08/2011 10:33, steve a écrit :
> Salut la liste,
>
> Je suis en train d'essayer de monter un reverse proxy avec apache2 sous
> Debian squeeze. Pour le moment j'obtiens un beau « Not found »..
>
> La configuration réseau est la suivante  :
>
> Internet  modem-router (192.168.1.1)
> ¦   ¦
> ¦   ¦
> ¦   ¦
>  proxy (192.168.1.12)   ` serveur web à atteindre (192.168.1.40)
>
>
> Ce que j'ai fait :
>
> 1) créé un fichier dans /etc/apache2/site-available/test
>
> avec dedans :
>
>
> 
> ServerName chezmoi.org
> 
>   
>   Order deny,allow
>   Allow from all
>   
>
>   ProxyPass   /test/ http://192.168.1.40/page.html
>   ProxyPassReverse/test   http://192.168.1.40/page.html
>
> ErrorLog /var/log/apache2/test/error.log
> LogLevel debug
> CustomLog /var/log/apache2/test/access.log combined
> 
>
>
> Puis j'ai activé les modules avec
>
> a2enmod proxy
> a2enmod proxy_http
>
> ensuite j'ai activé le virtual host « test » avec
>
> a2ensite test
>
> et enfin j'ai redémarré le serveur.
>
> Et en essayant (de l'extérieur du LAN) l'url http://chezmoi.org/test/, je 
> tombe sur cette erreur.
>
> Je peux pinguer sans problème du proxy vers 192.168.1.40.
>
>
> Qu'est-ce qu'il y a de faux dans ce montage ?
>
> Merci d'avance !
> steve
>



signature.asc
Description: OpenPGP digital signature

Re: A propos de fail2ban

[Thibaut Chèze]

Bonsoir,

> J'ai deux questions à propos de fail2ban qui tourne actuellement sur
> ma machine.
>
> 1°/ J'ai configuré fail2ban pour qu'il m'envoie un mail pour chaque
> adresse bannie.
> Je reçois entre 5 et 10 mails par jour que je classe dans un
> répertoire de ma boîte mail.
> Comme ça fait plusieurs mois que ça dure, j'ai plusieurs centaines d'@
> IP bannies.
>
> Y a t-il une possibilité de visualiser automatiquement la liste des
> @IP bannies ? (sur une page web par exemple, ou sous un autre format).
Pas de frontal à ma connaissance, mais coder une page web à partir de la
commande que vous indiquez ci-après n'est pas très difficile (si c'est
vraiment ce que vous souhaitez avoir...). Il doit surement y avoir
différentes petites astuces sur le net.

Par contre, fail2ban banni effectivement des IP, mais pour une durée
définie dans la conf (10min par défaut si je me souviens bien, 1h, 1j,
... cf "bantime"), parceque sinon... le parcours des tables pour chaque
paquet IP provoquerait une baisse de performance de votre réseaux au fur
et a mesure que le temps passe (sans compter les risques de DoS, la
réduction de la ram disponible, ...).
>
> 2°/ Voici ce que me renvoie la commande:
>
> # iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> fail2ban-ssh  tcp  --  anywhere anywhere   
> multiport dports ssh
> fail2ban-postfix  tcp  --  anywhere anywhere   
> multiport dports smtp,ssmtp
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain fail2ban-postfix (1 references)
> target prot opt source   destination
> RETURN all  --  anywhere anywhere   
>
> Chain fail2ban-ssh (1 references)
> target prot opt source   destination
> DROP   all  --  99.198.122.105   anywhere   
> DROP   all  --  204.110.14.17anywhere   
> DROP   all  --  247.112.140.187.ds.sparkstation.net
>   anywhere   
> DROP   all  --  58-242-115-208.static.reverse.lstn.net
>   anywhere   
> DROP   all  --  ip-72-167-47-28.ip.secureserver.net
>   anywhere   
> DROP   all  --  essen242.server4you.de
>   anywhere   
> DROP   all  --  66.11.123.195anywhere   
> DROP   all  --  truster-0.webhosting4.net
>   anywhere   
> RETURN all  --  anywhere anywhere
>
> J'avoue ne pas savoir quoi penser dernières lignes DROP ?
> D'après les infos que j'ai trouvées sur le NET cela ne semble pas très
> normal.
>
La chaine fail2ban-ssh contient les IP bannies par fail2ban pour le
service ssh (par analyse des log). Les autres chaines commencant par
"fail2ban-" aussi, pour d'autres service, dans votre cas, votre serveur
mail Postfix. Les entrées que vous voyez, sont celles qui on été bannies
suite à des tentatives d'accès infructueuses à ssh, et seront supprimées
une fois la durée du bannissement de chacune d'entre elles atteinte ou
un redémarrage de fail2ban. D'ailleurs, cette liste à surement changée
depuis le temps... Mais tout est parfaitement normal, vous n'êtes pas
très sollicité...

Pour en apprendre plus, aller lire la documentation est la meilleure
solution : http://doc.ubuntu-fr.org/fail2ban et
http://www.fail2ban.org/wiki/index.php/FAQ_french pour des documentation
en français, et surtout l'originale dans la langue de Shakespeare
: http://www.fail2ban.org/wiki/index.php/Main_Page

Un dernier point, si les mails vous sont inutiles, ou peu utiles, vous
devriez envisagez de les désactiver, vous économiseriez ainsi des
ressources sur les différentes machines qui manipules vos mails, de
l'espace disque, de l'énergie, et surement d'autres choses encore...

Thibaut


signature.asc
Description: OpenPGP digital signature

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonjour,

Après tests et surveillance, mes barrettes ne dépassent jamais les 45°C,
et sont le plus souvent à 42°C (:-)), la différence est dû à la
température de l'air qui entre dans la tour, non à l'utilisation de la ram.
Le voltage oscile entre 2.14V et 2.16V...
Je ne pense pas que le problème soit physique du coup...

Et la franchement, je ne vois pas quoi changer dans la conf pour changer
cela.

Le 12/09/2010 17:47, Thibaut Chèze a écrit :
> Bonjour
>   
>>   Reste à voir la stabilité avec 8 Gio. Là-dessus, mon avis est 
>> de faire gaffe à la température (donc aussi à la tension) : la 
>> RAM semble perdre en cohérence quand elle a chaud. (4 barrettes 
>> sont aussi plus difficiles à refroidir que 2 (plus serrées, 
>> etc.).) 
>>   
>> 
> En effet, perso, quand je les touches, elles ne sont pas "très chaudes",
> il y a un ventilateur d'extraction de 12cm 3cm au dessus d'elles.
> Les sensors m'indiquent qu'elles sont à 45°C en usage normal (pas
> spécialement stressant). Je ferais un retour si jamais elle augmente
> significativement lors d'une opération la sollicitant fortement.
>
> Autrement, le voltage est réglé à 2.10V dans le Bios, et le capteur
> indique 2.14 V, mais je ne pense pas qu'une si faible différence soit la
> cause des problèmes (Je regarderai egalement si cette valeur change
> lorsque le système est chargé).
>
>
>   



signature.asc
Description: OpenPGP digital signature

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonjour
>   Reste à voir la stabilité avec 8 Gio. Là-dessus, mon avis est 
> de faire gaffe à la température (donc aussi à la tension) : la 
> RAM semble perdre en cohérence quand elle a chaud. (4 barrettes 
> sont aussi plus difficiles à refroidir que 2 (plus serrées, 
> etc.).) 
>   
En effet, perso, quand je les touches, elles ne sont pas "très chaudes",
il y a un ventilateur d'extraction de 12cm 3cm au dessus d'elles.
Les sensors m'indiquent qu'elles sont à 45°C en usage normal (pas
spécialement stressant). Je ferais un retour si jamais elle augmente
significativement lors d'une opération la sollicitant fortement.

Autrement, le voltage est réglé à 2.10V dans le Bios, et le capteur
indique 2.14 V, mais je ne pense pas qu'une si faible différence soit la
cause des problèmes (Je regarderai egalement si cette valeur change
lorsque le système est chargé).




signature.asc
Description: OpenPGP digital signature

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonsoir,

J'ai remonter les deux autres barretes:

Voici les résultats pour en ne mettant pas l'option mem et en changeant
dans le bios la configuration de la ram pour la carte vidéo:
 * Vidéo 64M :
# dmesg | grep -F Memory
[0.00] Memory: 8122468k/9437184k available (3068k kernel code,
1115796k absent, 198920k reserved, 1886k data, 580k init)
[   53.814785] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).

 * Vidéo 128M :
# dmesg | grep -F Memory
[0.00] Memory: 8056932k/9437184k available (3068k kernel code,
1181332k absent, 198920k reserved, 1886k data, 580k init)
[   34.580225] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).

 * Vidéo 256M :
# dmesg | grep -F Memory
[0.00] Memory: 7927908k/9437184k available (3068k kernel code,
1312404k absent, 196872k reserved, 1886k data, 580k init)
[   50.808586] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).

 * Vidéo 512M :
# dmesg | grep -F Memory
[0.00] Memory: 7669860k/9437184k available (3068k kernel code,
1574548k absent, 192776k reserved, 1886k data, 580k init)
[   24.375618] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).

 * Vidéo Auto :
# dmesg | grep -F Memory
[0.00] Memory: 7927908k/9437184k available (3068k kernel code,
1312404k absent, 196872k reserved, 1886k data, 580k init)
[   23.845597] EDAC amd64: This node reports that Memory ECC is
currently disabled, set F3x44[22] (:00:18.3).

Auto est donc de 256M.

8122468k - 8056932k = 65536k = 64M Ok.
8056932k - 7927908k = 129024k = 126M NOk devrait être 128M.
7927908k - 7669860k = 258048k = 252M NOk devrait être 256M.

Bon, je ne sais trop quoi en conclure... Les résultats ne sont pas
exactement pile poil se qu'ils devraient, mais en même temps, je ne sais
pas avec précisions ce qu'ils doivent être... Tout ce que je peux dire,
c'est qu'ils n'en sont pas si éloignés, et que du coup, je ne pense pas
qu'il y ai un soucis vis à vis de cela.

Une opinion ?

Thibaut

Le 09/09/2010 11:05, Thibaut Chèze a écrit :
> Bonjour,
>   
>>> […] 
>>> Le système plante plus vite, plus la mémoire est grande, à
>>> 8192M, le système à tenu 4 jours...
>>>
>>> Autrement, j'ai essayé d'autres options du noyau après avoir
>>> exploré ces liens:
>>> […]
>>> 
>>>   
>>   Ce sont surtout des aveugles qui se guident entre eux, et donc 
>> tournent en rond. (Un peu comme nous, donc.)
>>   Le « problème » qu’ils essaient de régler, ce sont des 
>> messages bénins du noyau et la « perte » de 64 Mio pour/par 
>> l’IOMMU. Ça ne me semble pas en rapport avec ton problème de 
>> plantage.
>>   
>> 
> :-D
>   
>>   
>> 
>>> J'ai adopté les options "iommu=soft,noaperture,memaper" pour
>>> ne plus avoir ce message dans dmesg (le memaper était dans
>>> l'espoir de résoudre le problème:
>>> [0.004000] Aperture beyond 4Gb. Ignoring.
>>> [0.004000] Your BIOS doesn't leave a aperture memory hole
>>> [0.004000] Please enable the IOMMU option in the BIOS setup
>>> [0.004000] This costs you 64 MB of RAM
>>> ...
>>>
>>> Si quelqu'un en sait plus sur l'option iommu et peu me
>>> conseiller dans les options à placer dans mon cas,
>>> n'hésitez-pas, j'essaierai (pas avant jeudi, la je suis en
>>> cours de reconstruction du RAID sur la machine...) Je ne
>>> sais pas pourquoi, mais j'ai bien l'impression que mes
>>> soucis proviennent de la.
>>> 
>>>   
>>   Mm, moi pas. Comme quoi les impressions…
>>
>> Les options iommu :
>>
>> soft :
>>   Puisque tu as un AMD (d’après ta carte mère), Linux peut 
>> utiliser le GART (donc pas la peine de mettre iommu=soft).
>> Tu dois aussi voir ce genre de messages dans dmesg :
>>
>> [0.785442] PCI-DMA: Disabling AGP.
>> [0.785520] PCI-DMA: aperture base @ 2000 size 65536 KB
>> [0.785521] PCI-DMA: using GART IOMMU.
>> [0.785524] PCI-DMA: Reserving 64MB of IOMMU area in the AGP 
>> aperture
>>
>> memaper :
>>   C’est pour changer la taille du IOMMU. Sans valeur, c’est 
>> 64 Mio, donc idem que sans l’option.
>>
>> noaperture :
>>   Si je comprends bien, c’est pour empêcher d’utiliser 
>> l’ouverture prévue pour l’AGP pour l’IOMMU.
>>
>>   Pour voir l’effet de chaque option, dmesg > dm-{opts}
>> et regarde-les côte à côte… 
>>
>>   Cependant, le noyau semble très b

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonjour,
>> […] 
>> Le système plante plus vite, plus la mémoire est grande, à
>> 8192M, le système à tenu 4 jours...
>>
>> Autrement, j'ai essayé d'autres options du noyau après avoir
>> exploré ces liens:
>> […]
>> 
>   Ce sont surtout des aveugles qui se guident entre eux, et donc 
> tournent en rond. (Un peu comme nous, donc.)
>   Le « problème » qu’ils essaient de régler, ce sont des 
> messages bénins du noyau et la « perte » de 64 Mio pour/par 
> l’IOMMU. Ça ne me semble pas en rapport avec ton problème de 
> plantage.
>   
:-D
>   
>> J'ai adopté les options "iommu=soft,noaperture,memaper" pour
>> ne plus avoir ce message dans dmesg (le memaper était dans
>> l'espoir de résoudre le problème:
>> [0.004000] Aperture beyond 4Gb. Ignoring.
>> [0.004000] Your BIOS doesn't leave a aperture memory hole
>> [0.004000] Please enable the IOMMU option in the BIOS setup
>> [0.004000] This costs you 64 MB of RAM
>> ...
>>
>> Si quelqu'un en sait plus sur l'option iommu et peu me
>> conseiller dans les options à placer dans mon cas,
>> n'hésitez-pas, j'essaierai (pas avant jeudi, la je suis en
>> cours de reconstruction du RAID sur la machine...) Je ne
>> sais pas pourquoi, mais j'ai bien l'impression que mes
>> soucis proviennent de la.
>> 
>   Mm, moi pas. Comme quoi les impressions…
>
> Les options iommu :
>
> soft :
>   Puisque tu as un AMD (d’après ta carte mère), Linux peut 
> utiliser le GART (donc pas la peine de mettre iommu=soft).
> Tu dois aussi voir ce genre de messages dans dmesg :
>
> [0.785442] PCI-DMA: Disabling AGP.
> [0.785520] PCI-DMA: aperture base @ 2000 size 65536 KB
> [0.785521] PCI-DMA: using GART IOMMU.
> [0.785524] PCI-DMA: Reserving 64MB of IOMMU area in the AGP 
> aperture
>
> memaper :
>   C’est pour changer la taille du IOMMU. Sans valeur, c’est 
> 64 Mio, donc idem que sans l’option.
>
> noaperture :
>   Si je comprends bien, c’est pour empêcher d’utiliser 
> l’ouverture prévue pour l’AGP pour l’IOMMU.
>
>   Pour voir l’effet de chaque option, dmesg > dm-{opts}
> et regarde-les côte à côte… 
>
>   Cependant, le noyau semble très bien se débrouiller tout seul.
> Et les 64 Mio pour l’IOMMU semblent soit ne pas être un vrai 
> problème, soit, de toute façon, ne pas être récupérables sans 
> aide du BIOS.
>
>   
Merci pour tes précisions. Manifestement, j'ai la fausse illusion de
comprendre ce que je fais :-D. Effectivement, par la suite j'ai les 4
lignes que tu as cité.
>> D'ailleurs, avec cette option et sans la mem, la mémoire
>> disponible dans un free est inférieur de 1Mo que lors de
>> l'absence de celle-ci.
>>
>> Autrement, je souhaitais revalidé la bonne santé du nouveau
>> jeu de barrettes que j'ai installé suite au plantage à
>> 8192M, elles sont bonnes. Et dans un dernier test, je ne
>> tourne actuellement que sur elles, je vous met toutes les
>> infos que j'ai ci-après, des fois que cela vous donne des
>> pistes...
>> 
>   Quand tu fais un test, tu laisses tourner suffisamment ?
> (24-48 h)
>   
Oui, oui :-). Dernier test, 57h (et quand je les ai eux, j'ai testé
pendant plus de 4j, suite à mes problèmes, je voulais vraiment pouvoir
avoir confiance).
>   À noter aussi que memtest ne stresse pas toujours les 
> barrettes comme une utilisation réelle. Un bon gros md5sum sur 
> des données plus grosses que la RAM réussissait à me faire 
> planter des barrettes qui tenaient très bien face à memtest.
>   
Et actuellement, le système tourne sur les 2 barrettes récemment
obtenues (et dernièrement testées), il ne semble pas y avoir de problème
avec l'utilisation normal que j'en fais (comme tu l'a mentionner, gros
md5 de 8G en moyenne, par2 de fichiers ... et reconstruction du raid6).
Pour le moment aucun problème, le raid devrais finir aujourd'hui, a voir
si il n'y a pas de plantage au moment où il finit. Et si j'ai le temps,
je remet les 2 autres barrettes ce soir.
>   Donc, avec 4 Gio, tu perds « seuleument » 200 Mio. Ce qui est 
> quand même beaucoup si ta carte vidéo ne prend que 64 Mio (je 
> perds 142 Mio sur une machine dont la c.v. est à 128 Mio (mais 
> c’est pas forcément comparable : elle utilise le « Sideport » 
> d’AMD)) mais c’est sans rapport avec le Gio perdu avant.
>   Tu n’as aucune autre option dans le BIOS ? Tu as essayé de 
> changer la taille de la RAM de la c.v. pour voir si la 
> répercussion était exacte ?
>   
J'avais fait le test, j'ai plus les valeurs en tête, mais oui, je crois
bien me rappeler qu'en augmentant la taille de la ram video, je perdais
l'équivalent en ram disponible. Je referais le test et communiquerai les
infos.
>   Au fait, avec 8 Gio, c’était les mêmes barrettes (marque 
> caractéristiques) ? Parfois les mélanges…
>   
Oui ce sont les mêmes barrettes exactement, les DDR2 Corsair XMS2 de 2G
chacunes (1066Mhz, cas 5-5-5-15 T2 à 2.10V).

Merci beaucoup.

Thibaut



signature.asc
Description: OpenPGP digital signature

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonsoir à tous,

Je reviens vers vous, car de mon coté j'ai fais quelques avancées, mais
bon toujours rien de pleinement fonctionnel...

>> Que puis-je en conclure ? Que puis-je faire pour récupérer la
>> plage 0001fbf0 - 00024000, ou l'empêcher de
>> la dépasser ?
>> 
>   À mon avis, l’option mem= n’est pas la bonne piste car elle ne 
> fait que limiter la zone adressable. Tu as 8 Gio (moins env. 
> 256 Mio) si tu ne la mets pas, ce qui semble correct.
>   En revanche, il reste savoir pourquoi ça plante aussi 
> fréquemment quand elle n’y est pas. Mais là, moi pas savoir. 
> Peut-être voir avec la LKML (mais c’est sûr que sans trace des 
> oops, ça n’est pas évident).
>   (Tu peux aussi essayer d’autres valeurs pour mem=. P.ex. peut-
> être qu’à 8.5 Gio, tu récupèreras tout et ne planteras pas… Ça 
> peut être utile pour mieux cerner le problème.)
>
>   
Je suis d'accord, mem= n'est pas la solution, mais c'est déjà un début
pour pouvoir fonctionné en dégradé.
Et j'ai d'ailleurs essayé d'autres valeurs sans aucun succès. Le système
plante plus vite, plus la mémoire est grande, à 8192M, le système à tenu
4 jours...

Autrement, j'ai essayé d'autres options du noyau après avoir exploré ces
liens:
 *
http://vip.asus.com/forum/view.aspx?id=20080110054618984&board_id=1&model=M2NPV-VM&page=1&SLanguage=en-us
 * http://fixunix.com/kernel/385042-aperture-memory-hole-x86_64-a.html
 * http://fixunix.com/embedded/5808-memory-hole.html
 *
http://ubuntuforums.org/showthread.php?t=1018854&highlight=enable+iommu+option+bios
 * http://ubuntuforums.org/showthread.php?t=1063612
 *
http://ubuntuforums.org/showthread.php?t=1018854&highlight=enable+iommu+option+bios&page=3
 *
http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/x86_64/boot-options.txt
 * http://ubuntuforums.org/showpost.php?p=6855830&postcount=88

J'ai adopté les options "iommu=soft,noaperture,memaper" pour ne plus
avoir ce message dans dmesg (le memaper était dans l'espoir de résoudre
le problème:
[0.004000] Aperture beyond 4Gb. Ignoring.
[0.004000] Your BIOS doesn't leave a aperture memory hole
[0.004000] Please enable the IOMMU option in the BIOS setup
[0.004000] This costs you 64 MB of RAM
...

Si quelqu'un en sait plus sur l'option iommu et peu me conseiller dans
les options à placer dans mon cas, n'hésitez-pas, j'essaierai (pas avant
jeudi, la je suis en cours de reconstruction du RAID sur la machine...)
Je ne sais pas pourquoi, mais j'ai bien l'impression que mes soucis
proviennent de la.
D'ailleurs, avec cette option et sans la mem, la mémoire disponible dans
un free est inférieur de 1Mo que lors de l'absence de celle-ci.

Autrement, je souhaitais revalidé la bonne santé du nouveau jeu de
barrettes que j'ai installé suite au plantage à 8192M, elles sont
bonnes. Et dans un dernier test, je ne tourne actuellement que sur
elles, je vous met toutes les infos que j'ai ci-après, des fois que cela
vous donne des pistes...

Merci


# cat  /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ;
MemTotal:3996320 kB
MemFree:   34656 kB
Buffers:  194684 kB
Cached:  2730776 kB
SwapCached:0 kB
Active:  1386204 kB
Inactive:2419260 kB
Active(anon): 540224 kB
Inactive(anon):   340516 kB
Active(file): 845980 kB
Inactive(file):  2078744 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:  16777208 kB
SwapFree:   16777208 kB
Dirty:12 kB
Writeback:64 kB
AnonPages:880004 kB
Mapped:16368 kB
Shmem:   736 kB
Slab:  91768 kB
SReclaimable:  58352 kB
SUnreclaim:33416 kB
KernelStack:1672 kB
PageTables: 4800 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:18775368 kB
Committed_AS: 964500 kB
VmallocTotal:   34359738367 kB
VmallocUsed:  143712 kB
VmallocChunk:   34359579124 kB
HardwareCorrupted: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:4928 kB
DirectMap2M: 2025472 kB
DirectMap1G: 2097152 kB

 total   used   free sharedbuffers cached
Mem:  3902   3869 33  0190   2666
-/+ buffers/cache:   1012   2890
Swap:16383  0  16383

reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x1 ( 4096MB), size= 1024MB, count=1: write-back
reg03: base=0x0d800 ( 3456MB), size=  128MB, count=1: write-combining

# dmesg | grep -F Memory
[0.00] Memory: 3985096k/5242880k available (3068k kernel code,
1115796k absent, 141988k reserved, 1886k data, 580k init)
[   53.840105] EDAC amd64: This node reports that Memo

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonsoir,

>   Pour clairement (/proc/mtrr n’est pas utile, la preuve tu as 
> le même avec 7 ou 8 Gio) voir ce que Linux a comme RAM :
>   
En fait, le proc mtrr, c'était parce qu'il était différent dans le cas
ou dans le Bios je desactivais le Memory Hole Remapping, mais puisque le
système n'est pas plus stable dans ce cas, je n'ai pas insister.
> $ dmesg | grep -F Memory
> [0.00] Memory: 2048700k/2095936k available (3068k kernel 
> code, 388k absent, 46848k reserved, 1886k data, 580k init)
> (available = memory + absent + reserved)
>
>   Si ça ne correspond pas à ce qui est installé, ça peut être 
> parce que le BIOS ne donne pas tout : Linux se fie au BIOS (même 
> pas peur !).
>
>   Pour voir ce que Linux voit comme RAM passée par le BIOS :
> $ dmesg | grep -F usable
> [0.00]  BIOS-e820:  - 0009f800 
> (usable)
> [0.00]  BIOS-e820: 0010 - 7fed 
> (usable)
>
>   Tu sommes ensuites les intervalles :
> 0x9f800 + 0x7fed-0x10 = 2145843200
> 2145843200 ≈ 2046.44 Gio
>
>   Si ton PC plante seulement quand tu demandes au BIOS de rendre 
> les trous, c’est peut-être un problème de BIOS (= annonce de 
> mauvaises plages à Linux). Personne n’a signalé de problème avec 
> ta carte mère ?
>
>   
Pour ma carte mère la seul chose qui s'y rapproche c'était un post sur
le site d'asus avec le debut d'un boot kernel.
Mais je n'y ai rien vu de concluent :-$
Je donnerais le lien dès que je remet la main dessus.


Pour ce qui est des traces, la avec l'option "mem=" :

# dmesg | grep -F Memory
[ 0.00] Memory: 7021668k/8322048k available (3067k kernel code,
1115796k absent, 184584k reserved, 1886k data, 584k init)
[ 30.409195] EDAC amd64: This node reports that Memory ECC is currently
disabled, set F3x44[22] (:00:18.3).

# dmesg | grep -F usable
[ 0.00] BIOS-e820:  - 0009b800 (usable)
[ 0.00] BIOS-e820: 0010 - bbed (usable)
[ 0.00] BIOS-e820: 0001 - 00024000 (usable)
[ 0.00] user:  - 0009b800 (usable)
[ 0.00] user: 0010 - bbed (usable)
[ 0.00] user: 0001 - 0001fbf0 (usable)
[ 0.00] e820 update range:  - 0001
(usable) ==> (reserved)
[ 0.00] e820 update range: c000 - 0001
(usable) ==> (reserved)

Et sans l'option "mem=" :
# dmesg | grep -F Memory
[ 0.00] Memory: 8122476k/9437184k available (3067k kernel code,
1115796k absent, 198912k reserved, 1886k data, 584k init)
[ 45.902343] EDAC amd64: This node reports that Memory ECC is currently
disabled, set F3x44[22] (:00:18.3).

# dmesg | grep -F usable
[ 0.00] BIOS-e820:  - 0009b800 (usable)
[ 0.00] BIOS-e820: 0010 - bbed (usable)
[ 0.00] BIOS-e820: 0001 - 00024000 (usable)
[ 0.00] e820 update range:  - 0001
(usable) ==> (reserved)
[ 0.00] e820 update range: c000 - 0001
(usable) ==> (reserved)

Que puis-je en conclure ? Que puis-je faire pour récupérer la plage
0001fbf0 - 00024000, ou l'empêcher de la dépasser ?

Merci d'avance,

Thibaut




signature.asc
Description: OpenPGP digital signature

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

>> [ 7461.450522] BUG: unable to handle kernel paging request at
>> 89018b4f98e8
>> 
> [...]
> Peut-être à rapprocher avec le même problème que j'ai signalé :
> http://lists.debian.org/debian-user-french/2010/08/msg00221.html
>
>   
Après lecture, il n'est vraiment pas impossible que nous ayons le même
problème. Essai peut-être de mettre moins de barrettes, pour moi sa
devient fonctionnel. (Perso, pas de pb de voltage, il est bon, le cas
aussi... Physiquement, tout est ok normalement).
> Depuis, j'ai testé la ram pendant 48h. Il n'y a pas de défaut.
> Comme les plantages sont assez facilement reproductibles, j'évite de saturer 
> la ram avec de gros transferts de fichiers simultanés.
> Ces plantages sont apparus depuis que j'ai installé rdiff-backup. Je ne sais 
> pas si c'est lié.
>
>   
Par contre pas de rapport avec rdiff-backup, car je ne l'utilise pas, il
n'est même pas installer.
Ceci étant, je fais beaucoup d'action qui solicite la ram (transferts,
encodage, ...) mais c'est pour sa que j'en ai mis autant, donc pour moi
il est exclut de limités ces utilisations...

Mais bon si l'on me trouve une solution, elle fonctionnera peut-être
aussi pour toi ^^.

Thibaut



signature.asc
Description: OpenPGP digital signature

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

Bonjour,

>> Je viens vers vous car ma configuration plante (kernel oops), au bout
>> d'un certain temps, lorsque je sollicite l'intégralité de ma ram (soft +
>> cache).
>> Je pense que le problème viens de l'adressage
>> 
>   Tu as combien de barrette de mémoire : 2 ou 4 ?
>   Et avec 1 seule barrette ?
> le problème persiste ?
>   
J'avais mis plus de détails techniques dans la suite du mail. J'ai 4
barrettes, et le système est stable avec 2 (en dual channel).
>   Et si ca venait de l'affichage ?
> As-tu fais tourner un serveur SSH et essayé de prendre la machine à distance ?
>   
Et pour être plus précis, par ssh, ou console directe (clavier + ecran),
impossible de reprendre la main, car le device mapper étant planter
(Disques en raid6), plus d'accès disques possible, donc plus possible de
lancer de nouveaux soft (mem si théoriquement ils sont déjà chargés en
RAM). Le bash qui tournait avant le crash, tournait toujours, mais
impossible de lancer quoi que se soit dedans, ni même un autre bash...

J'ai réussi a avoir une trace par le passée, je te la met en fin de
mail, mais il se peut que mes traces actuelles soit un peu différente,
bien que très ressemble, car celle-ci à été faite à l'époque où l'un de
mes jeux de barrettes était défectueux.
> Cordialement.
>   
***
Kernel oops :

[ 7461.450522] BUG: unable to handle kernel paging request at
89018b4f98e8
[ 7461.452509] IP: [] clone_endio+0x1e/0xad [dm_mod]
[ 7461.452509] PGD 0
[ 7461.452509] Oops:  [#1] SMP
[ 7461.452509] last sysfs file: /sys/devices/virtual/block/md0/md/raid_disks
[ 7461.452509] CPU 2
[ 7461.452509] Modules linked in: ext2 ext4 mbcache jbd2 crc16 raid456
async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative
powernow_k8 xt_multiport iptable_filter ip_tables x_tables xfrm_user
xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 deflate zlib_deflate
ctr twofish twofish_common camellia serpent blowfish cast5 des_generic
cbc cryptd aes_x86_64 aes_generic xcbc rmd160 sha256_generic
sha1_generic hmac crypto_null af_key fuse clip atm md_mod dm_crypt
snd_hda_codec_nvhdmi snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_hwdep sd_mod crc_t10dif snd_pcm ide_pci_generic snd_timer edac_core
sata_promise video i2c_nforce2 ahci ata_generic joydev snd shpchp
serio_raw output wmi edac_mce_amd libata psmouse pcspkr i2c_core
asus_atk0110 pci_hotplug evdev amd74xx soundcore scsi_mod snd_page_alloc
button processor squashfs loop aufs(C) nfs lockd fscache nfs_acl
auth_rpcgss sunrpc ide_generic ide_core usbhid hid ohci_hcd sky2
ehci_hcd forcedeth usbcore nls_base thermal fan thermal_sys dm_mirror
dm_region_hash dm_log dm_mod
[ 7461.484282] Pid: 29577, comm: md0_raid6 Tainted: G C
2.6.32-trunk-amd64 #1 System Product Name
[ 7461.484282] RIP: 0010:[]  []
clone_endio+0x1e/0xad [dm_mod]
[ 7461.484282] RSP: 0018:880125c49c70  EFLAGS: 00010286
[ 7461.484282] RAX: a00a0010 RBX:  RCX:
001a000b
[ 7461.484282] RDX: 8801dccec7b8 RSI:  RDI:
c900063a0040
[ 7461.484282] RBP: 8802383ce780 R08:  R09:
880663c0
[ 7461.484282] R10: 880098126840 R11: a000160a R12:
8802129df858
[ 7461.484282] R13:  R14: 89018b4f98e8 R15:
88023b6960f0
[ 7461.484282] FS:  7f4a2c1996f0() GS:88000888()
knlGS:
[ 7461.484282] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[ 7461.484282] CR2: 89018b4f98e8 CR3: 01001000 CR4:
06e0
[ 7461.484282] DR0:  DR1:  DR2:

[ 7461.484282] DR3:  DR6: 0ff0 DR7:
0400
[ 7461.484282] Process md0_raid6 (pid: 29577, threadinfo
880125c48000, task 88023a5d1c40)
[ 7461.484282] Stack:
[ 7461.484282]  8800747e4a80 88007f686780 88023bfbd000

[ 7461.484282] <0> 880098126840 a00014ec 88007f46d150
8800747e4a80
[ 7461.484282] <0> 8801337c8950 88023dace200 000c

[ 7461.484282] Call Trace:
[ 7461.484282]  [] ? dec_pending+0x130/0x157 [dm_mod]
[ 7461.484282]  [] ? handle_stripe+0xc83/0x1785 [raid456]
[ 7461.484282]  [] ? __release_stripe+0x165/0x199
[raid456]
[ 7461.484282]  [] ? raid5d+0x3a5/0x3ee [raid456]
[ 7461.484282]  [] ? schedule_timeout+0x2e/0xdd
[ 7461.484282]  [] ? md_thread+0xf1/0x10f [md_mod]
[ 7461.484282]  [] ? autoremove_wake_function+0x0/0x2e
[ 7461.484282]  [] ? md_thread+0x0/0x10f [md_mod]
[ 7461.484282]  [] ? kthread+0x79/0x81
[ 7461.484282]  [] ? child_rip+0xa/0x20
[ 7461.484282]  [] ? kthread+0x0/0x81
[ 7461.484282]  [] ? child_rip+0x0/0x20
[ 7461.484282] Code: 0f 0b eb fe 5b 5d 41 5c 41 5d 41 5e c3 41 56 41 55
41 54 55 48 89 fd 53 4c 8b 67 58 89 f3 49 8b 7c 24 08 4d 8b 34 24 48 8b
47 08 <4d> 8b 2

Re: Utilisation stable de l'intégralité de la ram disponible

[Thibaut Chèze]

J'ai oublier de mettre la seconde option au boot que j'ai testé :
"iommu=noagp,noaperture"
Désolé,

Bonne soirée,

Thibaut


Le 31/08/2010 19:50, Thibaut Chèze a écrit :
> Bonsoir à tous,
>
> Je viens vers vous car ma configuration plante (kernel oops), au bout
> d'un certain temps, lorsque je sollicite l'intégralité de ma ram (soft +
> cache).
> Je pense que le problème viens de l'adressage, bien que j'ai joué de
> malchance par le passé (j'ai du changer à deux reprise un jeu de
> barrettes), celles-ci passent sans problème le memtest86+ v4.10. Mais
> celui-ci scan de 0 à 3G, puis passe de 4G à 9G (manifestement les
> adresses comprises entre 3G et ~4G sont remappée entre 8G et 9G) et je
> pense que le problème doit y être lier.
>
> Actuellement, j'ai réussi à obtenir un système "stable" en ajoutant
> l'option "mem=8127M" lors du boot (j'ai également essayé l'option "",
> sans succès) qui me permet d'avoir 6363M d'utilisables, soit une perte
> d'un peu plus d'1G. Auriez-vous une solution pour y palier ?
>
> Ma configuration:
> - OS: Debian GNU/Linux Squeeze 64Bit, Kernel 2.6.32-5 amd64
> - Carte Mère : Asus Formula 2 Crosshair (avec carte graphique
> intégrée qui prend 64M de ram au système, les valeurs possibles dans le
> BIOS sont 64M, 128M, 256M et 512M) avec l'option "Memory Hole Remapping"
> active dans le Bios, car sinon, seulement 7G sont utilisables sans pour
> autant que le système ne plante.
> - DDR2 Corsair 4x2G
>
>
> Infos en configuration fonctionnelle :
>
> ***
> #cat  /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ;
> cat /proc/pagetypeinfo
> MemTotal:7032884 kB
> MemFree:   52852 kB
> Buffers:  105520 kB
> Cached:  5759084 kB
> SwapCached:0 kB
> Active:  3662644 kB
> Inactive:3034516 kB
> Active(anon): 688384 kB
> Inactive(anon):   145028 kB
> Active(file):2974260 kB
> Inactive(file):  2889488 kB
> Unevictable:   0 kB
> Mlocked:   0 kB
> SwapTotal:  16777208 kB
> SwapFree:   16777208 kB
> Dirty: 20340 kB
> Writeback: 4 kB
> AnonPages:832564 kB
> Mapped:11576 kB
> Shmem:   848 kB
> Slab: 213196 kB
> SReclaimable: 179104 kB
> SUnreclaim:34092 kB
> KernelStack:1672 kB
> PageTables: 4872 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit:20293648 kB
> Committed_AS: 954036 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:  150900 kB
> VmallocChunk:   34359573492 kB
> HardwareCorrupted: 0 kB
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> DirectMap4k:8000 kB
> DirectMap2M: 3004416 kB
> DirectMap1G: 4194304 kB
>
>  total   used   free sharedbuffers cached
> Mem:  6868   6816 51  0103   5624
> -/+ buffers/cache:   1089   5778
> Swap:16383  0  16383
>
> reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
> reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
> reg02: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back
> reg03: base=0x2 ( 8192MB), size= 1024MB, count=1: write-back
> reg04: base=0x0d800 ( 3456MB), size=  128MB, count=1: write-combining
>
> Page block order: 9
> Pages per block:  512
>
> Free pages count per migrate type at order   0  1  2 
> 3  4  5  6  7  8  9 10
> Node0, zone  DMA, typeUnmovable  2  2  3 
> 3  3  1  0  0  1  0  0
> Node0, zone  DMA, type  Reclaimable  0  0  0 
> 0  0  0  0  0  0  0  0
> Node0, zone  DMA, type  Movable  0  0  0 
> 0  0  0  0  0  0  0  3
> Node0, zone  DMA, type  Reserve  0  0  0 
> 0  0  0  0  0  0  1  0
> Node0, zone  DMA, type  Isolate  0  0  0 
> 0  0  0  0  0  0  0  0
> Node0, zoneDMA32, typeUnmovable   2979 75  4 
> 1  0  0  0  0  0  0  0
> Node0, zoneDMA32, type  Reclaimable   1212 

Utilisation stable de l'intégralité de la ra m disponible

[Thibaut Chèze]

Bonsoir à tous,

Je viens vers vous car ma configuration plante (kernel oops), au bout
d'un certain temps, lorsque je sollicite l'intégralité de ma ram (soft +
cache).
Je pense que le problème viens de l'adressage, bien que j'ai joué de
malchance par le passé (j'ai du changer à deux reprise un jeu de
barrettes), celles-ci passent sans problème le memtest86+ v4.10. Mais
celui-ci scan de 0 à 3G, puis passe de 4G à 9G (manifestement les
adresses comprises entre 3G et ~4G sont remappée entre 8G et 9G) et je
pense que le problème doit y être lier.

Actuellement, j'ai réussi à obtenir un système "stable" en ajoutant
l'option "mem=8127M" lors du boot (j'ai également essayé l'option "",
sans succès) qui me permet d'avoir 6363M d'utilisables, soit une perte
d'un peu plus d'1G. Auriez-vous une solution pour y palier ?

Ma configuration:
- OS: Debian GNU/Linux Squeeze 64Bit, Kernel 2.6.32-5 amd64
- Carte Mère : Asus Formula 2 Crosshair (avec carte graphique
intégrée qui prend 64M de ram au système, les valeurs possibles dans le
BIOS sont 64M, 128M, 256M et 512M) avec l'option "Memory Hole Remapping"
active dans le Bios, car sinon, seulement 7G sont utilisables sans pour
autant que le système ne plante.
- DDR2 Corsair 4x2G


Infos en configuration fonctionnelle :

***
#cat  /proc/meminfo ; echo ; free -m ; echo ; cat /proc/mtrr ; echo ;
cat /proc/pagetypeinfo
MemTotal:7032884 kB
MemFree:   52852 kB
Buffers:  105520 kB
Cached:  5759084 kB
SwapCached:0 kB
Active:  3662644 kB
Inactive:3034516 kB
Active(anon): 688384 kB
Inactive(anon):   145028 kB
Active(file):2974260 kB
Inactive(file):  2889488 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal:  16777208 kB
SwapFree:   16777208 kB
Dirty: 20340 kB
Writeback: 4 kB
AnonPages:832564 kB
Mapped:11576 kB
Shmem:   848 kB
Slab: 213196 kB
SReclaimable: 179104 kB
SUnreclaim:34092 kB
KernelStack:1672 kB
PageTables: 4872 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:20293648 kB
Committed_AS: 954036 kB
VmallocTotal:   34359738367 kB
VmallocUsed:  150900 kB
VmallocChunk:   34359573492 kB
HardwareCorrupted: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:8000 kB
DirectMap2M: 3004416 kB
DirectMap1G: 4194304 kB

 total   used   free sharedbuffers cached
Mem:  6868   6816 51  0103   5624
-/+ buffers/cache:   1089   5778
Swap:16383  0  16383

reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back
reg03: base=0x2 ( 8192MB), size= 1024MB, count=1: write-back
reg04: base=0x0d800 ( 3456MB), size=  128MB, count=1: write-combining

Page block order: 9
Pages per block:  512

Free pages count per migrate type at order   0  1  2 
3  4  5  6  7  8  9 10
Node0, zone  DMA, typeUnmovable  2  2  3 
3  3  1  0  0  1  0  0
Node0, zone  DMA, type  Reclaimable  0  0  0 
0  0  0  0  0  0  0  0
Node0, zone  DMA, type  Movable  0  0  0 
0  0  0  0  0  0  0  3
Node0, zone  DMA, type  Reserve  0  0  0 
0  0  0  0  0  0  1  0
Node0, zone  DMA, type  Isolate  0  0  0 
0  0  0  0  0  0  0  0
Node0, zoneDMA32, typeUnmovable   2979 75  4 
1  0  0  0  0  0  0  0
Node0, zoneDMA32, type  Reclaimable   1212  7  3 
0  0  0  0  0  0  0  0
Node0, zoneDMA32, type  Movable230205133
77  0  0  0  0  0  0  0
Node0, zoneDMA32, type  Reserve  0  0  2 
6  6  6  2  0  0  1  0
Node0, zoneDMA32, type  Isolate  0  0  0 
0  0  0  0  0  0  0  0
Node0, zone   Normal, typeUnmovable519  0  0 
0  0  0  0  0  0  0  0
Node0, zone   Normal, type  Reclaimable  1  0  0 
0  0  0  0  0  0  0  0
Node0, zone   Normal, type  Movable209168 50 
0  0  0  0  0  0  0  0
Node0, zone   N

Re: Perte de connection sur carte D-Link

[Thibaut Chèze]

Bonjour,
> j'ai aussi rencontré le problème, c'est un bug connu :
>
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86798
>
> la seule solution est à chaque changement de noyau de suivre la procédure :
> Télécharger les sources du module r8168 chez Realtek :
>
> http://leblog.cfait.fr/post/2008/05/20/Ubuntu-et-Realtek
>
> cd /root/r8168-8.014.00/
> sudo -s
> make clean
> make modules
> make install
> depmod -a
>
> ajouter  "blacklist r8169" in /etc/modprobe.d/blacklist.conf
>
>
> update-initramfs -u
> reboot
>   
Merci, je n'avais jamais trouver ce rapport. Par contre je ne suis pas
certain qu'il correspond à mon problème, surtout que si je comprend bien
le bug est résolu a partir du noyau 2.6.22 et je suis en 2.6.26.
Ceci étant, je vais faire le test et tiendrais la liste informée :-D

Thibaut


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Perte de connexion sur carte D-Link

[Thibaut Chèze]

Bonjour,
>
> Aurais-tu dans syslog des demandent d'attribution dhcp trop
> fréquentes ? (genre toutes les 2 minutes) 
A priori non, cette interface est configurée en statique, mais cette
machine à un serveur DHCP en écoute sur cette interface, cependant rien
ne me laisse croire que des requêtes sont trop fréquentes.

Merci

Thibaut


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Perte de connexion sur carte D-Link

[Thibaut Chèze]

Bonjour,

>> La carte est neuve, la connectique est parfaite et je ne crois pas que
>> la carte mêre soit en cause. Ceci dit, en changeant de port PCI, le
>> problème persiste.
>> 
>
> J'ai eu un pb identique fût un temps. Ça venait de la ligne téléphonique.
> Après intervention d'un (bon, c'est pas le cas de tous) technico de FT
> il a repéré le soucis et m'a branché sur une autre ligne que était dispo.
> Depuis la connexion est nickel.
> J'avais tout essayé aussi : changement des cartes rezo, des modems, des
> machines donc des cartes-mères, et même problème.
> Peut-être une piste...
>
>   
Je ne pense pas que sa soit lier à mon problème, les pertes de connexion
sont que la carte ne répond plus, rien a voir avec des pertes de synchro
de ma box...
Mais merci, toute idée est bonne a soumettre.


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Perte de connection sur carte D-Link

[Thibaut Chèze]

Rebonsoir,
> "alors là ya un blème entre la chaise et le clavier" ...
>   
En effet...
> modconf fonctionne  au clavier avec les flèches haut et bas et
> employer la touche entrée
>
>   
Oui sa j'ai vu, mais bon, tu envisage que je fasse quoi, changer le
module charger pour la carte ? Si oui, tu pense à quoi ?
Actuellement r8169 est utiliser, et je n'ai trouver aucune documentation
qui en utilise un autre...

Bonne nuit

Thibaut


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Perte de connection sur carte D-Link

[Thibaut Chèze]

Rebonsoir,
> serait il possible de vérifier si modconf est installé 
>
> dpkg -l |grep modconf
>
> et ensuite lancer modconf dans xterm || TTY
>   
Bon modconf n'était pas installer, je l'ai donc fait histoire de voir.
Puis je l'ai lancer, mais franchement ne voit pas quoi faire avec :-$


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Perte de connexion sur carte D-Link

[Thibaut Chèze]

Bonsoir,

> Ceci étant, il faudrait voir du câble ou de la carte elle-même (la
> retirer, changer de port PCI). Certaines cartes souffrent de 
> problèmes de connectique. La carte est neuve
La carte est neuve, la connectique est parfaite et je ne crois pas que
la carte mêre soit en cause. Ceci dit, en changeant de port PCI, le
problème persiste.

Merci Papinux

Thibaut


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Perte de connexion sur carte D-Link

[Thibaut Chèze]

Bonsoir,

Et merci Bernard
> lspci |grep Ethernet
>   
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
00:12.0 Ethernet controller: D-Link System Inc DGE-528T Gigabit Ethernet
Adapter (rev 10)

La carte en question est la seconde
> uname -ar
>   
Linux *** 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686 GNU/Linux
> autrement est ce que le module est chargé  à l'aide de modconf
>   
Je ne connais pas exactement le mechanisme de chargement automatisé des
modules, mais le module nécessaire était automatiquement chargé.
> /etc/modules
>   
Cependant j'ai ajouté le module "r8169", mais le problème persiste
(après redémarrage bien entendu)

Merci Bernard

Thibaut


0x8AB309AD.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

smartmontools : 2 Currently unreadable (pending) sectors & 2 Offline uncorrectable sectors

[Thibaut Chèze]

Bonsoir,

Depuis quelques heures, je reçois des alertes smart pour une de mes
disques, et j'aimerais savoir que faire.
J'ai brièvement regardé des documentations, mais sa par un peu dans tout
les sens avec des calculs de secteur, modifications de LVM ...

Pour le moment le seul lien qui corresponde à quelque chose de cohérent
que j'ai trouver est :
http://smartmontools.sourceforge.net/badblockhowto.html#lvm
Mais j'avoue que c'est encore assez obscure pour moi, alors avant de me
lancer dedans, je voulais vos avis et conseils

Voici les messages des mails de smartmontools:

The following warning/error was logged by the smartd daemon:

Device: /dev/hda, 2 Offline uncorrectable sectors

For details see host's SYSLOG (default: /var/log/syslog).

The following warning/error was logged by the smartd daemon:

Device: /dev/hda, 2 Currently unreadable (pending) sectors

For details see host's SYSLOG (default: /var/log/syslog).


Et dans mon syslog j'ai :

Aug 10 20:21:43 angelina smartd[3579]: Device: /dev/hda, 2 Currently unreadable 
(pending) sectors
Aug 10 20:21:43 angelina smartd[3579]: Device: /dev/hda, 2 Offline 
uncorrectable sectors


Rien de plus

Après un test court j'ai :
smartctl -l selftest /dev/hda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining 
LifeTime(hours)  LBA_of_first_error
# 1  Short offline   Completed: read failure   20% 
8330 1371132601

Le sg_verify:
# sg_verify --lba=1371132601 /dev/hda
verify (10): pass through os error: Invalid argument
Verify(10) failed near lba=1371132601 [0x51b9d2b9]

Visiblement pas d'invocation correcte de la commande, mais le man ne
m'aide pas a faire mieux...

Le test long est en cours d'exécution, bien que je pense qu'il en
sortira exactement la même chose...

Par contre, j'avais cru comprendre que les disques détectaient
automatiquement leurs secteur défectueux et switchais sur des secteurs
de secours dans ces cas la automatiquement et de manière transparente
pour l'OS.

Pour ce qui est de mes données, elles sont dans une lvm au dessus d'un
raid5 (device mapper) de 4 disque (sans disque de secours)

Pourriez vous me dire ce qu'il vous faudrait comme informations
supplémentaire, ce que représente exactement ces erreurs (pour mon
disque, pour mes données), et ce que je dois faire pour remédié à ces
problèmes (contrôles à effectuer, le niveaux où intervenir le plus
efficacement) svp ?
Dois-je envisagé sérieusement/rapidement un recours à la garantie ? Des
données (de ces secteurs) doivent elles être restaurées (grace au RAID) ?


Merci d'avance pour votre aide,
Et toutes mes excuses si elles font doublons avec d'autre posts.

Thibaut Chèze

PS:
J'avais trouver sur le net une ligne a mettre dans le /etc/smartd.conf
pour programmer des tests automatiquement, mais le serveur refuse de
démarrer lorsqu'elle est présente
La ligne : DEVICESCAN -a -o on -S on -s (S/../.././05|L/../../6/01) -m
r...@localhost -M CheckDisk

Je suis preneur de tout conseils sur comment gérer mes disques durs
également.
Merci

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: pm-utils/pm-hibernate et wake on lan

[Thibaut Chèze]

kaliderus a écrit :

Je viens vers vous car ne trouve aucun élément de réponse sur le net,
ni dans les man de pm-utils...
Je suis sous Squeeze et donc la version de pm-utils en place est la
1.2.5-4. Tout d'abord, je précise que ma configuration bios est
fonctionnelle pour le wake on lan (avec le mode S3 pour l'ACPI), mais
le souci ce situe lors de la mise en hibernation avec pm-hibernate,


Je suis d'avis que le WOL ne sera en place que par le driver, non pas
la mise en veille via un script "d'hibernation".
 à


la fin du processus, il semble complètement éteindre l'interface ce
qui ne me permet donc plus de réveillé ma machine par la réseau.


C'est normal.
Je crois que peut de constructeurs fournissent les drivers qui
permettent l'extinction avec support WOL.
Car c'est bien au niveau du driver, si ma mémoire est bonne, que la
fonctionnalité doit être activée, juste avant l'extinction de la
machine (c'est le cas avec les nforce3 par exemple qui m'embêtaient il
y a quelques années).
La mise en veille est un autre principe.


Je ne te cache pas que je ne comprend pas tout, mais si je comprend quand
même un peu, pourquoi cela fonctionnerait il lorsque j'éteins simplement la
machine ? Mon problème ne survient que lorsque je la met en hibernation.



J'avais compris que le WOL ne fonctionnait pas du tout.
Dans le cas ou le WOL est effectif machine éteinte, je ne vois
effectivement pas de raison qu'il ne le soit pas en veille.

Sinon au moment d'éteindre la machine une fonction est appelée et dit
à la carte de se mettre en mode WOL, ce qui ne se passerait pas dans
le script de mise en hibernation, suceptible de na pas savoir gérer
tous les périphériques correctement.
Un script à modifier sans doute ?

N'y aurait-il pas quelquechose d'interessant ici par hasard ?
http://www.broadcom.com/support/ethernet_nic/netxtreme_desktop.php
Il y a aussi quelques bricoles en rapport avec les Broadcom dans les
paquets Debian, en faisant une recherche par description : aptitude
search '~dbroadcom'...

  
J'ai jeter un oeil, mais je me sens pas de ne pas utilisé ce qui n'a pas 
été empaqueté (et la flème de le faire).


D'au-tend que j'ai du nouveaux pour le coup, ce qui va fermer cette 
discussion ou au moins la faire déviée, le problème ne viens 
manifestement pas de pm-utils dans la mesure ou il a y 30 minutes j'ai 
réussi à démarrer ma machine qui était en hibernation par le wol...
Je ne me l'explique pas, d'au-tend que 20 minutes plus tôt je n'arrivais 
plus à démarrer la machine par le réseau même simplement éteinte. Pour 
l'heure, je crois que sa marche, je continue mes recherche et 
reviendrais vous en dire plus si j'avance...


Merci pour votre aide.

Thibaut Chèze

Re: pm-utils/pm-hibernate et wake on lan

[Thibaut Chèze]

Bonjour,

kaliderus a écrit :

Bonjour,


Bonjour,
Je n'ai pas lu tout le fil de la discussion, peut être que ma réponse
sera un redite ...

  

Bah on ne dirait pas :-)

Bonjour,
Je viens vers vous car ne trouve aucun élément de réponse sur le net,
ni dans les man de pm-utils...
Je suis sous Squeeze et donc la version de pm-utils en place est la
1.2.5-4. Tout d'abord, je précise que ma configuration bios est
fonctionnelle pour le wake on lan (avec le mode S3 pour l'ACPI), mais
le souci ce situe lors de la mise en hibernation avec pm-hibernate,



Je suis d'avis que le WOL ne sera en place que par le driver, non pas
la mise en veille via un script "d'hibernation".

 à
  

la fin du processus, il semble complètement éteindre l'interface ce
qui ne me permet donc plus de réveillé ma machine par la réseau.



C'est normal.
Je crois que peut de constructeurs fournissent les drivers qui
permettent l'extinction avec support WOL.
Car c'est bien au niveau du driver, si ma mémoire est bonne, que la
fonctionnalité doit être activée, juste avant l'extinction de la
machine (c'est le cas avec les nforce3 par exemple qui m'embêtaient il
y a quelques années).
La mise en veille est un autre principe.

  
Je ne te cache pas que je ne comprend pas tout, mais si je comprend 
quand même un peu, pourquoi cela fonctionnerait il lorsque j'éteins 
simplement la machine ? Mon problème ne survient que lorsque je la met 
en hibernation.

Auriez-vous quelques pistes pour résoudre ce problème ?



Contacter le constructeur/intégrateur de ta carte pour lui demander si
ce que tu veux faire est possible "librement" parlant ?
Si le driver n'est pas libre j'ai peur que la fonctionnalité soit
difficilement accessible, à ma connaissance il n'existe pas de
standards logiciel (niveau driver) pour cette fonction, donc chaque
constructeur fait ce qu'il veut.

Ce que j'ai dis était vrai pour les nforce3 il y a 3-4 ans. Qu'en
est-il maintenant ?

  
Informe-nous si tu trouve la solution, merci.


  

Je le ferais !


Thibaut

Re: pm-utils/pm-hibernate et wake on lan

[Thibaut Chèze]

Frédéric Boiteux a écrit :

Le Thu, 06 Aug 2009 10:53:54 +0200,
Thibaut Chèze  a
écrit :

  

Bonjour,

Merci pour ta réponse, je ne t'ai pas répondu plus tôt car je voulais 
tester dans tout les sens pour être sur...
Donc en fait j'avais déjà mis en place ce qui est nécessaire pour 
activer le wol sur l'interface, mais j'ai quand même essayé ton

script, j'ai bien vérifié le fait qu'il soit éxécuté, mais rien a
faire l'interface réseau en hibernation est éteinte... donc pas de
wake on lan.

D'autres idées ?



  Désolé, pas trop d'autres idées. Il me semble bien que cela avait
marché avec un portable (ThinkPad), même en hibernation, du moment que
l'on ne retirait pas la prise secteur (intérêt moyen il est vrai). Quel
est ta machine (type, modèle) ?

  
Ma machine est un desktop Dell Inspiron T3400, et la carte réseau est 
celle de la carte mère.
lspci : 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme 
BCM5754 Gigabit Ethernet PCI Express (rev 02)


Thibaut

Re: pm-utils/pm-hibernate et wake on lan

[Thibaut Chèze]

Bonjour,

Merci pour ta réponse, je ne t'ai pas répondu plus tôt car je voulais 
tester dans tout les sens pour être sur...
Donc en fait j'avais déjà mis en place ce qui est nécessaire pour 
activer le wol sur l'interface, mais j'ai quand même essayé ton script, 
j'ai bien vérifié le fait qu'il soit éxécuté, mais rien a faire 
l'interface réseau en hibernation est éteinte... donc pas de wake on lan.


D'autres idées ?

Thibaut

Frédéric Boiteux a écrit :

Le Wed, 05 Aug 2009 11:08:42 +0200,
Thibaut Chèze  a
écrit :

  

Bonjour,

Je viens vers vous car ne trouve aucun élément de réponse sur le net,
ni dans les man de pm-utils...

Je suis sous Squeeze et donc la version de pm-utils en place est la
1.2.5-4. Tout d'abord, je précise que ma configuration bios est
fonctionnelle pour le wake on lan (avec le mode S3 pour l'ACPI), mais
le souci ce situe lors de la mise en hibernation avec pm-hibernate, à
la fin du processus, il semble complètement éteindre l'interface ce
qui ne me permet donc plus de réveillé ma machine par la réseau.

Je précise que j'ai essayé de passer en mode S1 sans plus de succès

Auriez-vous quelques pistes pour résoudre ce problème ?



Bonjour,

  J'avais essayé de jouer avec le wake-on-lan sur un eeepc, mais j'ai dû
abandonner (faute de support du wol par la machine, et de support d'Asus
sur ce problème). Pour mes tests, j'avais réalisé un petit script pour
positionner le wol sur l'interface Ethernet avant le suspend/sleep, à
mettre dans  /etc/pm/sleep.d/ : voir fichier joint. Il utilise le
paquet ethtool que tu devras installer. Tu peux ensuite regarder les
traces dans /var/log/pm-suspend.log.

Fred.
  

pm-utils/pm-hibernate et wake on lan

[Thibaut Chèze]

Bonjour,

Je viens vers vous car ne trouve aucun élément de réponse sur le net, ni 
dans les man de pm-utils...


Je suis sous Squeeze et donc la version de pm-utils en place est la 1.2.5-4.
Tout d'abord, je précise que ma configuration bios est fonctionnelle 
pour le wake on lan (avec le mode S3 pour l'ACPI), mais le souci ce 
situe lors de la mise en hibernation avec pm-hibernate, à la fin du 
processus, il semble complètement éteindre l'interface ce qui ne me 
permet donc plus de réveillé ma machine par la réseau.


Je précise que j'ai essayé de passer en mode S1 sans plus de succès

Auriez-vous quelques pistes pour résoudre ce problème ?

Autrement, le bug #501902 du paquet pm-utils semble bien correspondre a 
ce problème, mais je suis surpris qu'il n'y ai eu aucune résolution ni 
beaucoup d'autres écho sur le net.


En vous remerciant d'avance pour votre aide,

Thibaut Chèze

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Postfix et ssl [je laisse tomber]

[Thibaut Chèze]

Rebonjour,

David BERCOT a écrit :

Le Mon, 03 Aug 2009 12:10:04 +0200,
Thibaut Chèze  a
écrit :
  

Bonjour,

David BERCOT a écrit :


Le Sun, 02 Aug 2009 23:21:02 +0200,
Ludovic GOMEZ  a écrit :
  
  

David BERCOT a écrit :



Finalement, ça m'a l'air un peu compliqué, mais surtout, je me dis
que ça va introduire des failles dans mon système qui est bien
sécurisé. Comme cela ne concerne que mon nouveau jouet (un HTC Hero
sous Androïd pour ne pas le nommer ;-))), je vais utiliser une
adresse gmail...

Merci néanmoins à chacun pour vos contributions...

David.  
  
  

Bonjour,

tu peux utiliser le smtp de gmail pour envoyer tes mails ou celui de
ton opérateur.


Mais pas avec mon adresse, si ?

Pour GMail, je m'identifie pour l'envoi, mais avec un compte GMail...
Ce serait donc celui-ci qui sera l'envoyeur, non ?

Sinon, en effet, ça pourrait m'intéresser ;-)
  

Alors avec GMail tu as moyen de déclarer que tu as un nom de domaine
(ou une autre adresse email) dans les préférences, et si tu active la
bonne option, l'adresse d'emission du mail restera celle de ton
domaine.



Oui, mais ça, c'est pour envoyer un mail à partir de GMail en faisant
croire qu'elle vient d'ailleurs.
Moi, je veux envoyer le mail à partir de mon HTC...
  


Oui mais du coup, si tu configure sa, et que tu met gmail en relayhost 
de ton serveur de mail, sa marchera, et les emails partant de ton 
serveur passerons par gmail comme relais, sans réécriture d'adresse de 
la par de google. Mais cette solution n'a rien avoir avec 
l'authentification soyons claire, c'est juste un moyen d'envoyé des mail 
sans être directement rejeter pour question de lutte contre le spam ou 
autre...


  
Autrement, j'ai personnellement mis en place une configuration 
ressemblant à ce que tu recherche. J'ai le port 25 en écoute pour les 
mails arrivant à destination de mon domaine, donc sans

authentification, avec le tls activé si les autres serveurs en ont
envie, et le 465, pour une connection ssl des mes postes, avec
authentification (dovecot) pour le coup. L'interêt est que seul les
machines passant par le 465 sont capables d'envoyer des mails à
d'autres domaines que le mien et ainsi, ma machine n'est pas un relais
ouvert (et accésoirement le contrôle des spams et virus diffèrent en
fonction du point d'entré). Bref si sa t'interesse, je t'en dirais
plus...



En effet, ça m'intéresse ;-) Si j'arrive à utiliser un autre serveur
SMTP, je ne vais pas me fatiguer. Maintenant, pour l'instant, je n'y
arrive pas...

Donc, ta config utilise Postfix ?
Alors oui, je veux bien...
  


Oui ma conf est faite avec Postfix, dovecot, spamassassin, clamav, 
dspam... et stunnel (pour la gestion de la connection directe en SSL).

Quand tu sera prêt on en reparlera


Merci d'avance.

David.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

  


Thibaut Chèze

Re: Postfix et ssl [je laisse tomber]

[Thibaut Chèze]

Bonjour,

David BERCOT a écrit :

Le Sun, 02 Aug 2009 23:21:02 +0200,
Ludovic GOMEZ  a écrit :
  

David BERCOT a écrit :


Finalement, ça m'a l'air un peu compliqué, mais surtout, je me dis
que ça va introduire des failles dans mon système qui est bien
sécurisé. Comme cela ne concerne que mon nouveau jouet (un HTC Hero
sous Androïd pour ne pas le nommer ;-))), je vais utiliser une
adresse gmail...

Merci néanmoins à chacun pour vos contributions...

David.  
  

Bonjour,

tu peux utiliser le smtp de gmail pour envoyer tes mails ou celui de
ton opérateur.



Mais pas avec mon adresse, si ?

Pour GMail, je m'identifie pour l'envoi, mais avec un compte GMail...
Ce serait donc celui-ci qui sera l'envoyeur, non ?

Sinon, en effet, ça pourrait m'intéresser ;-)
  


Alors avec GMail tu as moyen de déclarer que tu as un nom de domaine (ou 
une autre adresse email) dans les préférences, et si tu active la bonne 
option, l'adresse d'emission du mail restera celle de ton domaine.


Autrement, j'ai personnellement mis en place une configuration 
ressemblant à ce que tu recherche. J'ai le port 25 en écoute pour les 
mails arrivant à destination de mon domaine, donc sans authentification, 
avec le tls activé si les autres serveurs en ont envie, et le 465, pour 
une connection ssl des mes postes, avec authentification (dovecot) pour 
le coup. L'interêt est que seul les machines passant par le 465 sont 
capables d'envoyer des mails à d'autres domaines que le mien et ainsi, 
ma machine n'est pas un relais ouvert (et accésoirement le contrôle des 
spams et virus diffèrent en fonction du point d'entré). Bref si sa 
t'interesse, je t'en dirais plus...



David.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

  

Re: Changement de la clé des dépôts debian ?

[Thibaut Chèze]

Effectivement, j'avais répondu à la liste en Texte+HTML, il se peut donc 
que vous n'ayez pas reçu/lu ma réponse.


Bref, j'ai constater le même problème cette nuit, des updates répétés 
(cron-apt) m'ont signalé le problème jusqu'a 4h.
A mon avis, il y a du y avoir une erreur de signature des fichiers 
Release ou autres diff qui a donc été corrigée quelques heures plus tard.


Thibaut Chèze

Jean-Yves F. Barbier a écrit :

Goldy a écrit :
...

  

Je pense pas que ça soit nécessaire de réinstaller le système, je n'ai
pas fait la mise à jour voyant que les paquets ne pouvaient pas être
authentifiés, je ne l'ai faite que ce matin une fois que ce problème
n'était plus présent.



Très sage décision!
 
  

Et visiblement je n'ai pas été le seul, l'incident n'a duré que 2 heures
en pleine nuit ce qui peut expliquer l'absence d'échos, donc il est
probable que ça soit juste un problème temporaire sur le miroir.



ha bon, alors les autres ont du poster en HTML (=>/dev/null) parce que
je n'ai rien vu d'autre.

  


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Changement de la clé des dépôts debian ?

[Thibaut Chèze]

J'avais également ce problème, mais il n'était effectif qu'entre 2h et 
4h ce matin.

Je n'ai fait aucune autre action que des updates pour le corriger.

Thibaut

Goldy a écrit :

Jacky Boiron a écrit :
  

Salut,


apt-get install debian-archive-keyring
apt-get update


résoudra ton problème ;)




Le paquet était déjà installé et pas de mise à jour n'était disponible.

Mais étrangement, le problème n'est plus présent, je ne sais pas par
quelle miracle ceci a été réglé. Était-ce un problème sur le miroir qui
a été réglé ? Allez savoir.

Cordialement

  

Re: [HS] modifier le user d un lien casse

[Thibaut Chèze]

Bonjour,

man chown nous apprend :
-h, --no-dereference
 modifier les liens symboliques au lieu des fichiers 
référencés (utile seulement sur les systèmes permettant de changer le 
propriétaire d’un lien symbolique)


Amuse toi bien

Thibaut

giggzounet a écrit :

Bonjour,

bon desole pour ce HS. Je m enerve sur find depuis ce matin...alors en
desespere je viens vous voir :

j ai une arborescence enorme de fichiers. Je dois modifier le user de
chaque fichier. j utilise donc la commande suivante :
find . -exec chown user {} \;

mais le probleme c est qu il y a des liens casses dans cette
arborescence. bcp...et je dois modifier le proprio du lien casse...

bon ce n est pas mon arborescence, c est celle de mon chef. un symlinks
-rd serait des plus tentants...mais  il veut  absolument garder ses
liens casses...

une option de find permet elle de faire ca ?

Bye
Guillaume

  


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: [testing][gnome] moniteur système

[Thibaut Chèze]

Bonjour,

La documentation du programme dit :
Pour surveiller les systèmes de fichiers, sélectionnez l'onglet Systèmes
de fichiers.

Le Moniteur système affiche les informations sur les systèmes de
fichiers montés sous forme de tableau. De gauche à droite, le tableau
affiche les colonnes suivantes :

Périphérique
Emplacement du fichier de bloc

 
Répertoire
Point de montage (répertoire correspondant) du périphérique

 
Type
Type de système de fichiers

 
Total
Capacité totale

 
*Libre
Quantité d'espace non utilisé*

 
*Disponible
Quantité d'espace réellement utilisable*

 
Utilisé
Quantité d'espace utilisé (et pourcentage du total)


Mais bon sa on pouvais s'en douter... Après je pense que la différence
entre les deux doit être les blocs réservé à root (5% par défaut),
ajouter aux bloc réservés par le système de fichier pour son bon
fonctionnement.

Bonne journée

PS: Lire la doc sa a du bon ... Onglet Aide -> Sommaire -> Utilisation
-> III.XII. Surveillance des systèmes de fichiers

Gaëtan PERRIER a écrit :
> Bonjour,
>
> Qu'elle est la différence entre "Libre" et "Disponible" dans l'onglet
> "Systèmes de fichiers" ?
>
> Gaëtan
>
>   

Re: WebCalendar

[Thibaut Chèze]

Ah oui effectivement, on m'en avait parler, décrit comme open source, 
mais je n'avais pas encore tout vérifier. Il est sous Yahoo Public 
License, du coup on pourrait discuter longtemps mais sa ne correspond 
clairement pas à la philosophie du logiciel libre selon Debian. Désolé . :-(


Yves Rutschle a écrit :

On Fri, Jun 05, 2009 at 02:43:25PM +0200, Thibaut Chèze wrote:
  

Bonjour,

Regarde peut-être du coté de "Zimbra", sa fera plus que ce que tu veux,  
mais sa aura l'avantage de le faire :-)



Ça parait pas beaucoup plus libre que GCalendar, non?

Y.

  

Re: WebCalendar

[Thibaut Chèze]

Effectivement, il est sous Yahoo Public License :-$. On pourrait en 
débattre longuement, mais ce n'est clairement pas une licence compatible 
avec la philosophie du logiciel libre selon Debian.

Désolé :-(.

Yves Rutschle a écrit :

On Fri, Jun 05, 2009 at 02:43:25PM +0200, Thibaut Chèze wrote:
  

Bonjour,

Regarde peut-être du coté de "Zimbra", sa fera plus que ce que tu veux,  
mais sa aura l'avantage de le faire :-)



Ça parait pas beaucoup plus libre que GCalendar, non?

Y.

  

Re: WebCalendar

[Thibaut Chèze]

Bonjour,

Regarde peut-être du coté de "Zimbra", sa fera plus que ce que tu veux, 
mais sa aura l'avantage de le faire :-)


Edi Stojicevic a écrit :

Salut,

Je cherche un calendrier partagé qu'il serait simple de mettre en ligne
sur un dédié par exemple. Un truc un peu comme Google Calendar mais sans
que Big Brother n'est accès à tous les rdv ;)

Si quelqu'un a une solution fiable et sécurisée ;)

  


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: DNS, kimsufi et domaine .fr

[Thibaut Chèze]

Bonjour,

Sa aurait été apprécié que tu mette le vrai fichier de zone... Au moins 
on aurait pu te dire directement si sa viens effectivement de ta conf 
(faute de frappe...), et tester ton domaine (info que tu publie de toute 
façon donc ...). Je ne sais pas si sa peux venir de sa, mais je ne 
connais pas ce détail de syntaxe : les deux ligne avec les ';' (mais si 
c'était gênant ton bind te hurlerai dessus...).


Pour savoir quels problème tu peux avoir dans ta conf, tu as 
http://www.afnic.fr/outils/zonecheck ou installe le paquet zonecheck sur 
la machine.


Et sinon je dirais qu'il manque l'enregistrement du second NS, celui de 
gandi.


Thibaut Chèze

Goran Bogdanovic a écrit :

Bonjour,

Je dispose d'un serveur kimsufi sous Debian avec quelques sites en 
.com qui fonctionne correctement.
Je viens d'acheter un .fr chez gandi et je n'arrive pas a mettre a 
jour via le DNS via leur interface car

apparemment le "Zone check" a échoué :(

Voici mon fichier zone de ma config bind :

 $TTL24h
@INSOAns1.mondomaine.fr. root.mondomaine.fr. (
0805200901 ; serial
3h ; refresh
  30m ; retry
7d ; expire
3h ; negative cache ttl
)
;
;
@   INNS ns1.mondomaine.fr
@   INMX10 smtp.mondomaine.fr
ns1INA   XXX.XXX.XXX.XXX

www  INAXXX.XXX.XXX.XXX
smtp  INAXXX.XXX.XXX.XXX
popINAXXX.XXX.XXX.XXX

J'utilise également comme serveur dns secondaire celui de gandi 
(ns6.gandi.net).


Doit-on faire quelque chose de special pour les .fr chez gandi ?

Merci par avance ...

GB


--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a *Free* Account at www.mail.com <http://www.mail.com/Product.aspx>!

Re: Qu'est devenu dcc-client ?

[Thibaut Chèze]

Merci beaucoup Sylvain, pour cette réponse qu'on ne veut plus claire.

Et merci pour le lien, je garde sa bien au chaud pour les prochaines
fois ;-)

Thibaut Chèze

Sylvain Sauvage a écrit :
> Thibaut Chèze, mardi 5 mai 2009, 18:37:43 CEST
>   
>> Bonsoir,
>> 
>
> ’soir,
>
>   
>> Je suis à la recherche du paquet dcc-client (et dcc-common) pour
>> architecture i686 et si possible amd64 ? J'ai beau chercher dans les
>> dépôts, je n'y trouve que la version pour etch-m68k. Que c'est-il passé
>> ? il n'est plus maintenus ? Où puis-je le trouver, même en version etch
>> pour les architectures mentionnées précédemment ?
>> 
>
>   Bogue 464161. Je cite la partie intéressante :
>
> « Ack for the removal. Upstream told us that the outdated
> version in Etch causes serious problems inside the DCC network
> and upgrading to a new version is not an option since DCC turned
> non-free. »
>
>   En clair : vieux dcc tout pourri, nouveau pas libre, au revoir
> dcc.
>
> (Pour trouver ce genre d’info :
> http://packages.qa.debian.org/common/index.html
> et cliquer sur les messages « Removed… », on trouve alors le
> bogue et les autres messages.)
>
>   

Qu'est devenu dcc-client ?

[Thibaut Chèze]

Bonsoir,

Je suis à la recherche du paquet dcc-client (et dcc-common) pour
architecture i686 et si possible amd64 ? J'ai beau chercher dans les
dépôts, je n'y trouve que la version pour etch-m68k. Que c'est-il passé
? il n'est plus maintenus ? Où puis-je le trouver, même en version etch
pour les architectures mentionnées précédemment ?

Merci d'avance pour votre aide

Thibaut Chèze

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: serveur dhcp

[Thibaut Chèze]

Bonjour,

Pourrais-tu nous envoyer ton fichier de configuration, sa sera plus
simple comme sa ?

Merci

Thibaut Chèze

Maurice Guerrier a écrit :
> salut Thomas
>  j'avais deja mis la ligne option domain-name-servers @dns server du
> FAI,  je ne sais pas pourquoi ca ne marche pas
>  
> Guerrier MAURICE
> Cell.: +33(0) 6 10 30 43 46
>
>
> 
> *From:* Thomas GOBET 
> *To:* debian-user-french@lists.debian.org
> *Sent:* Monday, May 4, 2009 2:58:36 PM
> *Subject:* Re: serveur dhcp
>
> Bonjour à toi.
>
> Pour configurer l'adresse IP de ton serveur dns il suffit de rajouter
> la ligne suivante dans /etc/dhcp3/dhcpd.conf
>
> /option domain-name-servers @IP_server_dns ;
>
> /Tu peux aussi rajouter le nom de domaine par défaut pour tes clients
> avec cette ligne.
>
> /option domain-name "actu.com <http://actu.com>";/
>> bonjour a tous
>>
>> je suis en train de configurer un serveur dhcp pour mon reseau local;
>> je veux que les clients obtiennent non seulement l'adresse de mon
>> routeur mais aussi l'adresse ip de mon serveur de dns.
>> je sais pas quelle option mettre pourque le client puisse avoir
>> l'adresse de dns. pour le routeur le client l'obtient normalement:
>> je veux savoir quelle option dans dhcp3-server a mettre
>>
>> merci
>>  
>> Guerrier MAURICE
>> Cell.: +33(0) 6 10 30 43 46
>>
>>
>
>

Re: serveur dhcp

[Thibaut Chèze]

Bonjour,

As-tu bien forcer une redemande de dhcp (Connexions Réseau > Clic droit
sur l'interface > Réparer) ?
As-tu bien redémarrer ton service DHCP après chaque modifications de la
configuration ?

Ton problème pourrait bien être lier à une autre partie de ta
configuration, pourrais-tu nous envoyer ta conf complète, nous y verrons
plus claire stp ?


Pourquoi as-tu réouvert une discussion ? Celle-ci ne te dérange ?


Thibaut Chèze

Julien a écrit :
> Le lundi 04 mai 2009 à 07:39 -0700, Maurice Guerrier a écrit :
>   
>> mon client est un windows XP, il a pris l'adresse du routeur mais pas
>> celle du dns
>> 
>
> ah ... Est-ce que tout est configuré en automatique dans les propriété
> de tcp/ip :
>
> - Obtenir une adresse automatiquement 
> ET 
> - Obtenir les serveurs de noms automatiquement 
>
> Il faut mettre les deux sur automatique.
>
> Julien.
>
> PS : n'oublie pas la liste quand tu réponds (répondre a tous )
>
>
>
>
>
>   
>>  
>> Guerrier MAURICE
>> Cell.: +33(0) 6 10 30 43 46
>>
>>
>>
>>
>> __
>> From: Julien 
>> To: Maurice Guerrier 
>> Cc: debian-user-french@lists.debian.org
>> Sent: Monday, May 4, 2009 3:21:08 PM
>> Subject: Re: serveur dhcp
>>
>> Salut,
>>
>> Peut être que ton pb vient de la config coté client...
>>
>> As-tu essayé avec différents client ? Est-ce qu'il n'y aurait pas des
>> valeurs 'en dur' dans /etc/resolv.conf sur le client ?
>>
>> Si tu utilises le paquet dhcp3-server, il existe une interface
>> graphique : gdhcpd. qui te permet d'ajouter facilement des options
>> comme :
>>
>> - ntp server 
>> - WINS server 
>>
>> sans avoir à retenir ou à checher les numéros correspondants
>>
>> Julien 
>>
>> Le lundi 04 mai 2009 à 06:12 -0700, Maurice Guerrier a écrit :
>> 
>>> salut Thomas
>>>  j'avais deja mis la ligne option domain-name-servers @dns server du
>>> FAI,  je ne sais pas pourquoi ca ne marche pas
>>>  
>>> Guerrier MAURICE
>>> Cell.: +33(0) 6 10 30 43 46
>>>
>>>
>>>
>>>
>>>
>>>   
>> __
>> 
>>> From: Thomas GOBET 
>>> To: debian-user-french@lists.debian.org
>>> Sent: Monday, May 4, 2009 2:58:36 PM
>>> Subject: Re: serveur dhcp
>>>
>>> Bonjour à toi.
>>>
>>> Pour configurer l'adresse IP de ton serveur dns il suffit de
>>>   
>> rajouter
>> 
>>> la ligne suivante dans /etc/dhcp3/dhcpd.conf
>>>
>>>option domain-name-servers @IP_server_dns ;
>>>
>>> Tu peux aussi rajouter le nom de domaine par défaut pour tes clients
>>> avec cette ligne.
>>>
>>>option domain-name "actu.com";
>>>   
>>>> bonjour a tous
>>>>
>>>> je suis en train de configurer un serveur dhcp pour mon reseau
>>>> local; je veux que les clients obtiennent non seulement l'adresse
>>>> 
>> de
>> 
>>>> mon routeur mais aussi l'adresse ip de mon serveur de dns.
>>>> je sais pas quelle option mettre pourque le client puisse avoir
>>>> l'adresse de dns. pour le routeur le client l'obtient normalement:
>>>> je veux savoir quelle option dans dhcp3-server a mettre
>>>>
>>>> merci
>>>>  
>>>> Guerrier MAURICE
>>>> Cell.: +33(0) 6 10 30 43 46
>>>>
>>>>
>>>>
>>>> 
>>>
>>>   
>> -- 
>> Lisez la FAQ de la liste avant de poser une question :
>> http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
>> ``spam'' dans vos champs "From" et "Reply-To:"
>>
>> Pour vous DESABONNER, envoyez un message avec comme objet
>> "unsubscribe"
>> vers debian-user-french-requ...@lists.debian.org
>> En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
>>
>>
>>
>> 
>
>