Reprise du message précédent :
Ok, l'erreur vient bien du powernow (si je compare les logs) :  

Bref, dans 1 cas, l'initialisation ne se fait pas.

 
Le Hurd n'est pas un noyau. Le noyau sur lequel on essayait de le porter s'était L4. Maintenant c'est Coyotos, enfi de toute façon le Hurd est mort.

Pour ceux qui s'intéressent à la branche 2.6.16.y (branche stable).
Sortie du 2.6.16.21:
 
http://www.kernel.org/pub/linux/ke [...] -2.6.16.21

Euh le 2.6.17.1 fait parti de la branche stable nan ?

 
Ben les deux peuvent être considérés comme stables non ?  
 
Maintenant je ne crois plus qu'il faut parler de branche stable, juste de la branche 2.16.x. Ca me semble plus logique.

Au niveau de la numérotation du noyau, si je me goure pas, le premier numéro correspond à la version, le second à la branche (pair pour les branches stable, impair pour les branches de développement), le troisième à la révision de branche et le quatrième au correctif de révision.
 
Donc : 2 (version) . 6 (branche) . 17 (révision) . 1 (correctif)
 
 
Par conséquent, n'importe quel noyau numéroté 2.4.x ou 2.6.x.x est implicitement stable, les versions instables étant 2.3.x., 2.5.x ou la future 2.7.x

 
Non, cette numérotation a été zappée.
Il n'existe plus de branche stable/développement, avec les numéros paris/impairs.
C'est pour cela que beaucoup se plaignent que linus ne veut pas stabiliser le noyau, et que le release (en ce moment 2.6.17.1) n'est pas stable.
Un gars (Adrian Bunk) a donc décidé de lancer une branche -stable (2.6.16.y), qui n'incorporerait que les corrections de bugs/failles de sécurité), particulièrement adaptée aux serveurs.
La 2.6.16.y va donc continuer (c'est pour ça qu'on a eu un 2.6.16.21 après 2.6.17) tant qu'elle vivra, ensuite elle se resynchronisera sur la courante.
Je trouve que c'est une super bonne idée, surtout pour une machine en prod.
J'ai posté sur debian-kernel pour savoir s'ils compaient supporter cette branche, on m'a répondu à côté.  

Personne n'a de souci de température processeur avec le 2.6.17 ?

non  

 
non plus

Hum, bizarre alors (je suis en amd64, kt800, le reste cf config).

Moi je n'ai plus que les températures des disques.
J'ai une DFI Lan Party 4 avec un 3000+

Ok, c'est juste la température processeur qui est élevée pour ma part (le reste, c'est ok, comme d'hab ).
 
Sinon, la mobo, c'est une Gigabyte K8VT800 Pro avec un 3400+.

Voila le message quand je tape un sensors.

Je n'ai pourtant touché à rien dans la section I2C.
 
Autre chose, depuis la mise à jour je perds l'usage de mon clavier et de ma souris tout deux en USB. Je suis obligé de débrancher et rebrancher pour récupérer les deux.
J'ai déinstaller udev pour voir et ça à l'air de fonctionner correctement.
udev merderait donc avec le 2.6.17.1 ?

2.6.16.22 out sinon .
 

Oki merci pour ces précisions    
 
 

C'est-à-dire    Ils s'en tiennent uniquement aux dernières versions upstream officielles ?
 
Sinon je dois dire que j'ai depuis la version 2.6.3 abandonné les versions vanilla pour n'utiliser que les versions de noyau packagées et patchées par Debian avec une certaine satisfaction puisqu'à mon niveau je n'ai pas encore rencontré de problème majeur avec celles-ci (contrairement à certaines versions vanilla qui parfois déconnaient).

 
Voilà porquoi je n'utilise plus les kernels vanilla, spécialement quand ils viennent de sortir.
C'est une grosse source de problème, à cause des versions de udev, pcmciautils/cs, les scripts d'init.
 

 
Pour Debian, je n'en sais rien. Le mec m'a renvoyé vers un wiki qui n'est pas à jour, et ne m'a pas dit s'ils allaient supporter cette branche.
Pour vanilla, y'a en plus l'avantage que Debian patche ses noyaux (ajout de pwv par exemple), ça évite d'avoir à le faire soi-même.
 
Enfin c'est vrai que je trouve qu'il faudrait vraiment stabiliser le développement du noyau, ou alors utiliser la branche 2.6.16.y

 
Justement pour ma culture perso ... ils patchent quoi dans le noyal chez Debian ?

