Reprise du message précédent :
avant de crier sur le kernouille parce que les gruikeries kde4 ne fonctionne pas, faudrait regarder ce que te dis dmesg

Les "gruikeries kde4" et le kernel 2.6.31 sont tout à fait aptes à détecter et lire un dvd vidéo.

problème de permission pitetre? genre user pas dans le groupe optical.

Ou alors fiente dans le fstab

Et si j'ai regardé dmesg avant de crier au scandale, je peux?
 
Sinon, j'ai regardé les modules chargés entre le 30 et le 31. Les modules cdrom et ide_cd_mod n'ont pas été chargés.
Donc modprobe puis mplayer

Et ça te fait pas tilter ça ?

 
T'es plus vraiment sensé utiliser ce truc. De nos jours, le lecteur cd/dvd est piloté via la couche d'émulation SCSI (sr_mod -> CONFIG_BLK_DEV_SR).  

Pas trop. Pour moi,c'est udev qui a du mal.

Je creuse cette piste. J'ai bien l'option cochée mais par contre d'autres comme CONFIG_SCSI_PROC_FS ne le sont pas. Et de mémoire sous le 30, je les avais cochées.

Merci à tout le monde. Je vais revoir ma config' du noyo.

Je suis sur un noyau 2.6.27.33 fait maison pour raison de patchage et kernel minimal. J'aimerais mettre à jour mon initrd car j'y ai ajouté des hooks et scripts. Mais quand je tape update-initramfs -u, il me met à jour l'initrd du noyau 2.6.26.2 .
 
Une idée ?
 
Réponse : update-initramfs -u -t -k 2.6.27.33

J'ai du réinstaller ma gentoo et j'ai un problème qui doit être lié à la config de mon noyau.
J'ai un 2.6.30 et les lectures sur mon lecteur dvd font mettre le cpu en wait for I/O et ça rame.
 
Le lecteur dvd est sur une puce ide Jmicron et je n'avais pas le problème avant quelqu'un à une idée?

Probleme de DMA?

Ca existe encore cette notion? Hdparm ne veut rien savoir .
 
J'utilise la lib ata et ma device est /dev/sr0

Bon ben ça marche maintenant, plus d'I/O wait alors que je n'ai rien changé

http://www.h-online.com/open/featu [...] 72271.html \o/

Bonjour ! Je tente pour la première fois de compiler un noyau    
Je suis allé sur kernelnewbie : dans la FAQ, un cours tuto explique la procédure.
 
J'ai donc fait un make menuconfig : j'ai laissé les options telles quelles (il semble que les options soient celles de ma distrib de l'ancien noyau si je comprend bien, c'est une ubuntu 9.10).
J'ai compilé, tout va bien (woooo tout ce qu'il y a ! Je doute avoir besoin de tous ces firmware)
Bon si je fait un make install : j'imagine qu'il va placer le noyau à coté des autres, pas à la place du courant    
Il faut que j'ajoute une ligne à grub, c'est bien valable pour ubuntu ?
 
Avant de l'installer, je préfère pas faire de conneries    
Merci !

Le mieux serait de suivre la méthode ubuntu plutot que la métode "générique"

J'ai trouvé une page pour compiler un noyau sous ubuntu... mais compiler les noyaux d'ubuntu ! M'intéresse pas, je voudrais le vanilla  
Mais j'ai pas beaucoup cherché (pour une fois!) je pensais que kernelnewbie serait parfait pour cela  

[edit] bon je suis cette page pour le moment : http://www.howtoforge.com/kernel_compilation_ubuntu_p2

Je@nb ne te propose pas de compiler des noyaux ubuntu mais simplement d'utiliser la méthode ubuntu pour les compiler ce qui est sensiblement  différent.

guepe>> Faut savoir que te vas casser la compatibilité avec les paquets de modules ubuntu. Si tu personnalises ta config, tu vas casser la compatibilité avec certains services qui dépendent des modules que tu auras virés. Enfin, si tu n'as pas le userspace qui va avec, tu t'exposes à des incompatibilités parfois longues à diagnostiquer. Exemple récent: quand la 2.6.32 est arrivée, j'ai dû compiler la dernière version de hal à cause des changements dans cpufreq. Fût un temps où, quand le framework wireless a changé, j'avais dû compiler iw pour pouvoir l'utiliser. Là, je suis passé sous lucid, j'ai eu droit à un kernel panic à la compilation du module nvidia. GCC ayant changé de version, j'ai pu recompiler le noyau avant de pouvoir recompiler le module... et j'en passe.
Tout ça pour dire que ça présente autant d'avantages en terme de fiabilité que d'inconvénients en terme de maintenance.
 
