Reprise du message précédent :
Effectivement, je n'ai pas fait cette étape =/
Ça se passe comment ? make menuconfig ? Première fois que je fais ça

Si tout est bien installé il te suffit de faire en sorte que le bootloader aille chercher le bon fichier et à redémarrer.
Sur le pi je ne me souviens plus comment c'est fait... Le chemin du noyau est peut-être fixe.
Si tu as juste mis à jour ta distrib un redémarrage devrait suffire non ?

Un reboot ne suffit malheureusement pas non.

Demande sur un topic spécialisé raspberry pour configurer le bootloader.

Faut copier le fichier bzImage dans le répertoire /boot, genre (je suis dans /usr/src/linux bien entendu là) :

/boot est déjà monté à ce moment bien entendu .
Après tu upgrades le bootloader, genre, pour Grub2, tu peux éditer le fichier grub.cfg ou faire un :

 
nb : je copie aussi mon .config dans le /boot pour plus de sécurité, genre (je suis encore dans /usr/src/linux là):

 
edit : ah, oui, sous Debian ... tu devrais juste ugrader la config du bootloader et puis c'est bon, sous réserve que tes liens dynamiques soient ok aussi (désolé, je ne connais pas Debian).

   
 
Non mais surtout c'est sur raspberry pi, le bootloader est un peu spécial il me semble.

Il faudrait déjà trouver le nom de ton bootloader.
 
nb : quand j'écris, "je suis dans /usr/src/linux", c'est un lien dynamique vers le noyau courant, hein .

C'est un truc spécifique au raspberry, bon qu'il demande sur le bon topic j'arrête là cette discussion ça n'apportera rien

Encore pire
Je suppose que tu compiles en root ?
La best practice reste de copier les sources quelque part dans ton home et compiler en simple user.

Et oui, je mets à jour mon système via l'utilisateur root, étonnant non ?

OK. Laisse tomber.

Ok, pas de souci, ça te permettra de te documenter quelque peu.

Tu parles de /root ?

3.15 out !

noyau 3.15 documenté sur linuxfr
http://linuxfr.org/news/sortie-du-noyau-linux-3-15

Avec le 3.15.0 en regardant une vidéo via le site youtube (je n'ai pas le plugin) et Firefox (30) :
 

 
 
edit : c'est reproductible (idem en 3.15.1 bien entendu).

est-ce que tu as aussi des problèmes de son avec d'autres logiciels ? ( écoute d'un mp3 par exemple avec mplayer )

tu as activé le mode html5 pour youtube ?

https://www.youtube.com/html5?hl=fr

mais si le message stressant de syslog n'entraine aucun désagrément dans la lecture de fichier multimédia alors ce n'est pas la peine de s’inquiéter

je suis sous archlinux, pas de kernel 3.15.x disponible dans les dépôts stables, souvent les mainteneurs d'archlinux attendent 4 ou 5 versions  avant de proposer une nouvelle branche 3.x.y (  3.15.5 par exemple ), ceci afin d'être certain que les bugs de jeunesse de la nouvelle branche 3.x soient corrigés,

tu devrais peut-être en faire autant,

en attendant regarde si ton bug a été déclaré dans le bugzilla du kernel, ou de alsa

Ça vient en effet du noyau 3.15, je n'ai aucun souci sous le 3.14 .
 
edit : je lis bien la vidéo en html5 et le reste est également bien configuré.

finalement le kernel 3.15.1 est arrivé plus tôt que prévu sous archlinux,
 
j'ai donc fait le test de la vidéo de j_c_p, je n'ai pas le message d'erreur,
 
mais je n'utilise pas pulseaudio

J'ai refait plusieurs tests ensuite, et ce souci n'arrive que via Firefox ... donc, oui, ça doit être relié à une connectique sonore de ce navigateur.
Le truc, aussi, c'est que j'ai pulseaudio d'installé, mais il me semble que c'est relatif aux librairies 32bits ... bref à voir de plus près (sinon, je n'utilise qu'Alsa à la base).

j'ai utilisé aussi firefox, avec le mode html5 pour youtube,