Je n'ai pourtant touché à rien dans la section I2C.  

Autre chose, depuis la mise à jour je perds l'usage de mon clavier et de ma souris tout deux en USB. Je suis obligé de débrancher et rebrancher pour récupérer les deux.
J'ai déinstaller udev pour voir et ça à l'air de fonctionner correctement.
udev merderait donc avec le 2.6.17.1 ?
Aucun pb avec de mon cote.
Pour les modules i2c, tu les as bien reinstalles si tu utilises l'i2c externe et non celui du kernel?

La derniere fois que j'avais regarde, ils viraient juste les firmwares proprietaires

le kernel comporterait des firmwares propriétaires ?
(ou tu confonds avec l'ajout chez ubuntu des firmwares propriétaires )

http://lwn.net/Articles/130700/

ok.

Bonjour,
 
Quelqu'un a testé swsusp3 ? http://lwn.net/Articles/153203/  
 
Normalement, il est maintenant dans le 2.6.17.
 
Des feedback ?

 
Où vois-tu que c'est _dans_ le noyau ?
J'ai seulement vu qu'un patch était disponible (datant de 2005).
Sinon je veux bien essayer dès que le 2.6.17 sera dispo pour debian.
 
ps : j'utilise déjà suspend2.

Euh j'ai rien touché à la configuration dans le noyau à ce sujet la.
J'ai réutilisé le même .config

 
tu trouveras l'information là-dedans:
http://wiki.kernelnewbies.org/LinuxChanges
 
Et le 2.6.17 est dispo pour debian depuis la dernière mise à jour.

2.6.17 ? Je n'ai vu qu'un 2.6.16+2.6.17rcX et un 2.6.17 pour powerpc sur pdo... Je regarde ca plus précisément, c'est surement une blague de pdo encore

 
pdo est mis à jour en retard par rapport aux ftp. C'est la même chose pour les changelog.  
 
C'est un peu chiant quand tu mets à jour qq minutes après le ftp mais je ne vais pas le plaindre, j'ai qu'à attendre.
 
Edit: je parle des sources. Les binaires ne sont pas encore là

Ah ok, donc les sources etait bien présentes, mais je vais pas m'amuser à compiler un kernel, trop loin

les images arrivent ce soir  

Vous l'avez l'air bien au courant

Je lis les journaux : http://incoming.debian.org/  
 
Edit: quelqu'un sait quand splashy arrive dans Sid ?

Moé
 
Ferait bien de sortir un linux-image-x.y.z-skas3

quand il aura quitté experimental ?

 
Où il n'aurait jamais du entrer...

pour le problème du vbi c'est le develo de zapping qui a changé l'offset qui était par defaut dans le code : il l'a passé de 244 à 144 conclusion tous les softs qui utilisent le vbi marchent plus (sauf zapping je suppose).
l'auteur de AleVT a remonté le pb et le mec de zapping dit qu'il a raison et pas l'autre ..... je vous épargne les échanges d'email.
j'ai donc contacté l'auteur d'AleVT qui m'a donné un patch pour AleVt et donc pour XdTV aussi. Je 'lai depuis commité dans notre CVS.
je suppose que pour nxtvepg il faudrait aussi faire le boulot et forcer la valeur de l'offset vbi à 244 comme il l'était avant les modfis du noyau 2.6.16 et supp (c'est aussi vrai pour le 2.6.17).
a suivre
 
Pingus

et voici le solution de l'auteur Tom'
 
"Appearently the driver is reporting invalid VBI parameters. When using the specified offset (to skip the sync pulse at the start of each TV line) nxtvepg will read slightly beyond the end of each teletext line. This probably won't cause any harm though, hence as a temporary solution you can just comment out lines 680 to 689 in file epgvbi/zvbidecoder.c (i.e. put /* before and */ after them)  
 
-tom "

donc il me sembe qu'on se ré-oriente vers une modification des logiciels ayant a capturer des données vbi afin d'être en accord avec la nouvelle méthode de capture ?

oui puisque le mec qui a modifié dans le code du kernel ne veut pas revenir sur son code.
lit donc ca c'est assez pathétique:
 
http://lists.zerezo.com/video4linux/msg10694.html
 
Pingus

on y ajoute un soupçon de documentation pas forcément très explicite et on se retrouve avec un beau merdier...