Reprise du message précédent :
dans le kernel y a tout ce qu'il faut pour ma config mais je ne sais pas si ils ont déjà porté tous les sensors dans le kernel.
 
Pour google je suis sur que si tu cherches le nom de tacrte mere nforce2 ou juste nforce2 & lm-sensors ou lm_sensors tu auras trouve en quelques minutes quelqu'un qui explique comment il a fait pour configurer les sensors avec le nforce2

mais il faut encore un autre module ou quoi ?
parce que là je cherche mais je trouve pas  

bon j'avais pas tilter qu'il fallait aller dans la casse "sensors chip" du config du kernel
quand j'y suis allé, j'ai vu it87 dont je me souvenais avec le sensors-detect sous kernel 2.4
donc je l'ai foutu, et Ô miracle ! ... ça marche aussi bien que sous 2.4.21, à savoir, tous mes ventillo se mettent à tourner à fond, et les valeurs indiquées sont ubuesque  
 
bon, ça c'est avec i2c-isa
j'ai toujours pas compris pourquoi il ne veut rien entendre avec le i2c-nforce2 qui est censé être fait pour

j'ai l'impression que tu charges les modules au pif

 
Heu.. c ou que ca s'active ce truc, g aucun repertoire /sys moi    
 
j'vois pas l'option dans le noyau, et aucun package me donne de réponse pour sysfs  

 
le sysfs c'est un cramfs, je crois pas qu'il y ait besoin d'une option pour ça
en tout cas ça marche chez moi mais j'ai peut-être mis un truc au pif sans m'en rendre compte

 
non, sensors-detect m'avait dit avec le kernel 2.4 de charger i2c-isa et it87
mais là ça marche encore moins bien que sur le 2.4
et je comprends pas pourquoi le module spécifique au nforce2 ne sert à rien ...
 
tout ce que je trouve sur google, c'est le patch pour les anciens noyaux pour pouvroir avoir le support des sensors du nforce2
mais moi je veux pas ça je l'ai déjà direct dans le 2.6

 
a oué c un truc a mounté sorry

 
tu crées le rep et dans le fstab tu mets :

g vu g vu  

C'est quoi ta carte mère?

 
c'est la FN45 du shuttle sn45g basé sur le nforce2 ultra 400  

Et en ouvrant le pc pour voir la référence exacte du chip il est sensé être supporté?
 
http://www2.lm-sensors.nu/~lm78/cv [...] chips/it87

 
c'est à dire que c'est un shuttle alors bon, spa facile d'y accéder  
enfin sur la photo (contractuel je pense), c'est marqué it_quelque chose

Dites, j'ai un petit souci avec mes fortunes qui s'affichent mal dans la console, dès que j'ai un accent ou un caractère un peu spécial ca me fait du beau paté, j'ai pourtant compilé mon kernel avec tous les nls nécessaires et la lecture d'un volume FAT par exemple ne pose pas de pb au niveau des nom de fichiers ...
 
Autre chose, le sysfs sert dans quels cas précis autres que les lmsensors ? Sera-t-il backporté en 2.4 ?

test3 out !  
ça se sentait, ils disaient que les mm5 était une tentative de stabilisation de la branche courante  

Effectivement, sortie du 2.6.0-test3, j'ai mis à jour le sujet du topic. Sinon, j'ai pas encore l'annonce de Linus et les news ne sont encore pas là, je referais mon petit message d'annonce demain ...
 
Pour les séries -mm, pas encore dispos pour cette nouvelle version, c'est ici :
http://www.kernel.org/pub/linux/ke [...] tches/2.6/
 
Et évidament, le site officielle et l'url de téléchargement :
http://www.kernel.org/
http://www.kernel.org/pub/linux/ke [...] t3.tar.bz2
 
Sinon, on a un comparatif intéressant des nouveaux filesystems dans les noyaux 2.6 disponible sur KernelTrap :
http://www.kerneltrap.org/
http://kerneltrap.org/node/view/715

l'usb (ohci) et le réseau (nvnet closed-source de nvidia) ne marche pas avec le test3 alors qu'il marche bien avec les test2

Donc on attend le -mm1
 
Tu as ces infos par lkml ou la liste de bugs ?

 
non, j'ai ces infos par moi qui est testé
et je vais me faire envoyer chier pour mon report du bug sur le réseau, je le sens  
driver closed source oblige...
pb c'est que ça marche avec le test2 mais pas le test3 donc je pense que le pb vient du kernel et non du driver ...

test3-mm1 out
voyons voir si c'est mieux  

 
ça marche
pas aussi bien que le test2-mm5 mais ça semble bien marcher  

 
Ca veut dire quoi "pas aussi bien"  

 
j'ai des messages d'erreurs comme avec les premieres test2 (corrigé dans le test2-mm5)
c'est dommage de les voir revenir
mais c'est pas méchant
tout marche correctement (utilisable)
pas de perte de donner pour l'instant ( )
donc pour moi ça me va

oulah !je viens de voir que mes dernier rep dans /lib/modules sont passé de 2.5Mo à 20Mo sans savoir pourquoi

 
Je suis sure que tu vas trouver vite fait et nous dire ce qui provoque ce cancer

ah ouai quand même ... va falloir m'expliquer un truc là :
 

 
 
bref, y-a du changement mais pas au point de changer la taille à ce point

reiserfs : 2.4Mo dans le gros, 244ko dans le petit
 le son : 7Mo de plus dans le gros  
alors là je capte rien, y-a pas tant que ça de diff entre les 2 conf pourtant  

