Reprise du message précédent :
j'utilise udev (et je n'ai plus devfs dans le noyau ).

et tu as monté sysfs sur /sys?

oui (none on /sys type sysfs (rw))

2.6.11.2 !!!
 
http://www.kernel.org/

wow les gros changement qui nous touche pas

ca devient un peu n'importe quoi je trouve...
 
était-ce vraiment un bug bloquant, qui force à sortir une 11.2 avec un seul correctif dedans ?

Non c'est uniquement la nouvelle numérotation

 
http://linuxfr.org/2005/03/08/18449.html

s/ / /g

Dites, il y a des gens qui ont des problemes d'iowait avec un kernel 2.6 ?
 
Voila le probleme : au taf j'ai des redhat AS3 avec un kernel 2.4.21 et le nfs marche nickel, pas de probleme d'iowait. Pour les besoins du softs, j'ai installé tout le bordel pour les upgrader en 2.6, j'ai pris le kernel.src en rpm de la redhat AS4 et hop, j'ai une redhat AS3 avec un 2.6.9. Mais la, c'est le drame, des que je copie des fichiers sur le serveur nfs ou que je les copie du serveur en local, Top et vmstat me disent que ma machine est à 99% d'iowait, elle rame comme c'est pas possible et les transferts sont lenttttssssss. Non ce n'est pas un probleme de full duplex car en ssh ou ftp j'obtient 10 Mo/s. J'ai essayé differentes options de montage (hard/soft, udp, tcp) et rien. J'ai aussi tester un 2.6.10, 2.6.11.2, et toujours pareil. J'ai cherché sur google, des gens ont le meme problems mais pas de solutions en fait.
 
J'aimerai bien avoir des retours d'expérience si certains ont des conf qui sont ok ou qui ont le meme probleme que moi.
 
A savoir aussi que chez moi j'ai deux debian, et j'ai à peu pres le meme probleme... Bizarre tout ça, mais ça me saoule !

Hum, faudrait que je tests chez moi, mais j'ai un hub à 10Mb, donc le problème vient pas vraiment de là
 
C'est quoi iowait ? Un processus noyau ?

 
 
non, c'est le noyau qui attend pour une réponse à une requete d'entrée/sortie et ça bloque tout quand y-a trop d'attente de ce type (en gros hein )

 
<sarcasme>
alors moi j'attends le 2.6.11.57 pour être sûr qu'il est stable.
Il devrait sortir demain midi, au plus tard.....
</sarcasme>
 

Fireball > j'ai pas remarqué de problème sans préempt, en shed cfq et avec des services/utils bien à jour sur les machines, par contre j'en ai eu un gros paquet entre clients 2.6 et serveur sous 2.4 (perte de connexions, conso CPU), je mettais ça sur le dos des supports de versions NFS et des mécanismes d'auth/sécue
 
un truc aussi, direct i/o sur le nfs ?

 
 
tiens je trouve ca très interressant ton problème
 
au boulot, on roule sur AIX 4.3.3 et 5.2
On parle à un serveur de fichier DFS (produit ibm) et on a régulièrement des problèmes d'IOwait sur nos serveurs qui parle beaucoup aux serveurs de fichier
 
on croyait jusque l'a à un problème du client dfs, qui permet de parler au fileserver, mais ton cas est similaire mais avec nfs

Bonjour,
alors mes problemes sont entre une redhat AS3 modifiée avec un kernel 2.6 et un filer EMC² et un filer netapp. C'est carrément un probleme de NFS coté client sur la redhat. De plus, j'ai un probleme similaire avec ma suse kernel 2.6 vers les memes filer, et sur ma debian chez moi entre mon desktop kernel 2.6 et mon serveur en 2.4... J'avoue qu'on est un peu perdu sur ce probleme. D'apres le developpeur, les iowaits freeze la machine quand il lance sont soft, et du coup, c'est inexploitables pour lui. Putain de nfs... Bon hop j'y retourne
 
BMO : l'option directio est présente dans un des kernel de test mais je ne l'ai pas mis dans le mount. Je vais essayer tiens

BMO : Pour le directio, en plus de l'option dans le kernel, il faut spécifier une option dans le mount ? Je cherche dans le man et sur google mais je ne trouve rien de concluant
 
Merci

Non, rien de plus à faire, la fonction est compilée en hard, mais attention tout de même, cette option désactive le cache des fichiers, sur de gros volumes simultanés tu peux te retrouver avec un DoS si la ou les machines ne suivent pas, donc surveille bien de près
 
ce que tu peux essayer aussi, c'est pas forcément très "safe" mais ça peut peut-être apporter quelques modifs sur les perfs, c'est l'option "nolock" de mount pour NFS
 
surveille aussi si tu n'as pas un/des timeout qui trainent dans dmesg/les logs
 