Si tu veux toujours le faire je te mettrais mon how-to personnel (plutôt une checklist/memo pratique).

Mon but n'est pas de "tourner" avec un noyau que je compile moi-même, mais d'apprendre à en faire une compilation/installation... pourquoi pas après tout chercher à apprendre ?    
Je sais bien que c'est super galère à gérer à tous les jours, mais ce que je veut faire c'est _essayer_ une fois, réussir une compil et un chargement à peu près correct...  
Bref, me faire les dents  

 
Tu as raison

 
Si ce n'est que ça, c'est pas vraiment compliqué. C'est la partie config qui est très longue si tu veux la faire bien et que tu ne connais pas ça par coeur. C'est à "usage interne" donc avec très peu d'explication (à faire en root), ça te donnera l'occasion de chercher à comprendre :
 
1) Downloader les sources tar.bz2 sur kernel.org
 
2) Les extraire dans /usr/src
tar -xvf linux-x.y.z
 
3) linker les sources
ln -s linux-x.y.z linux
 
4) passer dans le dossier linux
cd /usr/src/linux
 
5) copier mon fichier de config dans les sources
cp /boot/config-$(uname -r) /usr/src/linux/.config
 
5bis) Si besoin de patcher les sources, downloader le dernier patch .bz2 et le mettre à la racine des sources. (bzcat patch-*.bz2 | patch -p1 -R pour annuler un vieux patch).
bzcat patch-*.bz2 | patch -p1
 
6) make menuconfig et effectuer les changements
 
7)  cpufreq-set -g performance && make-kpkg clean && CONFIG_DEBUG_SECTION_MISMATCH=y CONCURRENCY_LEVEL=4 make-kpkg --initrd --append-to-version=-custom-r1 kernel_image kernel_headers modules_image && cd .. && ls -al && dpkg -i linux*2.6.32*.deb && rm linux*2.6.32*.deb && cpufreq-set -g ondemand

d'ailleurs, fais toi plutot un make gconfig / make xconfig ; c'est plus agréable pour lire la documentation

Un truc très important quand on commence:
après avoir lancé make menuconfig, va dans le menu "kernel hacking" puis vérifie que "kernel debugging" est bien désactivé. Sinon ton noyau sera très gros et lent.

Bon, après 2 jours de tests en 2.6.32-2 (patchs Debian) sous Sid, suis finalement revenu en 2.6.30...

Niveau latence les perfs sont en berne, je trouve. Un exemple : sous le même userland, avec le 2.6.32 l'effet de disparition progressive de la barre de lecture dans gnome-mplayer fait ramer les vidéos comme pas possible (image/son hachés), dans le même genre j'observe une baisse de la fluidité (saccade) lorsque je change de bureau virtuel (effet de glissement "vitre" sous E17) ; je n'ai aucun de ces problème avec le 2.6.30 (pas testé le 2.6.31 en revanche).

Bref, sur ma config (DELL Inspiron 8500) du moins, je ne trouve pas cette nouvelle version super convaincante, comparée à la 2.6.30. Je me demande si ce n'est pas en partie lié à l'implémentation RCU utilisée par défaut (Tree-based hierarchical RCU) ; étant plus extensible/efficace dans le cas de larges configs SMP, elle a remplacée l'ancienne implémentation (Classic RCU), certes plus limitée, mais qui reste finalement peut être plus adaptée pour les machines à base mono-processeur.

Ah bah c'est le contraire pour moi, depuis le 2.6.32 sauce sidux, j'ai enfin une bonne fluidité avec gnome-mplayer sur du i915 et du nvidia (chip 8200).
 

j'ai également noté des souci en 2.6.32 et plus au niveau de la gestion des chipsets atheros

Le seul souci que j'ai remarqué avec le 2.6.32, c'est que même la dernière version de HAL utilise des fonctions récemment dépréciées dans hald-addon-cpufreq. Vu l'état d'abandon de HAL et son usage largement répandu, c'est pas le moment de le casser avant que la succession soit prête.

