Reprise du message précédent :

 
je plussifie

vous me conseillez quoi comme 2.6 récent? test4-mm6? test5? test6-mm1? Autre?

au fait perchut2 pour lm-sensors avec ton it87 essaye modprobe it87 temp_type=0x1c
 
Ca donne toujours des temps délirantes ou c'est mieux?

 
test2-mm1 je dirais, voire un test2 avec un mm supérieur

c'est vieux ca!

 
ouai mais moins de bugs il me semble, mais je dirais qu'il faut tester, ça dépend de ta config

 
c'est malin je m'en suis mis partout !    

le test2-mm1 est le dernier à marcher avec ma passerelle pour mon modem speedtouch usb
par contre celui qui semblait marcher le mieux (en apparence en tout cas) pour ma machine principale, c'est le test2-mm5
le dernier que j'ai testé et qui marche bien c'est le test4-mm4
et j'ai pas testé du tout le test5 parce que j'attends le mm2 avec impatience parce que vu le temps qu'il met à le pondre, j'imagine qu'il va être bien !  
 
bon par contre les vacances sont fini donc je crains que ça aille bcp moins vite maintenant

upgrade des module-init-tools dans sid : j'ai plus aucun message d'erreur au boot

 
depuis vendredi ya le patch bk3
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/

Alors que le 2.4.22 est en bk17, la honte
D'ailleurs, pkoi on a des bk sur le 2.4.22 et un 2.4.23-pre3 ?!?

 
euh c t pas it87 je crois, mais je vais jeter un coup d'oeil, le temps de me réveiller

 
le pre c'est avant la release, les bk c'est apres

bon bah finalement j'ai installé le 2.4.22-ck2
 
C'est un 2.4 avec quasiment tous les patchs d'interactivité backportés du 2.6
 
Le meilleur des 2 mondes quoi

il répond bien ? là je suis en train de compiler un 2.4.22 bien patché, j'ai foutu la base -ck pour le preempt/sched/lowlatency, mais bon si ça répond pas aussi bien qu'un 2.6 ou un kernel suse, je vais être déçu

test5-mm2 !!!      
    aller hop, je fonce !  
     

j'attends que tu l'ais testé avant de m'y mettre

 
j'attends de savoir utiliser le gpg sur jabber via kopete avant de tester  

rho le boulet  
 
 

ouééééé
 
je sais ce que je fais ce soir      

http://lkml.org/lkml/2003/9/14/158

c'est pas mauvais ce qu'il fait M. Morton quand même

au fait, je viens de me rendre compte que mon graveur ide ne marchait pas ... faut toujours l'émulation scsi ou quoi ??

pas avec un cdrecord récent normalement

 
nan mais y-a même pas device créer pour la partie cdrom du graveur
c'est bizarre ...

t'as pas le hdX correspondant ? tu crés un lien

 
bah non, j'avais pas non plus le /dev/ide/... correspondant ...
hors il se crée tout seul pour les disques durs
donc je vois pas pourquoi je devrais les créer à la main

devfs ?

 
ouai

bon, ça commence à être franchement pénible à tester là
ils arretent pas de changer les noms des structures et du coup je peux pas installer mes pilotes nvidia (gforce et nforce)

http://lkml.org/lkml/2003/9/15/103
et ben

et merde, je fais des reportbug à droite à gauche à ce sujet alors qu'en fait le problem semble venir de ma debian (un pb dans une récente mise à jour on dirait )
 
mais je demande aux nombreux experts présent sur ce forum :
d'où vient les fichiers /usr/include/linux/module.h et /usr/include/linux/modversions.h ?
parce que lors de la compile, nvnet à besoin de module.h (y-a un include dans les sources)
hors à la ligne 21 de celui ci, il y a un include sur linux/modversions.h, mais celui n'existe pas
voilà d'ailleurs l'erreur à la compile :

alors ? c'est quoi ce bordel ? il est passé où ce fichier ?

faut pas qu'il aille voir dans /usr/include
 
regarde si tu as bien /usr/src/`uname -r`/include/linux/modversions.h
 

je dirais même plutôt : /lib/modules/`uname -r`/build/include/linux/modversions.h
 
c'est plus cohérent

 
j'ai recherché dans tout /usr et le rep build pointe vers le rep source du kernel (à savoir /usr/src/linux)
donc non, y-a pas  

tiens on en apprend tous les jours décidemment
là je compare les deux rep :
/usr/src/linux/include/linux
et
/usr/include/linux/
et leur contenu est similaire mais pas identique
le premier est plus complet et plus récent (normal je viens de compiler)
y-a pas modversions dans aucun des deux, mais les modules.h du premier ne fait pas appel à modversion justement ...
me demande si je vais pas bidouiller un peu tout ça... mais faudrait pas que je casse quelque chose  

 
nan, ça c'est normal, /usr/include/linux est composé par glibc-devel, mais en aucun cas il ne faut utiliser ce répertoire pour compiler quoique ce soit en rapport avec le noyau !
 
c'est plutôt pour les applies....
 
mais si tu n'as pas /usr/src/linux/include/linux/modversions.h, c'est que tu n'as pas compilé de noyau avec ces sources ou alors tu as fait un make mrproper, dans ce cas il faut recharger la conf, puis :
 
(- make dep) kernel 2.4
- make bzImage
tu fais un CTRL + C pour interrompre et là normalement tu devrais avoir ton modversions.h de créé

 
bon alors je continue mon investigation et j'ai bien ce fichier
mais nvnet utilise /usr/include/linux/module.h (cf erreur indiqué plus haut)
et celui ci cherche modversions.h dans le même répertoire
c'est d'autant plus surprenant que ça marchait très bien avant ...

dans nvnet.h j'ai ça :

donc je vois mal comment il pourrait aller voir dans les sources du noyau
et pourtant ça a toujours marché jusque maintenant

ola ... je sais  pas, y-a surement un truc que j'ai mal fait ... je viens de me rendre compte que /lib/modules/2.6.0-test5-mm2/build pointe vers "." au lieu de pointer vers /usr/src/linux-2.6.0-test5-mm2    
 
bon, je vais refaire un essaie, mais y-a bcp de trucs louche dans cette histoire

 
c'est le linux/module.h des sources, il me semble que le chemin s'affiche entièrement à la compilation
 
tu peux essayer d'éditer le Makefile et virer le -I/usr/include/linux
 
edit : il me semble aussi qu'en fixant la variable $SYSINCLUDES ou $SYS_INCLUDES (je sais plus) çà aide dans ces cas-là