pour ce qui est de ta config perso @home, teste sans le support NFS v4 sur 2.6, c'est peut-être plus dur à concevoir en prod par contre
 
edit : tiens t'as essayé aussi les rsize/wsize ?

oui on a essayé avec différent rsize/wsize, sans succés. Le support v4 est desactivé de partout.
 
Pour le io direct, ben j'ai deux kernel, l'un avec l'option et l'autre sans, et on a toujours le meme probleme.
 
Pas de messages d'erreur ou de timeout dans les logs.

c'est la merde là quand même, je crois pas que le prob va s'arranger tout de suite, vu le nombre de retours sur les ML... d'ailleurs un beau 0 pointé pour RHLE

là il y a une lecture intéressante sur l'optimisation de NFS, rapport des perfs avec les modes sync/async d'export/montage : http://www.int-evry.fr/mci/user/pr [...] FS/nfs.txt

Ca rale sur les maillings lists de redhat au sujet du nfs ? Je ne sais pas si c'est un probleme de redhat ou du 2.6, car j'ai le meme probleme sur d'auter distrib. C'est flagrant sur ma deb et sur ma suse, ça l'est moins mais il est présent quand meme. Bizarre, bizarre, bizarre

la RHLE intervient souvent dans les reports

un petit up pour accuellir un 2.6.12-rc1 tout frais tout chaud
 
EDIT : faut patcher le 2.6.11 et non pas le 2.6.11.4
 

pas bien, le 2.6.11 il est tout lent
http://lkml.org/lkml/2005/3/17/59

quelqu'un sous 2.6.11.5 ?
 

 
gcc4 inside, mais le 2.6.11 compile sans problème avec le même .config...
 
 
étant donné qu'un problème semble en apporter d'autres, à mon avis on va avoir le droit à un beau :

Roooolala, ca fait 3 noyau 2.6.1x que je compile et toujours la même erreur au boot :

J'avait compiler un 2.6.9 en novembre dernier et je n'avait eu aucun problème, mais là sur les dernières versions impossible de trouvé d'ou ca peut venir ...
Quelqu'un pourrait m'eclairer ?    
 

T'as mis le support IDE, ton chipset et ton filesystme en dur dans ton noyau ? (ou en modules + initrd)

 
fedora ?

Le systeme de fichier est EXT3 et il me semble que je l'ai mis..

non, je suis sous Debian (sarge).
 
.config
 

J'ai recompiler un noyau avec CONFIG_MSDOS_FS en dur et non en module, et toujours la même erreur, rien y fait je ne voit pas du tout d'où ca peut venir

est-ce que vous arrivez à avoir une console en framebuffer avec les drivers nvidia (les derniers) ?
 
j'ai beau compiler le framebuffer avec uniquement le driver VESA, ça bug lorsque X est lancé.
 

 
?

oui
 

quel noyau, quel patch, quel driver nvidia stp ?

pardon  
 
2.6.12-rc1-mm3 & nvidia 7167
sur un centrino + geforce 440Go
 
mais ça fait une éternité que j'ai plus de problème entre le FB et les pilotes nvidia (largement plus d'un an)

 
  Ayé ca marche, en fait il booter sur /dev/hda1 au lieu de /dev/hda3
   ste vielle erreur
 
Par contre j'ai un autre problème, c'est que maintenant avec ce noyau 2.6.11.5, le système freeze 2-3 min apres le lancement du mode graphique .
 

Moi j'ai un bleme.
IMPOSSIBLE de booter linux sur ma Tyan Tiger en monoproc.
Kernel panic inévitable au démarrage
Mais je crois que c mon disque dur qui est mort, je choppe ma carte SCSI bientôt.

http://kerneltrap.org/node/4940
linux 2.6, c'est lent !  

Soit c'est un prob de config de ton kernel, soit c'est un prob de config de ton BIOS ou soit c'est ton dur qui est mort    
Chez moi (même carte mère cf. ma config) sa boote nickel en monoproc tout comme en SMP

Moi c'est la merde avec le noyau 2.6.11 car je suis sous suse 9.2 et ca boot mais le chemin d'acces a reise ,il ne le trouve pas grr !  
 
Je vais etre bon a recompilé et reconfigurer le noyau. Deja que j'ai de mechant artefact avec 6800 sous le noyau 2.8.24.13 et c'est pire si j'installe le dernier pilote.(vu qu'il reclame un noyau plus recent)
 

Bon, faudrait que je me remette un peu à ma deb quand même (viva l'AMD64) ... ya quoi comme patchsets sympas en ce moment ? Toujours les mm et les ck ?
Sinon, vous avez testé initng ? Est-ce qu'il est pas trop lourd à installer et est-ce qu'il fonctionne bien ?
 
J'essaierais de mettre à jour la première page la semaine prochaine qd même