ça fait comme s'il compilait tout en static  
les modules me paraissent énorme
encore un exemple : isofs me prend 700 ko  
je supute qu'il s'agit d'une des options du début de la conf au sujet des modules ... donc ce serait ma faute  
je soupsonne tout particulierement :
 

 
j'ai décoché pour gagner en place justement
enfin je sais pas si ça vient de ça
faudrait que je teste mais ça me parait bizarre  

qq'un saurait il m'expliquer pourquoi les patches mm prennent tant de place ??
c'est normal et connu et j'ai encore loupé un épisode ou alors y-a un truc qui cloche avec ces patches ?

Bah perso, avec ma config, j'ai jamais eu de pbs de place, tout c'est toujours bien passé, à part le kernel lui même qui est un peu plus gros que les 2.4 (mais bon c'est normal), je ne crois pas que le pb vienne des séries -mm ... je vais essayer le 2.6.0-test3-mm1 et je te dirais
Sinon, j'aîmerais savoir à quoi exactement sert sysfs ...
 
PS : Mon 2.6.0-mm5 marche du feu de dieu !

Je viens de vérifier mes tailles de modules ... et effectivement, je fais le même constat que toi !
Je compare ici un noyau 2.4.21 patché ck3 et mon 2.6.0-test2-mm5 :

Ce qui m'étonne, c'est que les modules qui sont sensés apporter les mêmes fonctionnalités sont 10 fois plus lourdes sur le 2.6 par rapport au 2.4 ! Par exemple ext2, qui n'a pas vraiment bougé en fonctionnalité, et les nls, c'est époustouflant ! Je ne sais pas s'il faut faire un bugreport (à mon avis on n'est pas les premiers à s'en rendre compte) mais c'est très étonnant et très gênant si effectivement le 2.6 prend 10 fois plus de ram pour stocker ses modules !
Je vais tester avec le 2.6.0-test3 sec puis le 2.6.0-test3-mm1.
 
C'est peut-être un pb de compilateur, sachant que j'ai upgradé ma deb avant de lancer la compilation (gcc 3.3.1) ...

bah j'ai fait tous les tests possibles et immaginable, et je peux t'affirmer que ça vient bien des mm : avec la même config, et quazi rien dedans, le test3 fait 1.2Mo et le test3-mm1 fait 3.1Mo ... je vois pas où ça pourrait augmenter à ce point alors que c'est la même conf
je parle là du rép dans /lib/modules
la taille du vmlinuz ne bouge pas elle
 

il récupère une partie du boulot que faisait /proc avant
les drivers y mettent les info qu'ils ont besoin de communiquer avec le système
(c'est ce que j'en ai compris mais je connais pas la raison du sysfs sur le /proc)
 

c'est le mieux chez moi

 
ah je suis content, je commençais à me demander quelle connerie j'avais encore bien pu faire !
le bugreport, je pense effectivement pas que ce soit une bone idée pour ça, parce que si ça se trouve c'est normal, ou au moins, connu
donc le mieux serait d'en parler plutot sur la lkml (y-a rien pour les mm eux même et je pense que ça les dérangera pas si on report sur cette ml)
comme je l'ai dit, ça me fait penser à un truc compiler en static (même si ça n'a pas vraiment de sens pour un kernel)
 
et c'est pas un pb de compilateur ou autre puisque moi j'ai fait le test entre test3 et test3-mm1 avec exactement les même versions de prog (pas de mise à jour entre les deux)
d'ailleurs si tu as bien regardé les tailles de mes rep, tu peux voir que les test2-mm1 et test2-mm2 font 4 Mo (avec bcp de truc dedans par contre là), et que les mm3 et mm5 (j'ai sauté le mm4 ) font plus de Mo
donc je supputte qu'une merde a été rajouté entre les 2  

j'ai foutu ça sur la lkml, on verra bien ce qu'ils en pensent

ben ils ont pas l'air d'en penser grand chose

bah lkml c'est pas blabla@linux.kernel on peut pas répondre en mettant juste plein de smileys débiles

 

 
au fait, tu as remarqué la même chose de ton coté ?

Je viens de compiler le 2.6.0-test3-mm1, je vais compiler en version standard et je te dirais. Je trouve ca un peu curieux que ca se retrouve sur un -mm1, qui par définition ne devrait pas incorporer beaucoup de changements ... sinon, tu nous tiens au courant pour la lkml
Le seul changement au niveau config que j'ai remarqué du test2 au test3 c'est la possibilité d'inclure le .config et les infos de compil dans le noyau ...

j'ai honte
j'ai envoyé un mail à andrew morton, qui m'a très rapidement et très gentillement répondu
mais je le soupçonne de s'être foutu de ma gueule ironiquement  
sa réponse :
 

 
c'est de l'ironie son histoire de patch, non ?
 
bon en fait c'était un peu évident et je suis sur que plein de monde savait ici sans le dire !      
c'est du débugage inclut par les mm à la compile
d'ailleurs il patch le makefile, c'est les premieres ligne du patch qui font ça ... c'était pourtant pas compliqué à voir  
le début du patch :
 

 
y-a qu'à enlever ça j'imagine ...
chui bien passer pour un con là quand même

Donc on enlève quoi en fait ... uniquement l'ajout de cflags "-g" dans le Makefile principal ? Tu aurais le patch complet ?
 
Autre chose : j'aîmerais permettre l'accès à une partition FAT32 en lecture seule sans éxécution pour les users normaux, et en accès complet pour le root, quel paramètre dois-je mettre dans mon fstab ?
 
Et sinon, j'ai un petit problème de charset dans le 2.6.0-test3 : le clavier français ne l'est plus vraiment ... notamment la touche "=" qui donne "-", et d'autres désagréments de ce type que je n'ai pas avec le 2.4, et que je ne me souviens pas avoir eu avec les précédentes versions 2.6.