J 'ai une question sur la branche 2.6.
Sait on jusqu'ou va aller cette branche ? 2.6.99 ? , 2.6.999 ?
Sait on sur quels criteres Linus va décider de passer a 2.8 ?

 
Abandon de HAL , alors que Xorg s'en est servi dans sa derniere release pour la detection des perifs genre clavier/souris (on peut faire sans , d'ailleur ce que je fait sous xBSD) , mais ça la fout mal quand même comme choix.

Probablement vu le rythme actuel...

non.
A l'heure actuelle cette méthode d'ajouts de fonctionnalités lui convient parfaitement donc bon
D'autant plus qu'on note qu'un certain nombre de distributions semblent vouloir opter pour la maintenance d'un kernel « stable » pour 2-3 ans (en gros rester par exemple sur un 2.6.33)

et d'après ce que j'ai compris now les versions impaires ne sont plus réservées au dev, right ?

Oui.
Faut suivre.
Cordialement.
 

 
le noyau linux ne casse pas l'ABI. hal continuera à marcher.

Les numeros impairs pour le dev portaient uniquement sur le 2ieme chiffre (1.1, 1.3, 2.1, 2.3, 2.5...) donc, non, non, rien n'a change
Tous les 2.6 sont des versions stables

C'est pas les seuls concernés, visiblement.
 
Chez Debian, il y a actuellement un rapport de bug ouvert pour les chipsets ralink.

 
Bizarrement de mon côté j'ai - semble-t-il - moins de soucis en atheros avec le 2.6.32 qu'avec le 2.6.31

Absolument aucun souci avec le .32 et de l'Ath

je n'en avais pas parlé mais cela concerne également ralink chez mandriva  

 
j'en ai eu un peu mais avec le 2.6.32.2 ca remarche au poil

 
Ca existe aussi sur arch apparemment, faut que je teste avec mon 1005HA qui a une 3080 dedans, normalement ils viennent d'intégrer le driver dans le kernel

Je sais que je réponds avec trois semaines de retard, mais au cas où ça intéresserait des gens...

Il n'y a pas de raison de faire la compilation en root, on peut utiliser fakeroot pour les moments où il faut faire semblant d'être root pour la création du paquet debian.

Je viens de faire un tour dans le README qui est dans les sources pour y chercher autre chose et je vois qu'il est déconseillé d'utiliser /usr/src/linux pour les sources :

Par contre on peut utiliser par exemple /usr/src/linux-2.6, /usr/src/linux-2.6.32... même si je ne vois personnellement pas l'intérêt de mettre les sources là plutôt que dans /home/login.

Pour suivre la version de développement c'est plus simple d'utiliser git, par exemple pour suivre le noyau de Linus :

pour créer le répertoire initial (ça télécharge plusieurs centaines de méga-octets), puis à chaque fois qu'on veut mettre à jour il suffit d'aller dans le répertoire et de faire

 
 
Pour savoir où on en est :

qui renvoie par exemple pour moi v2.6.33-rc2-268-g45d28b0.
 
 
Je suis au 268e commit après le tag v2.6.33-rc2, si je veux revenir à la version 2.6.32 je fais

et pour revenir où j'étais

Je ne suis pas convaincue que ce soit utile, chez moi le gouverneur est ondemand, et évidemment au début de la compilation le processeur passe à la vitesse maximale, mais au bout d'un moment la vitesse diminue et au lieu d'avoir « hardware limits: 800 MHz - 1.60 GHz » dans cpufreq-info, je n'ai plus que « hardware limits: 800 MHz - 1.33 GHz », puis seulement 1.07 GHz et enfin 800 MHz comme fréquence maximale. L'utilisation d'un autre gouverneur n'y changerait rien puisque c'est une limitation du hardware (probablement pour éviter la surchauffe).

Comme dit au-dessus, utiliser fakeroot, et puisque j'étais dans la lecture de README, il y a l'option "O=output/dir" qui permet de mettre tous les fichiers objets dans un répertoire différent de celui des sources et donc d'éviter de compiler en étant root même si les sources sont dans /usr/src, mais je ne sais pas si ça marche avec make-kpkg.
 
 
On peut aussi compiler simplement avec « fakeroot make deb-pkg » pour obtenir un paquet debian (avec le noyau et les modules mais pas les headers) ; on peut mettre les scripts qui vont bien dans /etc/kernel pour mettre à jour grub, générer l'initramfs,... pour que tout ça soit fait automatiquement quand on installe ou désinstalle un paquet créé de cette façon (make-kpkg utilise aussi ces scripts depuis la version 12).