Reprise du message précédent :
Un nouveau message, au boot du 2.6.28, si je ne me trompe pas (je n'en avais pas le souvenir avec le 2.6.27) :

Depuis le 2.6.26, class_device_create n'existe plus. Il faut utiliser device_create.
http://kerneltrap.org/man/linux/man9/device_create.9
 
Et ce topic aurait besoin d'être plus souvent mis à jour

Bonsoir
 
est-ce que certains parmi vous sont impacté par ce vieux bug ?
 
http://bugzilla.kernel.org/show_bug.cgi?id=7372
http://bugzilla.kernel.org/show_bug.cgi?id=12309
 
C'est quand même dingue qu'un tel bug existe depuis si longtemps

Je l'avais constaté avec un kernel 2.6.25. Un simple ls sur un dossier peu rempli (genre 3 sous dossiers/5 fichiers) ne s'est exécuté qu'à la fin d'un transfère de 15Go (déplacement d'une VM entre 2 hdd). Soit plusieurs minutes plus tard.
J'ignore si le bug est toujours là ou non, je ne fais pas ça tous les jours.

Ben d'après les bug report, il est présent meme dans les versions récentes

J'ai aussi remarqué ce phénomène lors de grosses copies de fichiers volumineux (etch en 2.6.24).

et un type semble lier ça à l'ordonnanceur E/S CFQ qui est passé par défaut depuis le 2.6.18

Oui j'ai vu ça pour l'ordonnanceur mais en lisant à droite à gauche, ça ne semble pas être la vraie raison

Ce bug semble plus lié au task scheduler (CFS) qu'aux io schedulers.
Que ce soit CFQ, anticipatory ou deadline, un ls lors d'un gros cp va allouer de la bande au ls (et prioriser les lectures); c'est justement à ça qu'ils servent.
 
Pour ceux qui ont le problème de manière clairement reproductible, pourriez-vous essayer:
1) echo -n deadline > /sys/block/ledisquedur/queue/scheduler
Pour s'assurer que CFQ n'est pas (directement) la cause du bug
2) Essayer de voir si le problème se produit aussi sur un kernel avec l'option Group CPU scheduler (General setup) désactivée
 

Salut,
 
on a meme ce probleme sur des montages NFS...

Depuis quelques mois, je traîne un "problème".
A chaque démarrage, juste entre grub2 et le message *reading files needed to boot*, j'ai le message d'erreur suivant :
modprobe: FATAL: Could not load /lib/modules/<version du kernel>/modules.dep : no such a file

J'ai fait quelques recherches mais ce que je trouve ne correspond pas à mon cas. Les gens qui se plaignent de ce message ne peuvent pas booter (blocage définitif ou kernel panic) ; chez moi, ça bloque juste le boot 3-4sec puis ça démarre et fonctionne parfaitement.
D'autre part, le fichier modules.dep est bien à l'endroit indiqué et je compile le système de fichier / en dur.
Je suppose que je dois oublier un détail mais quoi...
Je compile les sources vanilla à partir d'une ubuntu 8.10 avec make-kpkg clean && CONFIG_DEBUG_SECTION_MISMATCH=y CONCURRENCY_LEVEL=4 make-kpkg --initrd --append-to-version=-yuuki-r1 kernel_image kernel_headers modules_image

Si vous avez une idée ou qu'il faut des précisions, n'hésitez pas.

Essaie un coup de depmod pour voir.

Pas mieux.  
Je vais essayer avec les contrôleurs disques compilés en dur.
 
PS : le message d'erreur était incomplet. Donc il ne trouve pas le fichier, qui pourtant, est à l'endroit indiqué.

Messieurs,    
 
J'ai depuis plusieurs mois un soucis avec le noyau linux, et une partie de mon matériel. Il en résulte un Kernel panic bloquant.
Le "bug" n'était pas dans les anciennes version du noyau.  
 
Bref, je vous fourni les liens de signalements.
 
http://bugzilla.kernel.org/show_bug.cgi?id=11121
Signalé également chez debian : http://bugs.debian.org/cgi-bin/bug [...] bug=504655
 
Voilà, ma question est, est-ce qu'un jour quelqu'un va s'occuper de ca ? Savez vous ce que je peux faire pour éventuellement aider ? Je ne vois pas quoi faire de plus, le signalement est exactement ce que j'ai. Quelqu'un sais comment se passent le signalement et le traitement au niveau du noyau ?

Tu peux reposter un message sur le bugzilla et voir ce qu'il se passe, mais a part cela...

pour ma part la kernaille refuse d'entendre raisons:
 

j'ai bien effecuté un make-kpkg clean avant

Le 2.6.29 est sorti hier, faudrait p'tet voir à mettre à jour ce topic quoi