regarde si tu peux désinstaller pulseaudio ( moins il y a de trucs installés mieux c'est pour la stabilité ), normalement ce serveur de son n'est pas obligatoire, sous archlinux je n'ai pas de pulseaudio, pour l'avoir il faut explicitement l'installer,

c'est peut-être un autre paquet qui a installé en traitre ce paquet pulseaudio sans demander ton autorisation ( genre dépendance optionnelle ), il faudrait que tu regardes quel paquet dans ton système requiert l'installation de pulseaudio, une commande gentoo qui liste les paquets qui ont besoin de pulseaudio ou qui ont demandé son installation

pulse audio c'est lourd pour rien , alors qu'alsa est dans le kernel

Il restait alsa-plugins (avec le use pulseaudio) d'où le paquet pulseaudio ... ceci enlevé, et après recompilation de Firefox, je teste là.
 
edit : pareil, j'ai un freeze complet (je n'arrive pas au bout de la vidéo, vers les 3/4 je dirais) et rien dans les logs là (je vais peut-être activer le debug sur Firefox et retester demain).
Aussi, je retenterai avec la version antérieure de Firefox.
 
edit2 : à voir FS#39806 - [linux] firefox freezes and crashes with kernel 3.14-4.

ne pas confondre alsa et dmix. Tu as besoin d'un serveur son pour mixer plusieurs sources audio, dmix le fesait de base quand tu n'avais rien d'installé, se n'est plus franchement le cas. alsa n'est qu'une interface commune et une architecture de drivers son. Si tu n'a que alsa, non tu ne pourra pas mixer plusieurs sources sonores.
Ils sont en train de refondre alsa (la couche kernel et userspace) et il se peut que pendant ce temps, certaines interfaces foirent, et certains drivers ne soient plus supportés (firmware et toute l'infra userspace).
PulseAudio n'est pas forcément lourd, il est surtout crade et assez mystique dans son fonctionnement, mais risque fortement de devenir "la base", dmix étant sur le point de passer deprecated. (CF skype qui change d'interface)
Firefox est aussi en train de changer de gestionnaire de conteneur très certainement pour avoir une interface compatible pepper.

Le souci est réglé en revenant à Firefox-29 (désolé du HS du coup).

3.16 out !

Compilation en cours

Installé hier sans souci .
Sinon, (à propos de mon souci avec Firefox), c'est corrigé dans la version 31.

 
tu utilises gentoo ? ( sur ton profil il y a marqué debian )
 

non Debian en effet, mais je récup le .config de mon noyal actuel, et je génère un .deb

edit : j'ai besoin de tester les derniers noyal pour x raisons

D'ailleurs si ça intéresse, pour du Jessie en x64, un deb avec le kernel et l'autre avec les headers : https://cloud.vates.fr/public.php?s [...] 79763e2c2c

http://linuxfr.org/news/sortie-de-linux-3-16
 
Grosse news de linuxfr.org détaillant le kernel 3.16

linuxfr.org
 
XaT

 
S'te régression en visibilité.
En gros, ça revient a avoir juste un gros /proc/cgroups (ou /sys/fs/cgroups a la mode redhat), plus du tout de sous dossiers par contrôle. En gros, moi qui gère une bonne partie de mes cartes et synchros via cgroups a l'ancienne, ça va être la grosse merde quand j'aurai 10 devices portant le même nom ... C'est sur que casser les interfaces kernel qui vont bien pour traquer les processus après avoir mis en avant leurs super logs de la mort qui tue ... Heureusement que c'est du devel parce que je sent le patch a la barbare chez moi pour conserver le comportement hiérarchisé. Si je chope le mec qui fait passer le commit, je lui fait bouffer ses roustons (Greg, si tu m'entend, te voilà prévenu.)

As-tu lu http://lwn.net/Articles/601840/ ?
Il y a le passage (à priori assez foutrement mal traduit dans l'esprit sur lfr, étonnant d'habitude les report kernel sont bons) :
 

 
Déjà pour avoir la nouvelle hiérarchie, faut la forcer, et ce n'est pas pour demain que le montage sera celui par défaut, ce qui n'empecherait pas d'avoir si certains font des retours dans ce sens (et pas en les traitant d'idiots) d'avoir un type de montage genre mount -t cgroup -o __OLD__behavior cgroup <mount-point> pour garder l'existant.
 
Cependant, quand je vois aussi cela :
 

 
J'ai tendance à dire que sois tu te réveilles tard, soit tu sur-évalue l'impact réel que ça pourra avoir. Après je suppose que si on leur montre par a+b que dans des cas pas si tordu (le tiens) est bien ça fout la merde, il pourrait y avoir des retouche dans la migration. Mais surtout ça donne aussi l'impression que ce n'est vraiment pas un truc commité à l'arrache comme parfois ils savent le faire, et qu'on est llooiinnnn d'un diktak pro-RH comme tu sembles encore le penser (ton aversion anti-systemd et anti-RH est parfois un peu ... déplacée).
 
