hum hum, après plusieurs tests : Alsa 1.0.5a ne fctionne pas chez moi sur le 2.6.8.1 …
Sachant que le 1.0.6 passe bien, mais que le pilote a été bcp modifié et que les mixeurs st bizarres, de même que le réglage du volume, l’option 1.0.6 est exclue :/.
Sinon, via portage, je peux rétrograder au 1.0.3 (en dessous du 1.0.5a, le 1.0.4 étant sucré), mais comme le noyau 2.6.8.1 contient Alsa 1.0.4, je reste sur cette version pour ce noyau (bizarre que le 1.0.5a ne passe pas, même sur un mm :/).
Qqn a des infos dessus ?
NB : le pilote Alsa 1.0.5a passe nickel sur les noyaux antérieurs au 2.6.8.1 … (enfin, j’ai pas testé le 2.6.9-rc1 encore, mais tt le reste, avec les mm, love, nitro …).
édit : je regarde sur la mailling list Alsa http://sourceforge.net/mailarchive/forum.php?forum_id=1751
édit (2) : bon, c’est un bug pour le 1.0.6 http://sourceforge.net/mailarchive/forum.php?thread_id=5375093&forum_id=1751
Anecdote : le réglage est à fond par défaut avec le 1.0.6, ça peut surprendre
Ensuite, reste à voir pq le 2.6.8.1 reste en stand bye au boot sur les mixeurs avec le 1.0.5a …
Recherche une mignone petite idée…
Je cherche à connaitre l’arbre des fonctions appellées par le noyau, avec les dates d’appels.
Si qq 1 à une idée?
non dsl mais si tu trouves je suis preneur
J’ai des patchs ltt pour le 2.6.??? que j’ai relooké pour le 2.6.8, je ne sais pas si ça va tourner?
En cas je vais voir si je peux modifier le projet ltt pour faire ce que je veux. je te dis ça dès que possible.
Bon pour le moment ce n’est pas top, il faut que je remette les mains dans le cambouis… à ce niveau c’est même dans les égouts
Tu as besoin de tracer quel genre de fonctions appellées par le noyau? toutes?
2.6.9-rc1-mm1 out
_benj
Août 27, 2004, 9:07
1888
compilation bientôt, espérons qu’il démarre
_benj
Août 27, 2004, 9:46
1889
bon ben alors
[fixed] fsck.reiserfs for device /dev/hda5 exited with signal 6
fakbill : J’ai besoin de tracer la pile d’appel de NFSv4 lors d’une écriture d’un fichier
Val1472 : merci, en fait ce qui est indispensable c’est d’avoir les dates d’appels. je cherche à savoir pourquoi on perd tant de temps dans l’écriture de certains fichiers avec NFSv4.
en sommes ce serait plus exactement un profiler qu’il faudrait
Oui, mais le seul que je connaisse est OProfile qui donne une charge statistique des fonctions, et ça ne me va pas trop : en fait la charge du système est presque nulle.
J’ai réussi à patcher avec LTT (après de grosses bidouilles) et je vais rajouter des marqueurs de temps aux trace données par LTT.
Dès que j’ai un truc qui marche je l’envoie sur la mailing list LTT.
C’est bon j’ai mergé les patchs LTT, je vais voir ce que ça donne.
edit: ce que ça donne : c’est la forêt vierge, j’ai 1 fichier par CPU, et comme les interruptions sont réparties sur les 2 cpu, c’est la galère à lire. Les temps sont donnés en cycle d’horloge, supersimple à lire.
"ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc1/2.6.9-rc1-mm2/
Nothing particularly noteworthy here. Some seriously bad scheduler
v_atekor : et ben si avec ça tu arrive à trouver les appels dans lesquels vous perdez du temps chapeau
c’est un pacth qui essaye de réduire les temps de lantence dans le noyau ça non?
En fait il ne les réduit pas, mais il me donne le temps passé dans les sections critiques… et en fait pratiquement le temps passé dans les fonctions. Ce n’est pas loin de ce que je cherche
Ha oui : un survol du code vient de me faire comprendre ça…
Ce fut laborieux… mais j’y suis à mes traces interressantes :
Je crois que les fonctions qui se trainent sont :
Je vais faire les mêmes tests sur le client.
2.6.9-rc1-mm3 out (le love1 basé sur le mm2 était pas mal, sauf Alsa un peu cassé quoi :/, et puis il fallait aussi patcher les Nvidia)
http://sourceforge.net/mailarchive/forum.php?thread_id=5375093&forum_id=1751
(mais mon tps de réaction a été élevé 
et je suis entrains de m’en faire un sur mesure