Perso, j'ai pas mal de problèmes d'ACPI/IRQ avec 2.6.29. Problèmes qui n'existaient pas avant.
Je veux bien qu'asus codent leur table ACPI comme des porcs, mais si ça fonctionnait bien jusque là, il n'y a pas de raison de créer un problème réel pour contourner un problème cosmétique.
 

c'est juste des warnings ou bien ça fait planter ?

Globalement la machine est stable (pour le peu que j'ai eu le temps de tester).
Par contre mon it87 n'est plus accessible puisqu'il me le colle sur une adresse I/O conflictuelle. Et ma carte nvidia qui était tranquille sur son IRQ MSi 317 se retrouve en partage sur le 26.
 
Pour le nvidia, j'étais tombé sur une discussion où il est question que ce le bug soit chez nvidia. Après tout, peut-être que le binaire n'est pas encore 100% adapté au 2.6.29.
Par contre, l'it87 n'a pas de raison de se mettre à faire n'importe quoi.

En fait, j'imagine qu'il est possible de forcer un module a utiliser une plage d'I/O ?

modinfo <nom_du_module> pour connaitre les options que tu peux passer à modprobe ou insmod

J'ai trouvé un syntaxe générique pour ce genre de chose (ça n'apparaît pas dans modinfo). Faudra que je teste :
 
modprobe <module> io=0xXXXX irq=XX

Dans le rapport de bug sur bugzilla deux personnes demandent de git bisecter pour trouver le commit exact qui a créé le problème, tu peux faire ça si tu sais faire (ou es prêt à apprendre) et as le temps.

bonjour
je viens de compiler mon premier noyeau le 2.6-29 en laissant mes options par défaut dans le menuconfig.
Je suis sous Xubuntu Intrepid.
 
Par contre j arrive a booter sans soucis avec mon new kernel, chouette!
Mais je n ai pas ma nvidia de détectée... Apparement il en veut pas
Sachant qu avant les drivers proprio étaient installé.
J'aurais oublier de cocher quelque chose dans le menu config?
 une piste?
merci

Il faut recompiler les modules pour le nouveau noyau

Comparatif des kernels: http://www.phoronix.com/scan.php?p [...] arks&num=1

Super on a des chiffres mais pas une seule explication du pourquoi c'est plus rapide /plus lent...

c'est phoronix, pas lwn, ils testent, ils newsent mais niveau technique c'est pas l'extase.

Mouais...

c'est normal que les "hdX" sont reconnus en "sdX" ?
y a un moyen de désactiver ça ?
 
edit : resolu
 
 
 
 

passé en 2.6.29 hier soir, jusqu'ici, tout va bien

 
Depuis pas mal de temps (la nouvelle libata, ca doit faire 2 ans au moins) non ?

 
 
ça fait 2 ans que j'ai pas fait d'install  

À propos du swap :
 
- j'ai 8Go de ram et je constate qu'il y a toujours besoin d'un peu de swap (c'est pour cela que j'ai remis une petite partition ad hoc) alors qu'il reste de la mémoire standard de dispo.
 
- j'ai lu (sûrement sur KernelTrap, mais, il faudrait que je recherche plus en profondeur pour être plus précis) que ce souci est présent avec les noyaux 2.6.28/2.6.29, mais comme je n'ai beaucoup de ram que depuis peu, il m'est difficile de me faire une idée la-dessus.
 
Bref, j'aurais aimé savoir si quelqu'un a plus de précision .
 
nb : 2.6.29.1 là (je compile le .2 ce soir, avec tous ses correctifs, mais peut-être que ce souci vient tout bonnement d'ailleurs).
 
edit : titre du topic pas à jour .

Supprime le swap et tu verras que ca marche toujours tres bien.
Je n'ai qu'1 Go de ram et je me sers du swap uniquement pour le suspend to disk.

Je note fl0ups, mais ça reste un peu étrange comme comportement cette partie swap.

Fais une recherche sur la swappiness si ca te travaille
 
Ci-dessous le premier lien que j'ai trouve:
http://www.linuxvox.com/linux-arti [...] swappiness

Faut pas prendre le noyau pour un jambon: s'il a virer des trucs en swap en faveur d'autres pages, c'est parce que c'est inutilisé.
Je vois pas le souci avec ça. L'intégralité des applications allouent des tas de conneries jamais touchés, c'est des bons candidats pour être balancer en swap.

Ok Taz .
Merci pour le lien fl0ups : très intéressant .

 
histoire perso : depuis 2 ans, j'ai 2 go de ram en gentoo, et plus de swap. J'ai du avoir droit à 5 ou 6 cas où la machine est arrivée à bout de souffle - plus de ram - et ou ma kernaille a killé le vilain process qui bouffait tout.