Donc avant de vouloir te lancer dans la cuisine expérimentale, certains ne manqueront pas de te rappeler que ça date de plus de 2 ans cette refonte et qu'ils ne t'ont peut être pas entendu exprimer tes réserves sur cette nouvelle façon de faire, surtout si c'est un truc que tu utilises souvent et fortement.

 
Attend attend, j'ai bien écrit que pour l'instant c'est en devel, c'est donc une option, qui est mise en place via un mount, et encore a condition de compiler ton kernel en devel. Le "rebuild" en lui même n'est pas si récent, en fait, c'est pas un rebuild mais une implémentation de quand les cgroups eux même ont été implémentés. Il a été demandé qu'il y ai deux lignes disponibles : une ligne configurable via scripts pour les admins avec une gestion fine possible et un trie hiérarchique en fonction des critères, et une ligne configurable via outils userspace, sauf que là, on commence a parler de retirer la possibilité d'avoir quelque chose de compréhensible. Après certes, rien n'est uniformisé. Mais faire une uniformisation horizontale comme ça un peu a l'arrache, et vouloir la rendre mandatory parce qu'un outils qui devrait se cantonner a l'userspace pourra mettre en place ses propres contrôleurs, bof bof.
De toutes façon, comme j'ai dit également, au moins moi, irai forker cette partie du kernel et ferait mes patchs (c'est déjà lourdement patché pour avoir des arrangements CPU, et des links mémoires assez sauvage pour optimiser ZFS et les contrôleurs IB) si j'arrive plus a faire mes scripts et régler comme j'ai envie mes synchros et mes usages process.

C'est le coté "à l'arrache" qui me semble totalement exagéré : le truc est en gestion depuis début 2012, il y a eu pas mal de comm dessus sur la façon dont ils pensaient le faire, et aussi une intégration 2 fois repoussée.
 
Ca me fait penser plutôt à du iptable / nftable, le premier va encore survivre un bon paquet de temps (malheureusement), même si les cgroups ce n'est pas le truc autant utilisé de façon visible d'un point de vue user. Ils peuvent difficilement balancer l'existant, surtout avec la montée en puissance de l'utilisation de plus en plus des cgroups.
 
Bon courage pour les patchs, ptete que tout n'est pas à jeter dans https://git.kernel.org/cgit/linux/k [...] 0765d0ad05

 
Le truc qui me fait penser que c'est fait plus ou moins a l'arrache, c'est que le main dev de la refonte précise bien : https://www.kernel.org/doc/Document [...] rarchy.txt

 
Et moi, voir des interfaces aller exposer les cgroups en userland, bof surtout le PID1.

 
Humm, j'ai tendance à lire l'inverse en fait : la version "hiérarchisée" va demander un support de capabilities (voir man 7 capabilities pour plus d'infos) pour éviter d'en exposer "trop" pour le userland comme ça serait le cas maintenant. Enfin c'est ce qui est mis au début de la section 5.1 de la doc que tu cites. J'ai l'impression que ce que tu cites est justement un état des lieux actuel, mais bon d'un autre coté, je n'ai pas fait LEA à la fac, donc ma perception est peut être erronée

 
Justement, je dit bien que des fonctions cgroups exposées en userland, bof. Sauf que le CAP n'est pas actuellement mis en place et ne le sera pas. L'autre soucis majeur que je vois pointer c'est que si tu as la main sur le "nouveau root" (l'initramfs) qui charge ton PID1, ben avec les cgroups, tu peu introduire des modifications kernel quasiment invisibles, et le soucis du PID1 que tu sais que je dénigre, c'est qu'il est foutrement mal configuré sur 99% des systèmes actuels. Avec les cgroups tu peut littéralement faire disparaître des radars un process hein, alors certes, avant c'était pas top, mais là ...   (voir pire, un container LXC actuellement peu faire du privileged escalation tellement c'est bien foutu leurs isolation <_< )
Bref, on commence vaguement a avoir le pire du pire niveau scénario qui se profil.

Je ne vois vraiment pas de quel PID1 tu veux parler    
Et pourquoi ils n'utiliseront pas cap ? Enfin globalement, j'ai quand même l'impression qu'ils veulent corriger le tir avec les cgroups, dont il faut bien une interface minimale pour le suerland si on veut quand même s'en servir non ? Sur ce, à demain !